intra-AS messaging for route leak prevention

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.