Part 1: Route-Map tagging for 2-way Redistribution, a prevention mechanism for routing loops!

Above is a “Single-Point 2-way Redistribution” in our network, which is honestly not going to (probably ever) present a loop from sharing or “leaking”routes back into their own domains, however route-tagging usefulness goes beyond just Redistribution as we will see it I assume in the next topic up PBR (Policy Based Routing / Policy Routing) and Route-Maps have quite a few BGP mechanisms so I expect to see it there as well.

On the topic of going beyond what we are learning here today, and what this type of topology this information is really going to be useful or necessary for:

That’s right, I hit you with TWO paint pictures in a single post, things are starting to heat up! What you see in the above Topology is a “Multi-Point 2-way Redistribution” scenario where all 3 ASBR’s are going to be sharing routes between domains, and you do not want OSPF routes going into the RIP domain being redistributed back into the OSPF domain as a RIP route. This is CCIE level configuration and troubleshooting, so we will stick Single-Point 2-way Redistribution.

So back to this scenario we have some work with R3 to do here, and firstly that is to remove all redistribution / route maps / ACL’s from our last lab:

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#no access-list 5 permit 5.0.0.0 0.255.255.255
R3(config)#no access-list 15 permit 172.12.15.0 0.0.0.255
R3(config)#router ospf 1
R3(config-router)#no redistribute rip subnets route-map RIP2OSPF
R3(config-router)#no route-map RIP2OSPF
R3(config)#do show ip proto
Routing Protocol is “ospf 1”
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 172.12.33.3
  It is an area border and autonomous system boundary router
  Redistributing External Routes from,
    rip

I wanted to point out a VERY IMPORTANT concept again here when removing all the attributes, and I did a show run to verify that they were all gone, but “sh ip proto” shows rip is still being redistributed despite being specifically removed it seems to always leave a general rip redist behind, so always “no redistribute rip” or “no redistribute connected” as well no “no redistribute rip/connected subnets” – ALWAYS MAKE SURE TO REMOVE IT AT IT’S BASE AS REMOVING THE LONGER REDISTRIBUTE COMMANDS!!

Speaking of connected subnets, I have released lo3 (3.3.3.3 /32) and lo30 (30.30.30.0 /24) into the wild as “Connected” routes on R3, as they have an interesting error console message that I would like to demonstrate so I removed those from the RIP network:

R3(config)#router rip
R3(config-router)#no network 3.3.3.3
R3(config-router)#no network 30.30.30.0
R3(config-router)#

Route-map Tagging on Redistribution as stated above is a route loop prevention mechanism that is usually reserved for multi-point 2 way redistributes, but is best practice to also put on single-point’s like ours to prevent the very unlikely possibility of route leaking (OSPF re-learning its own routes via Redist).

These are where sequence numbers will become more significant as we need the right permit and deny’s in place to stop route leaks, while allowing legitimate routes to be redistributed. I have a (hopefully) pretty simple example I will step through the configuration, with explanations and pointers throughout the configuration.

So without further ado, I have a couple of things I want to demonstrate:

R3(config)#route-map RIP2OSPF permit 10
R3(config-route-map)#set tag 10
R3(config-route-map)#router ospf 1
R3(config-router)#redistribute rip subnets ?
  metric       Metric for redistributed routes
  metric-type  OSPF/IS-IS exterior metric type for redistributed routes
  route-map    Route map reference
  tag          Set tag for routes redistributed into OSPF
  <cr>

R3(config-router)#redistribute rip route-map RIP2OSPF ?
  metric       Metric for redistributed routes
  metric-type  OSPF/IS-IS exterior metric type for redistributed routes
  subnets      Consider subnets for redistribution into OSPF
  tag          Set tag for routes redistributed into OSPF
  <cr>

R3(config-router)#redistribute rip route-map RIP2OSPF subnets ?
  metric       Metric for redistributed routes
  metric-type  OSPF/IS-IS exterior metric type for redistributed routes
  tag          Set tag for routes redistributed into OSPF
  <cr>

R3(config-router)#redistribute rip route-map RIP2OSPF subnets
R3(config-router)#redistribute connected route-map RIP2OSPF subnets
R3(config-router)#

I’ve highlight the few things to be learned from this output:

• When redistributing, you can put metrics / metric-types / subnets before or after your route-map statement and it will work the same way
• You can use the same route-maps on different routing domains your Redistributing

So now all O EX routes should have the route tag of 10, lets check it out:

R4#sh ip route ospf

Gateway of last resort is not set

      3.0.0.0/32 is subnetted, 1 subnets
O E2     3.3.3.3 [110/20] via 172.12.34.3, 00:05:42, FastEthernet0/1
O E2  5.0.0.0/8 [110/20] via 172.12.34.3, 00:05:56, FastEthernet0/1
      172.12.0.0/16 is variably subnetted, 7 subnets, 2 masks
O E2     172.12.15.0/24 [110/20] via 172.12.34.3, 00:05:56, FastEthernet0/1
O        172.12.33.3/32 [110/2] via 172.12.34.3, 02:07:56, FastEthernet0/1
O E2     172.12.123.0/24 [110/20] via 172.12.34.3, 00:05:56, FastEthernet0/1
R4#sh ip proto
*** IP Routing is NSF aware ***

