Routing Protocol Redistribution using Tags and admin distance

Generally when I have been playing around with redistribution I have only been using route tags to eliminate routing loops, however this may not always work.

Below is a redistribution lab topology I have been recently playing with.

The base configurations prior to doing redistribution are shown below:

R4
hostname R4
!
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
!
interface Serial0/0
 description R5 S0/0
 ip address 192.168.45.4 255.255.255.0
 clock rate 2000000
!
interface FastEthernet0/1
 description R6 Fa0/0
 ip address 192.168.46.4 255.255.255.0
 duplex auto
 speed auto
!
router eigrp 45
 network 4.4.4.4 0.0.0.0
 network 192.168.45.4 0.0.0.0
 no auto-summary
!
router ospf 456
 log-adjacency-changes
 network 4.4.4.4 0.0.0.0 area 46
 network 192.168.46.4 0.0.0.0 area 46
!


R5
hostname R5
!
interface Loopback0
 ip address 5.5.5.5 255.255.255.255
!
interface Serial0/0
 description R4 S0/0
 ip address 192.168.45.5 255.255.255.0
!
interface FastEthernet0/1
 description R6 Fa0/1
 ip address 192.168.56.5 255.255.255.0
 duplex auto
 speed auto
!
router eigrp 45
 network 5.5.5.5 0.0.0.0
 network 192.168.45.5 0.0.0.0
 no auto-summary
!
router ospf 456
 log-adjacency-changes
 network 5.5.5.5 0.0.0.0 area 56
 network 192.168.56.5 0.0.0.0 area 56
!


R6
hostname R6
!
interface Loopback0
 ip address 6.6.6.6 255.255.255.255
!
interface FastEthernet0/0
 description R4 Fa0/1
 ip address 192.168.46.6 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet0/1
 description R5 Fa0/1
 ip address 192.168.56.6 255.255.255.0
 duplex auto
 speed auto
!
interface Serial0/0
 description R7 S0/0
 ip address 192.168.67.6 255.255.255.0
 clock rate 2000000
!
router ospf 456
 log-adjacency-changes
 network 6.6.6.6 0.0.0.0 area 0
 network 192.168.46.6 0.0.0.0 area 46
 network 192.168.56.6 0.0.0.0 area 56
!
router rip
 version 2
 network 6.0.0.0
 network 192.168.67.0
 no auto-summary
!

R7
hostname R7
!
interface Loopback0
 ip address 7.7.7.7 255.255.255.255
!
interface Serial0/0
 description R6 S0/0
 ip address 192.168.67.7 255.255.255.0
!
router rip
 version 2
 network 7.0.0.0
 network 192.168.67.0
 no auto-summary
!

In this example, I want to have mutual redistribution across all protocols to ensure connectivity regardless as to which link fails.

Redistribution happens at three locations - R6: Between RIP and OSPF while both R4 and R5 redistribute between OSPF and EIGRP

Route-Tags shall be used to ensure that routes originated by a routing protocol are not injected back into it.  To keep things straight forward, I am using the default admin distances for the protocols for their tags.

R6

route-map RIP2OSPF deny 10
 match tag 110
!
route-map RIP2OSPF permit 20
 match tag 90
 set tag 90
!
route-map RIP2OSPF permit 30
 set tag 120

route-map OSPF2RIP deny 10
 match tag 120
!
route-map OSPF2RIP permit 20
 match tag 90
 set tag 90
!
route-map OSPF2RIP permit 30
 set tag 110
!
router rip
 redistribute ospf 456 route-map OSPF2RIP metric 3
router ospf 456
 redistribute rip subnets route-map RIP2OSPF metric 100

R4/R5

route-map OSPF2EIGRP deny 10
 match tag 90
!
route-map OSPF2EIGRP permit 20
 match tag 120
 set tag 120
!
route-map OSPF2EIGRP permit 30
 set tag 110
