I-BGP/IGP design case
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/
My thoughts and words are my own.
From: cisco-nsp [mailto:cisco-nsp-bounces@
Sent: Tuesday, September 16, 2014 9:10 AM
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
> BGP1 would be something like Rtr BGP1 can reach
> ‘18.104.22.168/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 22.214.171.124. so it can route it to my
> other IBGP router at 10.10.10.10But my IGP doesn’t have a route for
> 126.96.36.199 as I don’t redistribute BGP into IGPSo catch-22 . I’ve
> resolved this internally using tunnels between my I-BGP routers and
> 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 188.8.131.52/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.
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 email@example.com
archive at http://puck.nether.net/
> 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.
though the boxes can certainly handle BGP just fine (CRS
with the current generation RP’s).
IPv6 is still carried in the core for now, obviously.
> 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 (
> html ) or a relevant draft here (
> s-07 )
RFC 3107 is certainly a consideration when scaling end-to-
end MPLS backbones, e.g., networks with Metro-E boxes
running IP/MPLS on things such as the ME3600X.
In these cases, BGP-LS could also be interesting.
Time will tell.
Van: cisco-nsp [mailto:cisco-nsp-bounces@
Verzonden: dinsdag 16 september 2014 10:42
Aan: Rich Lewis; firstname.lastname@example.org
Onderwerp: Re: [c-nsp] I-BGP/IGP question On 16/09/2014 09:27, Rich Lewis wrote:
> I know this is good practice, but only because I’ve heard lots of
> knowledgeable!) people *say* that it’s good practice.
next-hop-self + source-interface lo0 forces the next-hop of the BGP NLRI to be the loopback interface. This means that:
1. you can fully delegate the business of optimum next-hop lookup to your IGP instead of ibgp. This is a good deal faster.
2. if there is an intermediate interface flap, ibgp will take ages to route around it and in the interim, routing loops may occur.
3. the bgp best path algorithm uses the igp metric of the bgp next-hop as a tie-breaker, so you get slightly better control of route policy calculation.
iBGP is designed for heavyweight information carrying, not reacting quickly to network topology changes. Best use an igp and depend on recursive route lookup for that.
Van: cisco-nsp [mailto:cisco-nsp-bounces@
Verzonden: dinsdag 16 september 2014 10:27
Onderwerp: Re: [c-nsp] I-BGP/IGP question On 16/09/2014 05:55, Wes Smith wrote:
> I’ve often wondered how large ISPs handle some basic IGP design issues Phil Smith’s “BGP for Internet Service Providers” presentation explains a standard approach: