Stuck (Vol.1 2.6 CUCM DHCP)

I am stuck trying to complete task 2.6.  UCM, 3750, and R1 are all configured according to specification.  The phones at HQ acquire DHCP, register, and all is well. Where I am stuck is br1. br1 is configured according to the solution but the phones (two 7965) will not acquire DHCP from UCM.  I temporarily moved an HQ phone that successfully registers at HQ to the HWIC-ESW on br1 and it will not acquire DHCP.  

I realize there is a massive amount of check-list items.  I can ping from br1 vlan 11 to the server at HQ which means the WAN is working fine. I have triple checked the DHCP config for br1 on UCM and it contains the appropriate information for br1's IP network.  Below are output from br1.  Are there any debugs or other tools I can use to see what is happening when the phones boot?

 

 

interface FastEthernet0/1/0

 description == BR1 IP Phone

 switchport access vlan 12

 switchport mode trunk

 switchport voice vlan 11

 spanning-tree portfast

!

interface FastEthernet0/1/1

 description == BR1 IP Phone

 switchport access vlan 12

 switchport mode trunk

 switchport voice vlan 11

 spanning-tree portfast

!


interface Vlan11

 description == Voice VLAN

 ip address 177.2.11.1 255.255.255.0

 ip helper-address 177.1.10.10

!         

interface Vlan12

 description == Data VLAN

 ip address 177.2.12.1 255.255.255.0

!



r2-br1#show cdp neigh

Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge

                  S - Switch, H - Host, I - IGMP, r - Repeater


Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID

SEP002290BA2ECC  Fas 0/1/1          134           H       IP Phone  Port 1

SEP002290BA2CB6  Fas 0/1/0          153           H       IP Phone  Port 1

r1-hq            Ser 0/0/1:0.1      152         R S I     2811      Ser 0/0/1:0.1

r2-br1#



 

 

 

r2-br1#ping 177.1.10.10 source vlan 11

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 177.1.10.10, timeout is 2 seconds:

Packet sent with a source address of 177.2.11.1 

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms

 

 

 

r2-br1#trace 177.1.10.10 source vlan 11

Type escape sequence to abort.

Tracing the route to 177.1.10.10

  1 177.0.101.1 8 msec 4 msec 8 msec

  2 177.1.10.10 4 msec 8 msec 4 msec

 

 

UCM DHCP

 

