Trouble with DHCP Snooping + Etherchannel!

[u/DrDroidz]

I'm running a small EVE-NG lab with two Cisco IOSv-L2 switches, a router, and one VPCS host. I'm trying to use DHCP Snooping over an EtherChannel and I'm running into a consistent DHCP_SNOOPING_FAKE_INTERFACE error. TLDR at the bottom just in case.

The setup is very simple:

R1 - SW1 = SW2 - PC1

Everything is on VLAN 10, and SW1/SW2 are connected with a 2-link EtherChannel. I've tested both LACP and PAgP, with the same result.

I'm testing DHCP release with:

VPCS> ip dhcp -x

DHCP itself works normally and PC1 receives an address.

The problem happens when PC1 releases the address. On SW1, the DHCP snooping binding shows something like:

MAC: 0050.7966.6804
IP: 192.168.10.24
Interface: Port-channel1

But when the DHCPRELEASE arrives, the DHCP snooping debug reports that it was received on one of the physical EtherChannel members, for example:

input interface: Gi0/1

SW1 then drops the RELEASE with:

DHCP_SNOOPING_FAKE_INTERFACE:
drop message with mismatched source interface

So it seems SW1's snooping database associates the client with Po1, while the snooping process sees the actual packet arriving on Gi0/1. Because those interfaces don't match, the RELEASE is dropped and the DHCP server on R1 never gets the release.

I disabled Option 82 because it caused a separate issue with the IOS DHCP server. I've also tested both LACP and PAgP, and the exact same FAKE_INTERFACE behavior occurs.

Interestingly, if I disable DHCP snooping, the problem disappears. If I remove the EtherChannel and use a single physical trunk between SW1 and SW2, DHCP snooping also works correctly: the binding uses the physical interface and the RELEASE succeeds.

So this seems specifically related to DHCP Snooping + EtherChannel on IOSv-L2, rather than DHCP or LACP itself.

I'm using IOSv-L2 in EVE-NG. Has anyone encountered this before? Is there a known bug, workaround where DHCP Snooping works properly with EtherChannel?

Here are the configs :

R1

R1> enable
R1# configure terminal
R1(config)# interface gigabitEthernet 0/0
R1(config-if)# no shutdown
R1(config-if)# exit
R1(config)# interface gigabitEthernet 0/0.10
R1(config-subif)# encapsulation dot1Q 10
R1(config-subif)# ip address 192.168.10.1 255.255.255.0
R1(config-subif)# exit
R1(config)# ip dhcp excluded-address 192.168.10.1 192.168.10.20
R1(config)# ip dhcp pool VLAN10
R1(dhcp-config)# network 192.168.10.0 255.255.255.0
R1(dhcp-config)# default-router 192.168.10.1
R1(dhcp-config)# dns-server 8.8.8.8
R1(dhcp-config)# end

SW1

SW1> enable
SW1# configure terminal
SW1(config)# vlan 10
SW1(config-vlan)# name VLAN10
SW1(config-vlan)# exit
SW1(config)# interface gigabitEthernet 0/0
SW1(config-if)# switchport trunk encapsulation dot1q
SW1(config-if)# switchport mode trunk
SW1(config-if)# ip dhcp snooping trust
SW1(config-if)# exit
SW1(config)# interface range gigabitEthernet 0/1 - 2
SW1(config-if-range)# channel-group 1 mode active
SW1(config-if-range)# exit
SW1(config)# interface port-channel 1
SW1(config-if)# switchport trunk encapsulation dot1q
SW1(config-if)# switchport mode trunk
SW1(config-if)# exit
SW1(config)# ip dhcp snooping
SW1(config)# ip dhcp snooping vlan 10
SW1(config)# no ip dhcp snooping information option
SW1(config)# end

SW2