!
route-map EIGRP2OSPF deny 10
 match tag 110
!
route-map EIGRP2OSPF permit 20
 match tag 120
 set tag 120
!
route-map EIGRP2OSPF permit 30
 set tag 90
!
router eigrp 45
 redistribute ospf 456 route-map OSPF2EIGRP metric 100000 1 255 1 1500
router ospf 456
 redistribute eigrp 45 subnets route-map EIGRP2OSPF metric 100


So far everything should be fine in the quiescent state.  However if we play around with links it is possible to introduce some problems (whenever working on a redistribution lab performing "debug ip routing" can be quite helpful)

If bounce a link between R6 and R5 we can see that the route to R7 Loopback disappears

R6#sh ip route 7.7.7.7
Routing entry for 7.7.7.7/32
  Known via "rip", distance 120, metric 1
  Redistributing via ospf 456, rip
  Advertised by ospf 456 metric 100 subnets route-map RIP2OSPF
  Last update from 192.168.67.7 on Serial0/0, 00:00:01 ago
  Routing Descriptor Blocks:
  * 192.168.67.7, from 192.168.67.7, 00:00:01 ago, via Serial0/0
      Route metric is 1, traffic share count is 1

R6#debug ip routing
IP routing debugging is on
R6#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R6(config)#int fa0/1
R6(config-if)#shut
*Mar  1 00:16:34.343: RT: is_up: FastEthernet0/1 0 state: 6 sub state: 1 line: 1 has_route: True
*Mar  1 00:16:34.343: %OSPF-5-ADJCHG: Process 456, Nbr 5.5.5.5 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar  1 00:16:34.343: RT: interface FastEthernet0/1 removed from routing table
*Mar  1 00:16:34.343: RT: del 192.168.56.0 via 0.0.0.0, connected metric [0/0]
*Mar  1 00:16:34.343: RT: delete network route to 192.168.56.0
*Mar  1 00:16:34.347: RT: NET-RED 192.168.56.0/24
*Mar  1 00:16:34.347: RT: Pruning routes for FastEthernet0/1 (2)
*Mar  1 00:16:34.351: RT: delete route to 192.168.45.0 via 192.168.56.5, FastEthernet0/1
*Mar  1 00:16:34.351: RT: NET-RED 192.168.45.0/24
*Mar  1 00:16:34.351: RT: delete route to 5.5.5.5 via 192.168.56.5, FastEthernet0/1
*Mar  1 00:16:34.351: RT: no routes to 5.5.5.5, flushing
*Mar  1 00:16:34.351: RT: NET-RED 5.5.5.5/32
*Mar  1 00:16:34.351: RT: delete network route to 5.0.0.0
*Mar  1 00:16:34.351: RT: NET-RED 5.0.0.0/8
*Mar  1 00:16:36.327: %LINK-5-CHANGED: Interface FastEthernet0/1, changed state to administratively down
*Mar  1 00:16:36.335: RT: is_up: FastEthernet0/1 0 state: 6 sub state: 1 line: 1 has_route: False
*Mar  1 00:16:37.327: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
*Mar  1 00:16:37.335: RT: is_up: FastEthernet0/1 0 state: 6 sub state: 1 line: 1 has_route: False
*Mar  1 00:16:39.859: RT: add 5.5.5.5/32 via 192.168.46.4, ospf metric [110/100]
*Mar  1 00:16:39.863: RT: NET-RED 5.5.5.5/32

