cisco hands-on experience


DHCP Discover Failure in a Port-Channel

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):

    1. DHCP Discover
    2. DHCP Offer
    3. DHCP Request
    4. 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

config parts
Switch TEST:
!
ip dhcp snooping vlan 1,103,104,162,217
no ip dhcp snooping information option
ip dhcp snooping
ip domain-list xy.xy.dom
no ip domain-lookup
!
spanning-tree mode rapid-pvst
spanning-tree portfast bpduguard default
spanning-tree portfast bpdufilter default
spanning-tree extend system-id
spanning-tree uplinkfast
spanning-tree backbonefast
!
!
interface Port-channel1
description -> trunk to SW2
switchport trunk allowed vlan 1,103,104,162,217
switchport mode trunk
ip dhcp snooping trust
!
interface GigabitEthernet0/1
description -> trunk to SW2
switchport trunk allowed vlan 1,103,104,162,217
switchport mode trunk
udld port
channel-group 1 mode active
ip dhcp snooping trust
!
interface GigabitEthernet0/2
description -> trunk to SW2
switchport trunk allowed vlan 1,103,104,162,217
switchport mode trunk
udld port
channel-group 1 mode active
ip dhcp snooping trust
!

 

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!

 

 

  1. Rob Reply

    Did you ever find the solution? Highly interested in the outcome.

    • Jacob Reply

      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.

  2. Steve Reply

    Did you ever resolve this? I’m having seemingly the same exact issue.

  3. Pokal Reply

    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.

    • Jacob Reply

      Hi Pokal,
      you did a great job – it works fine for me, too. 🙂

  4. ReinaldoTEcheverria Reply

    Hi to every , since I am actually eager of reading this website’s post to be
    updated regularly. It consists of nice data.

  5. lucas Reply

    im having same problem at our network with port-channels applied to the trunk links between switches.

    ======how would we apply this command?========

Leave a Reply to Steve Cancel reply

*

captcha *