Ok, so the right way to do it is in iBGP. That pretty much answers the question - don't redistribute those ixp-participant prefixes into my IGP. I have a lot of iBGP homework to do, to make it work with the 5 POPs that are all taking full route feeds. I tried once and couldn't get the BGP tables working correctly with a full mesh of the 5 routers, so it looks like time to try it again, this time with a route reflector.
________________________________ From: Christopher Morrow <morrowc.lists@gmail.com> To: Eric A Louie <elouie@yahoo.com> Cc: Patrick W. Gilmore <patrick@ianai.net>; NANOG list <nanog@nanog.org> Sent: Tuesday, January 14, 2014 10:37 PM Subject: Re: best practice for advertising peering fabric routes
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 member and make sure we're maintaining the agreed-upon practices (I'll re-read/review my agreement with the IXP)
So if that is the case, I have to rely on the peering fabric to just return traffic, since the rest of my network (save the directly connected router) 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 eventually 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 other 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 that 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 pure 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 destined 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