I-BGP/IGP design case

Exactly what Mark said. The only design you’d have an issue with that is if you had routers that do not run BGP. Even then, you could solve that with MPLS ( not necessarily TE, a good old bgp-free core design with LDP would be just fine ) , but that’s really not a use case anymore as pretty much everything can run BGP.

Keep in mind that running BGP and having the full BGP table can be 2 separate things. You generally want all your routing boxes to run BGP, as you’d usually have customer nets and ptp nets ( if you want them ) in it. For everything else, a default ( or multiple defaults, depending on your topology ) should suffice. If you want to be scalable, you’ll design your IGP so that it only carries your loopbacks ( incidentally, those are the only addresses you probably want to label if you’re using LDP ).

Lately, there have been a few designs that offer extreme scalability, based on rfc3107 ( bgp-lu ) , but I’ve yet to hear of anyone actually implementing them . You can find cisco’s flavor here ( http://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/mpls/116127-configure-technology-00.html ) or a relevant draft here ( https://tools.ietf.org/html/draft-ietf-mpls-seamless-mpls-07 )

My thoughts and words are my own.

Kind Regards,

Spyros

—–Original Message—–
From: cisco-nsp [mailto:cisco-nsp-bounces@puck.nether.net] On Behalf Of Mark Tinka
Sent: Tuesday, September 16, 2014 9:10 AM
To: cisco-nsp@puck.nether.net
Cc: Wes Smith
Subject: Re: [c-nsp] I-BGP/IGP question

On Tuesday, September 16, 2014 06:55:40 AM Wes Smith wrote:

> I’ve often wondered how large ISPs handle some basic IGP design issues
> re routing between I-BGP nodes in the network. For example ..  assume
> two BGP routers connected over a backbone running some kind of IGP
> I-BGP uses the local IGP to route to other I-BGP nodes within the
> ASThe I-BGP next-hop address is the Egress I-BGP node (normally) or
> the IBPG peer loopbackBest practice says to keep the IGP small, for
> example just the I-BGP loopbacks So a potential routing table entry in
> router
> BGP1 would be something like Rtr BGP1 can reach
> ‘8.8.8.8/32 via 10.10.10.10, where 10.10.10.10 is router BGP-2s
> loopback address and BGP-2 is the egress router So far so good. .. I
> understand all this part.  But my puzzle is .. for this to work, the
> IGP would also need
> to have a route for 8.8.8.8.   so it can route it to my
> other IBGP router at 10.10.10.10But my IGP doesn’t have a route for
> 8.8.8.8 as I don’t redistribute BGP into IGPSo catch-22 . I’ve
> resolved this internally using tunnels between my I-BGP routers and
> using
> next-hop-self. But I’m pretty small scale ..   How do
> larger organisations do it? I’m guessing MPLS TE or other tunnels
> between the POPs .. but would like to hear from some folks that have
> done it.Thanks WS (apologies for any dups..)

First, use NEXT_HOP=self; it’s good practice.

Your iBGP speakers will have 8.8.8.8/32 via 10.10.10.10 as an entry, for example.

Your router will then do a look-up for how to get to 10.10.10.10. It will see that this is known via the IGP (IS- IS, OSPF, Static, e.t.c.), which will have an exit interface (TenGigabitEthernet0/2, for example) toward the next-hop (10.10.10.20, for example).

And so it goes until the packet gets to 10.10.10.10.

It really is that simple.

Mark.

This e-mail and any attachment(s) contained within are confidential and are intended only for the use of the individual to whom they are addressed. The information contained in this communication may be privileged, or exempt from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete the communication without retaining any copies. Rolaware Hellas SA is not responsible for, nor endorses, any opinion, recommendation, conclusion, solicitation, offer or agreement or any information contained in this communication.

_______________________________________________
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/