Re: best practice for advertising peering fabric routes

[Eric A Louie <elouie () yahoo com>]

Never mind, I just carefully re-read the point.  Right, I'll filter the prefix(es) of the IXP LAN(s) that I'm connected 
to and not let THAT get out, no reason to advertise it since no traffic ever goes to it.  That still has me asking to 
how best to advertise the rest of the public prefixes coming from the other fabric members.





> ________________________________
> From: Eric A Louie <elouie () yahoo com>
> To: Patrick W. Gilmore <patrick () ianai net>; NANOG list <nanog () nanog org> 
> Sent: Tuesday, January 14, 2014 10:22 PM
> Subject: Re: best practice for advertising peering fabric routes
>
>
> 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?
>
>
>
>
> > ________________________________
> > 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