A solution I put in place at UUnet circa 1997 was to take a set of /32 routes representing major destination, e.g. ISP web sites, content sites, universities, about 20 of them, and temporarily place a /32 static route to each participant at the public exchange and traceroute to the destination. In this manner one can build a matrix to see how each participant gets to each destination. When we found someone sending traffic to us with whom we were not peering, it was only a small bit of work to contact the ISP and ask them to fix the "error". One guy whose initial were GBO fixed it several times if I remember correctly. I wonder how prevalent third-party next hops (here share my peering!) are nowadays? From time to time it was interesting to watch peers and see when they figured out others were using them for transit. BTW, I wonder how many folks did do the ICMP acl stuff. We never did it at UUNET that I remember. In 1997 I know the routers could handle the ACL, at least as well as routers in those days could be said to handle traffic. The guy that taught it to me had the initial NS over a margarita at Rio Grande. Completely preventing the potential for the problem is superior to detecting it. But at the time, without a clear method for preventing it, detection was good. I remember MFS tried to implement mac filters but bugs in the code rendered it a moot exercise. -alan vijay gill wrote:
If you are unfortunate enough to have to peer at a public exchange point, put your public ports into a vrf that has your routes.
On 4/18/09, Jeff Young <young@jsyoung.net> wrote:
Best solution I ever saw to an 'unintended' third-party peering was devised by a pretty brilliant guy (who can pipe up if he's listening).
On Apr 18, 2009, at 11:35 AM, Nick Hilliard wrote
On 18/04/2009 01:08, Paul Vixie wrote:
....pointing default, ....