DHCP Discover Failure in a Port-Channel
1. Introduction
Yesterday we stumbled over an absolutely curious phenomenon in association with the DHCP
process and a port-channel. With a port-channel the DHCP discovery process fails.
Our network design is like cisco enterprise environment commended. There are an
access-layer -> distribution layer -> core layer (in direction to the core).
Everything works fine from the beginning from SW1 and SW2. DHCP discovery is
no problem and works fine. On switch 1-3 we have dhcp snooping operational.
The dhcp snooping trust settings are set to the uplinks and respectively to the port-channels.
For testing purposes we cascade an additional switch to the access/edge layer at switch 2.
On switch ‘SW_test’ we have plugged in an Access-Point to see, if that device get an dhcp lease.
We configured from Switch ‘test’ to SW2 a port-channel with LACP and added some allowed vlans.
The appropriate vlan for us is vlan 162. At the first time we reloaded the switch ‘test’ the Access Point get a
dhcp lease from our dhcp enterprise server. We reload the switch ‘test’ again and now the Access Point or
Laptop client for example, didn’t get a dhcp lease anymore. After that we checked our dhcp snooping settings.
For us – everything looks fine.
On all switches the command ‘no ip dhcp snooping information option’ was configured. After a while of
troubleshooting, we found out that the problem is indepentend form the dhcp snooping feature.
We use the IOS version ‘c2960-lanbasek9-mz.122-58.SE2.bin’ on the test switch.
On Switch SW1 and SW2 we use the IOS version ‘c3560-ipbasek9-mz.122-55.SE8.bin’.
On Switch SW3 we use the IOS version ‘c3750-ipservicesk9-mz.122-55.SE5.bin’.
We configured on Switch ‘test’ and SW2 every possible port-channel constellations.
LACP, LAgP and mode on (without a aggregation protocol – 802.3ad). The three constellations were without
success in association to the dhcp process.
2. Sequence of a dhcp assignment
Additional Information:
A trusted port can accept and send all of the 4 DHCP packets.
With this background only the ports in direction to the dhcp server have to be set to trusted.
On an access port a DHCP offer packet may not be transferred.
An untrusted port can transmit the following dhcp packets (green):
- DHCP Discover
- DHCP Offer
- DHCP Request
- DHCP Acknowledge
3. Debug information fields
- ciaddr = Client IP Address
- yiaddr = Your IP Address
- siaddr = Server IP Address (DHCP Server)
- giaddr = Gateway IP Address
- chaddr = Client Hardware Address
- sname = Name of DHCP Server
- sa = Source Address
Given the following figure
4. Debug analysis
To debug dhcp packets we used the following debug commands.
SW_test#debug ip dhcp snooping event
SW_test#debug ip dhcp snooping packet
SW_test#debug ip dhcp snooping agent
SW_test#show debug
DHCP Snooping packet debugging is on
DHCP Snooping event debugging is on
DHCP Snooping database debugging is on
If you use the ‘debug dhcp’ command, the debug function will recognize only packets, if you run a dhcp server
on your cisco device.
With port-channels active the dhcp process fails. (Debug on SW2)
Feb 21 11:54:16.815: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Po2 for pak. Was not set
Feb 21 11:54:16.815: DHCPSNOOP(hlfm_set_if_input): Clearing if_input for pak. Was Po2
Feb 21 11:54:16.815: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Po2 for pak. Was not set
Feb 21 11:54:16.815: DHCP_SNOOPING: received new DHCP packet from input interface (Port-channel2)
Feb 21 11:54:16.815: DHCP_SNOOPING: process new DHCP packet, message type: DHCPDISCOVER, input interface: Po2, MAC da: ffff.ffff.ffff, MAC sa: 0007.1234.5678, IP da: 255.255.255.255, IP sa: 0.0.0.0, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 0007.1234.5678
Feb 21 11:54:16.815: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (162)
Without port-channels config the dhcp process succeed. (Debug on SW2)
Feb 21 17:02:09.771: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Gi0/2 for pak. Was not set
Feb 21 17:02:09.771: DHCPSNOOP(hlfm_set_if_input): Clearing if_input for pak. Was Gi0/2
Feb 21 17:02:09.771: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Gi0/2 for pak. Was not set
Feb 21 17:02:09.771: DHCP_SNOOPING: received new DHCP packet from input interface (GigabitEthernet0/2)
Feb 21 17:02:09.771: DHCP_SNOOPING: process new DHCP packet, message type: DHCPOFFER, input interface: Gi0/2, MAC da: ffff.ffff.ffff, MAC sa: 8478.acbd.4231, IP da: 255.255.255.255, IP sa: x.x.x.x, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: x.x.x.249, DHCP siaddr: 10.xx3.x0.x0, DHCP giaddr: x.x.x.x, DHCP chaddr: 0007.1234.5678.
The next day i try out another IOS Version.
If somebody have any solution of this phenomenal tricky behaviour – don’t hesitate to get in contact with me.
See you soon – Jacob!
Did you ever find the solution? Highly interested in the outcome.
Unfortunately not – SW3 is a important node in our network and it’s difficult to do a reasonable troubleshooting,
because we have to open a RFC for changes. (very time-consuming)
I personally don’ t think, it is a software IOS version bug. The only chance is to do a significant paket
trace with wireshark, to get a deeeper look into the behaviour of paket traveling over the nodes.
I will post immediately, if we figure out a solution.
Did you ever resolve this? I’m having seemingly the same exact issue.
Hi, I had similar issue at my network and spanning-tree link-type point-to-point solved it.
I’ve putted it at SW2 and SW-test in your config.
Hi Pokal,
you did a great job – it works fine for me, too. 🙂
Hi to every , since I am actually eager of reading this website’s post to be
updated regularly. It consists of nice data.
im having same problem at our network with port-channels applied to the trunk links between switches.
======how would we apply this command?========