[113725] in North American Network Operators' Group
Re: IXP
daemon@ATHENA.MIT.EDU (vijay gill)
Mon Apr 20 00:35:54 2009
In-Reply-To: <1F5C73A9-A5D5-4D44-BFC3-8A0E87B3797F@jsyoung.net>
Date: Sun, 19 Apr 2009 18:35:21 -1000
From: vijay gill <vgill@vijaygill.com>
To: Jeff Young <young@jsyoung.net>, Nick Hilliard <nick@foobar.org>,
Paul Vixie <vixie@isc.org>, nanog@merit.edu
Errors-To: nanog-bounces@nanog.org
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. Default
will be suboptimal to debug.
I must say stephen and vixie and (how hard this is to type) even
richard steenbergens methodology makes the most sense going forward.
Mostly to prevent self-inflicted harm on parts of the exchange
participants. Will it work? Doubtful in todays internet clue level
/vijay
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). When he discovered traffic
> loads coming from non-peers he'd drop in an ACL that
> blocked everything except ICMP - then tell the NOC to
> route the call to his desk with the third party finally gave
> up troubleshooting and called in...
>
> fun memories of the NAPs...
>
> jy
>
>
> On Apr 18, 2009, at 11:35 AM, Nick Hilliard wrote:
>
>> On 18/04/2009 01:08, Paul Vixie wrote:
>>> i've spent more than several late nights and long weekends dealing
>>> with
>>> the problems of shared multiaccess IXP networks. broadcast storms,
>>> poisoned ARP, pointing default, unintended third party BGP,
>>> unintended
>>> spanning tree, semitranslucent loops, unauthorized IXP LAN
>>> extension...
>>> all to watch the largest flows move off to PNI as soon as somebody's
>>> port was getting full.
>>
>
>
--
Sent from my mobile device
