246 RackSwitch G8000: Application Guide
The iBGP peers have to maintain reciprocal sessions to every other iBGP router in
the same AS (in a full-mesh manner) to propagate route information throughout the
AS. If the iBGP session shown between the two routers in AS 20 was not present
(as indicated in Figure 22), the top router would not learn the route to AS 50, and the
bottom router would not learn the route to AS 11, even though the two AS 20 routers
are connected via the RackSwitch G8000.
Figure 22. iBGP and eBGP
Typically, an AS has one or more border routers—peer routers that exchange routes
with other ASs—and an internal routing scheme that enables routers in that AS to
reach every other router and destination within that AS. When you advertise routes
to border routers on other autonomous systems, you are effectively committing to
carry data to the IPv4 space represented in the route being advertised. For
example, if you advertise 192.204.4.0/24, you are declaring that if another router
sends you data destined for any address in 192.204.4.0/24, you know how to carry
that data to its destination.
Forming BGP Peer Routers
Two BGP routers become peers or neighbors once you establish a TCP connection
between them. For each new route, if a peer is interested in that route (for example,
if a peer would like to receive your static routes and the new route is static), an
update message is sent to that peer containing the new route. For each route
removed from the route table, if the route has already been sent to a peer, an update
message containing the route to withdraw is sent to that peer.
For each Internet host, you must be able to send a packet to that host, and that host
has to have a path back to you. This means that whoever provides Internet
connectivity to that host must have a path to you. Ultimately, this means that they must
“hear a route” which covers the section of the IPv4 space you are using; otherwise,
you will not have connectivity to the host in question.
To Next Page
Loading...
Need help?
General
