Partial vs Full tables

Baldur Norddahl baldur.norddahl at
Wed Jun 10 22:01:38 UTC 2020

Am I correct in assuming loose mode RPF only drops packets from unannounced
address space in the global routing table? And the downside of doing so is
that sometimes we do receive packets from that address space, usually back
scatter from traceroute or other ICMP messages.

Currently about 25% of the routable address space is not advertised in the
DFZ. Loose mode RPF could filter this. Is there any data on how much
traffic actually arrives from this space?



On Wed, Jun 10, 2020 at 10:07 PM William Herrin <bill at> wrote:

> On Wed, Jun 10, 2020 at 11:20 AM Brian Johnson <brian.johnson at>
> wrote:
> > Disagree with Bill here. It will depend on the complexity of the network
> as to use of uRPF in any mode (loose or strict). In general, I never use
> uRPF on transit links and use pure filters to ensure accurate filters are
> in place. uRPF may be used internally in either mode to great advantage and
> I’ve done it both ways.
> Hi Brian,
> Do you know and understand what you broke? It's one thing to make a
> judgement call. Quite another to wave your hands and say, "Oh well,
> nobody complained so it must be OK."
> > If you are looking for corner cases, avoid networking. I do not know of
> a protocol or a technique that I cannot find a corner case for.
> Not sure what you're saying here. Corner cases aren't a bad thing.
> They're just the point where a technology or technique is most likely
> to break. If you want reliability, you're supposed to identify the
> corner cases and then you're supposed to game out what happens in
> those corner cases. A result will be acceptable or unacceptable and if
> it's unacceptable you don't do that. If you haven't identified and
> gamed the corner cases then (A) you can't prove your stuff is reliable
> and (B) it probably isn't.
> With RPF, the corner cases you're looking for are: what situations
> would cause a packet to come from the wrong interface? For example, if
> you had some sort of routing loop where router A thought it could get
> to a destination via router B but router B thinks that destination
> unreachable so it returns the packet to its default route at router A.
> RPF then drops the packet because router B isn't an acceptable source.
> That's a corner case for RPF but it's an acceptable case because the
> packet would be dropped regardless.
> Another corner case with strict RPF is that your best route to a
> destination is transit C but a packet with that source arrives from
> transit D. That's broken, it causes significant problems for the
> network and as a result it constrains you to not use strict RPF in
> network scenarios where that's possible.
> Loose mode RPF tries to overcome the limitation by saying: as long as
> there's a route announced from D we'll accept packets from D even if C
> is the best route.
> So loose mode changes the nature of the corner cases you're looking
> for. Instead of looking for situations where the packet came from
> somewhere other than the best route, you're looking for situations
> where the packet came from an interface that advertises no return
> route at all. What are these situations?
> You may have gotten a packet from a reciprocal peer whose customer has
> told them not to advertise their route to you. Your peer isn't
> policy-routing deep in their core, so no matter what their customer
> instructs their packets to you will follow your peer's preferred path.
> If you use loose RPF there, you will black-hole that network's
> packets.
> You may have gotten an ICMP TTL expired from a router on a distant
> peering lan whose operator doesn't announce the lan's route for
> security purposes. After all, those routers don't need to be reached
> from the Internet. If you lose that packet, traceroute fails to reveal
> the hop.
> You may have gotten an ICMP fragmentation needed message from a router
> on the same distant peering lan. If you drop that packet, path MTU
> discovery fails and everything beyond that router is unreachable with
> TCP.
> So you might want to consider whether any of these corner cases is
> activated by the way you use loose mode RPF.
> Regards,
> Bill Herrin
> --
> William Herrin
> bill at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the NANOG mailing list