Partial vs Full tables

Chris Adams cma at
Wed Jun 10 23:32:52 UTC 2020

Once upon a time, William Herrin <bill at> said:
> On Wed, Jun 10, 2020 at 3:02 PM Baldur Norddahl
> <baldur.norddahl at> wrote:
> > Am I correct in assuming loose mode RPF only drops packets from unannounced address space in the global routing table?
> Actually, I'm not sure since my plan around RPF is "10 foot pole." Is
> "loose mode" really just filtering packets the current routing table
> deems to be bogons? If it's not tied in any way to the actual routing
> paths then it seems poorly named.

I think it's just named that because it was an extension of uRPF; it's
the same mechanism, just stops one step sooner (loose uRPF looks up the
source IP in the FIB to see if it exists, while strict mode then also
looks at the source interface to see if it matches the FIB next-hop).

Loose mode does also make dropping bad traffic easier - for example, if
you have a BGP-triggered remote blackhole, not only will you drop
traffic destined to the IP, but from the source (at least, depending on
the router and config - some treat null routes as "valid path" for loose
uRPF and some do not).

> PMTUD and traceroute responses
> are examples: a router telling a host information but expecting no
> response.

The only typical potentially-valid sources that a router with a full
table wouldn't have that I can see is some peering networks, where the
peering fabric space is not announced in BGP.  You should never see PMTU
issues there, since everybody properly operating on the peering fabric
should have the same MTU (or they'll potentially have BGP issues
anyway).  And while TTL expired messages could also come from a peering
IP, that seems a super corner case (especially since peering is usually
closer rather than farther away).

I've seen enough providers that drop hops in traceroute that I can only
assume nobody really cares about that case either.

Chris Adams <cma at>

More information about the NANOG mailing list