Partial vs Full tables

Fri Jun 12 02:01:21 UTC 2020

Mark (and others),

I used to run loose uRPF on peering/transit links for AS3128 because I used to think that tightening the screws was always the "right thing to do".   

I instrumented at 60s granularity with vendor J uRPF drop counters on these links.  Drops during steady state [bgp converged] were few [Kbps].  Drops during planned maintenance were at much rates for a few minutes.

What was happening: I advertise a handful of routes to transit/peers from multiple ASBR.  Typically my ASBR sees 800K FIB and a few million RIB routes  We all know this takes a good amount of time to churn..   

For planned maintenance of ASBR A [cold boot upgrades], if recovery didn't include converging my inbound routes before doing eBGP advertising, I'd be tossing packets due to loose uRPF.  

Remember during this time 'ASBR B'  in my AS is happy egressing traffic as soon as 'ASBR A' advertises my dozen or so prefixes via eBGP, I start to see return traffic much sooner than before 'ASBR A' has converged.  No more specific return route yet other than maybe default for a few minutes if unlucky..  The result is bit bucket networkwide despite ASBR B functioning just fine.

Maybe everyone already convergences inbound before advertising eBGP and I made a rookie mistake, but what about unplanned events?

For me the summary is that I was causing more collateral damage than good [verified by time series data], so I turned off loose URPF.  YMMV.

-Michael

> -----Original Message-----
> From: NANOG <nanog-bounces at nanog.org> On Behalf Of Mark Tinka
> Sent: Thursday, June 11, 2020 12:14 PM
> To: nanog at nanog.org
> Subject: Re: Partial vs Full tables
> 
> 
> 
> On 10/Jun/20 19:31, William Herrin wrote:
> 
> >
> > Sorry, it'd be pre-coffee if I drank coffee and I was overly harsh
> > here. Let me back up:
> >
> > The most basic spoofing protection is: don't accept remote packets
> > pretending to be from my IP address.
> >
> > Strict mode URPF extends this to networks: don't accept packets on
> > interfaces where I know for sure the source host isn't in that
> > direction. It works fine in network segments whose structure requires
> > routes to be perfectly symmetrical: on every interface, the packet for
> > every source can only have been from one particular next hop, the same
> > one that advertises acceptance of packets with that destination. The
> > use of BGP breaks the symmetry requirement so close to always that you
> > may as well think of it as always. Even with a single transit or a
> > partial table. Don't use strict mode URPF on BGP speakers.
> >
> > Loose mode URPF is... broken. It was a valiant attempt to extend
> > reverse path filtering into networks with asymmetry but I've yet to
> > discover a use where there wasn't some faulty corner case. If you
> > think you want to use loose mode RPF, trust me: you've already passed
> > the point where any RPF was going to be helpful to you. Time to set it
> > aside and solve the problem a different way.
> 
> We don't run Loose Mode on peering routers because they don't carry a
> full table. If anyone sent the wrong packets that way, they wouldn't be
> able to leave the box anyway.
> 
> We do run Loose Mode on transit routers, no issues thus far.
> 
> We do run Strict Mode on customer-facing links that are stub-homed to us
> (DIA). We also run Loose Mode on customer-facing links that buy transit
> (BGP).
> 
> But mostly, BCP-38 deployed at the edge (peering, transit and customer
> routers) also goes a long way in protecting the network.
> 
> Mark.