Please help! DHCP is not working on my new VLAN.

[alissa.owsley]

Good afternoon,

I am working with a portion of network that consists of two switches, two routers, and one firewall out to the world.  I set up a new VLAN and as long as the PC connected to the interface has a static IP set, I can get out to the world.  As soon as I try to use DHCP on the PC it losses Internet and holds a 169.X.X.X address indicating the lack of DHCP (in my mind).  Everything is in line in a router-on-a-stick topology:

From CC Router:

!

ip cef

no ip dhcp use vrf connected

ip dhcp excluded-address 172.16.30.1 172.16.30.9

ip dhcp excluded-address 192.168.40.1 192.168.40.19

!

ip dhcp pool VOICE

   network 172.16.30.0 255.255.255.0

   default-router 172.16.30.1 255.255.255.0

   dns-server 192.168.199.7

   option 150 ip 172.16.20.21

   lease infinite

!

ip dhcp pool PUBLICACCESS

   network 192.168.40.0 255.255.255.0

   default-router 192.168.40.1 255.255.255.0

   dns-server 192.168.199.7 192.168.200.4

   lease infinite

!

.................

interface GigabitEthernet0/0

description LAN

no ip address

duplex auto

speed auto

!

interface GigabitEthernet0/0.1

description DATA VLAN

encapsulation dot1Q 1 native

ip address 192.168.199.1 255.255.255.0

no snmp trap link-status

!

interface GigabitEthernet0/0.20

description VOICESERVER VLAN

encapsulation dot1Q 20

ip address 172.16.20.1 255.255.255.0

no snmp trap link-status

!

interface GigabitEthernet0/0.30

description VOICE VLAN

encapsulation dot1Q 30

ip address 172.16.30.1 255.255.255.0

no snmp trap link-status

h323-gateway voip interface

h323-gateway voip bind srcaddr 172.16.30.1

!

interface GigabitEthernet0/0.40

description Public Access VLAN

encapsulation dot1Q 40

ip address 192.168.40.1 255.255.255.0

ip helper-address 192.168.200.1

no snmp trap link-status

The PUBLICACCESS pool is the one that I am trying to use.  I currently have it set in almost exactly the same way on the HH Router because I thought it might need to be on the second router and make use of the ip helper-address cmd on the first.  I do wonder if part of my problem is not knowing which interface address to point to with that command.  I tried applying it to G0/0.40 and pointing it to the VLAN 1 interface (G0/0.1) on CC Router as well as the VLAN 1 interface on HH Router.  I am happy to supply more information if needed.

Any help that anyone can give me is greatly appreciated.  This is my first go at DHCP and I am stuck.  Hopefully this make sense.

Thanks very much,

A.O.

[John Blakley · Accepted solution]

Alissa,

I'm assuming that the CC router is the one that's handing out addresses. If that's the case, remove the "ip helper" statement from g0/0.40 and try again.

The dhcp request is going to come in on g0/0.40 for those hosts that are part of that vlan. With the helper address, you're telling it to go to that address to have an address assigned.

HTH,
John

*** Please rate all useful posts ***

[alissa.owsley]

Thanks John,

I had it setup that way originally and it didn't work.  Setting up DHCP on the HH Router and using the ip helper-address was the second attempt at making it work.  I can change it back to DHCP on CC Router with no ip helper statement if that is best practice.  Anything else that I might be missing?

Thanks again for the quick response and the direction!

[John Blakley]

So, if you statically assign an address in 192.168.40.0/24 subnet, and make your port an access port of vlan 40 on the CC switch, does it work? You don't need the helper address on unless you need to get your addresses from a different subnet that what you come in on.

HTH,
John

*** Please rate all useful posts ***

[alissa.owsley]

Thank you for sticking with me John!

If I set up the PC with a static IP of 192.168.40.40 /24 and a default gateway of 192.168.40.1 everything works exactly like it is supposed to.  As soon as I tell the PC to obtain the IP address by DHCP I lose Internet connectivity.

Is the DHCP pool accessible to all of the subnets on the router?  If so, you are right that I don't need it.  Originally, I created the DHCP pool PUBLICACCESS on CC Router and did not use the ip helper-address and it didn't work.  I then went on a search for configuration that I might have missed and couldn't find anything other than using the ip helper-address command, so I played with that.

