Internal BGP Between Internet-Connected Routers ccsp bootcamp training center in delhi ncr

Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192

When an Enterprise uses more than one router to connect to the Internet, and those
routers use BGP to exchange routing information with their ISPs, those same routers need
to exchange BGP routes with each other as well. The BGP neighbor relationships occur inside
that Enterprise–inside a single AS–making these routers iBGP peers.
This first major section of Chapter 14 begins with a look at why two Internet-connected
routers need to have an iBGP neighbor relationship. Then, the text looks at various iBGP
configuration and verification commands. Finally, discussion turns to a common issue that
occurs with next-hop reachability between iBGP peers, with an examination of the options
to overcome the problem.
Establishing the Need for iBGP with Two Internet-Connected Routers
Two Internet-connected routers in an Enterprise need to communicate BGP routes to each
other because these routers may want to forward IP packets to the other Internet-connected
router, which in turn would forward the packet into the Internet. With an iBGP
peer connection, each Internet-connected router can learn routes from the other router
and decide if that other router has a better route to reach some destinations in the Internet.
Without that iBGP connection, the routers have no way to know if the other router
has a better BGP path.
For example, consider Figure 14-2, which shows two such cases. The figure shows a topology
that uses the following design options, as agreed upon with ISP1 and ISP3:
ASN 3 ISP3
ASN 1 ISP1
To 181.0.0.0/8
ASN 2 ISP2
I3-1
I1-1
460 CCNP ROUTE 642-902 Official Certification Guide
■ ISP1 sends full routing updates and a default route.
■ ISP3 sends partial updates and a default route.
First, consider the eBGP routing updates, particularly for the two prefixes highlighted in
the figure. Both ISP1 and ISP3 know routes for 181.0.0.0/8, but ISP3’s agreement with the
Enterprise is that ISP3 sends partial updates. This usually means ISP3 sends updates for
prefixes in its own ASN plus prefixes for customers attached to its ASN, such as
192.135.250.0/28 in this case. ISP1, however, sends full updates, so E1 learns an eBGP
route for both 181.0.0.0/8 and 192.135.250.0/28, but Router E2 only learns an eBGP route
for 192.135.250.0/28.
Next, take a closer look at the routes for 181.0.0.0/8, both on E1 and E2. Only E1 learns an
eBGP route for 181.0.0.0/8; E2 does not, because of ISP3’s partial updates. If E1 and E2
did not use iBGP between each other, E2 would never know that E1 had a good route for
181.0.0.0/8. So, without an iBGP connection, packets destined to hosts in 182.0.0.0/8 if
they arrived at E2 would be sent to ISP3 because of E2’s default route learned from ISP3.
However, if E1 and E2 form an iBGP neighbor relationship, E2 would know a route for
181.0.0.0/8 through E1 and would choose this route as its best route and would forward
such packets to E1. Then E1 would forward the packets to ISP1, as shown in the figure.
Finally, take a closer look at the routes for 192.135.250.0/28 on both E1 and E2. If none of
the ISPs changed the default PA settings for these routes, both E1 and E2 would choose
the route through E2 as the better route, due to the shorter AS_Path length (two ASNs
away through ISP3 versus four ASNs away through ISP1). Without iBGP between E1 and
E2, E1 would not learn of this better route through E2, so any packets destined to
192.135.250.0/28 that reach E1 would be forwarded to ISP1. With iBGP, E1 would know
of E2’s better route and forward the packets toward E2, as shown in the figure.
For both prefixes, iBGP allowed both routers in the same ASN to reach the same conclusion
about the better router through which to send packets for each Internet destination.
Configuring iBGP
The most basic iBGP configuration differs only slightly compared to eBGP configuration.
The configuration does not explicitly identify an eBGP versus an iBGP peer. Instead, for
iBGP, the neighbor’s ASN listed on the neighbor... remote-as neighbor-asn command lists
the same ASN as the local router’s router bgp command. eBGP neighbor remote-as commands
list a different ASN.
When two iBGP peers share a common physical link, such as E1 and E2 in Figure 14-1, the
iBGP configuration simply requires a single neighbor remote-as command on each router.
Example 14-1 shows the BGP configuration on both Router E1 and E2 with this single
neighbor command highlighted. The rest of the configuration lists the commands used to
configure other BGP settings (as described after the example). Note that Figure 14-1 in
the introduction to this chapter shows more detail about the eBGP peers as well.
www.CareerCert.info
Chapter 14: Internal BGP and BGP Route Filtering 461
Example 14-1 BGP Configuration on E1: Neighborships Configured
! Configuration on router E1
router bgp 11
no synchronization
bgp log-neighbor-changes
aggregate-address 128.107.0.0 255.255.224.0 summary-only
redistribute ospf 1 route-map only-128-107
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 password fred
neighbor 1.1.1.1 ebgp-multihop 2
neighbor 1.1.1.1 update-source Loopback1
neighbor 10.1.1.10 remote-as 11
no auto-summary
!
! Next, static routes so that the eBGP neighbor packets can reach
! I1-1’s loopback interface address 1.1.1.1
ip route 1.1.1.1 255.255.255.255 Serial0/0/0
ip route 1.1.1.1 255.255.255.255 Serial0/0/1
!
ip prefix-list 128-107 seq 5 permit 128.107.0.0/19 le 32
!
route-map only-128-107 permit 10
match ip address prefix-list 128-107 Neighbor 192.168.1.2 remote-as 3
! Now, on router E2
router bgp 11
no synchronization
bgp log-neighbor-changes
network 128.107.32.0
aggregate-address 128.107.0.0 255.255.224.0 summary-only
redistribute ospf 1 route-map only-128-107
neighbor 10.1.1.9 remote-as 11
neighbor 192.168.1.6 remote-as 3
neighbor 192.168.1.6 password barney
no auto-summary
!
ip prefix-list 128-107 seq 5 permit 128.107.0.0/19 le 32
!
route-map only-128-107 permit 10
match ip address prefix-list 128-107 Neighbor 192.168.1.2 remote-as 3
Only the four highlighted configuration commands are required for the E1-E2 iBGP peering.
Both refer to the other router’s IP address on the FastEthernet link between the two
routers, and both refer to ASN 11. The two routers then realize the neighbor is an iBGP
neighbor because the neighbor’s ASN (11) matches the local router’s ASN, as seen on the
router bgp 11 command.
www.CareerCert.info
462 CCNP ROUTE 642-902 Official Certification Guide
The example also lists the rest of the BGP configuration. Focusing on Router E1, the configuration
basically matches the configuration of Router E1 from the end of Chapter 13,
except that E1 has only one eBGP peer (I1-1) in this case instead of two eBGP peers. The
configuration includes the eBGP peer connection to I1-1, using loopback interfaces (1.1.1.1
on I1-1 and 11.11.11.11 on E1). The eBGP peers need to use eBGP multihop because of
the use of the loopbacks, and they use MD5 authentication as well. Finally, the configuration
shows the redistribution of the Enterprise’s public address range of 128.107.0.0/19 by
redistributing from OSPF and summarizing with the aggregate-address BGP subcommand.
E2’s configuration lists the same basic parameters, but with a few differences. E2 does not
use a loopback for its peer connection to I3-1, because only a single link exists between
the two routers. As a result, E2 also does not need to use eBGP multihop.
Refocusing on the iBGP configuration, Example 14-1 uses the interface IP addresses of
the links between Routers E1 and E2. However, often the Internet-connected routers in an
Enterprise do not share a common subnet. For example, the two routers may be in separate
buildings in a campus for the sake of redundancy. The two routers may actually be in
different cities, or even different continents. In such cases, it makes sense to configure the
iBGP peers using a loopback IP address for the TCP connection so that a single link failure
does not cause the iBGP peer connection to fail. For example, in Figure 14-1, if the
FastEthernet link between E1 and E2 fail, the iBGP connection defined in Example 14-1,
which uses the interface IP addresses of that link, would fail even though a redundant IP
path exists between E1 and E2.
The configuration to use loopback interfaces as the update source mirrors that same configuration
for eBGP peers, except that iBGP peers do not need to configure the
neighbor... ebgp-multihop command. One difference between iBGP and eBGP is that IOS
uses the low TTL of 1 for eBGP connections by default but does not for iBGP connections.
So, for iBGP connections, only the following steps are required to make two iBGP
peers use a loopback interface:
Step 1. Configure an IP address on a loopback interface on each router.
Step 2. Configure each router to use the loopback IP address as the source IP address,
for the neighborship with the other router, using the neighbor... update-source
ip-address command.
Step 3. Configure the BGP neighbor command on each router to refer to the other
router’s loopback IP address as the neighbor IP address in the neighbor
neighbor-ip remote-as command.
Step 4. Make sure each router has IP routes so that they can forward packets to the
loopback interface IP address of the other router.
Example 14-2 shows an updated iBGP configuration for Routers E1 and E2 to migrate to
use a loopback interface. In this case, E1 uses loopback IP address 10.100.1.1/32 and E2
uses 10.100.1.2/32. OSPF on each router has already been configured with a network
10.0.0.0 0.255.255.255 area 0 command (not shown), which then causes OSPF to advertise
routes to reach the respective loopback interface IP addresses.
Key
Topic
www.CareerCert.info
Chapter 14: Internal BGP and BGP Route Filtering 463
Example 14-2 iBGP Configuration to Use Loopbacks as the Update Source
! Configuration on router E1
interface loopback 0
ip address 10.100.1.1 255.255.255.255
router bgp 11
neighbor 10.100.1.2 remote-as 11
neighbor 10.100.1.2 update-source loopback0
! Configuration on router E2
interface loopback 1
ip address 10.100.1.2 255.255.255.255
router bgp 11
neighbor 10.100.1.1 remote-as 11
neighbor 10.100.1.1 update-source loopback1
The highlighted portions of the output link the key values together for the E1’s definition
of its loopback as the update source and E2’s reference of that same IP address on its
neighbor command. The neighbor 10.100.1.2 update-source loopback0 command on E1
tells E1 to look to interface loopback0 for its update source IP address. Loopback0’s IP address
on E1 has IP address 10.100.1.1. Then, E2’s neighbor commands for Router E1 all refer
to that same 10.100.1.1 IP address, meeting the requirement that the update source on
one router matches the IP address listed on the other router’s neighbor command.
Verifying iBGP
iBGP neighbors use the same messages and neighbor states as eBGP peers. As a result, the
same commands in Chapter 13 for BGP neighbor verification can be used for iBGP peers.
Example 14-3 shows a couple of examples, using Router E1’s iBGP neighbor relationship
with E2 (10.100.1.2) based on the configuration in Example 14-2.
Example 14-3 Verifying iBGP Neighbors
E1# show ip bgp summary
BGP router identifier 11.11.11.11, local AS number 11
BGP table version is 190, main routing table version 190
11 network entries using 1452 bytes of memory
14 path entries using 728 bytes of memory
11/7 BGP path/bestpath attribute entries using 1628 bytes of memory
7 BGP AS-PATH entries using 168 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 3 (at peak 4) using 96 bytes of memory
BGP using 4072 total bytes of memory
BGP activity 31/20 prefixes, 100/86 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 1 339 344 190 0 0 00:28:41 7
10.100.1.2 4 11 92 132 190 0 0 01:02:04 3
www.CareerCert.info
464 CCNP ROUTE 642-902 Official Certification Guide
E1# show ip bgp neighbors 10.100.1.2
BGP neighbor is 10.100.1.2, remote AS 11, internal link
BGP version 4, remote router ID 10.100.1.2
BGP state = Established, up for 01:02:10
Last read 00:00:37, last write 00:00:59, hold time is 180, keepalive interval
is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(new)
Address family IPv4 Unicast: advertised and received
! lines omitted for brevity
The show ip bgp summary command lists E1’s two neighbors. As with eBGP peers, if the
last column (the State/PfxRcd column) lists a number, then the neighbor has reached established
state, and BGP Update messages can be sent. The output can distinguish between
an iBGP or eBGP neighbor but only by comparing the local router’s ASN (in the
first line of output) to the ASN listed in each line at the bottom of the output.
The show ip bgp neighbors 10.100.1.2 command lists many details specifically for the
neighbor. In particular, it states that the neighbor is an iBGP neighbor with the phrase “internal
link,” as highlighted in the output.
Examining iBGP BGP Table Entries
To better understand the BGP table with two (or more) Internet-connected routers inside
the same company, start with one prefix, and compare the BGP table entries on the two
routers for that one prefix. By examining several such examples, you can appreciate more
about the benefits and effects of these iBGP neighborships.
This section examines the BGP tables on Routers E1 and E2, focusing on the prefixes
highlighted in Figure 14-2–namely, prefixes 181.0.0.0/8 and 192.135.250.0/28. To make
reading the output of the show commands a little more obvious, Figure 14-3 collects
some key pieces of information into a single figure. This figure shows the two BGP neighbor
relationships on each router, showing the update source and neighbor IP address of
each BGP neighbor relationship. It also lists the BGP RID of the routers.
Examples 14-4 and 14-5 compare the output on Routers E2 and E1 for prefix 181.0.0.0/8.
Example 14-4 lists output on Router E2, listing the BGP table entries for prefix
181.0.0.0/8. Remember, the design calls for ISP3 to only send partial updates, so E2 has
not received an eBGP route for 181.0.0.0/8 from I3-1. However, E1 has indeed learned of
that prefix from I1-1 (ISP1), and E1 has already advertised prefix 181.0.0.0/8 to E2.
Note: Several BGP routes seen in the examples in this chapter originate in ASNs not
shown in the figure. The figure shows enough of the topology to understand the first few
ASNs in the AS_Path for these routes.
The first command, show ip bgp 181.0.0.0/8 longer-prefixes, lists output with the same
general format as the show ip bgp command, but it limits the output to the prefixes in the
listed range. Only one such route exists in this case. The legend information at the top of
the output, plus the headings and meanings of the different fields, is the same as with the
show ip bgp command.
Next, the first command’s output denotes this route as an iBGP-learned route with code
“i” in the third character. The second command in the example, show ip bgp 181.0.0.0/8,
which displays a more detailed view of the BGP table entry and denotes this route as
iBGP-learned with the word “internal.” Similarly, the briefer show ip bgp 181.0.0.0/8 command
output lists this one route as E2’s best route by displaying a > in the second column,
whereas the more verbose output in the second command simply lists this route as “best.”
Next, consider these same commands on Router E1, as shown in Example 14-5. Comparing
the highlighted fields as matched in each of the examples:
■ Both list the same AS_Path (1, 2, 111, 112) because iBGP peers do not add ASNs to
the AS_Path when advertising to each other. So, both E1 and E2 have the same perspective
on the AS_Path and AS_Path length.
■ Both list the one route for 181.0.0.0/8 as the best path in part because each has
learned only one such path.
■ Both list a next_hop (a BGP PA) as 1.1.1.1, which is I1-1’s loopback interface used in
the E1 to I1-1 BGP neighbor relationship (also called the BGP neighbor ID).
■ E2 lists the route as an internal (iBGP-learned) route, whereas E1 lists it as an external
route.
Example 14-5 Router E1’s show Commands for BGP Routes for 181.0.0.0/8
E1# show ip bgp 181.0.0.0/8 longer-prefixes
BGP table version is 190, local router ID is 11.11.11.11
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 181.0.0.0/8 1.1.1.1 0 1 2 111 112 i
E1# show ip bgp 181.0.0.0/8
BGP routing table entry for 181.0.0.0/8, version 181
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
2
1 2 111 111, (received & used)
1.1.1.1 from 1.1.1.1 (1.1.1.1)
Origin IGP, localpref 100, valid, external, best
www.CareerCert.info
Chapter 14: Internal BGP and BGP Route Filtering 467
The output from these examples confirms that E1 learned the eBGP route for 181.0.0.0/8,
advertised it to E2, and E2 chose to use that iBGP learned route as its best route to reach
181.0.0.0/8.
Next, consider the route for 192.135.250.0/28, a route learned in the full BGP updates
from ISP1’s Router I1-1 and in the partial BGP updates from ISP3’s Router I3-1. After exchanging
this route using their iBGP peering, both E1 and E2 should see two possible
routes: an eBGP route learned from their one connected ISP and the iBGP route learned
from each other. Again assuming that the ISPs have not made any attempt to set PA values
to influence the best path choice, and knowing the neither E1 nor E2 have configured
BGP to influence the best path choice, the route through E2 should be best because of
the shorter AS_Path.
Example 14-6 shows the output of the show ip bgp command on both E1 and E2, again
for comparison. Note that the command used in the examples, show ip bgp
192.135.250.0/28 longer-prefixes, is used because it lists only the routes for that prefix,
rather than the full BGP table displayed by show ip bgp, but the format of the output is
almost identical.
Example 14-6 Comparing BGP Routes for 192.135.250.0/28 on E1 and E2
! First, on E1:
E1# show ip bgp 192.135.250.0/28 longer-prefixes
BGP table version is 26, local router ID is 128.107.9.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 192.135.250.0/28 1.1.1.1 0 1 2 3 4 i
*>i 192.168.1.6 0 100 0 3 4 i
! Next, on E2:
E2# show ip bgp 192.135.250.0/28 longer-prefixes
BGP table version is 25, local router ID is 10.100.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 192.135.250.0/28 192.168.1.6 0 3 4 i
First, E1 lists two routes for this prefix, one external and one internal. The output identifies
external routes by the absence of an “i” in the third character, whereas the output lists
an “i” in the third character for internal routes. In this case, E1’s internal route, with
next_hop 192.168.1.6, is E1’s best route, as was shown back in Figure 14-2. E1 chose this
iBGP route because of the shorter AS_Path length; the AS_Path is highlighted at the end
of each line.
www.CareerCert.info
E2’s output in the second half of Example 14-6 lists only a single route–its eBGP route for
192.135.250.0/28. That only one route appears, rather than two, is a good example of the
effect of two rules about how BGP operates:
■ Only advertise the best route in any BGP Update.
■ Do not advertise iBGP-learned routes to iBGP peers.
E2’s output lists a single route for 192.135.250.0/28—its external route learned from
ISP3—because E1 chooses not to advertise a route for 192.135.250.0/28 over the iBGP
connection. If you look back at E1’s output, E1’s best route for this prefix is its internal
route; so, if E1 were to advertise any route for this prefix to E2, E1 would advertise this internal
route, because it is E1’s best BGP route for that prefix. However, the second rule–do
not advertise iBGP-learned routes to iBGP peers–prevents E1 from advertising this route
back to E2. (Logically speaking, it makes no sense for E1 to tell E2 about a route when E2
is the router that originally advertised the route to E1 in the first place—a concept much
like Split Horizon, although technically the term does not apply to BGP.) As a result, E2
lists a single route for 192.135.250.0/28.
Note that if the route for 192.135.250.0/28 through ISP3 failed, then E1 would start using
the route through ISP1 as its best route. E1 would then advertise that best route to E2 that
could then forward traffic through E1 for destinations in 192.135.250.0/28.
Understanding Next-Hop Reachability Issues with iBGP
With IGPs, the IP routes added to the IP routing table list a next-hop IP address. With few
exceptions, the next-hop IP address routes exist in a connected subnet. For example, the
E1-E2 iBGP connection uses loopback interfaces 10.100.1.1 (E1) and 10.100.1.2 (E2). E1’s
OSPF-learned route to reach 10.100.1.2 lists outgoing interface Fa0/1, next-hop
10.1.1.10–an address in the LAN subnet that connects E1 and E2. (See Figure 14-3 a few
pages back for reference.)
Examples 14-5 and 14-6 also happened to show two examples of iBGP-learned routes and
their next-hop addresses. The next-hop addresses were not in connected subnets; the nexthop
addresses were not even IP addresses on a neighboring router. The two examples were
as follows; again, it may be helpful to refer to the notations in Figure 14-3:
■ Example 14-4: E2’s route for 181.0.0.0/8 lists next-hop address 1.1.1.1, a loopback interface
IP address on I1-1.
■ Example 14-6: E1’s route for 192.135.250.0/28 lists next-hop address 192.168.1.6,
which is I3-1’s interface IP address on the link between E2 and I3-1.
In fact, in the case of Example 14-4, the output of the show ip bgp 181.0.0.0/8 command
on E2 listed the phrase “1.1.1.1 from 10.100.1.1 (11.11.11.11)”. This phrase lists the next hop
(1.1.1.1) of the route, the neighbor from which the route was learned (10.100.1.1 or E1) and
the neighbor’s BGP RID (11.11.11.11, as listed in Figure 14-3).
BGP advertises these particular IP addresses as the next-hop IP addresses because of a default
behavior for BGP. By default, when a router advertises a route using eBGP, the advertising
router lists its own update-source IP address as the next-hop address of the route. In
other words, the next-hop IP address is the IP address of the eBGP neighbor, as listed on
468 CCNP ROUTE 642-902 Official Certification Guide
www.CareerCert.info
Chapter 14: Internal BGP and BGP Route Filtering 469
the neighbor remote-as command. However, when advertising a route to an iBGP peer,
the advertising router (by default) does not change the next-hop address. For example,
when I1-1 advertises 181.0.0.0/8 to E1, because it is an eBGP connection, I1-1 sets its own
IP address (1.1.1.1)–specifically the IP address I1-1 uses on its eBGP peer connection to
E1—as the next-hop. When E1 advertises that same route to iBGP peer E2, E1 does not
change the next-hop address of 1.1.1.1, so router E2’s iBGP-learned route lists 1.1.1.1 as the
next-hop address.
The IP routing process can use routes whose next-hop addresses are not in connected
subnets as long as each router has an IP route that matches the next-hop IP address. So, engineers
must understand these rules about how BGP sets the next-hop address and ensure
each router can reach the next-hop address listed in the BGP routes. Two main options exist
to ensure reachability to these next-hop addresses:
■ Create IP routes so that each router can reach these next-hop addresses that exist in
other ASNs.
■ Change the default iBGP behavior with the neighbor next-hop-self command.
The text now examines each of these two options in more detail.
Ensuring Routes Exist to the Next-Hop Address
Routers can still forward packets using routes whose next-hop addresses are not in connected
subnets. To do so, when forwarding packets, the router performs a recursive route
table lookup. For example, for packets arriving at E2 with a destination of 181.0.0.1, the
following would occur:
Step 1. E2 would match the routing table for destination address 181.0.0.1, matching
the route for 181.0.0.0/8, with next hop 1.1.1.1.
Step 2. E2 would next look for its route matching destination 1.1.1.1–the next-hop of
the first route–and forward the packet based on that route.
So, no matter the next-hop IP address listed in the routing table, as long as a working route
exists to reach that next-hop IP address, the packet can be forwarded. Figure 14-4 shows
the necessary routes in diagram form using two examples. E1 has a route to
192.135.250.0/28 with next hop 192.168.1.6; two arrowed lines show the required routes
on Routers E1 and E2 for forwarding packets to this next-hop address. Similarly, the
dashed lines also show the necessary routes on E2 and E1 for next-hop address 1.1.1.1, the
next-hop IP address for their routes to reach 181.0.0.0/8.
Two easily implemented solutions exist to add routes for these nonconnected next-hop IP
addresses: Either add static routes or use an IGP between the Enterprise and the ISPs for
the sole purpose of advertising these next-hop addresses.
Using neighbor... next-hop-self to Change the Next-Hop Address
The second option for dealing with these nonconnected next-hop IP addresses changes
the iBGP configuration so that a router changes the next-hop IP address on iBGP-advertised
routes. This option simply requires the neighbor neighbor-ip next-hop-self comwww.
CareerCert.info
470 CCNP ROUTE 642-902 Official Certification Guide
Loopback
1.1.1.1
I3-1
E1 I1-1
E2
to 1.1.1.1
to
1.1.1.1
to 192.168.1.6
Destination
192.168.1.6
Next-Hop
E2
Destination
1.1.1.1
Next-Hop
E1
192.168.1.6
to 192.168.1.6
Figure 14-4 Ensuring Routes Exist for Next-Hop Addresses in Other ASNs
mand to be configured for the iBGP neighbor relationship. A router with this command
configured advertises iBGP routes with its own update-source IP address as the next-hop
IP address. And because the iBGP neighborship already relies on a working route for these
update source IP addresses, if the neighborship is up, then IP routes already exist for these
next-hop addresses.
For example, on the iBGP connection from E1 to E2, E1 would add the neighbor
10.100.1.2 next-hop-self command, and E2 would add the neighbor 10.100.1.1 next-hopself
command. When configured, E1 advertises iBGP routes with its update source IP address
(10.100.1.1) as the next-hop address. E2 likewise advertises routes with a next-hop
address of 10.100.1.2. Example 14-7 shows E2’s BGP table, with a few such examples highlighted,
after the addition of these two configuration commands on the respective routers.
Example 14-7 Seeing the Effects of next-hop-self from Router E2
E2#show ip bgp
BGP table version is 76, local router ID is 10.100.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 192.168.1.6 0 0 3 i
* i 10.100.1.1 0 100 0 1 i
* i128.107.0.0/19 10.100.1.1 0 100 0 i
*> 0.0.0.0 32768 i
Key
Topic
www.CareerCert.info
Chapter 14: Internal BGP and BGP Route Filtering 471
s> 128.107.1.0/24 10.1.1.77 2 32768 ?
s> 128.107.2.0/24 10.1.1.77 2 32768 ?
s> 128.107.3.0/24 10.1.1.77 2 32768 ?
*>i181.0.0.0/8 10.100.1.1 0 100 0 1 2 111 112 i
*>i182.0.0.0/8 10.100.1.1 0 100 0 1 2 222 i
*>i183.0.0.0/8 10.100.1.1 0 100 0 1 2 i
*>i184.0.0.0/8 10.100.1.1 0 100 0 1 2 i
*>i185.0.0.0/8 10.100.1.1 0 100 0 1 2 i
*> 192.135.250.0/28 192.168.1.6 0 3 4 i
This completes the discussion of iBGP configuration and operation as related to the
routers actually connected to the Internet. The next section continues the discussion of
iBGP but with a focus on some particular issues with routing that may require iBGP on
routers other than the Internet-connected routers.