Subject: RE: [Idr] IBGP to replace IGP

From: "john smith" <[email-masked]>
Date: Tue, 23 Mar 2004 22:43:10 +0000

Check my reply to Ben, it covers a lot of commong ground

I think you missed out the point that I was planning to put 0.0.0.0/0 in the 
intermediate nodes to cover the internet.

It is nothing buy my IGP replaced with BGP. 0.0.0.0/0 and all that being 
considered for intermediate nodes.

Route flaps are a result of "actualy flaps somewhere" and if you were to 
follow the 0.0.0.0/0 principal neither would your intermediate nodes give a 
problem.

The loops would abound in case of any IGP too when u inject 0.0.0.0/0 into 
the IGP, so maybe I didnt quite get that point

>From: "Martin, Christian" <[email-masked]>
>To: 'john smith' <[email-masked]>, "[email-masked]'" 
><[email-masked]>
>Subject: RE: [Idr] IBGP to replace IGP
>Date: Tue, 23 Mar 2004 17:35:58 -0500
>
>Smith,
>
>Comments inline, as I have been following this thread.
>
>
> >It would be great if you could share some more information on
> >the "issues"
> >of convergence time, CPU loads, and RP overloads.
>
>Convergence is typically nonlienearly proportionate to CPU load, and
>vice-versa, and they often feed off each other in a negative way.  Network
>meltdowns are typically the result of routing loads disrupting topology
>maintenance mechanisms, thereby causing adjacency loss, which causes more
>routing load, which inhibits adjacency recreation, etc.  I've seen networks
>stay in persistent "ditches" because the
>convergence-adjacency-divergence-adjaceny-...loop stayed closed due to
>loading.  Not fun to have to rebuild all of your routers or reattach them 
>to
>the network one by one...
>
> >From my understanding
> >a. it makes more sense to have 1 routing protocol as we dont
> >have multiple
> >daemons scheduled on the CPU. (which ofcourse is not a problem
> >but then so
> >is the point you mentioned below)
>
>In either case, BGP will consume the vast majority of CPU cycles.  IGPs 
>that
>are properly tuned in stable environments hardly tickle the CPU, let alone
>heat it up.  Take LSA/P refresh out of the picture, and all the IGP does is
>send hellos and occasionally flood an LSA/P and compute an SPT once in a
>rare while.  In the Internet, BGP is constantly processing updates and
>withdrawals, all day, every day.  Sometimes, we see 100s of updates per
>minute, sometimes just a few, but they are always there.
>
> >b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like we
> >inject 0.0.0.0/0 into IGP to make unknown prefixes go to the
> >nearest BGP
> >node.So does that help reduce the size of your routing table?
>
>Large SPs must run a full BGP load, at a minimum, to give routes to their
>customers.  Unless you are talking about enterprise routing, we should 
>avoid
>discussions of default routes...
>
> >c. The cases u mention of changes, I presume you mean
> >route-flaps. Well in
> >that case, we eitherways have issues when IGP flaps, we
> >eitherways wait for
> >IGP to converge for BGP to converge etc? (I am sure "real
> >traffic" operators
> >do that)
>
>Modern IGPs, properly tuned, converge way faster than BGP.  BGP convergence
>is designed to be slow, so as not to place too much load on the global
>routing system.  Since BGP carries so many routes, and since the 
>topological
>density of the Internet Autonomous System graph increases every day, BGP 
>can
>often take minutes to converge.  IGPs take seconds, partly because they are
>usually lightweight.
>
> >d. We have the benefits of not having the "global view" dependent on 1
> >protocol while the internal topology dependent on another
>
>This is actually a sound design.  Think of the IGP as a topology discovery
>mechanism.  All BGP routes have a next-hop.  The goal of BGP is to take
>traffic to and from the "edges" of the network.  Sometimes, the edge is
>within your network, like a server farm.  IGPs are very good at discovering
>a topology and identifying the shortest path to each edge.  BGP is not
>designed for this, and to make it do so requires considerable planning and
>lots of policy.
>
> >e. all i need to teach the network admins is BGP :)
>
>It is much easier to learn simple IS-IS and OSPF than BGP.  Link State 
>IGPs,
>when employed for topology discovery, are exceedingly simple (particularly
>IS-IS in a single area).  BGP, on the otherhand, is a much bigger protocol
>that requires a lot of policy engineering in order for it to be effective.
>
> >f. Based on c, how would you say that it makes things more
> >complicated to
> >run iBGP only compared to IGP+0.0.0.0/0 (default originate and
> >originate
> >always) and all those things taken into consideration?
>
>Are you talking about running in an enterprise?  Default routes will not
>work in any large environment for next-hop discovery of your iBGP peer 
>IP's.
>Loops would abound...
>
>
>One of the problems with your proposal, and the primary reason this is not
>done, is that iBGP does not provide for transitive route dissemination in a
>network.  All 'other' IGPs do this.  This means your network topology must
>be highly symmetrical and/or fully meshed at layer 3 (at least in
>subsections) to allow for end-to-end route propagation.  Unless you can
>employ lots of confeds (ie, each router in a confed subAS), lots of
>route-reflectors, or a full-mesh topology at layer 3 (and layer 2 if you
>consider multiaccess networks fully-meshed), then this approach is not
>possible.
>
>BGP also has race-condition mitigation rules that prevent a BGP route from
>being learned from a next-hop that is known via BGP, so injecting routes
>into BGP and hoping to bootstrap the next-hops would be problematic.  This
>restriction is subtle and perhaps vendor specific, but usually, the 
>next-hop
>is recursed through an IGP or connected interface.  If this were possible,
>in any event, it would be slow-converging, as iBGP updates are typically
>spaced at 5 second intervals (depending on the event type).  Also, you will
>have to peer with every interface on the device, thus forcing traffic to
>take certain paths that may not be the best path available, as most BGP
>attributes are non-accumulating (ie, u have to statically increase, say,
>local-pref via policy as routes propagate along a set of routers in your
>AS).
>
>The reality is that even if such an approach _were_ possible, the drawbacks
>are much more severe than simply turning on an IGP and having it discover
>your topology.  Then, you may do what you with with iBGP.
>
>The best philosophy, IMO, is to place loopbacks and links in your IGP, and
>carry externals (either self-originated or from another AS) in your iBGP.
>Route-reflectors are useful if regionalized, as they make best path
>decisions before reflecting (so u want to be careful who peers with what to
>ensure path selection optimality).  Confeds afford more control, TE, etc.,
>but at what some claim to be a higher admin cost.  Use them based on what
>you are trying to do.
>
>HTH,
>Chris
>
> >would be great if you could help clarify this.
> >
> >-Smith
> >
>
>
>
>
>
>
> >
> >
> >
> >
> >You could certainly run BGP and statics without another
> >protocol for the
> >IGP, but why would you want to? Convergence times, CPU load on
> >RPs, etc.,
> >during changes would be rather unsatisfactory. If you want to run one
> >dynamic protocol at all costs, then what you describe below
> >will work, and
> >has worked for some, but people with real traffic don't waste
> >their time
> >with it.
> >
> >
> >Ben
> >
> >On Mar 15, 2004, at 8:24 PM, John Smith wrote:
> >
> >
> >Hi,
> >
> >I am very clear with the concept that IGPs cannot be used to carry the
> >entire BGP feed as
> >they cant be scaled to carry so many prefixes (even assuming
> >we add enough
> >TLVs to make
> >them carry the BGP attributes).
> >
> >What is not very clear to me is, why cant we use IBGP inside an AS to
> >completely do away
> >with IGPs. IGPs compute the best path to reach a particular
> >neighbor based
> >on the link
> >metric. This can be achieved in BGP also, if we include a TLV
> >to carry the
> >link cost.
> >Moreover, it is *mandatory* to run BGP on all the routers if we are
> >transiting traffic,
> >because if a router isnt speaking BGP then it cant forward BGP traffic.
> >
> >Cant we do away with IGPs (say in some small networks) and run
> >only IBGP
> >there?
> >
> >Any help/clues/pointers in this regard will be really appreciated.
> >
> >Regards,
> >Smith
> >
> >_________________________________________________________________
> >Tired of spam? Get advanced junk mail protection with MSN 8.
> >http://join.msn.com/?page=features/junkmail
> >
> >
> >_______________________________________________
> >Idr mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/idr
> >

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
http://join.msn.com/?page=features/virus

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Benjamin Black <[email-masked]>
Date: Tue, 23 Mar 2004 15:01:43 -0800

