Go CCIE Go!! - A Cisco Certified Internetwork Expert

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=117736&t=117734 ————————————————– FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html