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.
