On 23/05/16 15:45, Saku Ytti wrote:
Hey Florian,
Technically it is uRPF violation, you're getting packet from SADDR
0.0.0.0, which is clearly not routed to the interface. JunOS has this
same behaviour and you need to create exception ACL for uRPF to fix
it, I think it's fine, leveraging existing configuration infra,
without introducing new hacks in the code, which invariably will cause
bugs.
However I don't think IOS-XR has this exception ACL support for uRPF.
What you're seeing may be a bug, quick search for DDTS gave me this
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuu01825
I'm curious how '633892863' was solved. Perhaps 'not supported, use
ACL instead of uRPF'.
I know nothing about -XR but surely if uRPF was eating packets with
source of 0.0.0.0, the DISCOVER wouldn't make it to the server?
Seeing a DISCOVER at the server but no request sounds like the OFFER
getting dropped, which can happen if the route back to the giaddr from
the server hits an RPF failure (beyond tedious in ECMP-enabled HSRP
setups as we recently discovered...)
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
