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.

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.

If we look at R4 we should have two external routes with AD 170 going towards
the OSPF domain.

If we traceroute this traffic will go straight to R2.

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.

So what we just did is filter all external routes coming in on Fa0/0.
Did we achieve the wanted result?

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.

From R4 we now look at how it reaches 10.10.1.0/24.

Why does it have two entries for 10.10.1.0/24? Take a look in the
EIGRP topology table.

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.

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.

Then we change the metric on R5.

We can see that the metric change but at least we have no flapping.

Do we still have reachability?

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.

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.

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.

It is still there. Time for some route-maps.

First we will confirm on R5 that we now see a tag.

We now see the tag. There should be no tag on EIGRP internal routes.
We can confirm this on R6.

There should be no loop on R4 now. We will test with a traceroute.

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.

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.

Route redistribution – Route-maps and tagging
Tagged on:                     

2 thoughts on “Route redistribution – Route-maps and tagging

  • September 5, 2012 at 5:25 am
    Permalink

    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.

    Reply
  • December 12, 2012 at 2:02 pm
    Permalink

    Hi! Great post ! Could you share with us the configuration please?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: