IXP

Alan Hannan alan at routingloop.com
Mon Apr 20 06:37:46 UTC 2009


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 at 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, ....
>>>>         
>>     
>
>   





More information about the NANOG mailing list