Partial vs Full tables

Wed Jun 10 20:05:59 UTC 2020

On Wed, Jun 10, 2020 at 11:20 AM Brian Johnson <brian.johnson at netgeek.us> 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 herrin.us
https://bill.herrin.us/