This lab focuses on
the use of the BGP redistribution-internal
command and some of the pit falls of redistributing BGP into an IGP domain.
Concepts tested
-eBGP and IBGP
peering
-Next hop path
manipulation
-BGP/IGP
redistsribution
-Administrative
distance
Tasks to complete
this lab:
-Configure a eBGP
peering between R1 and PE1
-configure iBGP
peering between R1, R3, and R3 in AS 200
-Configure R1 and R4
to be route reflector clients of R3
-Redistribute BGP
into EIGRP on R4 and ensure that R5
can reach all the
advertised prefixes of PE1 when sourced from its
loopback address
-Resolve all routing
issues
Constraints
-BGP must be
redistributed into EIGRP on R4 and no where else
Topology
GNS3 files: link
Solution
We begin by
configuring our peering between our respective BGP speakers as required by the
lab.
R1(config)#router
bgp 200
R1(config-router)#neighbor
192.168.11.11 remote-as 100
R1(config-router)#neighbor
192.168.13.3 remote-as 200
R3(config)#router
bgp 200
R3(config-router)#neighbor
192.168.13.1 remote-as 200
R3(config-router)#neighbor
192.168.13.1 route-reflector-client
R3(config-router)#neighbor
192.168.34.1 remote-as 200
R3(config-router)#neighbor
192.168.34.1 route-reflector-client
R4(config)#router
bgp 200
R4(config-router)#neighbor
192.168.34.3 remote
R4(config-router)#neighbor
192.168.34.3 remote-as 200
We also need add the
next-hop-self command on R1 when sending advertisements to R3 because that will
provide a next hop prefix that can be recursively looked up by the downstream
routers when routing to PE1's advertised prefixes.
R1(config)#router
bgp 200
R1(config-router)#neighbor
192.168.13.3 next-hop-self
With that
configuration in place let's look at R3's and R4's routing tables
R3#sh ip route
<snip>
Gateway of last
resort is not set
172.16.0.0/24 is subnetted, 4 subnets
B 172.16.0.0 [200/0] via 192.168.13.1,
00:13:57
B 172.16.1.0 [200/0] via 192.168.13.1,
00:13:57
B 172.16.2.0 [200/0] via 192.168.13.1,
00:13:57
B 172.16.3.0 [200/0] via 192.168.13.1,
00:13:57
<snip>
R4#sh ip route
<snip>
172.16.0.0/24 is subnetted, 4 subnets
B 172.16.0.0 [200/0] via 192.168.13.1,
00:00:43
B 172.16.1.0 [200/0] via 192.168.13.1,
00:00:43
B 172.16.2.0 [200/0] via 192.168.13.1,
00:00:43
B 172.16.3.0 [200/0] via 192.168.13.1,
00:00:43
<snip>
R5#sh ip route
<snip>
5.0.0.0/8 is variably subnetted, 2
subnets, 2 masks
C 5.5.5.0/24 is directly connected,
Loopback0
L 5.5.5.5/32 is directly connected,
Loopback0
D 192.168.13.0/24 [90/2172416] via
192.168.35.3, 00:44:22, Serial1/0
D 192.168.34.0/24 [90/2681856] via
192.168.45.4, 00:44:22, Serial1/1
[90/2681856] via
192.168.35.3, 00:44:22, Serial1/0
192.168.35.0/24 is variably subnetted, 2
subnets, 2 masks
C 192.168.35.0/24 is directly connected,
Serial1/0
L 192.168.35.5/32 is directly connected,
Serial1/0
192.168.45.0/24 is variably subnetted, 2
subnets, 2 masks
C 192.168.45.0/24 is directly connected,
Serial1/1
L 192.168.45.5/32 is directly connected,
Serial1/1
As we can see from
the output above R5 does not see any of PE1's prefixes yet. So we should
redistribute BGP into EIGRP on R4 and make sure R5's loopback can reach PE1's
prefixes, which just happens to be the next task to complete.
R4(config)#router
eigrp 200
R4(config-router)#redistribute
bgp 200 metric 1 1 1 1 1
Now let's look at
the routing tables again.
R3#sh ip route
<snip>
Gateway of last
resort is not set
172.16.0.0/24 is subnetted, 4 subnets
B 172.16.0.0 [200/0] via 192.168.13.1,
00:13:57
B 172.16.1.0 [200/0] via 192.168.13.1,
00:13:57
B 172.16.2.0 [200/0] via 192.168.13.1,
00:13:57
B 172.16.3.0 [200/0] via 192.168.13.1,
00:13:57
<snip>
R4#sh ip route
<snip>
172.16.0.0/24 is subnetted, 4 subnets
B 172.16.0.0 [200/0] via 192.168.13.1,
00:00:43
B 172.16.1.0 [200/0] via 192.168.13.1,
00:00:43
B 172.16.2.0 [200/0] via 192.168.13.1,
00:00:43
B 172.16.3.0 [200/0] via 192.168.13.1,
00:00:43
<snip>
R5#sh ip route
<snip>
5.0.0.0/8 is variably subnetted, 2
subnets, 2 masks
C 5.5.5.0/24 is directly connected,
Loopback0
L 5.5.5.5/32 is directly connected,
Loopback0
D 192.168.13.0/24 [90/2172416] via
192.168.35.3, 00:44:22, Serial1/0
D 192.168.34.0/24 [90/2681856] via
192.168.45.4, 00:44:22, Serial1/1
[90/2681856] via
192.168.35.3, 00:44:22, Serial1/0
192.168.35.0/24 is variably subnetted, 2
subnets, 2 masks
C 192.168.35.0/24 is directly connected,
Serial1/0
L 192.168.35.5/32 is directly connected,
Serial1/0
192.168.45.0/24 is variably subnetted, 2
subnets, 2 masks
C 192.168.45.0/24 is directly connected,
Serial1/1
L 192.168.45.5/32 is directly connected,
Serial1/1
Hmmm…the tables look
the same as before. The problem here is that by default you cannot redistribute
iBGP into an IGP. eBGP learned prefixes will redistribute by default but
because we are doing the redistribution on R4 the prefixes are learned via an
iBGP neighbor. To get around this we use the BGP redistribute-internal command.
Be careful doing this in a production environment as this can lead to resource
and looping issues if not done with careful consideration of its impact to the
routing tables of your network.
R4(config)#router
bgp 200
R4(config-router)#bgp
redistribute-internal
OK, now let's
examine the routing tables again.
R3#sh ip rout
<snip>
172.16.0.0/24 is subnetted, 4 subnets
D EX 172.16.0.0 [170/2560512256] via
192.168.34.4, 00:00:34, Serial1/0
D EX 172.16.1.0 [170/2560512256] via
192.168.34.4, 00:00:34, Serial1/0
D EX 172.16.2.0 [170/2560512256] via
192.168.34.4, 00:00:34, Serial1/0
D EX 172.16.3.0 [170/2560512256] via
192.168.34.4, 00:00:34, Serial1/0
<snip>
R4#sh ip route
<snip>
172.16.0.0/24 is subnetted, 4 subnets
B 172.16.0.0 [200/0] via 192.168.13.1,
00:01:04
B 172.16.1.0 [200/0] via 192.168.13.1,
00:01:04
B 172.16.2.0 [200/0] via 192.168.13.1,
00:01:04
B 172.16.3.0 [200/0] via 192.168.13.1,
00:01:04
<snip>
R5#sh ip route
<snip> 172.16.0.0/24 is subnetted, 4 subnets
D EX 172.16.0.0 [170/2560512256] via
192.168.45.4, 00:01:53, Serial1/1
D EX 172.16.1.0
[170/2560512256] via 192.168.45.4, 00:01:53, Serial1/1
D EX 172.16.2.0
[170/2560512256] via 192.168.45.4, 00:01:53, Serial1/1
D EX 172.16.3.0
[170/2560512256] via 192.168.45.4, 00:01:53, Serial1/1
<snip>
Ah, now we see PE1's
prefixes in our global routing table. Now we just need to make sure PE1 can see
R5's loopback address and we should be good…?
R5(config)#router
eigrp 200
R5(config-router)#network
5.5.5.0 0.0.0.255
R1(config)#router
bgp 200
R1(config-router)#network
5.5.5.0 mask 255.255.255.0
OK, lets ping and
see what we get…
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 5.5.5.5
.....
Success rate is 0
percent (0/5)
Hhmm…
R5#traceroute
172.16.1.1 source loopback 0
Type escape sequence
to abort.
Tracing the route to
172.16.1.1
VRF info: (vrf in
name/id, vrf out name/id)
1 192.168.45.4 24 msec 20 msec 24 msec
2 192.168.34.3 16 msec 20 msec 44 msec
3 192.168.34.4 64 msec 16 msec 48 msec
4 192.168.34.3 64 msec 52 msec 60 msec
5 192.168.34.4 48 msec 64 msec 84 msec
6 192.168.34.3 80 msec 52 msec 88 msec
7 192.168.34.4 128 msec 108 msec 108 msec
<snip>
Well that is not
good, so what is going on here. Take a look at R5's routing table and
specifically look at the next hop values for the PE1 routes. They all point
back to R4 because that is where R3 learned the route from. So again there are
usually multiple ways to resolve this but let's fix this by focusing on what
the problem is. EIGRP has pre-empted the BGP routes in the routing table due to
its lower administrative distance. So to solve that problem we can change the
admin distance of external EIGRP routes.
R3(config)#router
eigrp 200
R3(config-router)#distance
eigrp 90 201
R3(config-router)#do
sh ip route
<snip>
172.16.0.0/24 is subnetted, 4 subnets
B 172.16.0.0 [200/0] via 192.168.13.1,
00:00:08
B 172.16.1.0 [200/0] via 192.168.13.1,
00:00:08
B 172.16.2.0 [200/0] via 192.168.13.1,
00:00:08
B 172.16.3.0 [200/0] via 192.168.13.1,
00:00:08
192.168.13.0/24 is variably subnetted, 2
subnets, 2 masks
C 192.168.13.0/24 is directly connected,
FastEthernet0/0
L 192.168.13.3/32 is directly connected,
FastEthernet0/0
192.168.34.0/24 is variably subnetted, 2
subnets, 2 masks
C 192.168.34.0/24 is directly connected,
Serial1/0
L 192.168.34.3/32 is directly connected,
Serial1/0
Note: Unfortunately
it's not possible at this time to conditional modify the EIGRP administrative
distance for external routes. This is only possible for internal routes.
Now that looks
better…
R5#traceroute
172.16.1.1 source loopback 0
Type escape sequence
to abort.
Tracing the route to
172.16.1.1
VRF info: (vrf in
name/id, vrf out name/id)
1 192.168.45.4 24 msec 32 msec 36 msec
2 192.168.34.3 20 msec 52 msec 52 msec
3 192.168.13.1 52 msec 80 msec 84 msec
4 192.168.11.11 80 msec * 88 msec
Obviously one my
question why redistribute on R4 in the first place but this is a lab and we are
intentionally not following best practices to create scenarios to test our
knowledge of specific concepts.
Sources:
No comments:
Post a Comment