Re: [c-nsp] asr9k dhcp relay + ipv4 verify unicast

[Florian Lohoff]

On Mon, May 23, 2016 at 06:02:10PM +0300, Tarko Tikan wrote:
> hey,
> 
> > interface BVI60004
> >  ipv4 address 10.4.5.1 255.255.255.0
> >  ipv4 verify unicast source reachable-via rx allow-self-ping
> 
> Is this actual config or simplified? If simplified, is there
> VRRP/HSRP involved?
> 
> If there is, it can be explained by DHCP return packet hitting other
> router (because it's sent to GIADDR but you only announce your
> connected prefix). Other router then fails to send packet to
> original router via connected interface because from other routers
> POV it fails RPF (saddr: dhcp-server, daddr: giaddr).

Thanks - thats it ... hsrp + ipv4 verify bit me again ...

Its simplyfied - there is HSRP but the giaddr is the interfaces address
not the HSRP address - so it would get routed back to the original
partner - But indeed that might be the reason the OFFER gets dropped.

And yes - hitting the HSRP partner first so it'l be put on that
L3 domain as its connected and the partner will drop it - bah.

Now looking for a workaround - announcing the HSRP partners interface
addresses as /32 seems to be the only real solution.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: Digital signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] asr9k dhcp relay + ipv4 verify unicast

[Phil Mayers]

On 23/05/16 16:02, Tarko Tikan wrote:

hey,


interface BVI60004
 ipv4 address 10.4.5.1 255.255.255.0
 ipv4 verify unicast source reachable-via rx allow-self-ping


Is this actual config or simplified? If simplified, is there VRRP/HSRP
involved?

If there is, it can be explained by DHCP return packet hitting other
router (because it's sent to GIADDR but you only announce your connected
prefix). Other router then fails to send packet to original router via
connected interface because from other routers POV it fails RPF (saddr:
dhcp-server, daddr: giaddr).


Yep. A PITA...

Often this is safe because both HSRP/VRRP members will forward the 
packet, both will be replied (usually identically - the DHCP server will 
tend to have allocated the lease already, so the 2nd gets the same 
offer/ack) and one will be dropped, but the other will arrive.


route for router#1 giaddr -> router #1 (uRPF ok)
route for router#2 giaddr -> router #1 (uRPF fail)

But if you're in ECMP-enabled networks, you can have a nasty where, from 
the DHCP server PoV:


ECMP hash for router#1 giaddr -> router #2 (uRPF fail)
ECMP hash for router#2 giaddr -> router #1 (uRPF fail)

...and both replies get dropped. This is statistically likely for approx 
1/4 of networks (all other things being equal).


Yet another reason that "layer 3 up on standby" protocols suck.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] asr9k dhcp relay + ipv4 verify unicast

[Tarko Tikan]

hey,


interface BVI60004
 ipv4 address 10.4.5.1 255.255.255.0
 ipv4 verify unicast source reachable-via rx allow-self-ping


Is this actual config or simplified? If simplified, is there VRRP/HSRP 
involved?


If there is, it can be explained by DHCP return packet hitting other 
router (because it's sent to GIADDR but you only announce your connected 
prefix). Other router then fails to send packet to original router via 
connected interface because from other routers POV it fails RPF (saddr: 
dhcp-server, daddr: giaddr).


--
tarko
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] asr9k dhcp relay + ipv4 verify unicast

[Phil Mayers]

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  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] asr9k dhcp relay + ipv4 verify unicast

[Saku Ytti]

On 23 May 2016 at 17:56, Phil Mayers  wrote:
> 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?

You're right, I most confess I didn't read email fully before
responding, apologies to OP for it.

> 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...)

Right, so speculation is, we offered something else than 10.4.5/24

Anyhow if it's low volume box, we can capture the NPU counter which
does uRPF drop, to see the exact packet being dropped.

Small script to find NPU captures in a session log and turn them into
PCAP - https://gist.github.com/ytti/436fe3b602a963acf21e

-- 
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] asr9k dhcp relay + ipv4 verify unicast

[Saku Ytti]

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'.