Any ideas what could keep the router from giving out addresses to the 192.168.40.0 /24 network?  Is there any configuration that needs to happen on the subinterface or switches to allow a new DHCP pool to come through?  Might be worth mentioning that DHCP for the other subnet is working.

Here is current config:

!

ip cef

no ip dhcp use vrf connected

ip dhcp excluded-address 172.16.30.1 172.16.30.9

ip dhcp excluded-address 192.168.40.1 192.168.40.19

!

ip dhcp pool VOICE

   network 172.16.30.0 255.255.255.0

   default-router 172.16.30.1 255.255.255.0

   dns-server 192.168.199.7

   option 150 ip 172.16.20.21

   lease infinite

!

ip dhcp pool PUBLICACCESS

   network 192.168.40.0 255.255.255.0

   default-router 192.168.40.1 255.255.255.0

   dns-server 192.168.199.7 192.168.200.4

   lease infinite

!

..........................................................................

!

interface GigabitEthernet0/0.40

description Public Access VLAN

encapsulation dot1Q 40

ip address 192.168.40.1 255.255.255.0

no snmp trap link-status

Thanks again!

[kcnajaf · Accepted solution]

Hi Alissa,

Since with the static ip address it is working fine that means the L2 path is clear between your router and pc.

Try enabling “debug ip dhcp events or debug ip dhcp server” on router and see if the dhcp requests are coming to router.

Regards

Najaf

Please rate when applicable or helpful !!!

[paulstone80]

Hi,

Have you tried creating a vlan 40 interface and moving the IP from Gi0/0.40 to the vlan interface?

Example

interface vlan 40

description Public Access VLAN

ip address 192.168.40.1 255.255.255.0

HTH

Paul    

[John Blakley]

At this point, I agree with Najaf. If you can put yourself in vlan 40 and it work, then your vlan tagging is working up to the router. Can you debug dhcp and see if you're getting to it? As far as your question about all subnets being accessible, yes, if the router has a pool that matches a source request (192.168.40.0/24 in this case) it will assign an address from that pool. Since the 192.168.40.0 network is on this router, there's no need to have the helper address configured.

Try "debug ip dhcp server events". What type of router is this and ios version?

HTH,
John

*** Please rate all useful posts ***

[alissa.owsley]

Thanks so much everyone, I am sorry for the delay.  I ran the "debug ip dhcp server events" command and received no feedback from the router.  What could stop the requests from getting there?  I don't have any access-lists setup right now.

The router is a Cisco 2821 (revision 53.50)

Cisco IOS Software, 2800 Software (C2800NM-SPSERVICESK9-M), Version 12.4(3g), RELEASE SOFTWARE (fc2)

ADSwitch is a Cisco WS-C3560-48PS

Cisco IOS Software, C3560 Software (C3560-IPBASE-M), Version 12.2(25)SEB4, RELEASE SOFTWARE (fc1)

and CCSwitch is a Cisco WS-C3560-24PS

Cisco IOS Software, C3560 Software (C3560-IPBASE-M), Version 12.2(35)SE5, RELEASE SOFTWARE (fc1)

Najaf, thank you for verifying that for me. That was the conclusion that I had come to also. Any idea what I can do to get the dhcp requests to reach the router?

Paul, I have that command set on the two switches, but not on the router.  Can you use that command on a router?  I don't recall ever seeing that done.

John, thank you for explaining the helper address to me and for being so helpful! Any ideas?

Thanks so much for your patience and help!

Alissa

[Rolf Fischer]

Hi Alissa,

just some ideas for troubleshooting procedure.

You have already verified that the connectivity client<>gateway works.

So "debug ip dhcp server packets" should  produce some output, you should see DHCP Discovers (Layer 2 broadcasts) from the client.

Is your logging level "debugging" ( show logging | incl level )?

Does "show processes cpu | incl DHCPD" produce some output?

If not: Have you verified that "service dhcp" is enabled?

If everithing looks correct until here, you could check the switches:

- is dhcp snooping enabled ( show ip dhcp snooping )? => If so, the uplinks have to be trusted

- spanning-tree portfast enabled on edgeports (Fa0/13))

A lot of questions, sorry for that.

Best regards

Rolf

P.S.:

useful show-commands on DHCP server:

show ip dhcp server statistics | e _0_

show ip dhcp pool

[paul driver]

1)Make sure the the switches have a trunk between them and are in host mode ( that is not set to routing) and have a default-gateway of the cc router
2) the pc access port is set to the svi of the connecting switch ( in this case vlan 40)

