Earlier I have done some posts on route redistribution and on
route filtering in different protocols. I wanted to expand on this
by showing different ways we can tag and do filtering with route-maps
when doing route redistribution.
We start out with this topology where two different OSPF segments are
separated by an EIGRP segment.
R2 will redistribute between OSPF and EIGRP mutually. R1 is redistributing
its loopback so it will be an external OSPF route. R4 and R5 will mutually
redistribute between EIGRP and OSPF. One interesting aspect about EIGRP is
that in the EIGRP packet we can see which protocol that originated the
route from the beginning. Take a look at this output showing the R1 loopback
in the EIGRP domain.
R4#sh ip eigrp topo 10.10.1.0/24 IP-EIGRP (AS 100): Topology entry for 10.10.1.0/24 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2560002816 Routing Descriptor Blocks: 10.10.24.2 (FastEthernet0/0), from 10.10.24.2, Send flag is 0x0 Composite metric is (2560002816/2560000256), Route is External Vector metric: Minimum bandwidth is 1 Kbit Total delay is 110 microseconds Reliability is 1/255 Load is 1/255 Minimum MTU is 1 Hop count is 1 External data: Originating router is 10.10.24.2 AS number of route is 1 External protocol is OSPF, external metric is 20 Administrator tag is 0 (0x00000000)
We can see that it came from OSPF 1 and that the ASBR is 10.10.24.2.
We also see that it had a metric of 20 and no tag applied to it. Where
is this information carried? Take a look at this packet capture.
We can see that a lot of information is carried for external routes.
This gives us options when doing tagging and filtering.
We configure distribution on R2 and then look at our options for doing
tagging and filtering.
R2#sh run | s router router eigrp 100 redistribute ospf 1 metric 1 1 1 1 1
If we look at R4 we should have two external routes with AD 170 going towards
the OSPF domain.
R4#sh ip route eigrp | i EX D EX 10.10.1.0 [170/2560002816] via 10.10.24.2, 00:07:22, FastEthernet0/0 D EX 10.10.12.0 [170/2560002816] via 10.10.24.2, 00:07:22, FastEthernet0/0
If we traceroute this traffic will go straight to R2.
R4#traceroute 10.10.1.1 num Type escape sequence to abort. Tracing the route to 10.10.1.1 1 10.10.24.2 32 msec 40 msec 28 msec 2 10.10.12.1 60 msec * 64 msec
What if we want external routes to go through R5 instead? We can
match on the route-type and incoming interface to block R2 routes.
This is a pretty blunt tool but can be good for some scenarios.
R4(config)#route-map RM_DENY_EXT_FA0/0 deny 10 R4(config-route-map)#match route-type external R4(config-route-map)#route-map RM_DENY_EXT_FA0/0 permit 100 R4(config-route-map)#router eigrp 100 R4(config-router)#distribute-list route-map RM_DENY_EXT_FA0/0 in fa0/0
So what we just did is filter all external routes coming in on Fa0/0.
Did we achieve the wanted result?
R4#sh ip route eigrp | i EX D EX 10.10.1.0 [170/2560030976] via 10.10.45.5, 00:00:21, FastEthernet0/1 D EX 10.10.12.0 [170/2560030976] via 10.10.45.5, 00:00:21, FastEthernet0/1 R4#traceroute 10.10.1.1 num Type escape sequence to abort. Tracing the route to 10.10.1.1 1 10.10.45.5 40 msec 36 msec 16 msec 2 10.10.35.3 56 msec 40 msec 40 msec 3 10.10.23.2 48 msec 28 msec 44 msec 4 10.10.12.1 68 msec * 68 msec
Now all external routes will go through R5 instead.
Currently we are not doing redistribution on R4 and R5. What will
happen with the EIGRP external routes when we do redistribution?
First we remove the previous configuration and then we configure
redistribution.
R4(config)#router eigrp 100 R4(config-router)#no distribute-list route-map RM_DENY_EXT_FA0/0 in FastEthernet0/0 R4(config-router)#redistribute ospf 1 metric 1 1 1 1 1 R4(config-router)#router ospf 10 R4(config-router)#redistribute eigrp 100 sub R5(config)#router eigrp 100 R5(config-router)#redistribute ospf 10 metric 1 1 1 1 1 R5(config-router)#router ospf 10 R5(config-router)#redistribute eigrp 100 sub
From R4 we now look at how it reaches 10.10.1.0/24.
R4#sh ip route 10.10.1.0 Routing entry for 10.10.1.0/24 Known via "eigrp 100", distance 170, metric 2560002816, type external Redistributing via eigrp 100, ospf 10 Advertised by ospf 10 subnets Last update from 10.10.45.5 on FastEthernet0/1, 00:00:52 ago Routing Descriptor Blocks: 10.10.45.5, from 10.10.45.5, 00:00:52 ago, via FastEthernet0/1 Route metric is 2560002816, traffic share count is 1 Total delay is 110 microseconds, minimum bandwidth is 1 Kbit Reliability 1/255, minimum MTU 1 bytes Loading 1/255, Hops 1 * 10.10.24.2, from 10.10.24.2, 00:00:52 ago, via FastEthernet0/0 Route metric is 2560002816, traffic share count is 1 Total delay is 110 microseconds, minimum bandwidth is 1 Kbit Reliability 1/255, minimum MTU 1 bytes Loading 1/255, Hops 1
Why does it have two entries for 10.10.1.0/24? Take a look in the
EIGRP topology table.
R4#sh ip eigrp topo 10.10.1.0/24 IP-EIGRP (AS 100): Topology entry for 10.10.1.0/24 State is Passive, Query origin flag is 1, 2 Successor(s), FD is 2560002816 Routing Descriptor Blocks: 10.10.24.2 (FastEthernet0/0), from 10.10.24.2, Send flag is 0x0 Composite metric is (2560002816/2560000256), Route is External Vector metric: Minimum bandwidth is 1 Kbit Total delay is 110 microseconds Reliability is 1/255 Load is 1/255 Minimum MTU is 1 Hop count is 1 External data: Originating router is 10.10.24.2 AS number of route is 1 External protocol is OSPF, external metric is 20 Administrator tag is 0 (0x00000000) 10.10.45.5 (FastEthernet0/1), from 10.10.45.5, Send flag is 0x0 Composite metric is (2560002816/2560000256), Route is External Vector metric: Minimum bandwidth is 1 Kbit Total delay is 110 microseconds Reliability is 1/255 Load is 1/255 Minimum MTU is 1 Hop count is 1 External data: Originating router is 10.10.56.5 AS number of route is 10 External protocol is OSPF, external metric is 20 Administrator tag is 0 (0x00000000)
We can see that one route is originating from OSPF 1, which is the true
source of the route and one is originating via OSPF 10. R5 is learning
this route via OSPF and then redistributing it into EIGRP and R4 is
learning that via EIGRP. Let us confirm that R5 sees this as an OSPF
route.
R5#sh ip route 10.10.1.0 Routing entry for 10.10.1.0/24 Known via "ospf 10", distance 110, metric 20, type extern 2, forward metric 2 Redistributing via eigrp 100 Advertised by eigrp 100 metric 1 1 1 1 1 Last update from 10.10.56.6 on FastEthernet1/0, 00:08:12 ago Routing Descriptor Blocks: * 10.10.56.6, from 10.10.46.4, 00:08:12 ago, via FastEthernet1/0 Route metric is 20, traffic share count is 1
Which it does. What would happen if R5 was redistributing with a
better metric than R2 is doing? First we enable debugging of ip
routing on R4. Remember that in a stable topology where everything
is converged there should be no changes.
R4#debug ip routing IP routing debugging is on
Then we change the metric on R5.
R5(config)#router eigrp 100 R5(config-router)#redistribute ospf 10 metric 100000 10 255 1 1500
RT: eigrp's 10.10.1.0/24 (via 10.10.45.5) metric changed from distance/metric [170/2560002816] to [170/30720] RT: del 10.10.1.0/24 via 10.10.24.2, eigrp metric [170/2560002816] RT: NET-RED 10.10.1.0/24 RT: NET-RED 10.10.1.0/24 RT: eigrp's 10.10.12.0/24 (via 10.10.45.5) metric changed from distance/metric [170/2560002816] to [170/30720] RT: del 10.10.12.0/24 via 10.10.24.2, eigrp metric [170/2560002816] RT: NET-RED 10.10.12.0/24 RT: NET-RED 10.10.12.0/24
We can see that the metric change but at least we have no flapping.
R4#sh ip route 10.10.1.0 Routing entry for 10.10.1.0/24 Known via "eigrp 100", distance 170, metric 30720, type external Redistributing via eigrp 100, ospf 10 Advertised by ospf 10 subnets Last update from 10.10.45.5 on FastEthernet0/1, 00:02:33 ago Routing Descriptor Blocks: * 10.10.45.5, from 10.10.45.5, 00:02:33 ago, via FastEthernet0/1 Route metric is 30720, traffic share count is 1 Total delay is 200 microseconds, minimum bandwidth is 100000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1
Do we still have reachability?
R4#traceroute 10.10.1.1 num Type escape sequence to abort. Tracing the route to 10.10.1.1 1 10.10.45.5 40 msec 16 msec 28 msec 2 10.10.56.6 48 msec 32 msec 28 msec 3 10.10.46.4 24 msec 44 msec 28 msec 4 10.10.45.5 52 msec 48 msec 52 msec 5 10.10.56.6 60 msec 60 msec 64 msec 6 10.10.46.4 64 msec 60 msec 60 msec 7 10.10.45.5 84 msec 108 msec 100 msec
Now we have a routing loop. What is happening here is that R4
is learning the route first via EIGRP and redistributes it into
OSPF. R5 learns this route via OSPF and then redistributes it
back into EIGRP and then R4 learns this route. They are now
both pointing at each other which means we have a loop.
What are our options of solving this? One way of solving it is
to increase the OSPF external AD on R5. That way R5 should not
redistribute it back to R4.
R5(config-router)#distance ospf external 180 R4#sh ip route 10.10.1.1 Routing entry for 10.10.1.0/24 Known via "ospf 10", distance 110, metric 20, type extern 2, forward metric 2 Last update from 10.10.46.6 on FastEthernet1/0, 00:00:38 ago Routing Descriptor Blocks: * 10.10.46.6, from 10.10.56.5, 00:00:38 ago, via FastEthernet1/0 Route metric is 20, traffic share count is 1 R4#traceroute 10.10.1.1 num Type escape sequence to abort. Tracing the route to 10.10.1.1 1 10.10.46.6 56 msec 36 msec 16 msec 2 10.10.56.5 48 msec 40 msec 40 msec 3 10.10.35.3 52 msec 52 msec 52 msec 4 10.10.23.2 112 msec 76 msec 72 msec 5 10.10.12.1 96 msec * 120 msec
That solved the loop changing the distance is a bit of a hack unless
we incorporate the same policy on all devices. At least all devices
involved in redistribution should have the same policy.
R4(config)#router ospf 10 R4(config-router)#distance ospf external 180 R4#traceroute 10.10.1.1 num Type escape sequence to abort. Tracing the route to 10.10.1.1 1 10.10.24.2 28 msec 32 msec 12 msec 2 10.10.12.1 44 msec * 60 msec
Yes, that solved it. A more elegant way is to use tagging and
filtering. We remove the previous distance commands.
What we can do now is to tag all external routes coming from OSPF 1
and then deny those routes from coming in if they have a tag set.
On R4 we tag routes with tag 444 and on R5 we will tag with 555.
First we confirm that the loop is back. You should note that with
redistribution you may see different results than I due to order of
operation. If that happens you could shutdown R5 link to R3 and
the loop should be back.
R4#traceroute 10.10.1.1 num Type escape sequence to abort. Tracing the route to 10.10.1.1 1 10.10.45.5 16 msec 44 msec 24 msec 2 10.10.56.6 36 msec 28 msec 36 msec 3 10.10.46.4 32 msec 40 msec 32 msec 4 10.10.45.5 48 msec 56 msec 48 msec 5 10.10.56.6 64 msec 56 msec 68 msec 6 10.10.46.4 48 msec 64 msec 60 msec
It is still there. Time for some route-maps.
R4(config)#route-map RM_DENY_EXT_FROM_R5 deny 10 R4(config-route-map)#match tag 444 R4(config-route-map)#route-map RM_DENY_EXT_FROM_R5 permit 100 R4(config-route-map)#route-map RM_SET_TAG_444 permit 10 R4(config-route-map)#match source-protocol ospf 1 R4(config-route-map)#match route-type external R4(config-route-map)#set tag 444 R4(config-route-map)#route-map RM_SET_TAG_444 permit 100 R4(config-route-map)#router eigrp 100 R4(config-router)#distribute-list route-map RM_DENY_EXT_FROM_R5 in R4(config-router)#router ospf 10 R4(config-router)#redistribute eigrp 100 route-map RM_SET_TAG_444 sub
First we will confirm on R5 that we now see a tag.
R5#sh ip route 10.10.1.0 Routing entry for 10.10.1.0/24 Known via "ospf 10", distance 110, metric 20 Tag 444, type extern 2, forward metric 2 Redistributing via eigrp 100 Advertised by eigrp 100 metric 100000 10 255 1 1500 Last update from 10.10.56.6 on FastEthernet1/0, 00:00:48 ago Routing Descriptor Blocks: * 10.10.56.6, from 10.10.46.4, 00:00:48 ago, via FastEthernet1/0 Route metric is 20, traffic share count is 1 Route tag 444
We now see the tag. There should be no tag on EIGRP internal routes.
We can confirm this on R6.
R6#sh ip route 10.10.24.0 Routing entry for 10.10.24.0/24 Known via "ospf 10", distance 110, metric 20, type extern 2, forward metric 1 Last update from 10.10.56.5 on FastEthernet0/1, 08:28:39 ago Routing Descriptor Blocks: 10.10.56.5, from 10.10.56.5, 08:28:39 ago, via FastEthernet0/1 Route metric is 20, traffic share count is 1 * 10.10.46.4, from 10.10.46.4, 08:30:34 ago, via FastEthernet0/0 Route metric is 20, traffic share count is 1
There should be no loop on R4 now. We will test with a traceroute.
R4#traceroute 10.10.1.1 num Type escape sequence to abort. Tracing the route to 10.10.1.1 1 10.10.24.2 28 msec 44 msec 12 msec 2 10.10.12.1 36 msec * 48 msec
The loop is gone. We should implement the same policy on R5 so if
R4 sends routes back to R5 it should stop it from learning them.
R5(config)#route-map RM_DENY_EXT_FROM_R4 deny 10 R5(config-route-map)#match tag 555 R5(config-route-map)#route-map RM_DENY_EXT_FROM_R4 permit 100 R5(config-route-map)#route-map RM_SET_TAG_555 permit 10 R5(config-route-map)#match source-protocol ospf 1 R5(config-route-map)#match route-type external R5(config-route-map)#set tag 555 R5(config-route-map)#router eigrp 100 R5(config-router)#distribute-list route-map RM_DENY_EXT_FROM_R4 in R5(config-router)#router ospf 10 R5(config-router)#redistribute eigrp 100 route-map RM_SET_TAG_555 sub
And that concludes this lesson. Route redistribution is always fun 🙂
You can look at some of my older posts for more ideas about filtering
routes.
Question here.When you mutual redistribute eigrp100 and ospf10 on R4 R5 .There should be route flapping occur,since R4R5 will use the route(10.1.1.0) from R6 with lower AD:110 versus 170 in EIGRP domain.Why your topology is stable?Thats odd.
Hi! Great post ! Could you share with us the configuration please?
R5 chooses R6 to reach R1’s loopback.