- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 :
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.
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 ,
- Labels:
-
Other
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It looks like L2 issue or DHCP issue. Who is your DHCP server?
Please, if this post was useful, leave your kudos and mark it as solved.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Same topology as the documentation. MX receives the DHCP discover , but drops it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
DHCP is over the S2S VPN. This is a spoke.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ah - that was not clear.
Did you configure DHCP relay?
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes. This setup is currently working for all clients and all sites.
Sorry for the confusion. I will edit the first post.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks,
Steve