Re: DHCP Snooping on Catalyst 9k platform

mifi · ‎07-08-2020

We migrated from Catalyst 6k5 to 9k platform and found that DHCP snooping works different on the new platform. I cannot find if it is a feature or bug. So far we had DHCP snooping only in access layer, not in core. After migration, the end hosts were not able to obtain IP addresses until we configured DHCP snooping for the client VLANs in the core switch as well.

To find out the root cause I built a lab:

[pc] -- [access sw] -- [core sw] -- [DHCP server]

In the first scenario the DHCP snooping was off on access and core switch. The DHCP server was first on the core switch then on the DHCP server. The client was obtaining IP.

In the second scenario I configured DHCP snooping on access switch for the pc VLAN.

The client was unable to get an IP, the dhcp snooping debug on access switch showed DHCPREQUESTs only.

In the third scenario I address DHCP snooping also on the core switch. The PC obtained IP immediately.

I am running recommended software 16.12.3 on core switch which is Cat 9500-24Q in the lab, in the production we have Cat 9500-24Y4C with IOS-XE 16.12.3a.

Any ideas?

Thanks,

Michal

Georg Pauwen · ‎07-09-2020

Hello,

odd. Was the uplink port from the access to the core switch configured as a trusted port (with snooping enabled only on the access switch) ?

mifi · ‎07-09-2020

Hi,

Thanks for the reply. Yes I know how to configure DHCP snooping ;) so I did configure upstream ports as DHCP snooping trusted. If I would not have done so, the client would not obtain IP even in the "snooping-enabled-on-core" scenario. Any other idea? I still think it is a bug, but I am not able to find anything in the bugsearch tool. It is also strange that I would be the only one affected..

Regards,

Michal

paul driver · ‎07-09-2020

Hello

@mifi wrote:

In the first scenario the DHCP snooping was off on access and core switch. The DHCP server was first on the core switch then on the DHCP server. The client was obtaining IP.

So either way when snooping is applied to only the access switch the client cannot obtain a lease from the server- correct?

As a test on access switch try to allow any option 82 information that could being relayed and dropped by the core switch that isnt running snooping..

Switch - (global or interface)
ip dhcp snooping information option allow-untrusted

If possible can you apply a debug and post the out in a file
debug ip dhcp server events
debug ip dhcp server packet
debug dhcp snooping

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

mifi · ‎07-09-2020

Hi Paul,

I run the debugs, with DHCP snooping disabled I see:

*Jul 9 10:16:55.775: DHCPD: Reload workspace interface Vlan231 tableid 0.
*Jul 9 10:16:55.775: DHCPD: tableid for 10.22.31.1 on Vlan231 is 0
*Jul 9 10:16:55.775: DHCPD: client's VPN is .
*Jul 9 10:16:55.775: DHCPD: No option 125
*Jul 9 10:16:55.776: DHCPD: inconsistent relay information.
*Jul 9 10:16:55.776: DHCPD: relay information option exists, but giaddr is zero.

This is regardless I run DHCP server locally and do not use any ip helper address on the core switch for the VLAN 231.

Again after enabling DHCP snooping ip dhcp snooping information option allow-untrusted on core switch the DHCP packets reach the DHCP server immediately.

Regards,

Michal

Georg Pauwen · ‎07-09-2020

Hello,

what do you use as DHCP server ?

mifi · ‎07-09-2020

In one scenario I use the DHCP server on the core switch, in the other scenario I use the isc-dhcp-server on the Debian machine.

paul driver · ‎07-09-2020

Hello

@mifi wrote:

.*Jul 9 10:16:55.776: DHCPD: relay information option exists, but giaddr is zero.

As snooping is enabled on the access switch and that switch it is happily inserting the dhcp snooping option 82 value (by way the access layer is ONLY where you should apply snooping, never on any core switch) it seems the core switch is dropping dhcp messages because of the zero gateway ip address (giaddr) just like other switches would do after reading this option value and find the dhcp message it isn’t applicable to its own switch.

Appending that command either globally or interface specific on the core switch should negate this checking of that option 82 value and allow the messages to through to the dhcp server running locally or remotely

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Georg Pauwen · ‎07-09-2020

Hello,

I check for bugs and found the one below, the 9K switches are affected. Your release 16.12.3a is listed under 'Known fixed releases', but you still might want to check it out:

DHCP snooping may drop dhcp option82 packets w/ ip dhcp snooping information option allow-untrusted
CSCvm55401
Description
Symptom:
DHCP snooping may drop packets with option82 when "ip dhcp snooping information option allow-untrusted" is configured under the untrusted downstream interface on version 16.6.4

Following message is seen when it is dropped.

*Sep 18 20:25:24.453: %DHCP_SNOOPING-5-DHCP_SNOOPING_NONZERO_GIADDR: DHCP_SNOOPING drop message with non-zero giaddr or option82 value on untrusted port, message type: DHCPDISCOVER, MAC sa: 54a2.7433.9664

when "ip dhcp snooping information option allow-untrusted" is configured globally issue is not seen.

Conditions:
Seen on 3850 running 16.6.4 code.

Downstream switch adds DHCP option 82, when the Relay switch receives packet with option 82 on untrusted port packet is dropped while "ip dhcp snooping information option allow-untrusted" is configured on the untrusted port.

Workaround:
1) Configure ""ip dhcp snooping information option allow-untrusted" globally instead at interface level
or
2) Configure untrusted port to be trusted "ip dhcp snooping trust"

mifi · ‎07-09-2020

My issue is that I used to run DHCP snooping on the access layer only, but with 9k in the core I have to enable it on the core switch as well. The question is: Is this a kind of change in the new platform, or is it wrong behaviour?

Georg Pauwen · ‎07-09-2020

Hello,

I read the config guides for both the 6500 and the 9K, it looks like DHCP snooping is (supposed to be) working exactly the same. The problem might be the access switches, what models and IOS versions do you use ?

What happens if you clear the bindings ?

clear ip dhcp snooping binding *

paul driver · ‎07-09-2020

Hello

@mifi wrote:
My issue is that I used to run DHCP snooping on the access layer only, but with 9k in the core I have to enable it on the core switch as well. The question is: Is this a kind of change in the new platform, or is it wrong behaviour?

No it shouldnt be, You should not or have no reason to apply snooping on any core/distrubution layer, its an access layer protection feature only.

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

mifi · ‎07-09-2020

OK, I am going to contact Cisco TAC, because this looks pretty much as a bug. Thanks!

mifi · ‎07-09-2020

Configuring "ip dhcp relay information trust-all" on the core switch did the trick. Now DHCP works with snooping enabled on access layer only.

Regards
Michal

Georg Pauwen · ‎07-09-2020

Hello,

good information ! So you did not need that on the 6K5, but on the 9K you do ? I did not find that documented anywhere...