MX - Unicast RPF failures on DHCP

RaphaelL
Kind of a big deal
Kind of a big deal

MX - Unicast RPF failures on DHCP

Hi ,

 

We are running MXs in NAT mode under the 15.44 code ( yeah I know. ) 

 

On some sites we have machines that have issues getting IP from DHCP. 

We can see the MX dropping thoses packets with the event log : 

RaphaelL_0-1677003224462.png

 

 

RaphaelL_0-1677003087056.png

 

Documentation states : Special exceptions are made for DHCP discover messages and for traffic used to synchronize information between MXs in a NAT warm spare configuration.

 

https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/IP_Source_Address_Spoofing_Protecti...

 

Has anyone ever encountered issues with RPF ? We have 1000++ networks , I'm pretty sure that I can find couple other examples.

 

Yes upgrading to MX17 or MX18 is planned , but I don't see any mention of that behavior in the patch notes.

 

EDIT : 

This is a branch. The MX is configured to relay DHCP packets to a DHCP server in our DC over the S2S VPN. Setup is working fine for 99.9999% of our clients/workstation except some which seems to be sourcing the requests with an IP different from 0.0.0.0 as per the RFC.

 

Thanks ,

11 Replies 11
alemabrahao
Kind of a big deal
Kind of a big deal

It looks like L2 issue or DHCP issue. Who is your DHCP server?

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.

RaphaelL_0-1677004964588.png

Same topology as the documentation.  MX receives the DHCP discover , but drops it.

RaphaelL
Kind of a big deal
Kind of a big deal

Wait.  Shouldn't DHCP discover packets be sourced with 0.0.0.0 ?  I might have to read the RFC again

 

 

 DHCP messages broadcast by a client prior to that client obtaining
   its IP address must have the source address field in the IP header
   set to 0.

https://www.rfc-editor.org/rfc/rfc2131

 

Well I think I found the issue.  Thoses machines are sourcing their DHCP discover with an IP different from 0.0.0.0.   Meraki support will confirm that. I will keep you guys updated. 

Wait - what? An MX doesn't forward DHCP between it's Internet port and LAN ports. The DHCP as shown in the drawing is only for the MX's Uplink. DHCP for clients downstream is handled by the MX itself. You'll need to configure a DHCP server on the VLANs configured on the MX.

LinkedIn ::: https://blog.rhbirkelund.dk/

Like what you see? - Give a Kudo ## Did it answer your question? - Mark it as a Solution 🙂

All code examples are provided as is. Responsibility for Code execution lies solely your own.

DHCP is over the S2S VPN. This is a spoke.

Ah - that was not clear.

 

Did you configure DHCP relay?

LinkedIn ::: https://blog.rhbirkelund.dk/

Like what you see? - Give a Kudo ## Did it answer your question? - Mark it as a Solution 🙂

All code examples are provided as is. Responsibility for Code execution lies solely your own.

Yes. This setup is currently working for all clients and all sites.

 

Sorry for the confusion. I will edit the first post. 

RaphaelL
Kind of a big deal
Kind of a big deal

I was right ! 

 

The IP source address spoofing protection is expected to block traffic from a device when it see's a source IP that does not match a known configured VLAN/subnet. In this case, the client device is sending DHCP discovers with a source IP address of 169.254.x.x instead of the expected 0.0.0.0.

A client should not be sourcing the DHCP discover using the APIPA address, as that goes against the standard set forth in RFC 2131:

"DHCP messages broadcast by a client prior to that client obtaining its IP address must have the source address field in the IP header set to 0."

 

So it is an expected behavior ! I will have to investigate why our HVAC windows machines are suddenly doing that.

Hi Raphael,
Looks  like I am running to the same issue but with some alarm controllers.  The source IP 169.254 is also used and the packets are dropped (unfortunately, not many logs on this). 

Did you find a work around?

Thanks,

Steve

RaphaelL
Kind of a big deal
Kind of a big deal

There are 4 ways to 'solve' this issue.

 

1- Contact your vendor and let them fix the DHCP issues ( Will take forever ) 

2- Update the firmware , OS of that alarm controller ( if this is a known issue on their side, it might be already fixed )

3- Set the device in IP static ( not ideal )

4- Disable IP Spoofing ( not ideal either ) 

 

We ending up rebooting and factory reset our defective machines and it is now working fine.

Thanks, 

Steve

Get notified when there are additional replies to this discussion.