[j-nsp] BGP Peering Policies - Best Practices

[Misak Khachatryan]

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 <niall.donaghy at geant.org<mailto:niall.donaghy at geant.org>> 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:m.khachatryan at gnc.am<mailto:m.khachatryan at gnc.am>]
Sent: 24 May 2019 17:27
To: Niall Donaghy <niall.donaghy at geant.org<mailto:niall.donaghy at geant.org>>
Cc: adamv0025 at netconsultings.com<mailto:adamv0025 at netconsultings.com>; Louis Kowolowski <louisk at cryptomonkeys.org<mailto:louisk at cryptomonkeys.org>>; Mark Tinka <mark.tinka at seacom.mu<mailto:mark.tinka at seacom.mu>>; juniper-nsp at puck.nether.net<mailto:juniper-nsp at puck.nether.net>
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 <niall.donaghy at geant.org<mailto:niall.donaghy at geant.org>> 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: adamv0025 at netconsultings.com<mailto:adamv0025 at netconsultings.com> [mailto:adamv0025 at netconsultings.com<mailto:adamv0025 at netconsultings.com>]
Sent: 22 May 2019 14:22
To: Niall Donaghy <niall.donaghy at geant.org<mailto:niall.donaghy at geant.org>>; 'Louis Kowolowski' <louisk at cryptomonkeys.org<mailto:louisk at cryptomonkeys.org>>; 'Mark Tinka' <mark.tinka at seacom.mu<mailto:mark.tinka at seacom.mu>>
Cc: juniper-nsp at puck.nether.net<mailto:juniper-nsp at puck.nether.net>
Subject: RE: [j-nsp] BGP Peering Policies - Best Practices

> From: Niall Donaghy <niall.donaghy at geant.org<mailto:niall.donaghy at geant.org>>
> 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 juniper-nsp at puck.nether.net<mailto:juniper-nsp at puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp