Mailing List Archive

BGP Peering Policies - Best Practices
We are currently a mix of Juniper and Cisco. With the Cisco routers eBGP
peering with providers, exchanges, and customers.

We will be reintroducing Juniper as peering routers. While I have some old
Juniper BGP peering policies I can build from, I would like know what is
working, or not working, well for others.

For example:
- How many BGP groups do you use?
- How are they organized, and does it simplify or complicate policy design?
- Do you have large import/export policies, or do you chain smaller
policies together?
- What "knobs" do you have in your policies and how do you organize them...
(reject, lower-pref, raise-pref, prepend, etc...)?
- Do you use policies to put prefixes into specific RIB groups? For what
purpose?
- Is anyone aware of a Best Practices guide for Junos BGP policy design?

Thanks,
Rick
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BGP Peering Policies - Best Practices [ In reply to ]
On 20/May/19 18:40, Richard Hicks wrote:


> - Do you use policies to put prefixes into specific RIB groups? For what

I know many people put the Internet in a VRF, so my only comment on this
one is that we don't do it.

In case you are looking for folk that don't, we are in that space.

The rest of your points should attract quite a few opinions :-).

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BGP Peering Policies - Best Practices [ In reply to ]
On May 20, 2019, at 11:50 AM, Mark Tinka <mark.tinka@seacom.mu> wrote:
>
> On 20/May/19 18:40, Richard Hicks wrote:
>
>> - Do you use policies to put prefixes into specific RIB groups? For what
>
> I know many people put the Internet in a VRF, so my only comment on this
> one is that we don't do it.
>
> In case you are looking for folk that don't, we are in that space.
>
> The rest of your points should attract quite a few opinions :-).
>
Are there non-technical reasons for leaving the Internet on the default RIB?

--
Louis Kowolowski louisk@cryptomonkeys.org <mailto:louisk@cryptomonkeys.org>
Cryptomonkeys: http://www.cryptomonkeys.com/ <http://www.cryptomonkeys.com/>

Making life more interesting for people since 1977

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BGP Peering Policies - Best Practices [ In reply to ]
Hi Rick,

some DENOG members have published their filters (or parts of it) on GitHub:

https://github.com/denog/routing-bcp

Best regards,
Theo Voss

Von: juniper-nsp <juniper-nsp-bounces@puck.nether.net> im Auftrag von Richard Hicks <richard.hicks@gmail.com>
Datum: Montag, 20. Mai 2019 um 16:41
An: "juniper-nsp@puck.nether.net" <juniper-nsp@puck.nether.net>
Betreff: [j-nsp] BGP Peering Policies - Best Practices

We are currently a mix of Juniper and Cisco. With the Cisco routers eBGP
peering with providers, exchanges, and customers.

We will be reintroducing Juniper as peering routers. While I have some old
Juniper BGP peering policies I can build from, I would like know what is
working, or not working, well for others.

For example:
- How many BGP groups do you use?
- How are they organized, and does it simplify or complicate policy design?
- Do you have large import/export policies, or do you chain smaller
policies together?
- What "knobs" do you have in your policies and how do you organize them...
(reject, lower-pref, raise-pref, prepend, etc...)?
- Do you use policies to put prefixes into specific RIB groups? For what
purpose?
- Is anyone aware of a Best Practices guide for Junos BGP policy design?

Thanks,
Rick
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BGP Peering Policies - Best Practices [ In reply to ]
On Mon, May 20, 2019 at 11:58:20AM -0500, Louis Kowolowski wrote:
> On May 20, 2019, at 11:50 AM, Mark Tinka <mark.tinka@seacom.mu> wrote:
> >
> > On 20/May/19 18:40, Richard Hicks wrote:
> >
> >> - Do you use policies to put prefixes into specific RIB groups? For what
> >
> > I know many people put the Internet in a VRF, so my only comment on this
> > one is that we don't do it.
> >
> > In case you are looking for folk that don't, we are in that space.
> >
> > The rest of your points should attract quite a few opinions :-).
> >
> Are there non-technical reasons for leaving the Internet on the default RIB?

Staff need to be trained to look in other RIBs?
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BGP Peering Policies - Best Practices [ In reply to ]
On 20/May/19 18:58, Louis Kowolowski wrote:

>
> Are there non-technical reasons for leaving the Internet on the
> default RIB?

It's simple.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BGP Peering Policies - Best Practices [ In reply to ]
On 20/May/19 19:39, Anderson, Charles R wrote:

> Staff need to be trained to look in other RIBs?

That's complex.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BGP Peering Policies - Best Practices [ In reply to ]
> Richard Hicks
> Sent: Monday, May 20, 2019 5:41 PM
>
> We are currently a mix of Juniper and Cisco. With the Cisco routers eBGP
> peering with providers, exchanges, and customers.
>
> We will be reintroducing Juniper as peering routers. While I have some
old
> Juniper BGP peering policies I can build from, I would like know what is
> working, or not working, well for others.
>
> For example:
> - How many BGP groups do you use?
> - How are they organized, and does it simplify or complicate policy
design?
What complicates things is the lack of dynamic update peer groups in junos.

I think the rest is somehow part of the secret sauce.
> - Do you have large import/export policies, or do you chain smaller
policies
> together?
> - What "knobs" do you have in your policies and how do you organize
them...
> (reject, lower-pref, raise-pref, prepend, etc...)?
> - Do you use policies to put prefixes into specific RIB groups? For what
> purpose?

> - Is anyone aware of a Best Practices guide for Junos BGP policy design?
Not really, but you might want to search for security policies (to be used
on ingress to your AS)
If such thing exist for junos it should definitely mention the fact that in
your input normalization/bleaching policies on Junos you also need to
include bleaching of extended communities with your AS#, cause junos will
happily accept say route-targets on all (even eBGP or non-MP-BGP) sessions
and install routes into VRFs by default, something to consider for policies
facing customers as well.

adam

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BGP Peering Policies - Best Practices [ In reply to ]
> Louis Kowolowski
> Sent: Monday, May 20, 2019 5:58 PM
>
> On May 20, 2019, at 11:50 AM, Mark Tinka <mark.tinka@seacom.mu> wrote:
> >
> > On 20/May/19 18:40, Richard Hicks wrote:
> >
> >> - Do you use policies to put prefixes into specific RIB groups? For
> >> what
> >
> > I know many people put the Internet in a VRF, so my only comment on
> > this one is that we don't do it.
> >
> > In case you are looking for folk that don't, we are in that space.
> >
> > The rest of your points should attract quite a few opinions :-).
> >
> Are there non-technical reasons for leaving the Internet on the default
RIB?
>
Are there technical reasons please?

adam

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BGP Peering Policies - Best Practices [ In reply to ]

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.

We've hit this problem.

Br,
Niall

-----Original Message-----
From: juniper-nsp [mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of adamv0025@netconsultings.com
Sent: 22 May 2019 09:46
To: 'Louis Kowolowski' <louisk@cryptomonkeys.org>; 'Mark Tinka' <mark.tinka@seacom.mu>
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] BGP Peering Policies - Best Practices

> Louis Kowolowski
> Sent: Monday, May 20, 2019 5:58 PM
>
> On May 20, 2019, at 11:50 AM, Mark Tinka <mark.tinka@seacom.mu> wrote:
> >
> > On 20/May/19 18:40, Richard Hicks wrote:
> >
> >> - Do you use policies to put prefixes into specific RIB groups?
> >> For what
> >
> > I know many people put the Internet in a VRF, so my only comment on
> > this one is that we don't do it.
> >
> > In case you are looking for folk that don't, we are in that space.
> >
> > The rest of your points should attract quite a few opinions :-).
> >
> Are there non-technical reasons for leaving the Internet on the
> default
RIB?
>
Are there technical reasons please?

adam

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BGP Peering Policies - Best Practices [ In reply to ]
On 22/May/19 13:30, Niall Donaghy wrote:

> 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.
>
> We've hit this problem.

That sounds like quite the spaghetti.

