Concepts tested:
-Route reflection
-Route reflection
clustering
-route advertisement
between eBGP peers, iBGP peers, and between route reflectors
-Next-hop processing using next-hop-self
-Next-hop processing using next-hop-self
Topology used
Tasks to complete
this lab:
-Configure eBGP
peering between R1-R2 and R11-R8
-Configure iBGP
peering between R2-R3 and R2-R4
-Configure iBGP
peering between R5-R6 and R5-R7
-Configure iBGP
peering between R8-R9 and R8-R10
-Configure iBGP
peering between R2-R5 and R2-R8 and R5-R8
-Configure a route
reflector cluster between R2-R3-R4 where R2
is the route reflector server and R3 and R4
are the clients using
cluster ID: 10.1.1.1
-Configure a route
reflector cluster between R2-R3-R4 where R2 is
the router reflector server and R6 and R7 are
clients using cluster
ID: 20.2.2.2
-Configure a router
reflector cluster between R8-R9-R10 where
R8 is the router reflector server and R9 and
R10 are route reflector
client using cluster ID: 30.3.3.3
-Advertise the
loopbacks of all routers including R1 and R11.
-Ensure reachability
to all eBGP and iBGP loopback addresses when
sourced from other loopbacks
-Constraints:
--Do not use static
routes
--Do not modify any
IGP configurations or IPs
--Use the least
amount of command necessary to accomplish tasks
--Solution should be
achieved using only BGP commands
Link to GNS3 configs: Link
Solution:
Begin by creating
the peering with R2 and advertising R1's and R11's loopback addresses
R1(config)#router
bgp 100
R1(config-router)#neighbor
192.168.12.3 remote-as 300
R1(config-router)#network
172.16.0.0 mask 255.255.255.0
R1(config-router)#network
172.16.1.0 mask 255.255.255.0
R1(config-router)#network
172.16.2.0 mask 255.255.255.0
R1(config-router)#network
172.16.3.0 mask 255.255.255.0
R11(config)#router
bgp 100
R11(config-router)#neighbor
192.168.118.9 remote-as 300
R11(config-router)#network
172.16.4.0 mask 255.255.255.0
R11(config-router)#network
172.16.5.0 mask 255.255.255.0
R11(config-router)#network
172.16.6.0 mask 255.255.255.0
R11(config-router)#network
172.16.7.0 mask 255.255.255.0
Next configure the
neighbor configuration on R2 defining R3 and R4 as route
reflector clients of
R2. This ensures any routes learned by a
client is reflected by R2 to its other client and non-client peers. In this case R4, R5, and R8 will learn
BGP learn routes from R3 via R2. Don't forget to configure the peering with R5
and R8 as well.
R2(config)#router
bgp 300
R2(config-router)#neighbor
192.168.23.3 remote-as 300
R2(config-router)#neighbor
192.168.23.3 route-reflector-client
R2(config-router)#neighbor
192.168.24.4 remote-as 300
R2(config-router)#neighbor
192.168.24.4 route-reflector-client
R2(config-router)#neighbor
192.168.28.8 remote-as 300
R2(config-router)#neighbor
192.168.25.5 remote-as 300
Continue by
configuring R3 to peer with R1 and R2 and R4 with R2.
R3(config)#router
bgp 300
R3(config-router)#neighbor
192.168.23.2 remote-as 300
R3(config-router)#neighbor
192.168.12.1 remote-as 100
R4(config)#router
bgp 300
R4(config-router)#neighbor
192.168.24.2 remote-as 300
Continue this
process of neighbor configuration across the remaining devices
R5(config)#router
bgp 300
R5(config-router)#neighbor
192.168.25.2 remote-as 300
R5(config-router)#neighbor
192.168.58.8 remote-as 300
R5(config-router)#neighbor
192.168.56.6 remote-as 300
R5(config-router)#neighbor
192.168.56.6 route-reflector-client
R5(config-router)#neighbor
192.168.57.7 remote-as 300
R5(config-router)#neighbor
192.168.57.7 route-reflector-client
R6(config)#router
bgp 300
R6(config-router)#neighbor
192.168.56.5 remote-as 300
R7(config)#router
bgp 300
R7(config-router)#neighbor
192.168.57.5 remote-as 300
R8(config)#router
bgp 300
R8(config-router)#neighbor
192.168.28.2 remote-as 300
R8(config-router)#neighbor
192.168.58.5 remote-as 300
R8(config-router)#neighbor
192.168.89.9 remote-as 300
R8(config-router)#neighbor
192.168.81.1 remote-as 300
R9(config)#router
bgp 300
R9(config-router)#neighbor
192.168.89.2 remote-as 300
R9(config-router)#neighbor
192.168.118.1 remote-as 200
R10(config)#router
bgp 300
R10(config-router)#neighbor
192.168.81.2 remote-as 300
The next step is to
define our route reflector clusters. To do this we define our cluster IDs on
each of our route reflector clients.
R2(config)#router
bgp 300
R2(config-router)#bgp
cluster-id 10.1.1.1
R5(config)#router
bgp 300
R5(config-router)#bgp
cluster-id 20.1.1.1
R8(config)#router
bgp 300
R8(config-router)#bgp
cluster-id 30.1.1.1
Now advertise the
loopback 0 networks of each AS 300 device
R2(config)#router
bgp 300
R2(config)#network
2.2.2.2 mask 255.255.255.255
R3(config)#router
bgp 300
R3(config)#network
3.3.3.3 mask 255.255.255.255
R4(config)#router
bgp 300
R4(config)#network
4.4.4.4 mask 255.255.255.255
R5(config)#router
bgp 300
R5(config)#network
5.5.5.5 mask 255.255.255.255
R6(config)#router
bgp 300
R6(config)#network
6.6.6.6 mask 255.255.255.255
R7(config)#router
bgp 300
R7(config)#network
7.7.7.7 mask 255.255.255.255
R8(config)#router
bgp 300
R8(config)#network
8.8.8.8 mask 255.255.255.255
R9(config)#router
bgp 300
R9(config)#network
9.9.9.9 mask 255.255.255.255
R10(config)#router
bgp 300
R10(config)#network 10.10.10.10 mask 255.255.255.255
At this point we
should confirm proper peering between devices and advertisement of our prefixes
R2#sh ip bgp sum
<snip>
Neighbor V AS MsgRcvd MsgSent TblVer
InQ OutQ Up/Down State/PfxRcd
192.168.23.3 4
300 8 17
36 0 0 00:03:10 5
192.168.24.4 4
300 19 29
36 0 0 00:13:06 1
192.168.25.5 4
300 20 22
36 0 0 00:13:05 3
192.168.28.8 4
300 21 21
36 0 0 00:12:57 2
R3#sh ip bg
<snip>
Neighbor V AS MsgRcvd MsgSent TblVer
InQ OutQ Up/Down State/PfxRcd
192.168.12.1 4
100 9 12
24 0 0 00:04:00 4
192.168.23.2 4
300 19 9
24 0 0 00:04:00 8
R4#sh ip bgp sum
<snip>
Neighbor V AS MsgRcvd MsgSent TblVer
InQ OutQ Up/Down State/PfxRcd
192.168.24.2 4
300 31 20
118 0 0 00:14:18 8
R6#sh ip bgp sum
<snip>
Neighbor V AS MsgRcvd MsgSent TblVer
InQ OutQ Up/Down State/PfxRcd
192.168.56.5 4
300 31 21
124 0 0 00:15:27 8
R7#sh ip bgp sum
<snip>
Neighbor V AS MsgRcvd MsgSent TblVer
InQ OutQ Up/Down State/PfxRcd
192.168.57.5 4
300 32 22
126 0 0 00:15:45 8
R8#sh ip bgp sum
<snip>
Neighbor V AS MsgRcvd MsgSent TblVer
InQ OutQ Up/Down State/PfxRcd
192.168.28.2 4
300 24 25
30 0 0 00:15:48 3
192.168.58.5 4
300 23 24
30 0 0 00:15:49 3
192.168.81.10 4
300 22 34
30 0 0 00:15:49 1
192.168.89.9 4
300 8 15
30 0 0 00:03:08 5
192.168.118.11 4
200 0 0
1 0 0 never
Idle
R9#sh ip b
<snip>
Neighbor V AS MsgRcvd MsgSent TblVer
InQ OutQ Up/Down State/PfxRcd
192.168.89.8 4
300 15 8
14 0 0 00:03:32 8
192.168.118.11 4
200 8 8
14 0 0 00:03:32 4
R10#sh ip bgp sum
<snip>
Neighbor V AS MsgRcvd MsgSent TblVer
InQ OutQ Up/Down State/PfxRcd
192.168.81.8 4
300 35 23
111 0 0 00:16:48 8
R11#sh ip bgp sum
<snip>
Neighbor V AS MsgRcvd MsgSent TblVer
InQ OutQ Up/Down State/PfxRcd
192.168.118.9 4
300 10 10
77 0 0 00:04:37 8
Everything looks
good as far as our neighbors go. Let's look at our BGP RIB table
R2#sh ip bgp
BGP table version is
37, local router ID is 2.2.2.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
*>
2.2.2.2/32 0.0.0.0 0 32768 i
*>i3.3.3.3/32 192.168.23.3 0 100
0 i
*>i4.4.4.4/32 192.168.24.4 0 100
0 i
*>i5.5.5.5/32 192.168.25.5 0 100
0 i
*>i6.6.6.6/32 192.168.56.6 0 100
0 i
*>i7.7.7.7/32 192.168.57.7 0 100
0 i
*>i8.8.8.8/32 192.168.28.8 0 100
0 i
*>i9.9.9.9/32 192.168.89.9 0 100
0 i
*>i10.10.10.10/32 192.168.81.10 0
100 0 i
* i172.16.0.0/24 192.168.12.1 0 100
0 100 i
* i172.16.1.0/24 192.168.12.1 0 100
0 100 i
* i172.16.2.0/24 192.168.12.1 0 100
0 100 i
* i172.16.3.0/24 192.168.12.1 0 100
0 100 i
As you can see from
the output above there is a problem. R11's prefixes are not in R2s RIB table
and R1's prefixes are not being installed in the global RIB table (its missing
the > symbol).
So why would this
be? Let's look at R2. There are a couple of reasons why a route will not get
installed from the BGP RIB table and placed into the global RIB. One reason is
If the path is marked as not synchronized it will not get installed. But we
have this turned off by default. Another reason is if the NEXT_HOP attribute is
inaccessible. Let's check that out:
R2#sh ip bgp
172.16.0.0/24
BGP routing table
entry for 172.16.0.0/24, version 0
Paths: (1 available,
no best path)
Not advertised to any peer
100, (Received from a RR-client)
192.168.12.1 (inaccessible) from 192.168.23.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100,
valid, internal
That looks like that
is our problem. So the 192.168.12.0/24 network is unreachable by R2. We can fix
that by advertising that network into our IGP or creating a static route but
that violates our LAB constraints. So another option is to change the next hop
to a prefix that is reachable. We can do that with the next-hop-self command on
R3.
R3(config)#router
bgp 300
R3(config-router)#neighbor
192.168.23.2 next-hop-self
The result of this
is after clearing the BGP session to speed things up
R2#sh ip bgp
<snip>
Network Next Hop Metric LocPrf Weight Path
*>
2.2.2.2/32 0.0.0.0 0 32768 i
*>i3.3.3.3/32 192.168.23.3 0 100
0 i
*>i4.4.4.4/32 192.168.24.4 0 100
0 i
*>i5.5.5.5/32 192.168.25.5 0 100
0 i
*>i6.6.6.6/32 192.168.56.6 0 100
0 i
*>i7.7.7.7/32 192.168.57.7 0 100
0 i
*>i8.8.8.8/32 192.168.28.8 0 100
0 i
*>i9.9.9.9/32 192.168.89.9 0 100
0 i
*>i10.10.10.10/32 192.168.81.10 0
100 0 i
*>i172.16.0.0/24 192.168.23.3 0 100
0 100 i
*>i172.16.1.0/24 192.168.23.3 0 100
0 100 i
*>i172.16.2.0/24 192.168.23.3 0 100
0 100 i
*>i172.16.3.0/24 192.168.23.3 0 100
0 100 i
R2#sh ip route
<snip>
172.16.0.0/24 is subnetted, 4 subnets
B 172.16.0.0 [200/0] via 192.168.23.3,
00:00:45
B 172.16.1.0 [200/0] via 192.168.23.3,
00:00:45
B 172.16.2.0 [200/0] via 192.168.23.3,
00:00:45
B 172.16.3.0 [200/0] via 192.168.23.3,
00:00:45
That is much better.
Now let's look at why R11's prefixes are missing.
R8#sh ip bgp
<snip>
Network Next Hop Metric LocPrf Weight Path
<snip>
*>i172.16.0.0/24 192.168.23.3 0 100
0 100 i
*>i172.16.1.0/24 192.168.23.3 0 100
0 100 i
*>i172.16.2.0/24 192.168.23.3 0 100
0 100 i
*>i172.16.3.0/24 192.168.23.3 0 100
0 100 i
*
i172.16.4.0/24 192.168.118.11 0
100 0 200 i
*
i172.16.5.0/24 192.168.118.11 0
100 0 200 i
*
i172.16.6.0/24 192.168.118.11 0
100 0 200 i
*
i172.16.7.0/24 192.168.118.11 0
100 0 200 i
It looks like the
same issue as R2, lets confirm that.
R8#sh ip bgp
172.16.4.0/24
BGP routing table
entry for 172.16.4.0/24, version 0
Paths: (1 available,
no best path)
Not advertised to any peer
200, (Received from a RR-client)
192.168.118.11 (inaccessible) from
192.168.89.9 (9.9.9.9)
Origin IGP, metric 0, localpref 100,
valid, internal
Sure enough, it’s
the same problem so our solution be the same, modify the NEXT_HOP attribute on
the advertising device to a prefix that is reachable by R8.
R8(config)#router
bgp 300
R8(config-router)#neighbor
192.168.89.8 next-hop-self
The result is below
R8#sh ip bgp
<snip>
Network Next Hop Metric LocPrf Weight Path
<snip>
*>i172.16.4.0/24 192.168.89.9 0 100
0 200 i
*>i172.16.5.0/24 192.168.89.9 0 100
0 200 i
*>i172.16.6.0/24 192.168.89.9 0 100
0 200 i
*>i172.16.7.0/24 192.168.89.9 0 100
0 200 i
Problem solved.
So if we check the
rest of our devices we should see that both our BGP and global RIB tables are
populated correctly and that we can ping all the prefixes when we source from
the local device's loopback address:
R6#
R6#sh ip bgp
BGP table version is
144, local router ID is 6.6.6.6
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
*>i2.2.2.2/32 192.168.25.2 0 100
0 i
*>i3.3.3.3/32 192.168.23.3 0 100
0 i
*>i4.4.4.4/32 192.168.24.4 0 100
0 i
*>i5.5.5.5/32 192.168.56.5 0 100
0 i
*>
6.6.6.6/32 0.0.0.0 0 32768 i
*>i7.7.7.7/32 192.168.57.7 0 100
0 i
*>i8.8.8.8/32 192.168.58.8 0 100
0 i
*>i9.9.9.9/32 192.168.89.9 0 100
0 i
*>i10.10.10.10/32 192.168.81.10 0
100 0 i
*>i172.16.0.0/24 192.168.23.3 0 100
0 100 i
*>i172.16.1.0/24 192.168.23.3 0 100
0 100 i
*>i172.16.2.0/24 192.168.23.3 0 100
0 100 i
*>i172.16.3.0/24 192.168.23.3 0 100
0 100 i
*>i172.16.4.0/24 192.168.89.9 0 100
0 200 i
*>i172.16.5.0/24 192.168.89.9 0 100
0 200 i
*>i172.16.6.0/24 192.168.89.9 0 100
0 200 i
*>i172.16.7.0/24 192.168.89.9 0 100
0 200 i
R6#ping 172.16.1.1
source lo 0
Type escape sequence
to abort.
Sending 5, 100-byte
ICMP Echos to 172.16.1.1, timeout is 2 seconds:
Packet sent with a
source address of 6.6.6.6
!!!!!
Success rate is 100
percent (5/5), round-trip min/avg/max = 64/85/104 ms
That concludes this
lab, I hope you enjoyed it. Please feel free to comment or ask questions and
I'll do my best to answer them.
References:
No comments:
Post a Comment