IOS-XE native DHCP snooping (debug functionality needed)

[GIdenJoe]

I want to share another "issue" that I had recently that might be or might not be a bug.

We are moving a customer from their old 3rd party network to a Meraki network where the central switches are a C9300L-M stack and the rest are MS130 non X models.

Then the IOS-XE 17.15.3 was considered RC so I went for that so I didn't need to do the longer painful upgrade later on.

When moving the DC servers to the new stack we noticed that a certain label printer was no longer getting an IP address.  The advantage of the Catalyst switches is that you can configure a SPAN session in dashboard using multiple source ports so I captured the port leading to the old switch network and two ports leading to the VM's that are running the DHCP servers.

To my surprise I noticed that most devices just worked but that printer DHCP discover messages were getting dropped.

As you can see in the screenshot, each mesage is several seconds apart so that means each frame is only received on the incoming port.

If I contrast that with my pc which I then connected on the same port as that printer so my message came into the Catalyst switches via the same port you will see 3 copies of incoming frames and two outgoing (which should be 3 also, strange).

When I used the show ip dhcp snooping command I could see that DHCP snooping is enabled on all the configured VLANs while this has not been configured in dashboard.  However each port is set as trusted and the rate limiting is set to unlimited.  This means that DHCP snooping is always enabled.

When doing the show ip dhcp snooping statistics command I could see dropped messages...
But I can't see while.  And since the debug command is prohibited in the Meraki Cloud CLI this is a major annoyance.

I checked the usuals:
All ports are still trusted
The mac address of the discover matches the mac address in the dhcp client
Both bootp flag unicast or broadcast DHCP messages are being responded too with the exception of the one printer.

The only difference I could find is that this printer did not give an option 60 vendor class identifier.
But I'm not sure if this is the reason why it dropped the discover messages.

So moral of the story:
- DHCP snooping is always enabled, keep this in mind
- Meraki give us debug access to these switches please!
- Also let us configure trusted vs untrusted ports instead of just mac addresses.  And maybe have the option to disable snooping on certain switches like distribution/core.

We were able to work around it by just giving that printer a fixed IP and are hoping no other devices will be experiencing this issue.

[cmr]

@GIdenJoe did you log a ticket as perhaps support can get to the debug messages, I know it isn't ideal, but at least you might get an answer?!?

[GIdenJoe]

If time wasn't an issue I would have.

However we had to rollback the installation the first time we did it and now we went forward.  If it were multiple devices then I would have made a case, however in this case it is just the one so we couldn't afford to spend any more time on it.

I do like these "specials" if they are not time constrained.

[cmr]

Surely the site needs a spare printer... 😉

[GIdenJoe]

Well I'm not sure it's a cheap one.
Although it's a sort of carboard label sticker printer it was a quite heavy one at that.

Had to carry it all the way from production to IT and then back again after the static IP fix.

[cmr]

Ah, maybe not then!

[PhilipDAth]

Has it used a client ID that is not a MAC address?

[GIdenJoe]

If you mean Client MAC then that is documented in Cisco's DHCP snooping documentation as one of the reasons it would reject it but alas the MAC is given.  Option 61 client identifier is present but only has the length parameter.

Also bootp flag is set to unicast but I have captured many discovers that have both unicast and broadcast flag set and these do work so that would not be it.