[c-nsp] IOS XR BGP

[Keegan Holley]

There's no family aggregate in cisco.  That's one of the reasons people buy
junipers in the first place.  If you want it to disappear when the
comprising routes are gone you should redistribute and use the aggregate
address command.  You can also use suppress maps but I can't remember if
they work with IGP routes or not.  You'll have to look it up.   If your
internet routes are already in your IGP what's the problem with
redistributing them into BGP?  Usually the goal is to keep the public
routes out of the IGP, but that depends on your topology.

2011/11/25 Nick Ryce <Nick.Ryce at lumison.net>

> Hi Vinny,
>
> aggregate-address only aggregates routes already in BGP and not from IGP.
>  I was looking for a way to do this ala Junos that doesn't require me to
> redistribute OSPF routes to BGP.
>
> Nick
>
> -----Original Message-----
> From: Vinny Abello [mailto:vinny at abellohome.net]
> Sent: 24 November 2011 19:17
> To: Oliver Boehmer (oboehmer)
> Cc: Nick Ryce; Eric Morin; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] IOS XR BGP
>
> On 11/24/2011 11:04 AM, Oliver Boehmer (oboehmer) wrote:
> >
> >> I require the specific to be from IGP.
> >>
> >> I have a funny feeling all I need to do is redistribute OSPF into BGP
> > then
> >> use the aggregate-address as-set summary-only
> > yes, and it looks you can limit the OSPF redistribution to a few (a
> > single?) more specific as you are only interested in the core
> > reachability?
> >
> >> Just need confirmation if there is any other way.
> > not to simulate your current solution in XR.
> >
> > But have you thought about orignating the aggregates you advertise to
> > the Internet (and customers) via some central routers in your core,
> > for example some RRs, instead of on the edge(s)? This way you will
> > never advertise them in case your edge devices become isolated (which,
> > if I read you correctly, is the purpose of this exercise?).
> >
> > If you chose this approach, you might also want to advertise these
> > aggregates with a special next-hop (like a private 10.1.1.1), and add
> > a static null0 to 10.1.1.1/32 on all your BGP routers. Then every
> > router seeing the aggregate will automatically create a Null0 and will
> > drop all packets to unallocated address space within these aggregates
> > as soon as it enters your network?
> I have to agree with Oli here. I've followed this practice originating
> aggregate routes from extremely well connected core routers at multiple
> points in my networks. To the best of my memory, I never used network
> statements at the border or edge. Once or twice when building out to a new
> geographical area before having all of the redundancy in place, this
> practice has saved us when a single failed backbone link isolates the new
> routers in question. They stop announcing anything to their peers and we
> stop seeing any announcements from them obviously when their iBGP sessions
> drop with the rest of the network.
>
> To me this always seemed like the most simple and effective approach. Is
> there a reason this would not work in this situation or is there a reason
> using the aggregate-address commands provides some other benefit I'm
> missing?
>
> -Vinny
>
>
> --
>
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the sender. Any
> offers or quotation of service are subject to formal specification.
> Errors and omissions excepted.  Please note that any views or opinions
> presented in this email are solely those of the author and do not
> necessarily represent those of Lumison.
> Finally, the recipient should check this email and any attachments for the
> presence of viruses.  Lumison accept no liability for any
> damage caused by any virus transmitted by this email.
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>