Go CCIE Go!! - A Cisco Certified Internetwork Expert

Sam
You do not need a full physical mesh between all the BGP routers in your network. You will still need to have a full mesh of IBGP peerings though.
ie
Router A will need to peer with B, C, D, and E Router B will need to peer with A, C, D, and E Router C will need to peer with A, B, D, and E Router D will need to peer with A, B, C, and E Router E will need to peer with A, B, C, and D … a full IBGP mesh.
Router A does not need to be directly physically connected to B, C, D, and E as long as it has a way of communicating with those routers (ie the peer addresses are in the IGP)
Regards
Peter
–On 08 February 2007 20:28 -0500 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=117765&t=117734 ————————————————– FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html