3) the port connecting to the cc router is in the corect vlan ( in this case vlan 40)

4) on the cc router "service dhcp" is enabled

If you are using the vlan40 as the native vlan then apply the "native" keyword to the gig0/0.40 interface

res

Paul

[alissa.owsley]

Thank you Paul,

The network works perfectly if the PC has a static IP set, so I feel like that verifies 1-3, am I wrong?  The router has "service dhcp" enabled and the other pool is working fine.  VLAN 40 is not the native.

[alissa.owsley]

Router Output:

CC-2821#debug ip dhcp server packet

CC-2821#show logging | incl level

    Console logging: level debugging, 248014 messages logged, xml disabled,

    Monitor logging: level debugging, 0 messages logged, xml disabled,

    Buffer logging: level debugging, 242728 messages logged, xml disabled,

    Trap logging: level informational, 139438 message lines logged

CC-2821#show processes cpu | incl DHCPD

117      500500   8649699         57 28.57% 31.06% 30.57%   0 DHCPD Receive

161        2060     34662         59  0.00%  0.01%  0.09%   0 DHCPD Timer

233           0     69330          0  0.00%  0.00%  0.00%   0 DHCPD Database

DHCP snooping is not enabled on either switch

Spanning-tree portfast is enabled on fa0/13

Show logging produces this:

Log Buffer (4096 bytes):

b).

261437: Jan  7 21:01:22.969: DHCPD: unicasting BOOTREPLY to client 089e.012b.a38b (192.168.40.21).

261438: Jan  7 21:01:24.077: DHCPD: Sending notification of DISCOVER:

261439: Jan  7 21:01:24.077:   DHCPD: htype 1 chaddr 089e.012b.a38b

261440: Jan  7 21:01:24.081:   DHCPD: remote id 020a0000c0a82801000000280000

261441: Jan  7 21:01:24.081:   DHCPD: circuit id 00000000

261442: Jan  7 21:01:24.081: DHCPD: DHCPDISCOVER received from client 0108.9e01.2ba3.8b on interface GigabitEthernet0/0.40.

261443: Jan  7 21:01:24.081: DHCPD: Seeing if there is an internally specified pool class:

261444: Jan  7 21:01:24.081:   DHCPD: htype 1 chaddr 089e.012b.a38b

261445: Jan  7 21:01:24.081:   DHCPD: remote id 020a0000c0a82801000000280000

261446: Jan  7 21:01:24.081:   DHCPD: circuit id 00000000

261447: Jan  7 21:01:24.081: DHCPD: Sending DHCPOFFER to client 0108.9e01.2ba3.8b (192.168.40.21).

261448: Jan  7 21:01:24.081: DHCPD: Including FQDN option name 'AMFS_PING_BOOK.aspenmusicschool.com.aspenmusicfestival.local' rcode1=0, rcode2=0 flags=0x0

261449: Jan  7 21:01:24.081: DHCPD: creating ARP entry (192.168.40.21, 089e.012b.a38b).

261450: Jan  7 21:01:24.081: DHCPD: unicasting BOOTREPLY to client 089e.012b.a38b (192.168.40.21).

9:   DHCPD: remote id 020a0000c0a82801000000280000

261543: Jan  7 21:01:29.809:   DHCPD: circuit id 00000000

261544: Jan  7 21:01:29.813: DHCPD: Sending DHCPOFFER to client 0108.9e01.2ba3.8b (192.168.40.21).

261545: Jan  7 21:01:29.813: DHCPD: Including FQDN option name 'AMFS_PING_BOOK.aspenmusicschool.com.aspenmusicfestival.local' rcode1=0, rcode2=0 flags=0x0

261546: Jan  7 21:01:29.813: DHCPD: creating ARP entry (192.168.40.21, 089e.012b.a38b).

261547: Jan  7 21:01:29.813: DHCPD: unicasting BOOTREPLY to client 089e.012b.a38b (192.168.40.21).

261548: Jan  7 21:01:30.593: DHCPD: DHCPREQUEST received from client 0108.9e01.2ba3.8b.

261549: Jan  7 21:01:30.593: DHCPD: Sending notification of ASSIGNMENT:

261550: Jan  7 21:01:30.593:  DHCPD: address 192.168.40.21 mask 255.255.255.0

