intra-AS messaging for route leak prevention
Mark Tinka
mark.tinka at seacom.mu
Fri Jun 10 17:02:50 UTC 2016
On 10/Jun/16 10:50, Job Snijders wrote:
> I second this. One of NTT's design principles is to be very strict in
> what we accept (e.g. "postel was wrong") at the ingress point. At the
> ingress point the route announcement is weighted, judged, categorized &
> tagged. This decides 99% of what happens next: the egress points are
> merely executing what was "decided" at ingress (but exceptions are
> possible).
Agree. We do the same.
>
> You say 'often', but I don't recognise that design pattern from my own
> experience. A weakness with the egress point (in context of route leak
> prevention) is that if you are filtering there, its already too late. If
> you are trying to prevent route leaks on egress, you have already
> accepted the leaked routes somewhere, and those leaked routes are best
> path somewhere in your network, which means you've lost.
Agree.
We don't do any AS_PATH filtering on egress.
The only AS_PATH-anything we do on border routers is signal
customer-initiated prepends via BGP communities. Those prepends are done
at the border routers carrying the interested transit network.
Otherwise, all egress filtering is based on BGP communities + general
"no longer then /24, /48" rule as a fail-safe.
Mark.
More information about the NANOG
mailing list