Go CCIE Go!! - A Cisco Certified Internetwork Expert

Thx Peter,
Thanks for clear up the question.
Thanks.
Br,
Sam
On 2/9/07, Sam Fok wrote: > > 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=117766&t=117734 ————————————————– FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html