Objective In the previous exercise you will remember the internal routers of our pod did not learn of external routes, but used default routes to lead them towards the frame switch. In this exercise we will set up Full-Mesh IBGP so our pod learns routes via BGP.
Download Equipment list, configuration files and network topology. ccnp-c8t2.zip
Setup
This exercise starts where "a simple IBGP and EBGP network" ended. Above is a link to the completed config files of the "a simple IBGP and EBGP network" exercise.
The first thing we will do here is strip the default route advertisements down on the edge routers.
P1R1(config)#no ip route 0.0.0.0 0.0.0.0 172.31.11.4
P1R1(config)#router rip
P1R1(config-router)#no default-information originate
P1R1(config-router)#end
P1R1#
Once this is done we set up the full mesh for the pod. This requires adding 2 more sessions on the edge routers and 3 sessions on the internal routers. We use the loopback addresses for this example.
P1R1(config)#router bgp 65001
P1R1(config-router)#neighb 10.200.200.13 remote-as 65001
P1R1(config-router)#neighb 10.200.200.14 remote-as 65001
P1R1(config-router)#end
P1R1#
Loopbacks provide added stability in full-mesh networks as the interface does not go down, in comparison to a physical interface when their is a failure. For this reason we will configure the internal routers to send their IBGP updates from their loopback address.
The following shows an example of what is required:
P1R3(config)#router bgp 65001
P1R3(config-router)#neighb 10.200.200.11 update-source loopback0
P1R3(config-router)#neighb 10.200.200.12 update-source loopback0
P1R3(config-router)#neighb 10.200.200.14 update-source loopback0
P1R3(config-router)#end
You should immediately see IBGP sessions become established. You could also check with the "show ip bgp summary" command.
The edge routers should see 2 EBGP and 3 IBGP sessions. The internal routers should just see the 3 IBGP sessions.
Show ip bgp to determine next hop for the route to 10.254.0.0
P1R1#sh ip bgp
BGP table version is 13, local router ID is 10.200.200.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
* i10.1.0.0/24 10.1.0.2 0 100 0 i
*> 0.0.0.0 0 32768 i
* i10.1.1.0/24 10.1.2.4 2 100 0 i
*> 0.0.0.0 0 32768 i
*> 10.1.2.0/24 10.1.1.3 2 32768 i
* i 10.1.0.2 0 100 0 i
* i10.1.3.0/24 10.1.2.4 1 100 0 i
*> 10.1.1.3 1 32768 i
* i10.97.97.0/24 172.31.11.4 0 100 0 64999 64997 i
* 172.31.11.4 0 64999 64997 i
*> 172.31.1.3 0 64998 64997 i
* i10.254.0.0/24 172.31.1.3 0 100 0 64998 i
* 172.31.11.4 0 64999 64998 i
*> 172.31.1.3 0 0 64998 i
r i172.31.1.0/24 172.31.1.3 0 100 0 64998 i
r 172.31.11.4 0 64999 64998 i
r> 172.31.1.3 0 0 64998 i
Network Next Hop Metric LocPrf Weight Path
r i172.31.11.0/24 172.31.11.4 0 100 0 64999 i
r> 172.31.11.4 0 0 64999 i
r 172.31.1.3 0 64998 64999 i
P1R1#
It shows 172.31.1.3. (Backbone Router). You will also see these routes in the BGP table of the internal pod routers. Howerver, these routes are not in the ip route table because this route is unreachable.
P1R3#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
R 10.200.200.11/32 [120/1] via 10.1.1.1, 00:00:23, Ethernet0
R 10.200.200.14/32 [120/1] via 10.1.3.4, 00:00:16, Serial0
R 10.200.200.12/32 [120/2] via 10.1.3.4, 00:00:16, Serial0
C 10.200.200.13/32 is directly connected, Loopback0
C 10.1.3.0/24 is directly connected, Serial0
R 10.1.2.0/24 [120/1] via 10.1.3.4, 00:00:16, Serial0
C 10.1.1.0/24 is directly connected, Ethernet0
R 10.1.0.0/24 [120/1] via 10.1.1.1, 00:00:24, Ethernet0
P1R3#
Problem: EBGP distributes the next hop (remote address) into the IBGP, but the pod does not have a route, static or otherwise to the remote network.
Solution: The local EBGP speaker has to advertise to the pod , that it is the next hop for this remote network, as opposed to the Backbone router. Achieve this with the following commands on both edge routers.
P1R1(config-router)#neighbor 10.200.200.13 next-hop-self
P1R1(config-router)#neighbor 10.200.200.14 next-hop-self
Now “show ip route” on P1R3. There is still no route to the 10.254.0.0 prefix!
This is because synchronization is on. If you disable synchronization, BGP can use routes learned from IBGP neighbors that are not present in the local routing table.
On all pod routers issue the following command.
P1R1(config-router)#no synchronization
BGP Synchronization is on by default in current IOS releases.
The BGP Synchronization rule states that a bgp router should not use or advertise to a neighbour a route learned by IBGP, unless that route is local or learned from the IGP.
Because we are running full mesh IBGP we can turn off synchronization with the ‘no synchronization’ command on all pod routers.
Sh ip route on P1R3 and verify BGP has injected the route into the local routing table.
P1R3#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
172.31.0.0/24 is subnetted, 2 subnets
B 172.31.1.0 [200/0] via 10.200.200.11, 00:00:15
B 172.31.11.0 [200/0] via 10.200.200.11, 00:00:15
10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
R 10.200.200.11/32 [120/1] via 10.1.1.1, 00:00:26, Ethernet0
R 10.200.200.14/32 [120/1] via 10.1.3.4, 00:00:01, Serial0
R 10.200.200.12/32 [120/2] via 10.1.3.4, 00:00:01, Serial0
C 10.200.200.13/32 is directly connected, Loopback0
C 10.1.3.0/24 is directly connected, Serial0
R 10.1.2.0/24 [120/1] via 10.1.3.4, 00:00:02, Serial0
B 10.97.97.0/24 [200/0] via 10.200.200.11, 00:00:16
C 10.1.1.0/24 is directly connected, Ethernet0
R 10.1.0.0/24 [120/1] via 10.1.1.1, 00:00:27, Ethernet0
B 10.254.0.0/24 [200/0] via 10.200.200.11, 00:00:34
P1R3#
Finally ping 10.254.0.254
P1R3#ping 10.254.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.254.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/36 ms
P1R3#
Wrapping Up
In this exercise we learnt about the "next-hop-self" command which is used to force BGP to use its own IP address as the next hop for eachnetwork it advertises to the neighbor, rather than letting the protocol choose the next-hop address to use.
We also learnt about Synchronization in the Cisco IOS. Sychronization is ON by default! If your AS is passing traffic from one AS to another, BGP should not advertise a route before all routers in your AS have learned about the route via IGP.
This behavior can be changed with the "no synchronization" command. Make sure you have a full mesh topology before disabling sychronization, otherwise you could end up with routing "black holes".
this post is based on an exercise from the book
CCNP Self Study:
Building Scalable Cisco Internetworks (BSCI)
Second Edition
No comments:
Post a Comment