Hi Niall, we have this knob in VRF and master instance, but IMHO having it in master is overkill. I should consider to remove it from master, as we have only mpls loopbacks routes there mostly.
Best regards, Misak Khachatryan, On Sat, May 25, 2019 at 1:24 AM Niall Donaghy <[email protected]<mailto:[email protected]>> wrote: Hi Misak, An excerpt from https://www.ripe.net/publications/docs/ripe-431 is below, my comments prefixed with ‘#’: “”” # # More permissive # Loose uRPF will drop the packet unless a route to the source address exists. The interface is irrelevant for this type. A variation of this mechanism allows ignoring the existence of default routes in the forwarding table. # # Less permissive # Feasible path uRPF will drop the packet unless a route (not necessarily the best) to the source address is through the interface on which the packet was received. Feasible path uRPF prevents issues in asymmetric and multihomed scenarios # # Least permissive # Strict uRPF will drop the packet unless the best route to the source address is through the interface on which the packet was received “”” My understanding of this document’s wording is that uRPF loose is more permissive than uRPF feasible path. The RIPE document appears misleading however, as in Junos ‘feasible-paths’ knob is more permissive than uRPF loose - https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/unicast-reverse-path-edit-routing-options.html#: “”” Description Control the operation of unicast reverse-path-forwarding check. This statement enables the RPF check to be used when routing is asymmetrical. Options active-paths—Consider only active paths during the unicast reverse-path check. feasible-paths—Consider all feasible paths during the unicast reverse-path check. “”” In your environment, are you applying this knob in all VRFs (routing-instances) and in the master instance? I’ll have to double-check with colleagues re: our uRPF testing. Br, Niall From: Misak Khachatryan [mailto:[email protected]<mailto:[email protected]>] Sent: 24 May 2019 17:27 To: Niall Donaghy <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; Louis Kowolowski <[email protected]<mailto:[email protected]>>; Mark Tinka <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [j-nsp] BGP Peering Policies - Best Practices Niall, worth to ask - did you experimented with forwarding-table { unicast-reverse-path feasible-paths; } in VRF routing options to resolve your issues? For more than 5 years we have Internet in VRF with mix of loose and strict uRPF on all customer interfaces - no issues with uRPF packet loss. Best regards, Misak Khachatryan On Wed, May 22, 2019 at 5:40 PM Niall Donaghy <[email protected]<mailto:[email protected]>> wrote: Hi Adam, Yes I can show: - When we had the internet table in inet.0, with uRPF loose, we did not have any problem. - When we moved internet into its own VRF, we had to disable uRPF loose to cure the issue of some packet loss (as I described). So you see, coming at it from the other direction - the problem was created by moving out of inet.0 vs. solved by moving into inet.0. :-) Convoluted setup, spaghetti ... yes yes - I'm not advocating, recommending, defending. Take my input for what it is - a real-world example which was asked for. The takeaway is not that I was able to give examples, but that these examples ought to serve as a caution to those trying to mix multiple VRFs - internet in one of those. uRPF behaviour may cause problems for you. urpf-fail-filters may or may not provide a workaround for you. Br, Niall -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] Sent: 22 May 2019 14:22 To: Niall Donaghy <[email protected]<mailto:[email protected]>>; 'Louis Kowolowski' <[email protected]<mailto:[email protected]>>; 'Mark Tinka' <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: RE: [j-nsp] BGP Peering Policies - Best Practices > From: Niall Donaghy <[email protected]<mailto:[email protected]>> > Sent: Wednesday, May 22, 2019 12:31 PM > > OP>> Are there non-technical reasons for leaving the Internet on the default > RIB? > Adam> Are there technical reasons please? > > How about: > > uRPF causing discarded packets in a multi-VRF environment, eg: > - Internet VRF, Private VRF #1, Private VRF #2. > - Customers connect to all and advertise same prefixes to all. > - Peers connect to perhaps Internet and a Private VRF and > advertise same > prefixes to all. > - Private VRFs reach Internet VRF via default routes over logical tunnels > (BGP). > - uRPF loose causes discards for some asymmetric traffic flows crossing > multiple VRFs. > I have a sympathy for your convoluted setup, however the above argument is a strawman logical fallacy unless you can show how moving to Internet in a default table would have helped to solve the uRPF problem. adam _______________________________________________ juniper-nsp mailing list [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