On 23 May 2016 at 17:36, Florian Lohoff  wrote:
>
> Hi,
> today i had to debug an ASR9001 setup with DHCP Relay and an
> ipv4 verify unicast source reachable-via rx allow-self-ping on
> an BVI interface. The clients failed to get leases - I saw
> DISCOVERS on the server side and the server sent out
> OFFERS. I could not determine whether the OFFER fails
> to reach the client or the REQUEST would not reach the server.
>
> [ ... ]
>
> dhcp ipv4
>  profile relayprofile relay
>   helper-address vrf default 10.7.8.9
>   giaddr policy replace
>  !
>  interface BVI108 relay profile relayprofile
>  interface BVI60004 relay profile relayprofile
>
> [ ... ]
>
> interface BVI60004
>  ipv4 address 10.4.5.1 255.255.255.0
>  ipv4 verify unicast source reachable-via rx allow-self-ping
>
> Removing the ipv4 verify unicast ... solved the issue which
> left me a little puzzled. My google foo turned up nothing
> concerning incompatibilities ...
>
> From my understanding the verify unicast is a pure input packet
> validation. The whole DHCP handshake would not create packets
> stemming from an invalid IP address on the L2 Bridge e.g.
> the BVI interface so i have no clue where and why the packet
> would be dropped.
>
> Flo
> --
> Florian Lohoff f...@zz.de
>  UTF-8 Test: The  ran after a , but the  ran away
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIVAwUBV0MVX5DdQSDLCfIvAQpzQA/7BROfXOU0dUeQ+yK4uykgGrvImlw1FDbx
> sSW6zZJZqVN1bY0yy37onD6bT2ZDOOYWOy7Oann0UQ+UfXP6y6/LpW0FYt4S2eTf
> rCi2psYzjwzYhpyfIfuFGW3Z5G+9z3JNhyICVdLOdLv6jeVpoGxBPMRKUYLrBoJ0
> XB7vpQ63gX8VpNutniBOGnUuYW9QY3+N+d2zcjReIRxEMtonakijY7feINMiK8fB
> s9/Cx1Sdx1B2VbX+fPryUSp+tcjyaqX2jK9dNSHGFIo60P2I/xlFa+Z+mvjTwWa3
> ZyIr4UiJtWLoHi6uM5j9Iuzpk0Rds+YnFBeE1IMlRhMSfl7DmybW60Xj2rEy/Vjb
> aOGawABD88nuTQy1YtgrS02U37hSr0Gt+7M/9A0patAw1mQFLHdb4Sjqu5UFvnZu
> 1ACeu7sudtu/EZJZteIwenoTsSCyDLnWc3WV9i62U4iNfNQqhWdKIheODC45sFrz
> rws09VQunka7wyVVjJ3CcSw0WewWUrGEKRZfJqpaPagKBFWaMGCGipINlgvnV352
> aOTLbG//Dm0biLHdlylErOi00TnCYS0OEIojxKq5d0tEbop6qTRfKnt6DL2smyBb
> 28B34wHf2tYGrsMRGpo1N/VNTT7/vYqQoc0yOzV7NzncOQT2O0D0WoT/AYb8zauK
> uKaILzAU6cU=
> =xpfI
> -END PGP SIGNATURE-
>
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/



-- 
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] asr9k dhcp relay + ipv4 verify unicast

[Florian Lohoff]

Hi,
today i had to debug an ASR9001 setup with DHCP Relay and an
ipv4 verify unicast source reachable-via rx allow-self-ping on
an BVI interface. The clients failed to get leases - I saw
DISCOVERS on the server side and the server sent out
OFFERS. I could not determine whether the OFFER fails
to reach the client or the REQUEST would not reach the server.

[ ... ]

dhcp ipv4
 profile relayprofile relay
  helper-address vrf default 10.7.8.9
  giaddr policy replace
 !
 interface BVI108 relay profile relayprofile
 interface BVI60004 relay profile relayprofile

[ ... ]

interface BVI60004
 ipv4 address 10.4.5.1 255.255.255.0
 ipv4 verify unicast source reachable-via rx allow-self-ping

Removing the ipv4 verify unicast ... solved the issue which
left me a little puzzled. My google foo turned up nothing
concerning incompatibilities ...

From my understanding the verify unicast is a pure input packet
validation. The whole DHCP handshake would not create packets
stemming from an invalid IP address on the L2 Bridge e.g.
the BVI interface so i have no clue where and why the packet
would be dropped.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: Digital signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/