261551: Jan  7 21:01:30.593:   DHCPD: htype 1 chaddr 089e.012b.a38b

261552: Jan  7 21:01:30.593:   DHCPD: lease time remaining (secs) = -1

261553: Jan  7 21:01:30.593: DHCPD: Appending system default domain

261554: Jan  7 21:01:30.593: DHCPD: Using hostname 'AMFS_PING_BOOK.aspenmusicschool.com.aspenmusicfestival.local' for dynamic update (from FQDN option)

261555: Jan  7 21:01:30.593: DHCPD: Sending DHCPACK to client 0108.9e01.2ba3.8b (192.168.40.21).

261556: Jan  7 21:01:30.593: DHCPD: Including FQDN option name 'AMFS_PING_BOOK.aspenmusicschool.com.aspenmusicfestival.local' rcode1=0, rcode2=0 flags=0x0

3.933: DHCPD: Sending notification of ASSIGNMENT:

261604: Jan  7 21:01:33.933:  DHCPD: address 192.168.40.21 mask 255.255.255.0

261605: Jan  7 21:01:33.933:   DHCPD: htype 1 chaddr 089e.012b.a38b

261606: Jan  7 21:01:33.933:   DHCPD: lease time remaining (secs) = -1

261607: Jan  7 21:01:33.933: DHCPD: Appending system default domain

261608: Jan  7 21:01:33.933: DHCPD: Using hostname 'AMFS_PING_BOOK.aspenmusicschool.com.aspenmusicfestival.local' for dynamic update (from FQDN option)

261609: Jan  7 21:01:33.933: DHCPD: Sending DHCPACK to client 0108.9e01.2ba3.8b (192.168.40.21).

261610: Jan  7 21:01:33.933: DHCPD: Including FQDN option name 'AMFS_PING_BOOK.aspenmusicschool.com.aspenmusicfestival.local' rcode1=0, rcode2=0 flags=0x0

261611: Jan  7 21:01:33.933: DHCPD: creating ARP entry (192.168.40.21, 089e.012b.a38b).

261612: Jan  7 21:01:33.933: DHCPD: unicasting BOOTREPLY to client 089e.012b.a38b (192.168.40.21).

261613: Jan  7 21:01:35.033: DHCPD: Sending notification of DISCOVER:

261614: Jan  7 21:01:35.033:   DHCPD: htype 1 chaddr 089e.012b.a38b

261615: Jan  7 21:01:35.033:   DHCPD: remote id 020a0000c0a82801000000280000

261616: Jan  7 21:01:35.033:   DHCPD: circuit id 00000000

261617: Jan  7 21:01:35.033: DHCPD: DHCPDISCOVER received from client 0108.9e01.2ba3.8b on interface GigabitEthernet0/0.40.

261618: Jan  7 21:01:35.033: DHCPD: Seeing if there is an internally specified pool class:

9: DHCPD: Including FQDN option name 'AMFS_PING_

Looks to me like it is going through the motions, but I am concerned about the "261606: Jan 7 21:01:33.933: DHCPD: lease time remaining (secs) = -1" line.  (I have the leases set to infinite.)

Please explain to me if there is something here that I am missing.  I am obviously a bit new to this stuff!

Thanks so much for the clear response!  I am stepping out of the familiar on this one.

[Rolf Fischer]

 "261606: Jan 7 21:01:33.933: DHCPD: lease time remaining (secs) = -1" line.  (I have the leases set to infinite.)

I can only guess about that. The lease time is represented in units of seconds, and is specified as a 32-bit unsigned integer. An infinite lease means all 32 bit are set to 1 (4294967295 in decimal).

Two's complement representation of an all-ones binary values is -1 (although this wouldn't be unsigned...), and probably the developers found "-1" more handy than "4294967295" in a debug output.

I wouldn't worry about that.

But I wonder why you want to have infinite leases at all?

DHCPD: DHCPDISCOVER received from client 0108.9e01.2ba3.8b on interface GigabitEthernet0/0.40
DHCPD: Sending DHCPOFFER to client 0108.9e01.2ba3.8b (192.168.40.21)
DHCPD: DHCPREQUEST received from client 0108.9e01.2ba3.8b
DHCPD: DHCPACK to client 0108.9e01.2ba3.8b

Looks like expected. Did the client receive it's DHCP information now?

Best regards

Rolf

[paul driver]

If this isnt still working can you please post the config for the two switches.

res

Paul