[168186] in North American Network Operators' Group
Re: best practice for advertising peering fabric routes
daemon@ATHENA.MIT.EDU (Christopher Morrow)
Wed Jan 15 01:39:31 2014
In-Reply-To: <1389766976.17890.YahooMailNeo@web181605.mail.ne1.yahoo.com>
Date: Wed, 15 Jan 2014 01:37:29 -0500
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Eric A Louie <elouie@yahoo.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Wed, Jan 15, 2014 at 1:22 AM, Eric A Louie <elouie@yahoo.com> wrote:
> Thank you - I will heed the warning. I want to be a good community membe=
r and make sure we're maintaining the agreed-upon practices (I'll re-read/r=
eview my agreement with the IXP)
>
>
> So if that is the case, I have to rely on the peering fabric to just retu=
rn traffic, since the rest of my network (save the directly connected route=
r) will not know about those routes outbound? And what about my customers =
who are counting on me routing their office traffic through my network into=
the peering fabric to their properties? (I have one specifically who is e=
ventually looking for that capability) Do I have to provide them some sort=
of VPN to make that happen across my network to the peering fabric router?
>
perhaps I'm confused, but you have sort of this situation:
ixp-participants -> ixp -> your-router -> your-network -> your-customer
you get routes for ixp-participants from 'ixp'
you send to the 'ixp' (and on to 'ixp-participants') routes for
'your-customer' and 'your-network'
right?
then so long as you send 'your-customer' the routes you learn from
'ixp' (which you set 'next-hop-self' on in ibgp from 'your-router' to
'your-network' (in the ibgp-mesh that you will setup) ... everything
just works.
All routers behind 'your-router' in 'your-netowrk' see
'ixp-participants' with a next-hop of 'your-router' who still knows
'send to ixp!' for the route(s) in question.
>
>
>
>>________________________________
>> From: Patrick W. Gilmore <patrick@ianai.net>
>>To: NANOG list <nanog@nanog.org>
>>Sent: Tuesday, January 14, 2014 7:11 PM
>>Subject: Re: best practice for advertising peering fabric routes
>>
>>
>>Pardon the top post, but I really don't have anything to comment below ot=
her than to agree with Chris and say rfc5963 is broken.
>>
>>NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An =
IXP LAN should not be reachable from any device not directly attached to th=
at LAN. Period.
>>
>>Doing so endangers your peers & the IX itself. It is on the order of not =
implementing BCP38, except no one has the (lame, ridiculous, idiotic, and p=
ure cost-shifting BS) excuse that they "can't" do this.
>>
>>--
>>TTFN,
>>patrick
>>
>>
>>On Jan 14, 2014, at 21:22 , Christopher Morrow <morrowc.lists@gmail.com> =
wrote:
>>
>>> On Tue, Jan 14, 2014 at 9:09 PM, Cb B <cb.list6@gmail.com> wrote:
>>>> On Jan 14, 2014 6:01 PM, "Eric A Louie" <elouie@yahoo.com> wrote:
>>>>>
>>>>> I have a connection to a peering fabric and I'm not distributing the
>>>> peering fabric routes into my network.
>>>>>
>>>
>>> good plan.
>>>
>>>>> I see three options
>>>>> 1. redistribute into my igp (OSPF)
>>>>>
>>>>> 2. configure ibgp and route them within that infrastructure. All the
>>>> default routes go out through the POPs so iBGP would see packets desti=
ned
>>>> for the peering fabric and route it that-a-way
>>>>>
>>>>> 3. leave it "as is", and let the outbound traffic go out my upstreams=
and
>>>> the inbound traffic come back through the peering fabric
>>>>>
>>>>>
>>>
>>> 4. all peering-fabric routes get next-hop-self on your peering router
>>> before going into ibgp...
>>> all the rest of your network sees your local loopback as nexthop and
>>> things just work.
>>>
>>>>> Advantages and disadvantages, pros and cons? Recommendations?
>>>> Experiences, good and bad?
>>>>>
>>>>>
>>>>> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the
>>>> POPs yet. That's another issue completely from a planning perspective=
.
>>>>>
>>>>> thanks
>>>>> Eric
>>>>>
>>>>
>>>> http://tools.ietf.org/html/rfc5963
>>>>
>>>> I like no-export
>>>
>>
>>
>>
>>
>>
