On 6/Jun/16 17:54, Job Snijders wrote:
> There is the "human network" approach, where operators share information > with each other which be used to generate config to help block > "unlikely" announcements from eBGP neighbors. > > For instance AT&T and NTT agreed (through email) that there should be no > intermediate networks between 2914 & 7018, therefore NTT blocks > announcements that match as-path-regexp '_7018_' on any and all eBGP > sessions, except the direct sessions with 7018. NTT calls this concept > "peerlocking". I suppose if one is performing prefix- and ASN-based filtering, then you "should" not learn peer paths via customers. If you augment that with AS_PATH-based filtering, you "will not" learn peer paths via customers. One thing we do to reduce opportunistically hazardous vectors is to not learn customer paths via peers. Mark.
