EIGRP Redistributed Routes

[network_dude]

Hey Everyone,

I'm having a bit of a routing issue...

I have two sites connected via a point to point T1; I'm running EIGRP between the routers in the same antonymous system. I am also redistributing static routes between the two sites.

The problem I'm seeing is the redistributed routes externally learned via EIGRP are taking precedence over the local static routes...

Example:

D EX 172.1.0.0/16 via 10.128.1.1

S 172.0.0.0/8 via 10.10.1.1

I'm if on the local router with the 172.0.0.0/8 static route and try to trace to 172.1.2.0 I'm sent to 10.128.1.1.

I would think that a local static route would take precedence over the learned route, but this is not happening. This is causing some routing issues in production.

Does anyone know if there is a way to resolve this issue?

Thanks in advance,

Scott

[Richard Burts]

Scott

The question of local static route vs redistributed EIGRP route involves administrative distance and it comes into play when you have the same prefix learned from two different sources. But that is not what you have. 172.0.0.0/8 is a very different prefix from 172.1.0.0/16. And in IOS (as in most of networking) routing is done based on longest prefix. The longest prefix is the best fit and is the route used to make the forwarding decision.

Without knowing a bit more about the topology of your network it is hard to tell you how to fix your issue. But the issue is quite clear - you are learning a more specific redistributed route and not using the local static route. If you are trying to get to 172.1.2.0 and if 172.1.0.0/16 is reachable from the other router why would you not want to go through the other router? Or are you waying that the 172.1.0.0/16 is actually not a correct route? If you can clarify that we may be able to help you resolve this.

HTH

Rick

[network_dude]

Hey Rick,

Thanks for the quick response...

This is for our disaster recovery site, so we need the traffic to go out a specific way. The routes I'm getting via EIGRP are sending the traffic back to our main campus; instead off going through our MPLS link we have on site at Disaster Recovery. This is the reason we need our local static routes to take precedence.

We cannot turn off route redistribution on our main campus because there are other remote sites where the routes are valid and working properly.

If you need more info, please let me know.

Thanks again,

Scott

[Richard Burts]

Scott

I am not sure that I have enough information to really give you a good answer. But based on what you are saying here I wonder if configuring a distribute list on your router to suppress the 172.1.0.0/16 would be a solution.

HTH

Rick

[amit-singh]

Rick,

As we dont have the enough information this. Can we try changing the static route to 172.1.0.0/16 on the local router. This should set the prefix length as same and now only the AD will be the consideration.What would you suggest ?

HTH,

-amit singh

[Richard Burts]

Amit

Without more information it is difficult to know whether one alternative is better than the other. Certainly configuring a 172.1.0.0/16 static route would correct the immediate issue. I wonder why the original static was a /8? And I wonder if we start creating /16 statics how many we will need to create? And without more information about their environment and what their requirements really are we will not be able to identify the optimum solution.

HTH

Rick

[amit-singh]

Rick, Agreed to your point:

Scott :Please give us the whole topology diagram and more information about your environment. Once we have an idea about the your network and your requirement, we will be at a point to suggest a solution on this.

-amit singh

[Richard Burts]

Amit

I have thought about this some more and have identified part of what I was thinking but did not verbalize when I suggested the distribute list as a solution in his situation.

Scott is testing in a disaster recovery situation. The 172.1.0.0/16 is advertised from the live production network. He is testing with 172.0.0.0/8 to test situations in which the live production network is no longer available. Using the distribute list to filter the advertisement of 172.1.0.0/16 is a better representation of the failure scenario then is configuring a local static for 172.1.0.0/16.

HTH

Rick