R6(config-if)#no shut
*Mar  1 00:16:46.307: RT: is_up: FastEthernet0/1 1 state: 4 sub state: 1 line: 1 has_route: False
*Mar  1 00:16:46.311: RT: add 192.168.56.0/24 via 0.0.0.0, connected metric [0/0]
*Mar  1 00:16:46.311: RT: NET-RED 192.168.56.0/24
*Mar  1 00:16:46.311: RT: interface FastEthernet0/1 added to routing table
*Mar  1 00:16:48.283: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
*Mar  1 00:16:48.291: RT: is_up: FastEthernet0/1 1 state: 4 sub state: 1 line: 1 has_route: True
*Mar  1 00:16:49.283: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up
*Mar  1 00:16:49.291: RT: is_up: FastEthernet0/1 1 state: 4 sub state: 1 line: 1 has_route: True
*Mar  1 00:16:50.959: %OSPF-5-ADJCHG: Process 456, Nbr 5.5.5.5 on FastEthernet0/1 from LOADING to FULL, Loading Done
*Mar  1 00:16:59.883: RT: del 5.5.5.5/32 via 192.168.46.4, ospf metric [110/100]
*Mar  1 00:16:59.887: RT: add 5.5.5.5/32 via 192.168.56.5, ospf metric [110/11]
*Mar  1 00:16:59.891: RT: NET-RED 5.5.5.5/32
*Mar  1 00:16:59.895: RT: closer admin distance for 7.7.7.7, flushing 1 routes
*Mar  1 00:16:59.899: RT: NET-RED 7.7.7.7/32
*Mar  1 00:16:59.899: RT: add 7.7.7.7/32 via 192.168.56.5, ospf metric [110/100]
*Mar  1 00:16:59.899: RT: NET-RED 7.7.7.7/32
*Mar  1 00:16:59.899: RT: add 192.168.45.0/24 via 192.168.56.5, ospf metric [110/100]
*Mar  1 00:16:59.899: RT: NET-RED 192.168.45.0/24

R6(config-if)#do sh ip route 7.7.7.7
Routing entry for 7.7.7.7/32
  Known via "ospf 456", distance 110, metric 100
  Tag 120, type extern 2, forward metric 10
  Redistributing via rip
  Last update from 192.168.56.5 on FastEthernet0/1, 00:00:16 ago
  Routing Descriptor Blocks:
  * 192.168.56.5, from 5.5.5.5, 00:00:16 ago, via FastEthernet0/1
      Route metric is 100, traffic share count is 1
      Route tag 120

On R6 we can see that the route to 7.7.7.7 is now being learnt through OSPF even though we were the one to put it there in the first place!  The issue here is because of the administration distance of the route.  RIP has an admin distance of 120, OSPF 110 and EIGRP 90.

On R6 our RIP route from R7 is redistributed into OSPF to R4 and R5.  When the link between R6 and R5 is brought down, the only way R5 knows about this route is when it is redistributed by R4 into EIGRP.
When the link between R6 and R5 comes back into service, that route is redistributed from EIGRP into OSPF by R5 and advertised to R6.  For the same route, the lower administration distance, the more belivable and therefore the RIP route is ignored (as can be seen by the debug above)

R6(config-if)#do ping 7.7.7.7

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

It is no surprise that that the ping to R7 failed, since R6 is the adjacent router to R7 and thinks the way there is via R5 - traffic to 7.7.7.7 will zoom around the network until the TTL expires

If we reset the OSPF process on R6 - things can return to the normal state (the route for 7.7.7.7 originated into OSPF will be withdrawn from EIGRP by R4 and wont be advertised back into OSPF by R5)