Routing Protocol is “ospf 1”
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 172.12.44.4
  It is an area border router
  Number of areas in this router is 4. 4 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
    4.4.4.4 0.0.0.0 area 4
    172.12.34.0 0.0.0.255 area 34
    172.12.44.0 0.0.0.255 area 51
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.12.33.3          110      00:06:14
  Distance: (default is 110)

R4#

So Redistribution is happening, but neither “sh ip route” or “sh ip proto” is going to show you route tags, and surprisingly neither is the gigantic amount of output from “sh ip ospf”

To see your route tags, you will need to do and extended “sh ip route” :

R4#sh ip route 3.3.3.3
Routing entry for 3.3.3.3/32
  Known via “ospf 1”, distance 110, metric 20
  Tag 10, type extern 2, forward metric 1
  Last update from 172.12.34.3 on FastEthernet0/1, 00:25:12 ago
  Routing Descriptor Blocks:
  * 172.12.34.3, from 172.12.33.3, 00:25:12 ago, via FastEthernet0/1
      Route metric is 20, traffic share count is 1
      Route tag 10
R4#

And there it can be seen a couple times, so this is how it will need to be determined if a particular route is tagged in a route-map. Now to Redistribute OSPF2RIP via route-map, and I am about to hit a snag that you will see:

R3(config)#route-map OSPF2RIP permit 20
R3(config-route-map)#set tag 20
R3(config-route-map)#router rip
R3(config-router)#redistribute ospf 1 route-map OSPF2RIP
R3(config-router)#do sh ip route

Gateway of last resort is 172.12.123.1 to network 0.0.0.0

     3.0.0.0/32 is subnetted, 1 subnets
C       3.3.3.3 is directly connected, Loopback3
     4.0.0.0/32 is subnetted, 1 subnets
O IA    4.4.4.4 [110/2] via 172.12.34.4, 00:33:18, FastEthernet0/1
R    5.0.0.0/8 [120/1] via 172.12.123.1, 00:00:14, Serial0/2
     172.12.0.0/16 is variably subnetted, 5 subnets, 2 masks
C       172.12.33.0/24 is directly connected, Loopback33
C       172.12.34.0/24 is directly connected, FastEthernet0/1
O IA    172.12.44.4/32 [110/2] via 172.12.34.4, 00:33:19, FastEthernet0/1
R       172.12.15.0/24 [120/1] via 172.12.123.1, 00:00:15, Serial0/2
C       172.12.123.0/24 is directly connected, Serial0/2
R*   0.0.0.0/0 [120/1] via 172.12.123.1, 00:00:15, Serial0/2
R3(config-router)#do sh ip route 4.4.4.4
Routing entry for 4.4.4.4/32
  Known via “ospf 1”, distance 110, metric 2, type inter area
  Redistributing via rip
  Last update from 172.12.34.4 on FastEthernet0/1, 00:33:32 ago
  Routing Descriptor Blocks:
  * 172.12.34.4, from 172.12.44.4, 00:33:32 ago, via FastEthernet0/1
      Route metric is 2, traffic share count is 1

So we will not be able to verify the route tags on the ASBR applying them because it already has both networks running on it, so there is not redistributed routes on the ASBR, however to verify a tag I need a down-stream router and being this is connected to the NBMA network I have to see if R1 is able to see the routes:

R1#sh ip route

Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
C       1.1.1.1 is directly connected, Loopback1
     5.0.0.0/32 is subnetted, 1 subnets
D       5.5.5.5 [90/156160] via 172.12.15.5, 02:35:39, FastEthernet0/1
     172.12.0.0/24 is subnetted, 4 subnets
R       172.12.33.0 [120/1] via 172.12.123.3, 00:00:10, Serial0/0
R       172.12.34.0 [120/1] via 172.12.123.3, 00:00:10, Serial0/0
C       172.12.15.0 is directly connected, FastEthernet0/1
C       172.12.123.0 is directly connected, Serial0/0
R1#clear ip route *
R1#sh ip route

Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
C       1.1.1.1 is directly connected, Loopback1
     5.0.0.0/32 is subnetted, 1 subnets
D       5.5.5.5 [90/156160] via 172.12.15.5, 00:00:07, FastEthernet0/1
     172.12.0.0/24 is subnetted, 4 subnets
R       172.12.33.0 [120/1] via 172.12.123.3, 00:00:06, Serial0/0
R       172.12.34.0 [120/1] via 172.12.123.3, 00:00:06, Serial0/0
C       172.12.15.0 is directly connected, FastEthernet0/1
C       172.12.123.0 is directly connected, Serial0/0
R1#

I even did the “clear ip route *” as I thought perhaps RIP wasn’t updating, but no it just doesn’t see the routes. Now like with Distribute-List’s, I don’t know if this is an NBMA issue or a RIP issue routing over the NBMA, so I will need to put a different protocol on the WAN once I “wr erase” and “reload” these routers to give this another try.

So I hate to do this, but I’ll stop it here as I will need to re-cable a router to directly connect to R3, and reconfigure that router from scratch which sounds like a blast at 10:30pm on a Saturday night but I will save it for Sunday.

Once we have the third router, we will be able to explore how to configure denying traffic by tag #, so that routes are not leaking back into their own domains – I will be back to finish this up as soon as I get motivated tomorrow 🙂