install this on all your internal, upstream, downstream
interfaces (cisco router) [cef required]:
"ip verify unicast source reachable-via any"
This will drop all packets on the interface that do not
have a way to return them in your routing table.
Of course, this is the IP RIB and may not include all the
potential paths in the BGP Adj-RIBs-In, right? As such,
you've still got the potential for asymmetric routing to
break things.
Juniper has a somewhat viable solution to the 100% source
validation for bgp customers. they will consider non-best
paths in their unicast-rpf check on the customer interface. This
means that even if 35.0.0.0/8 is best returned via your
peer instead of via the provider the packet came in, but they
are advertizing the prefix to you, you will not drop the packet.
What's a "bgp customer"? Can they support 500K+ uRPF entries here?
-danny
> install this on all your internal, upstream, downstream
> interfaces (cisco router) [cef required]:
>
> "ip verify unicast source reachable-via any"
>
> This will drop all packets on the interface that do not
> have a way to return them in your routing table.
Of course, this is the IP RIB and may not include all the
potential paths in the BGP Adj-RIBs-In, right? As such,
you've still got the potential for asymmetric routing to
break things.
No, this is "if i have a path in fib" back to this source,
transmit else drop;
It does not validate that it is reachable via that interface, just
reachable at all.
so as long as you aren't null routing 1918 space in your network
to drop packets destined for 1918 space, it will determine there is no
route (back) and drop it.
> Juniper has a somewhat viable solution to the 100% source
> validation for bgp customers. they will consider non-best
> paths in their unicast-rpf check on the customer interface. This
> means that even if 35.0.0.0/8 is best returned via your
> peer instead of via the provider the packet came in, but they
> are advertizing the prefix to you, you will not drop the packet.
What's a "bgp customer"? Can they support 500K+ uRPF entries here?
I'm not sure what the hardware limitations on the Juniper
router are with this unicast rpf. It was introduced
recently (I think in 5.3?) and i personally have not done a
significant amount of testing with it. I'm just offering it as
general knowledge for those that aren't aware that Juniper
has unicast rpf, and that it is somewhat different from
the cisco per-interface model as well as offering a different
type of check that may address some peoples design issues.
(this uses the bgp adj-rib-in info), not the cisco check i
describe above.
- jared
"reachable-via any" means you're only going to drop the packet if you
don't have *ANY* route back to them. I think that if you're in a situation
where you have asymmetric routing, and have a packet coming in on one path
that you theoretically COULD send to the destination, and the destination
has an alternate-path route back to the source, *but you don't have ANY route*,
then you're already in a "broken" state anyhow.
Unless I'm missing something, that's what he said; fib == loc-rib
for the purposes of this discussion, and loc-rib is built from the
various adj-ribs-in.
That said, I'm curious to know how asymmetric routing can break
this. As long as someone is sending (and you are installing) a
prefix that includes the source address this check will pass.
If you don't have a route back to the source at all, that isn't
asymmetric routing, it's network partitioning, assuming the source
is legitimate.
--Jeff
> > Of course, this is the IP RIB and may not include all the
> > potential paths in the BGP Adj-RIBs-In, right? As such,
> > you've still got the potential for asymmetric routing to
> > break things.
>
> No, this is "if i have a path in fib" back to this source,
> transmit else drop;
Unless I'm missing something, that's what he said; fib == loc-rib
for the purposes of this discussion, and loc-rib is built from the
various adj-ribs-in.
Correct, but it is not doing a check to see if it's returnable
via the interface it came in, just if it's returnable at all.
As the fib/rib is built off of the adj-rib-in (minus filtering
and local policy), and the check on the cisco validates against
the CEF (fib) table on the Linecard (or centralized CPU in the
case of non-[fully-]distributed platforms) i wanted to clarify the
check that is performed.
That said, I'm curious to know how asymmetric routing can break
this. As long as someone is sending (and you are installing) a
prefix that includes the source address this check will pass.
If you don't have a route back to the source at all, that isn't
asymmetric routing, it's network partitioning, assuming the source
is legitimate.
Exactly. If I can't reach you, I don't want to
have my hosts or routers spend more time than is necessary
dealing with your requests.
- Jared