cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
733
Views
0
Helpful
9
Replies

DHCP on 2821

johnsonk1024
Level 1
Level 1

I think I put this in the wrong forum earlier, so I apologize if anyone is having to read it twice.

Hello,

Recently my 2821 quit issuing DHCP addresses. I have the pool set up for our IP phones, but I can't figure out what is keeping the phones from obtaining an addresses. Their switch ports are configured as follows:

interface GigabitEthernet1/3

switchport

switchport trunk encapsulation dot1q

switchport trunk native vlan 2

switchport trunk allowed vlan 2,3

switchport mode trunk

switchport nonegotiate

switchport voice vlan 3

no ip address

mls qos trust dscp

The VLAN interfaces are configured as:

interface Vlan2

ip address 172.16.36.1 255.255.255.0

!

interface Vlan3

ip address 172.16.136.1 255.255.255.0

ip helper-address 192.168.254.221

Using "debug ip dhcp server packets" I can see dhcp requests coming into the router:

3296854: Sep 21 18:14:47.489: DHCPD: DHCPREQUEST received from client 0004.0de8.bcb3.

3296855: Sep 21 18:14:47.489: DHCPD: Finding a relay for client 0004.0de8.bcb3 through relay 172.16.136.1.

3296856: Sep 21 18:14:47.489: DHCPD: Seeing if there is an internally specified pool class:

3296857: Sep 21 18:14:47.489: DHCPD: htype 1 chaddr 0004.0de8.bcb3

3296858: Sep 21 18:14:47.489: DHCPD: remote id 020a0000c0a8fedd00000000

3296859: Sep 21 18:14:47.489: DHCPD: circuit id 00000000no deb

However, the router never issues a dhcpoffer.

sh ip dhcp server stat

Memory usage 23526

Address pools 1

Database agents 0

Automatic bindings 0

Manual bindings 0

Expired bindings 0

Malformed messages 0

Secure arp entries 0

Message Received

BOOTREQUEST 0

DHCPDISCOVER 0

DHCPREQUEST 2080

DHCPDECLINE 0

DHCPRELEASE 0

DHCPINFORM 0

Message Sent

BOOTREPLY 0

DHCPOFFER 0

DHCPACK 0

DHCPNAK 0

I can post addition information if necessary. Please help if you have seen this before.

9 Replies 9

Richard Burts
Hall of Fame
Hall of Fame

Kendall

This configuration describes a DHCP server at 192.168.254.221. Can you verify IP connectivity from your router to this address (using the VLAN 3 address as the source of your packet)? (extended ping with 192.168.254.221 as the destination and with 172.16.136.1 as the source)

The first thing I would check would be IP connectivity and if that is good the next thing I would check is whether that DHCP server has an appropriate scope defined for subnet 172.16.136.1 255.255.255.0.

Also I am not sure how important it is but the configuration guidelines for configuring voice vlan say that it should be configured on an access port. You have it on a trunk port.

HTH

Rick

HTH

Rick

I am able to ping from 172.16.136.1 to 192.168.254.221, verifying IP connectivity.

The DHCP scope set up for this network is:

ip dhcp excluded-address 172.16.136.1 172.16.136.19

!

ip dhcp pool 1

network 172.16.136.0 255.255.255.0

default-router 172.16.136.1

option 176 ascii "MCIPADD=172.16.22.194,172.16.22.195,MCPORT=1719,TFTPSRVR=10.1.10.108,L2Q=1,L2QVLAN=3,VLANTEST=300"

As for the voice vlan residing on a trunk port, I don't believe there are problems related to this, but if there are, I have a lot of changes to make in the near future. We have 5 sites configured this way.

Thanks.

Kendall

I do not know that it causes any problem to have voice vlan on a trunk port. I only know that the documentation specifies that it should be an access port. In fact since the real purpose of voice vlan is to permit a tagged frame on an access port (normally tagged frames are only allowed on trunk ports) I suspect that putting it on a trunk is not a big deal. I also suspect that the voice vlan configuration here is not doing any good and is essentially redundant.

If you have proper IP connectivity and the DHCP server has an appropriate scope configured, then the next thing I would take a look at is the possibility that there is a filter somewhere along the data path that is denying DHCP requests.

HTH

Rick

HTH

Rick

Rick,

Thank you for the replies.

This is pretty confusing because the router hosting the DHCP scope is the next physical device after the switch connecting the phone.

Also, I am able to see dhcprequest packets inbound on the 2821 sourced from 172.16.136.1. However, the router isn't sending any dhcpoffer packets.

Thanks again.

Kendall

I agree that it is quite puzzling. I have a couple of thoughts:

- your original post says that the router recently stopped issuing addresses. This seems to imply that it was working and then stopped. If that is the case do you have any idea of what change(s) were made?

- from the presence of multiple VLAN interfaces on the switch with IP addresses would I be correct in assuming that IP routing is enabled on the switch?

- can you give us some detail about how the switch connects to the router? Is it a trunk with multiple VLANs or is it a single routed interface?

- from the router can you ping to the 172.16.136.1 address?

HTH

Rick

HTH

Rick

To my knowledge there were no changes made (I am one of 4 administrators). We did experience a power outage (city wide) and lost ups before we were able to gracefully shut down all the devices. Once power was restored, everything came up and worked as expected until we tried to move a phone to a different office. (Moving it back didn't help)

As for the configuration between the router and switch, they are on a point-to-point /30 network. We do have multiple vlans on the switch, a 6506 with 4 vlans.

-yes, I can succesfully ping 172.16.136.1 from the router.

During the power outage, I presume the router and switch and phones all got rebooted did they? In which case, the first DHCP attempt must have worked. Can you confirm that?

Then you tried moving the phone. To a different port on the same VLAN(s), or to a different site? And it didn't work. If it was just to an adjacent port, normally you would expect the DHCP server to offer back the original lease wouldn't you?

But then you tried moving back, and it failed to DHCP.

Are the phones on the other sites (which I presume also suffered the power outage) OK when you try and move them?

I'm not sure, but there is something that suggests looking for something to do with port security or ARP inspection or DHCP snooping. Do you do any of that security stuff?

But you also say that you can see the DHCP request at the 2821, but no offer. And that is monitoring at the router I suppose, or on the attached switch via a SPAN?

If you look at the DHCP bindings at the 2821, does it give any clues?

Sorry, lots of questions, but I hope one of them is a valid lead.

Kevin Dorrell

Luxembourg

Yes the first attempt at DHCP worked, yes.

When we moved the phone to an adjacent port the phone did not receive a DHCPoffer. We also tried to move a second phone, but it now has the same symptoms.

We don't have dhcp snooping or arp insecption enabled on this link.

When I checked the 2821 this morning I noticed that there is one dhcp binding, but no more.

Is that binding for anything significant? That might give us a clue. So if there is only one binding, where are the rest of the telephones listed?

Is it possible that the pool is all used up, even if the DHCP server does not know so? For example, let us hypothesise that the router went down but the telephones didn't, so they have kept their binding. The router thinks it has plenty of pool left. But before it offers an address, it will normally ARP for it, just in case. (Now I'm getting confused, because I don't know how that would work through a relay. Perhaps it pings for it.) And if it doesn't find any of its pool addresses still free, what then?

Sorry, perhaps I'm clutching at straws here ;-)

Kevin Dorrell

Luxembourg

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco