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 <yo...@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, ....