How have you resolved it?

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BGP Peering Policies - Best Practices [ In reply to ]
In respect of uRPF, it is turned off, so we have not 'resolved' the issue.
Anti-spoof filters are in place however.

Without considering which pasta shape best fits the scenario, I can tell you we'd have uRPF loose back on if it were feasible. :)


-----Original Message-----
From: Mark Tinka [mailto:mark.tinka@seacom.mu]
Sent: 22 May 2019 12:57
To: Niall Donaghy <niall.donaghy@geant.org>; adamv0025@netconsultings.com; 'Louis Kowolowski' <louisk@cryptomonkeys.org>
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] BGP Peering Policies - Best Practices



On 22/May/19 13:30, Niall Donaghy wrote:

> 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.
>
> We've hit this problem.

That sounds like quite the spaghetti.

How have you resolved it?

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BGP Peering Policies - Best Practices [ In reply to ]
> From: Niall Donaghy <niall.donaghy@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BGP Peering Policies - Best Practices [ In reply to ]
On 22/May/19 15:21, adamv0025@netconsultings.com wrote:

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

We run both Strict and Loose mode uRPF on all our routers, without
issue. Our Internet leaves in the default table, and we've never had a
uRPF issue.

I would not have foreseen a problem like the one Niall has faced, if I
were to run the Internet in a VRF. I would not have even considered it
to be a potential issue. But because of all the unknowns previously
documented with limitations when the Internet is in a VRF, as well as
what we don't already know as software continues to bloat, I simply stay
away from it. I am not suffering anything by not having our Internet in
a VRF.

It's like Broadcom chipsets on IP/MPLS routers... it's getting better
with each iteration of the silicon, but there is always a niggle you
may, or not may know about.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BGP Peering Policies - Best Practices [ In reply to ]
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@netconsultings.com [mailto:adamv0025@netconsultings.com]
Sent: 22 May 2019 14:22
To: Niall Donaghy <niall.donaghy@geant.org>; 'Louis Kowolowski' <louisk@cryptomonkeys.org>; 'Mark Tinka' <mark.tinka@seacom.mu>
Cc: juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] BGP Peering Policies - Best Practices

> From: Niall Donaghy <niall.donaghy@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BGP Peering Policies - Best Practices [ In reply to ]
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@geant.org<mailto:niall.donaghy@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@netconsultings.com<mailto:adamv0025@netconsultings.com> [mailto:adamv0025@netconsultings.com<mailto:adamv0025@netconsultings.com>]
Sent: 22 May 2019 14:22
To: Niall Donaghy <niall.donaghy@geant.org<mailto:niall.donaghy@geant.org>>; 'Louis Kowolowski' <louisk@cryptomonkeys.org<mailto:louisk@cryptomonkeys.org>>; 'Mark Tinka' <mark.tinka@seacom.mu<mailto:mark.tinka@seacom.mu>>
Cc: juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
Subject: RE: [j-nsp] BGP Peering Policies - Best Practices

> From: Niall Donaghy <niall.donaghy@geant.org<mailto:niall.donaghy@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@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: BGP Peering Policies - Best Practices [ In reply to ]
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@gnc.am]
Sent: 24 May 2019 17:27
To: Niall Donaghy <niall.donaghy@geant.org>
Cc: adamv0025@netconsultings.com; Louis Kowolowski <louisk@cryptomonkeys.org>; Mark Tinka <mark.tinka@seacom.mu>; juniper-nsp@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@geant.org<mailto:niall.donaghy@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@netconsultings.com<mailto:adamv0025@netconsultings.com> [mailto:adamv0025@netconsultings.com<mailto:adamv0025@netconsultings.com>]
Sent: 22 May 2019 14:22
To: Niall Donaghy <niall.donaghy@geant.org<mailto:niall.donaghy@geant.org>>; 'Louis Kowolowski' <louisk@cryptomonkeys.org<mailto:louisk@cryptomonkeys.org>>; 'Mark Tinka' <mark.tinka@seacom.mu<mailto:mark.tinka@seacom.mu>>
Cc: juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
Subject: RE: [j-nsp] BGP Peering Policies - Best Practices

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

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