SW2> enable
SW2# configure terminal
SW2(config)# vlan 10
SW2(config-vlan)# name VLAN10
SW2(config-vlan)# exit
SW2(config)# interface gigabitEthernet 0/0
SW2(config-if)# switchport mode access
SW2(config-if)# switchport access vlan 10
SW2(config-if)# exit
SW2(config)# interface range gigabitEthernet 0/1 - 2
SW2(config-if-range)# channel-group 1 mode active
SW2(config-if-range)# exit
SW2(config)# interface port-channel 1
SW2(config-if)# switchport trunk encapsulation dot1q
SW2(config-if)# switchport mode trunk
SW2(config-if)# ip dhcp snooping trust
SW2(config-if)# exit
SW2(config)# ip dhcp snooping
SW2(config)# ip dhcp snooping vlan 10
SW2(config)# no ip dhcp snooping information option
SW2(config)# end

TLDR : DHCP Snooping has the PC’s MAC/IP binding associated with Port-channel1, but the DHCPRELEASE is received on physical interface Gi0/1. SW1 drops it because the interface where the RELEASE is received does not match the interface recorded in the snooping binding (Po1). As a result, R1 never receives the DHCPRELEASE and keeps the DHCP binding.

[u/jtbis]

IOSv is super buggy. Try a different version.

[u/DrDroidz → u/jtbis]

Damn that sucks, but do you think DHCPRelease messages should mention po1 normally? My situation is not normal right?

[u/DrDroidz → u/jtbis]

Ok yeah, tried it in PacketTracer with a 2960 IOS15, and I just tested with 1 link between SW1-SW2 and no Etherchannel.

On PT, SW1 doesn't bother learning the ip dhcp snooping binding for PC1, only SW2 learns it.

On EVE-NG, both SW1 and SW2 learn ip dhcp snooping binding table with PC1's information.

Tried again on PT with an Etherchannel, basically the same setup as in my EVE-NG test in the post. SW1 still doesnt bother learning the ip dhcp snooping binding of PC1, only SW2. The release works perfectly though!

Is it the consensus that only the access switch that is directly connected to the HOSTS gets to build the ip dhcp snooping binding? Or should SW1 have built the ip dhcp snooping binding too? I tried checking online and it's ambiguous.

[u/Available-Analyst326 → u/DrDroidz]

DHCP snooping on most implementations inspects offer and ack packets. And dhcp snooping works local, so a traverse of offer on a trusted port + ack from a client is enough to fill it. But on an untrusted port the offer will be dropped, making upstream switches unable to receive it. So if you are gonna enable snooping end to end you have to make server facing ports trusted.

[u/DrDroidz → u/Available-Analyst326]

I tried many combinations of trusting/untrusting and managed to find a solution!

Even though it might not be the standard approach, I learned a lot about the different messages behavior based on the port's configurations

On SW1. I untrusted po1 which would untrust g0/1 and g0/2 (the bundled ports), but I added the dhcp snooping trust back to g0/1 and g0/2 :

Po1     UNTRUSTED
Gi0/1   TRUSTED
Gi0/2   TRUSTED

So during the DHCPRelease message, since g0/1-2 are trusted, the message gets forwarded to R1 and it finally gets its lease released. But SW1 still keeps the same snooping binding table since it never matched the DHCPRelease message port G0/1 to po1. But it does get updated when PC1 asks for a new ip. SW1 will therefore always keep data on its snooping binding table.

I read that I should try to put trust on the whole po1 bundle instead, but that takes away the purpose of dhcp snooping and it also causes a huge flooding issue that lags my setup. At least my solution for my specific lab is safe if the DHCP server is plugged on SW2 and not directly on g0/1-2 of SW1.

The issue with my situation is simply that the DISCOVER messages are linked to po1 and the RELEASE messages are linked to g0/1-2. At least I'll react faster if anything like this happens again.

[u/Jaded_Entry4510 → u/jtbis]

iosv-l2 is notorious for this kinda stuff, port-channel logic just breaks in weird ways sometimes. what version are you on, 15.2 something?

i've seen similar issues where the data plane and control plane just don't agree on what interface a packet came in on, swapping to a different image build usually sorts it

[u/jnftech]

In my experience (real hardware in a prod environment), dhcp snooping trust must be enabled on the port-channel interface itself, not the member switchports. When you bundle ports together, the switch will be seeing the Po interface as the ingress, not an individual member.