from the sound of things you don't need bgp at all, except to announce 
routes to your upstreams.  rejecting all routes from a peer tends to 
limit the size of adj-rib-in as well as reduce the cpu load of route 
flaps.  handle the rest with an igp and a default and you are done (and 
your network admins need know almost nothing about bgp).

ben

On Mar 23, 2004, at 2:43 PM, john smith wrote:

> I think you missed out the point that I was planning to put 0.0.0.0/0 
> in the intermediate nodes to cover the internet.
>
> It is nothing buy my IGP replaced with BGP. 0.0.0.0/0 and all that 
> being considered for intermediate nodes.
>
> Route flaps are a result of "actualy flaps somewhere" and if you were 
> to follow the 0.0.0.0/0 principal neither would your intermediate 
> nodes give a problem.
>
> The loops would abound in case of any IGP too when u inject 0.0.0.0/0 
> into the IGP, so maybe I didnt quite get that point
>
>> loading.  Not fun to have to rebuild all of your routers or reattach 
>> them to
>> In either case, BGP will consume the vast majority of CPU cycles.  
>> IGPs that
>> customers.  Unless you are talking about enterprise routing, we 
>> should avoid
>> density of the Internet Autonomous System graph increases every day, 
>> BGP can
>> It is much easier to learn simple IS-IS and OSPF than BGP.  Link 
>> State IGPs,
>> work in any large environment for next-hop discovery of your iBGP 
>> peer IP's.
>> Loops would abound...
>>
>>

---

From: Benjamin Black <[email-masked]>
Date: Tue, 23 Mar 2004 15:01:43 -0800

ben