This subject is
slightly dated especially given the version 5 updates to the lab exam. Never
the less it's important to understand all concepts just in case we need it in
the exam. So today's lab is focused on synchronization. Fire up the lab and
enjoy!
Topics covered:
-eBGP/iBGP peering
-IGP/BGP
redistribution
-BGP synchronization
-RIB Failures
Complete the follow
tasks to complete this lab:
-The iBGP sessions
between R1-R2-R3 in AS 100 have already been configured for you including
advertising the loopbacks into the BGP RIB table
-Create eBGP
sessions between R1-PE11 and R3-PE22 per the diagram
-Ensure the
50.1.0.0/24 prefix being advertised by PE11 is learned via eBGP by PE22 via AS
100
Constraints:
-Do not modify the
BGP configuration within AS10,20, or 100.
-ensure that the
50.1.0.0/24 network transits AS 100 and is learned by PE22
-you may modify the
IGP configuration if necessary
Topology used
GNS3 files: Link
Solution
Let's begin by
configuring the iBGP sessions between the R1-R2-R3 devices.
R1(config)#
R1(config-router)#
R1(config)#router
bgp 100
bgp
log-neighbor-changes
network 1.1.1.1 mask
255.255.255.255
R1(config-router)#neighbor
192.168.1.11 remote-as 10
R1(config-router)#neighbor
192.168.2.2 remote-as 100
Let's begin by
examining the BGP RIB table on each device in AS 100.
R1#sh ip bgp
<snip>
Network Next Hop Metric LocPrf Weight Path
*>
1.1.1.1/32 0.0.0.0 0 32768 i
r>i2.2.2.2/32 192.168.2.2 0 100
0 i
r>i3.3.3.3/32 192.168.3.3 0 100
0 i
*>
50.1.0.0/24 192.168.1.11 0 0 10 i
R2#sh ip bgp
<snip>
Network Next Hop Metric LocPrf Weight Path
r>i1.1.1.1/32 192.168.2.1 0 100
0 i
*>
2.2.2.2/32 0.0.0.0 0 32768 i
r>i3.3.3.3/32 192.168.3.3 0 100
0 i
* i50.1.0.0/24 192.168.1.11 0 100
0 10 i
R3#sh ip bgp
<snip>
Network Next Hop Metric LocPrf Weight Path
r>i1.1.1.1/32 192.168.2.1 0 100
0 i
r>i2.2.2.2/32 192.168.3.2 0 100
0 i
*>
3.3.3.3/32 0.0.0.0 0 32768 i
Well R3 isn't
receiving any BGP routes from R2. Since this is iBGP that could easily be fixed
on R2 with route-reflection but that is already configured.
R2#sh run | sec
router bgp
router bgp 100
synchronization
network 2.2.2.2 mask 255.255.255.255
neighbor 192.168.2.1 remote-as 100
neighbor 192.168.2.1 route-reflector-client
neighbor 192.168.3.3 remote-as 100
neighbor 192.168.3.3 route-reflector-client
So why isn't R3
receiving the routes from R2? Well if you noticed synchronization is enable on
this device as well as R1 and R3. The BGP synchronization rule states that if
an AS provides transit service to another AS, BGP should not advertise a route
until all of the routers within the AS have learned the route via an IGP.
So R2 is not going
to advertise the 50.1.0.0/24 prefix unless its learned of it via an IGP.
Looking at its routing table that is clearly not the case.
R2#sh ip route
<snip>
1.0.0.0/32 is subnetted, 1 subnets
D 1.1.1.1 [90/156160] via 192.168.2.1,
00:13:40, FastEthernet0/0
2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected,
Loopback0
3.0.0.0/32 is subnetted, 1 subnets
D 3.3.3.3 [90/156160] via 192.168.3.3,
00:13:42, FastEthernet0/1
192.168.2.0/24 is variably subnetted, 2
subnets, 2 masks
C 192.168.2.0/24 is directly connected,
FastEthernet0/0
L 192.168.2.2/32 is directly connected,
FastEthernet0/0
192.168.3.0/24 is variably subnetted, 2
subnets, 2 masks
C 192.168.3.0/24 is directly connected,
FastEthernet0/1
L 192.168.3.2/32 is directly connected,
FastEthernet0/1
R2#sh ip bgp
neighbors 192.168.3.3 advertised-routes
<snip>
Originating default
network 0.0.0.0
Network Next Hop Metric LocPrf Weight Path
r>i1.1.1.1/32 192.168.2.1 0 100
0 i
*>
2.2.2.2/32 0.0.0.0 0 32768 i
r>i3.3.3.3/32 192.168.3.3 0 100
0 i
Total number of
prefixes 3
R3#sh ip route
<snip>
Gateway of last
resort is not set
1.0.0.0/32 is subnetted, 1 subnets
D 1.1.1.1 [90/158720] via 192.168.3.2,
00:35:55, FastEthernet0/0
2.0.0.0/32 is subnetted, 1 subnets
D 2.2.2.2 [90/156160] via 192.168.3.2,
00:35:57, FastEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
C 3.3.3.3 is directly connected,
Loopback0
D 192.168.2.0/24 [90/30720] via 192.168.3.2,
00:35:57, FastEthernet0/0
192.168.3.0/24 is variably subnetted, 2
subnets, 2 masks
C 192.168.3.0/24 is directly connected,
FastEthernet0/0
L 192.168.3.3/32 is directly connected,
FastEthernet0/0
192.168.4.0/24 is variably subnetted, 2
subnets, 2 masks
C 192.168.4.0/24 is directly connected,
FastEthernet0/1
L 192.168.4.3/32 is directly connected,
FastEthernet0/1
Even though router
reflection is enable on R2 it will not advertise that prefix due to
synchronization being enabled. The lab states we cannot modify the BGP
configuration so we cannot turn off synchronization which would be preferred,
so we must satisfy the synchronization rule and advertise the prefix via IGP.
Below is the configuration I used to accomplish that but there are variations
on the same idea that would also work.
R1#sh ip
as-path-access-list
AS path access list
1
permit ^10$
R1#sh route-map
route-map
BGP_TO_EIGRP, permit, sequence 10
Match clauses:
as-path (as-path filter): 1
Set clauses:
Policy routing matches: 0 packets, 0 bytes
R1#sh run | sec
router eigrp
router eigrp 100
network 1.1.1.1 0.0.0.0
network 192.168.2.1 0.0.0.0
redistribute bgp 100 metric 1 1 1 1 1
route-map BGP_TO_EIGRP
The idea above is to
redistribute the 50.1.0.0/24 network into our IGP which is EIGRP in this
instance. This places the 50.1.0.0/24 network into the routing tables of both
R2 and R3 which allow them to advertise our prefix.
R2#sh ip route
<snip>
D EX 50.1.0.0 [170/2560002816] via 192.168.2.1,
00:31:48, FastEthernet0/0
<snip>
One more piece is
missing to make this all work. Notice that R2 has a BGP route for 50.1.0.0/24
but its next hop is inaccessible. Because it is unreachable R2 still will not
advertise it to R3. Fix this everything should work
R2#sh ip bgp
50.1.0.0/24
BGP routing table
entry for 50.1.0.0/24, version 4
Paths: (1 available,
no best path)
Not advertised to any peer
10, (Received from a RR-client)
192.168.1.11 (inaccessible) from 192.168.2.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100,
valid, internal, synchronized
We fix this by using
the next-hop-self command on R1.
R2#sh ip bgp
50.1.0.0/24
BGP routing table
entry for 50.1.0.0/24, version 11
Paths: (1 available,
best #1, table default, RIB-failure(17))
Advertised to update-groups:
2
10, (Received from a RR-client)
192.168.2.1 from 192.168.2.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100,
valid, internal, synchronized, best
Now R2 advertises
the prefix to R3 which in turn advertises the router via its eBGP connection to
PE22.
PE22#sh ip bgp
BGP table version is
14, local router ID is 22.22.22.22
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
*>
1.1.1.1/32 192.168.4.3 0 100 i
*>
2.2.2.2/32 192.168.4.3 0 100 i
*>
3.3.3.3/32 192.168.4.3 0 0 100 i
*>
50.1.0.0/24 192.168.4.3 0 100 10 i
---------
If you noticed on
R1, R2, and R3 many of the loopback address where in RIB failure. If you are not familiar with that, essentially it
means the BGP was unable to install the BGP route into the default routing
table. There could be several reasons for that but to see why that is in this
lab you can issue the command below:
R2#sh ip bgp
rib-failure
Network Next Hop RIB-failure RIB-NH Matches
1.1.1.1/32 192.168.2.1 Higher admin distance n/a
3.3.3.3/32 192.168.3.3 Higher admin distance n/a
50.1.0.0/24 192.168.2.1 Higher admin distance n/a
So according to the
output above BGP could not install these routes into the global RIB table
because EIGRP which has a lower administrative cost of 90 compared to that of
iBGP which is 200. This normally would be a bad thing but when synchronization
is on its actually a good thing because the rule requires the IGP routes exist
in order to advertise the routes in BGP.
No comments:
Post a Comment