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
A typical Enterprise network design uses default routes inside the Enterprise, as advertised
by the IGP, to draw all Internet traffic toward one or more Internet-connected
routers. The Internet-connected routers then forward the traffic into the Internet.
However, as discussed in Chapter 12, “Internet Connectivity and BGP,” in the section
“Choosing One Path over Another Using BGP,” routing loops can occur when the Internet-
connected routers do not have a direct connection to each other. For example, if the
Internet-connected routers sit on opposite sides of the country, the two routers may be
separated by several other internal routers in the Enterprise because they do not have a direct
link.
To show a simple example, the same Enterprise network design shown in all previous figures
in this chapter can be changed slightly by just disabling the FastEthernet link between
the two routers, as shown in Figure 14-5.
Figure 14-5 shows an example of the looping problem. The figure uses the same general
criteria as the other examples in this chapter, so that E1’s best route for 192.135.250.0/28
points to Router E2 as the next hop. E1’s best route for the next-hop IP address for its
route to 192.135.250.0/28–regardless of whether using next-hop self or not–sends the
packet back toward the Enterprise core. However, some (or possibly all) of the Enterprise
routers internal to the Enterprise, such as WAN1 and Core1, use a default that sends all
packets toward Router E1. Per the steps in the figure, the following happens for a packet
destined to 192.135.250.1:
Step 1. WAN1 sends the packet using its default route to Core1.
Step 2. Core1 sends the packet using its default route to E1.
Step 3. E1 matches its BGP route for 192.135.250.0/28, with next hop E2 (10.100.1.2);
the recursive lookup on E1 matches a route for 10.100.1.2 with next hop
Core1, so E1 sends the packet back to Core1.
neighbor 10.100.1.2 next-hop-self
!
neighbor 10.100.1.3 remote-as 11
neighbor 10.100.1.3 update-source loopback0
neighbor 10.100.1.3 next-hop-self
!
neighbor 10.100.1.4 remote-as 11
neighbor 10.100.1.4 update-source loopback0
neighbor 10.100.1.4 next-hop-self
! Next, Core1’s configuration
interface loopback0
ip address 10.100.1.3 255.255.255.255
!
router bgp 11
neighbor 10.100.1.1 remote-as 11
neighbor 10.100.1.1 update-source loopback0
!
neighbor 10.100.1.2 remote-as 11
neighbor 10.100.1.2 update-source loopback0
!
neighbor 10.100.1.4 remote-as 11
neighbor 10.100.1.4 update-source loopback0
The configurations on E1 and Core1 mostly match. The commonly used commands simply
define the neighbor’s ASN (neighbor... remote-as) and list the local router’s BGP update
source interface (neighbor... update-source). However, note that the engineer also
configured E1–the Internet-connected router–with the neighbor... next-hop-self command.
In this case, the Internet-connected routers want to set their own update-source IP
addresses as the next hop for any routes. However, the engineer purposefully chose not to
use this command on the two internal routers (Core1 and Core2) because the eventual destination
of these packets will be to make it to either E1 or E2 and then out to the Internet.
By making the next-hop router for all iBGP-learned routes an address on one of the Internet-
connected routers, the packets will be correctly forwarded.
For perspective, Example 14-9 shows Core1’s BGP table after adding the configuration
shown in Example 14-8, plus the equivalent configuration in E2 and Core2. Focusing on
the routes for 181.0.0.0/8 and 192.135.250.0/28 again, note that E1 and E2 had already
agreed that E1’s route for 181.0.0.0/8 was best and that E2’s route for 192.135.250.0/28 was
best. As a result, Core1 knows only one route for each of these destinations, as shown in
the example. Also, the next-hop addresses for each route refer to the correct of the two
Internet-connected routers: 10.100.1.1 (E1) for the route to 181.0.0.0/8 and 10.100.1.2 (E2)
for the route to 192.135.250.0/28.
www.CareerCert.info
Chapter 14: Internal BGP and BGP Route Filtering 475
Example 14-9 BGP Table on Router Core1
Core-1# show ip bgp
BGP table version is 10, local router ID is 10.100.1.3
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
r i0.0.0.0 10.100.1.2 0 100 0 3 i
r>i 10.100.1.1 0 100 0 1 i
* i128.107.0.0/19 10.100.1.2 0 100 0 i
*>i 10.100.1.1 0 100 0 i
*>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
*>i192.135.250.0/28 10.100.1.2 0 100 0 3 4 i
IGP Redistribution and BGP Synchronization
You can also redistribute BGP routes into the IGP to solve the routing loop problem. This
solution prevents the routing loop by giving the internal Enterprise routers knowledge of
the best exit point for each known Internet destination.
Although it solves the problem, particularly when just learning with lab gear at home, redistribution
of BGP routes into an IGP is generally not recommended. This redistribution
requires a relatively large amount of memory and a relatively large amount of processing
by the IGP with the much larger number of routes to process. Redistributing the number
of routes in the full Internet BGP table could crash the IGP routing protocols.
Note: BGP consumes less memory and uses less CPU for a large number of routes as
compared to the equivalent number of routes advertised by an IGP, particularly when compared
to OSPF. So using the iBGP mesh may cause internal routers to learn all the same
routes but without risk to the IGP.
Although not recommended, the idea of redistributing eBGP-learned Internet routes into
the Enterprise IGP needs to be discussed as a backdrop to discuss a related BGP feature
called synchronization or sync. The term refers to the idea that the iBGP-learned routes
must be synchronized with IGP-learned routes for the same prefix before they can be
used. In other words, if an iBGP-learned route is to be considered to be a usable route,
then that same prefix must be in the IP routing table and learned using some IGP protocol
such as EIGRP or OSPF. More formally, the synchronization features tells a BGP router the
following:
Do not consider an iBGP-learned route as “best” unless the exact prefix was learned
via an IGP and is currently in the IP routing table.
www.CareerCert.info
476 CCNP ROUTE 642-902 Official Certification Guide
For companies, such as the Enterprise shown in Figure 14-5, the combination of redistributing
eBGP routes into an IGP, and configuring synchronization on the two routers that
run BGP (E1 and E2), prevents the routing loop shown in that figure. Again using prefix
192.135.250.0/28 as an example (see Figure 14-5), E2 again learned this prefix with eBGP.
E1 learns this same prefix through its iBGP neighborship with E2, and both agree that E2’s
BGP route is best.
When E2 has successfully redistributed prefix 192.135.250.0/28 into the Enterprise’s IGP
(OSPF in the examples in this chapter), E1, with sync enabled, thinks like this:
I see an IGP route for 192.135.250.0/28 in my IP routing table, so my iBGP route for
that same prefix is safe to use.
However, if for some reason the redistribution does not result in an IGP route for
192.135.250.0/28, then E1 thinks as follows:
I do not see an IGP-learned route for 192.135.250.0/28 in my IP routing table, so I will
not consider the iBGP route through E2 to be usable.
In this second case, E1 uses its eBGP-learned route through I1-1, which defeats the routing
loop caused at Step 3 of Figure 14-5.
Later IOS versions default to disable synchronization because most sites avoid redistributing
routes from BGP into an IGP when using BGP for Internet routes, instead preferring
iBGP meshes (or alternatives) to avoid these routing black holes. The setting is applied to
the entire BGP process, with the synchronization command enabling synchronization and
the no synchronization command (default) disabling it.
Note: The suggestion to avoid redistribution from BGP into an IGP generally applies to
cases in which BGP is used to exchange Internet routes. However, BGP can be used for
other purposes as well, including the implementation of Multiprotocol Label Switching
(MPLS). Redistribution from BGP into an IGP when using BGP for MPLS is reasonable
and commonly done.
No comments:
Post a Comment