Comments

  • interface FastEthernet0/1/0
     description == BR1 IP Phone
     switchport access vlan 12
     switchport mode trunk
     switchport voice vlan 11
     spanning-tree portfast

    Although I don't think that your configuration will neccessarily have problems, but it is not standard method. Here is the configuration:



     

    interface FastEthernet0/1/0
     description == BR1 IP Phone
     switchport mode trunk
     swtchport trunk native vlan 12

     switchport voice vlan 11
     spanning-tree portfast

     

    Shutdown your ports to the IP phone and no shout them when you finished the configration.
  • Hello Mark,

     

    As Jordan indicated, when using the HWIC switch module in R2, you should use the switchport trunk native vlan syntax. This should resolve your issue. If not, please let us know.

     

    Thanks!

  • That didn't seem to make any difference.  I'm running out of ideas at this point.  Do you guys have any other suggestions?  I posted my br1 config here.  I actually do not think it is specific to DHCP.  If I move one phone to HQ and let it auto register then move it back to br1, it boots and because it cannot acquire DHCP it tries to use the previously assigned DHCP address and is stuck 'Registering'.  This tells me that both DHCP and TFTP are not working correctly from br1.  This is strange, because I can ping pub/sub fine from 177.2.11.1.

     

     

    interface FastEthernet0/1/0

     description == BR1 IP Phone

     switchport trunk native vlan 12

     switchport mode trunk

     switchport voice vlan 11

     spanning-tree portfast

    !

    interface FastEthernet0/1/1

     description == BR1 IP Phone

     switchport trunk native vlan 12

     switchport mode trunk

     switchport voice vlan 11

     spanning-tree portfast

    !

     

  • I executed tshark on the Linux server running VMWare and it looks like the DHCP requests are arriving from br1 phones towards UCM but there is no response from the server. I removed the DHCP subnet and added it again but that did not make a difference.  I am pulling hairs at this point.

     


    [[email protected] ~]# tshark udp port bootps

    Capturing on eth0

      0.000000   177.2.11.1 -> 177.1.10.10  DHCP DHCP Discover - Transaction ID 0x565f

     23.615495   177.2.11.1 -> 177.1.10.10  DHCP DHCP Request  - Transaction ID 0x5686

     32.001650   177.2.11.1 -> 177.1.10.10  DHCP DHCP Discover - Transaction ID 0x565f

     87.620370   177.2.11.1 -> 177.1.10.10  DHCP DHCP Discover - Transaction ID 0x5686

     91.614048   177.2.11.1 -> 177.1.10.10  DHCP DHCP Discover - Transaction ID 0x5686

     

     

  • While the two br1 phones were continuing their attempt to acquire an IP I rebooted an HQ phones.  I noticed the HQ router sends a DHCP request and there is an immediate ACK from PUB.  Why would br1 send DHCP Discover constantly? It sends a DHCP request periodically as well and it seems as if UCM just ignores it.

     

     

      0.000000   177.2.11.1 -> 177.1.10.10  DHCP DHCP Discover - Transaction ID 0x14bf

      8.948138   177.2.11.1 -> 177.1.10.10  DHCP DHCP Discover - Transaction ID 0x565f

     12.947827   177.2.11.1 -> 177.1.10.10  DHCP DHCP Discover - Transaction ID 0x565f

     17.399485   177.1.11.1 -> 177.1.10.10  DHCP DHCP Request  - Transaction ID 0x5686

     17.406133  177.1.10.10 -> 177.1.11.1   DHCP DHCP ACK      - Transaction ID 0x5686

     17.406157  177.1.10.10 -> 177.1.11.1   DHCP DHCP ACK      - Transaction ID 0x5686

     20.948189   177.2.11.1 -> 177.1.10.10  DHCP DHCP Discover - Transaction ID 0x565f

     23.606405   177.1.11.1 -> 177.1.10.10  DHCP DHCP Request  - Transaction ID 0x5686

     

  • Did you run 
    utils csa disable
    on the CUCM server?


    On Dec 1, 2009, at 9:09 PM, MarkH wrote:

    I executed tshark on the Linux server running VMWare and it looks like the DHCP requests are arriving from br1 phones towards UCM but there is no response from the server. I removed the DHCP subnet and added it again but that did not make a difference.  I am pulling hairs at this point.

     

    [[email protected] ~]# tshark udp port bootps

    Capturing on eth0

      0.000000   177.2.11.1 -> 177.1.10.10  DHCP DHCP Discover - Transaction ID 0x565f

     23.615495   177.2.11.1 -> 177.1.10.10  DHCP DHCP Request  - Transaction ID 0x5686

     32.001650   177.2.11.1 -> 177.1.10.10  DHCP DHCP Discover - Transaction ID 0x565f

     87.620370   177.2.11.1 -> 177.1.10.10  DHCP DHCP Discover - Transaction ID 0x5686

     91.614048   177.2.11.1 -> 177.1.10.10  DHCP DHCP Discover - Transaction ID 0x5686


     
     



    Internetwork Expert - The Industry Leader in CCIE Preparation
    http://www.internetworkexpert.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • Can you post a screenshot of the HQ subnet that works properly?

  • Mark,

    Can you please also post a screenshot of your HQ DHCP Subnet as you did your BR1 scope?

    Thanks.



    On Dec 1, 2009, at 9:15 PM, MarkH wrote:

    While the two br1 phones were continuing their attempt to acquire an IP I rebooted an HQ phones.  I noticed the HQ router just sends a DHCP request and thee is an immediate ACK from PUB.  Why would br1 send DHCP Discover as opposed to DHCP request?

     

      0.000000   177.2.11.1 -> 177.1.10.10  DHCP DHCP Discover - Transaction ID 0x14bf

      8.948138   177.2.11.1 -> 177.1.10.10  DHCP DHCP Discover - Transaction ID 0x565f

     12.947827   177.2.11.1 -> 177.1.10.10  DHCP DHCP Discover - Transaction ID 0x565f

     17.399485   177.1.11.1 -> 177.1.10.10  DHCP DHCP Request  - Transaction ID 0x5686

     17.406133  177.1.10.10 -> 177.1.11.1   DHCP DHCP ACK      - Transaction ID 0x5686

     17.406157  177.1.10.10 -> 177.1.11.1   DHCP DHCP ACK      - Transaction ID 0x5686

     20.948189   177.2.11.1 -> 177.1.10.10  DHCP DHCP Discover - Transaction ID 0x565f

     23.606405   177.1.11.1 -> 177.1.10.10  DHCP DHCP Request  - Transaction ID 0x5686





    Internetwork Expert - The Industry Leader in CCIE Preparation
    http://www.internetworkexpert.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • Seems like your CUCM DHCP configuration problem. Make sure there should be two seperate DHCP pools in this case. One for HQ and the other for Br1, and make sure every paramter are correctly set.


    2009/12/2 MarkH <[email protected]>

    While the two br1 phones were continuing their attempt to acquire an IP I rebooted an HQ phones.  I noticed the HQ router just sends a DHCP request and thee is an immediate ACK from PUB.  Why would br1 send DHCP Discover as opposed to DHCP request?

     


      0.000000   177.2.11.1 -> 177.1.10.10  DHCP DHCP Discover - Transaction ID 0x14bf

      8.948138   177.2.11.1 -> 177.1.10.10  DHCP DHCP Discover - Transaction ID 0x565f

     12.947827   177.2.11.1 -> 177.1.10.10  DHCP DHCP Discover - Transaction ID 0x565f

     17.399485   177.1.11.1 -> 177.1.10.10  DHCP DHCP Request  - Transaction ID 0x5686

     17.406133  177.1.10.10 -> 177.1.11.1   DHCP DHCP ACK      - Transaction ID 0x5686

     17.406157  177.1.10.10 -> 177.1.11.1   DHCP DHCP ACK      - Transaction ID 0x5686

     20.948189   177.2.11.1 -> 177.1.10.10  DHCP DHCP Discover - Transaction ID 0x565f

     23.606405   177.1.11.1 -> 177.1.10.10  DHCP DHCP Request  - Transaction ID 0x5686




    Internetwork Expert - The Industry Leader in CCIE Preparation
    http://www.internetworkexpert.com

    Subscription information may be found at:


    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • Here are the screenshots.  I did execute 'utils csa disable' but that did not solve my issue.  I'm brainstorming as much as I can but I think I will call it quits until tomorrow morning. [:|]

     

    HQ Subnet

     

    DHCP Server

  • Try changing your "Subnet IP Address" field for BR1 from 177.2.11.1 to 177.2.11.0 ?




    On Dec 1, 2009, at 9:47 PM, MarkH wrote:

    Here are the screenshots.  I did execute 'utils csa disable' but that did not solve my issue.  I'm brainstorming as much as I can but I think I will call it quits until tomorrow morning. Indifferent

     

    HQ Subnet

     

    DHCP Server




    Internetwork Expert - The Industry Leader in CCIE Preparation
    http://www.internetworkexpert.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • Changing the last to octet from .1 to .0 does not fix it.  The Configuration guide shows .1 and it works for HQ.  I have followed the guide word for word and tried the task on both CUCM 7.0 and 7.1.3 and end up with the same results. I may be overlooking something but at this point I am wondering if there is something missing either from one of the configs or in CUCM, although I have checked CUCM against the task configuration many times and it matches. 

    Is it possible for someone from INE to perform the task configuration and do a sanity check to make sure it does work?

  • Jordon,

    The configuration for the task shows "switchport access vlan 12" as the appropriate switch port config for br1. I realize using the native vlan statement is preferred but by the time I could not get DHCP to work for br1 I decided to match the task's configuration to be sure I wasn't doing anything incorrectly.  Thanks for the recommendation.

  • Hey Mark,

     

    I'm sure that you've already tried this, but have you confirmed that the phone is in fact looking for DHCP, and does not have a static address? Also, have you tried shutting the port down, leaving it for a little while, then bringing it back up, and checking the status messages on the phone?

     

    Finally, you may want to try using R2 as a temporary IOS dhcp server, allowing the phone to get an IP, then checking to ensure that you can ping that phone from the CUCM server.

     

    HTH

  • Josh,

    I am absolutely 100% certain the phones are looking for DHCP.  The tshark packet capture on the 3750 (port mirror) shows the phones from br1 sending their DHCP request to PUB (DHCP Discover, DHCP Request, coming from 177.2.11.1). I can physically move the phones from br1 to HQ's 3750 switch and they come up fine.  I've done factory resets, erase network config, you name it and I've tried it.  

    At this point I am going to move on to the next lab.  I am confident at some point I will come across something that uncovers the mystery.  I appreciate everyone's time.

     

  • here is your sanity check: you're not alone.

     

    i even had the same problem when i changed to using IOS dhcp

     

    if you do debug ip dhcp packets/events on r2 you will see that the phone just keeps sending requests (not even discovers, as it already has an address and it wants to renew).

     

    even when R2 is the dhcp server it will NOT reply.

     

    2 ways i got past this:

     

    1. factory reset the phone (since you are using internetworkexpert racks, just ask support go in and do it)

    2. this one is very tedious but it worked:

     

    --i used IOS dhcp on r2

    --then made a reservation (basically a pool with only 1 address that references the phones MAC)

    --phone is happy, it gets the address

    --then i delete the pool

    --phone gets sent a NACK and loses its lease

    --phone then behaves like a good phone and communicates normally, no matter which dhcp you use.

     

    not sure if creating a 1-cleint subnet in CUCM DHCP is possible or even works the same, but this is how i won this war.

     

     

     

  • Aquabrown, thanks for sharing.  At least I know it isn't just me.  I moved my br1 phones over to my CME router and configured them as ephones and they came up right away. The problem seems isolated to phones that need DHCP from CUCM over the WAN, but I'm not sure where the real source of the issue resides. What model phones are you using?  I am using 7965's.  

  • This was all on the internetworkexpert racks.

  • Aquabrown,

    I moved on to lab 2.7 and I did not have any problems when br1 is configured with IOS DHCP.  My phones auto registered with PUB very quickly.  I had the lab knocked out within minutes. I am not going to give up on isolating the root cause of the DHCP problem.  Not sure when I'll get around to it though.

     

  • If your problem is still, maybe I didn't put it clearly. Since I didn't see Br1 subnet on your sreenshot, I assume that you didn't make it. You should set TWO seperate subnets on the CUCM. It means you set one subnet, 177.1.11.0, for HQ, and then copy it, make it another subnet, 177.2.11.0, make sure change every prameter needed, for Br1. 



     

    You may wonder why? Because your BR1 gateway ip address is 177.2.11.1, you've got to gain 177.2.11.0/24 for the phones in BR1. And the DHCP would not send ip address other than 177.2.11.0 to your BR1 phones. Maybe you would like to have 177.1.11.0/24 for your Br1 phones, it's OK. You can disconnet them from R2 and connect them to SW1. Is that clear?




    2009/12/3 MarkH <[email protected]>

    Aquabrown, thanks for sharing.  At least I know it isn't just me.  I moved my br1 phones over to my CME router and configured them as ephones and they came up right away. The problem seems isolated to phones that need DHCP from CUCM over the WAN, but I'm not sure where the real source of the issue resides. What model phones are you using?  I am using 7965's.  





    Internetwork Expert - The Industry Leader in CCIE Preparation
    http://www.internetworkexpert.com

    Subscription information may be found at:


    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • Thanks, Jordan.  I had two DHCP subnets in UCM PUB from the very start. It's something beyond the scope of this discussion since Aquabrown appears to have experienced the same problem.  I appreciate your input and I'm sure I could use your help for upcoming tasks as well.  Thanks again!

     

  • Glad you didn't face any additional issues there. I dont know what got into my phones then!!

     

    At any rate we've all picked up lots of other "little things" to be on the lookout for.

     

    Hope you get to the bottom of it soon ! :)

Sign In or Register to comment.