[189940] in North American Network Operators' Group
Re: intra-AS messaging for route leak prevention
daemon@ATHENA.MIT.EDU (Mark Tinka)
Fri Jun 10 13:03:01 2016
X-Original-To: nanog@nanog.org
To: Job Snijders <job@instituut.net>, Joe Provo <nanog-post@rsuc.gweep.net>
From: Mark Tinka <mark.tinka@seacom.mu>
Date: Fri, 10 Jun 2016 19:02:50 +0200
In-Reply-To: <20160610085017.GF2524@Vurt.local>
Cc: "nanog@nanog.org" <nanog@nanog.org>, "Sriram,
Kotikalapudi \(Fed\)" <kotikalapudi.sriram@nist.gov>
Errors-To: nanog-bounces@nanog.org
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.