R6(config-if)#do clear ip ospf proc
Reset ALL OSPF processes? [no]: yes
*Mar  1 00:19:24.267: %OSPF-5-ADJCHG: Process 456, Nbr 4.4.4.4 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar  1 00:19:24.323: %OSPF-5-ADJCHG: Process 456, Nbr 5.5.5.5 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar  1 00:19:24.331: RT: delete route to 192.168.45.0/24
*Mar  1 00:19:24.331: RT: NET-RED 192.168.45.0/24
*Mar  1 00:19:24.335: RT: delete route to 4.4.4.4/32
*Mar  1 00:19:24.335: RT: NET-RED 4.4.4.4/32
*Mar  1 00:19:24.335: RT: delete network route to 4.0.0.0
*Mar  1 00:19:24.339: RT: NET-RED 4.0.0.0/8
*Mar  1 00:19:24.355: RT: delete route to 5.5.5.5/32
*Mar  1 00:19:24.359: RT: NET-RED 5.5.5.5/32
*Mar  1 00:19:24.359: RT: delete network route to 5.0.0.0
*Mar  1 00:19:24.363: RT: NET-RED 5.0.0.0/8
*Mar  1 00:19:24.371: RT: delete route to 7.7.7.7/32
*Mar  1 00:19:24.371: RT: NET-RED 7.7.7.7/32
*Mar  1 00:19:24.371: RT: delete network route to 7.0.0.0
*Mar  1 00:19:24.371: RT: NET-RED 7.0.0.0/8
*Mar  1 00:19:24.551: %OSPF-5-ADJCHG: Process 456, Nbr 5.5.5.5 on FastEthernet0/1 from LOADING to FULL, Loading Done
*Mar  1 00:19:24.551: %OSPF-5-ADJCHG: Process 456, Nbr 4.4.4.4 on FastEthernet0/0 from LOADING to FULL, Loading Done
*Mar  1 00:19:29.539: RT: add 4.4.4.4/32 via 192.168.46.4, ospf metric [110/11]
*Mar  1 00:19:29.539: RT: NET-RED 4.4.4.4/32
*Mar  1 00:19:29.543: RT: add 5.5.5.5/32 via 192.168.56.5, ospf metric [110/11]
*Mar  1 00:19:29.543: RT: NET-RED 5.5.5.5/32
*Mar  1 00:19:29.547: RT: add 192.168.45.0/24 via 192.168.56.5, ospf metric [110/100]
*Mar  1 00:19:29.547: RT: NET-RED 192.168.45.0/24
*Mar  1 00:19:29.547: RT: add 192.168.45.0/24 via 192.168.46.4, ospf metric [110/100]
*Mar  1 00:19:29.547: RT: NET-RED 192.168.45.0/24
*Mar  1 00:19:49.191: RT: add 7.7.7.7/32 via 192.168.67.7, rip metric [120/1]
*Mar  1 00:19:49.195: RT: NET-RED 7.7.7.7/32


We can see that this fixes things (until the next time we lose one of the OSPF links and it gets restored) We know that the problem is related to the route believability (Admin Distance) so the obvious answer is to modify it.

We have at least two ways to do so:
 Increase the Admin Distance of OSPF
 Decrease the Admin Distance for RIP

Related to the second, I will decrease the admin distance for a specific route (7.7.7.7/32)


R6(config-if)#access-list 1 permit host 7.7.7.7
R6(config)#router rip
R6(config-router)#distance 105 192.168.67.7 0.0.0.0 1

Not too long after after applying this change we can see:

*Mar  1 00:22:10.359: RT: closer admin distance for 7.7.7.7, flushing 1 routes
*Mar  1 00:22:10.363: RT: add 7.7.7.7/32 via 192.168.67.7, rip metric [105/1]
*Mar  1 00:22:10.367: RT: NET-RED 7.7.7.7/32

105 is less than 110, so R6 will not insert the OSPF route into the RIB - lets verify this by bouncing the link between R5 and R6 again:

R6(config-router)#int fa0/1
R6(config-if)#shut
*Mar  1 00:25:56.751: RT: is_up: FastEthernet0/1 0 state: 6 sub state: 1 line: 1 has_route: True
*Mar  1 00:25:56.755: %OSPF-5-ADJCHG: Process 456, Nbr 5.5.5.5 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar  1 00:25:56.763: RT: interface FastEthernet0/1 removed from routing table
*Mar  1 00:25:56.767: RT: del 192.168.56.0 via 0.0.0.0, connected metric [0/0]
*Mar  1 00:25:56.767: RT: delete network route to 192.168.56.0
*Mar  1 00:25:56.767: RT: NET-RED 192.168.56.0/24
*Mar  1 00:25:56.767: RT: Pruning routes for FastEthernet0/1 (2)
*Mar  1 00:25:56.771: RT: delete route to 192.168.45.0 via 192.168.56.5, FastEthernet0/1
*Mar  1 00:25:56.771: RT: NET-RED 192.168.45.0/24
*Mar  1 00:25:56.771: RT: delete route to 5.5.5.5 via 192.168.56.5, FastEthernet0/1
*Mar  1 00:25:56.771: RT: no routes to 5.5.5.5, flushing
*Mar  1 00:25:56.771: RT: NET-RED 5.5.5.5/32
*Mar  1 00:25:56.771: RT: delete network route to 5.0.0.0
*Mar  1 00:25:56.771: RT: NET-RED 5.0.0.0/8
*Mar  1 00:25:58.727: %LINK-5-CHANGED: Interface FastEthernet0/1, changed state to administratively down
*Mar  1 00:25:58.735: RT: is_up: FastEthernet0/1 0 state: 6 sub state: 1 line: 1 has_route: False
*Mar  1 00:25:59.727: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
*Mar  1 00:25:59.735: RT: is_up: FastEthernet0/1 0 state: 6 sub state: 1 line: 1 has_route: False
*Mar  1 00:26:02.275: RT: add 5.5.5.5/32 via 192.168.46.4, ospf metric [110/100]
*Mar  1 00:26:02.275: RT: NET-RED 5.5.5.5/32

R6(config-if)#no shut
*Mar  1 00:26:29.059: RT: is_up: FastEthernet0/1 1 state: 4 sub state: 1 line: 1 has_route: False
*Mar  1 00:26:29.059: RT: add 192.168.56.0/24 via 0.0.0.0, connected metric [0/0]
*Mar  1 00:26:29.063: RT: NET-RED 192.168.56.0/24
*Mar  1 00:26:29.063: RT: interface FastEthernet0/1 added to routing table
*Mar  1 00:26:31.023: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
*Mar  1 00:26:31.027: RT: is_up: FastEthernet0/1 1 state: 4 sub state: 1 line: 1 has_route: True
*Mar  1 00:26:32.023: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up
*Mar  1 00:26:32.031: RT: is_up: FastEthernet0/1 1 state: 4 sub state: 1 line: 1 has_route: True
*Mar  1 00:26:33.995: %OSPF-5-ADJCHG: Process 456, Nbr 5.5.5.5 on FastEthernet0/1 from LOADING to FULL, Loading Done
*Mar  1 00:26:44.575: RT: del 5.5.5.5/32 via 192.168.46.4, ospf metric [110/100]
*Mar  1 00:26:44.579: RT: add 5.5.5.5/32 via 192.168.56.5, ospf metric [110/11]
*Mar  1 00:26:44.579: RT: NET-RED 5.5.5.5/32
*Mar  1 00:26:44.579: RT: add 192.168.45.0/24 via 192.168.56.5, ospf metric [110/100]
*Mar  1 00:26:44.583: RT: NET-RED 192.168.45.0/24

As we can see there has been no change to the routing table for 7.7.7.7

R6(config-if)#do sh ip route 7.7.7.7
Routing entry for 7.7.7.7/32
  Known via "rip", distance 105, metric 1
  Redistributing via ospf 456, rip
  Advertised by ospf 456 metric 100 subnets route-map RIP2OSPF
  Last update from 192.168.67.7 on Serial0/0, 00:00:25 ago
  Routing Descriptor Blocks:
  * 192.168.67.7, from 192.168.67.7, 00:00:25 ago, via Serial0/0
      Route metric is 1, traffic share count is 1

R6(config-if)#do ping 7.7.7.7

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

While using route tags is one of the tools to control routing loops, understanding the admin distance is also worthwhile knowing.