Go CCIE Go!! - A Cisco Certified Internetwork Expert

Thx Peter,
I am wonder why i still need full-mesh when IGP makes all routers can access other directly or indirectly. For example:
Edge A —-B —–C ——D ——-Edge E
In above, A and E don’t have direct connect to C, but we still can use IGP to let A/E to form IBGP and thus i don’t need full mesh in this case. right? I am afraid I confused the term ‘full physical mesh’ with ‘full IBGP mesh’?
Thanks. Br,
Sam
On 2/8/07, Peter Walker wrote: > > Sam > > Responses in-line > > –On 08 February 2007 03:48 -0500 Sam Fok wrote: > > > Dear all, > > > > I am studying BGP, and have some question on BGP scalability. > > > > Since BGP won’t advertise route between IBGP, so we need > > Yep. BGP uses AS-PATH for loop prevention. As IBGP does not modify > AS-PATH we can not use AS-PATH to detect a loop within an AS. To get > around this BGP adds a rule that says that prefixes received via IBGP > can not be advertised back out via IBGP. > > This has the net effect that every BGP speaking router within an AS > must form a neighbor relationship with every other BGP speaking > router in the AS. > > > full-mesh between BGP peer, otherwise blackhole occurs. But this > > solution is high cost. Right? (Is it assumed that no IGP running > > inside the AS?) > > This solution is not necessarily high cost. In a small network with > only a few BGP routers it is fine. The problem is that it does not > scale very well. > > 2 IBGP routers require 1 IBGP session > 3 IBGP routers require 3 IBGP sessions > 4 IBGP routers require 6 IBGP sessions > 5 IBGP routers require 10 IBGP sessions > > 10 IBGP routers require 45 IBGP sessions > > > > > Or we can use either route-reflector or confederation instead > > of full-mesh. Right? > > Yes, we can either change the rules about IBGP routers forwarding > IBGP routes and create a special type of BGP router that is allowed > to forward IBGP routes under certain conditions, or we can break down > our large AS into multiple virtual sub autonoumous systems. > > > > Isn’t it we can use IGP inside the AS to let the edge router > > to form IBGP peers with all the routers and thus eliminate the need > > to use route-reflector or confederation? If so, that mean IGP + > > IBGP can solve the problem? > > I am not sure but I think you may be confusing two issues here. > > IBGP neighbors do not need to be directly connected to each other, as > long as they are both able to route packets to each other. This may > be done with static routes, or more commonly via the IGP that is > being used in the AS. The use of an IGP to route packets between to > IBGP neighbors, does not remove the need for BGP speaking routers > within an AS to have a full mesh between them. > > If your AS is not a transit AS then you do not necessarily need BGP > speaking routers anywhere other than at your network edge. These > routers can peer with each other across your network. > > If you have a transit AS (ie packets are allowed to enter on one edge > of your network and exit at another edge) then you have an additional > requirement. > > Edge ]—- (A) —– (B) —– (C) —-[ Edge > > In the above diagram if a packet arriving at the edge connected to > Router A should be routed out at the edge connected to Router C then > we have three basic routing requirements. > > 1) Router C must know that the destination is reachable via its edge > connection. > > It can learn this via an EBGP relationship with an external peer > > 2) Router A must know that the destination is reachable across the AS. > > It can learn that router C knows how to route to > the destination via an IBGP relationship with Router C > > It can also learn how to route packets towards Router > C (the next hop) from the IGP or a static route. > > 3) Router B must also know that the destination is reachable via > router C. > > It should learn this via an IBGP relationship with router C > > It should also be noted that for packets to return router B must also > be able to route back to the original source via A. To do this it > must also have an IBP relationship with router A > > —– > > To summarise, every router that transit packets travel through must > also have full routing information. The easiest way to do this is for > it to be part of the IBGP mesh. > > Another way to ensure this is the case might be to redistribute the > full BGP routing table into the IGP but this has its own problems > (how many IGPs do you know that can handle 200,000+ destinations). > > > > > > While for synchronization, if a BGP route to be advertised, it > > requires the next-hop of the BGP route be accessible (in the > > routing table). That means again we need either > > full-mesh/route-reflector/confederation/IGP, right? > > Wrong. > > For a BGP route to be used the next hop must be reachable. That is > correct. However that is not synchronisation. > > Synchronisation is the requirement that each prefix must also be > present in the IGP table before it can be advertised. This may have > made sense in the days that the internet routing table was only a few > thousand prefixes. We have over 200,000 prefixes advertised on the > internet nowdays. It just isn’t feasible to redistribute these all > into our IGPs. > > > > I heard that there is rare to enable synchronization in the > > real world, is it because IGP already handle the problem? > > As it isn’t really feasible to have the full internet routing table > in our IGP, then it doesn’t make sense to require a route to be in > the IGP before we advertise it. > > > > > Please correct me. > > Hope that helps > > > > Thanks. > > > > Br, > > > > Sam > > > > > > > Regards > > Peter

Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=117764&t=117734 ————————————————– FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html