EIGRP Static Route Redistribution

Unanswered Question
Oct 18th, 2007

Hi, I need some advice on the default behaviour of 'redistribute static'.

Background - we have a fully routed core network with Cat 6500's. Our Exchange network is behind an ISA firewall and is split across two 6500's for resilience. One of the 6500's routes traffic to exchange via ISA with a static route which is redistributed into EIGRP and propagated to the rest of the network i.e:

ip route x.x.252.0 255.255.255.0 x.x.42.10

x.x.42.10 is the IP address of the ISA Firewall.

I need to implement resilient routing for the Exchange network, I've tried adding the static route on the second 6500 and redistributing this but this is causing a routing loop on our other routers that have connections to both of the exchange routers:

6500#sh ip route x.x.252.0

Routing entry for x.x.252.0/24

Known via "eigrp 138", distance 170, metric 3072, type external

Redistributing via eigrp 138, bgp 64750

Advertised by bgp 64750

Last update from x.x.110.3 on Vlan3, 19:43:27 ago

Routing Descriptor Blocks:

* x.x.110.3, from x.x.110.3, 19:43:27 ago, via Vlan3

Route metric is 3072, traffic share count is 1

Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

x.x.1.26, from x.x.1.26, 19:43:27 ago, via Vlan806

Route metric is 3072, traffic share count is 1

Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

x.x.1.9, from x.x.1.9, 19:43:27 ago, via Vlan802

Route metric is 3072, traffic share count is 1

Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

The first route above via Vlan3 is from an old link that we'll be taking out of service shortly and originates from the same 6500 as the second route.

The third route is the one which I think is causing the loop and comes from the second 6500 that I tried to add the static route to.

I don't understand why the third route gives a hop count of 1 when the IP Address for ISA is not active on that router?

I hope this makes sense, if not please ask and I'll try to clarify!

Any tips would be appreciated?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Edison Ortiz Thu, 10/18/2007 - 04:39

> I don't understand why the third route gives a hop count of 1 when the IP Address for ISA is not active on that router?

It's one hop away from the device performing the redistribution, not the destination IP.

robward Thu, 10/18/2007 - 04:42

OK, I'm lost as to why I'm getting a routing loop then. I'd have thought EIGRP would use the correct route?

Edison Ortiz Thu, 10/18/2007 - 04:49

Can you post a traceroute from the routers experiencing the loop ?

If both 6500s are redistributing static, the leaf routers will see two routes and should load-balance between the two 6500s.

Something is missing from your post that is causing the loop. Posting the configs will help.

robward Thu, 10/18/2007 - 05:27

The affected Routers are connected to both of the 6500's on Ten Gigabit links.

The static route is:

ip route x.x.252.0 255.255.255.0 x.x.42.10

I have EIGRP configured with 'redistribute static'.

Traceroutes look like each 6500 is trying to send the packet back to the other but only one of them (the original 6500) is routing for the x.x.42.x network that the ISA Firewall is on:

rb-cs1#traceroute x.x.252.74

Type escape sequence to abort.

Tracing the route to imap.x.x (x.x.252.74)

1 ct-cs1-rb-cs1.x.x (x.x.1.9) 0 msec

mr-cs3-rb-cs1.x.x (x.x.1.26) 0 msec

mr-cs3.x.x (x.x.110.3) 0 msec

2 mr-cs2-ct-cs1.x.x (x.x.1.6) 0 msec * *

3 mr-cs3-mr-cs2.x.x (x.x.1.14) 0 msec * *

4 * * *

5 * * *

6 * * *

7 * * *

8 * * *

9

For info mr-cs3 is the original 6500 that's routing for the x.x.42.x network. Rb-cs1 is the router in 'the middle' and ct-cs1 is the other router that has the static route applied.

I can post configurations if necessary but they are quite big these are heavily populated 6509's!

Edison Ortiz Thu, 10/18/2007 - 12:29

You can cut down the layer2 stuff.

Try this command

show run | be router

and post its output here. I suggest you sanitize it and just leave the last 2 octects on IP addresses.

robward Fri, 10/19/2007 - 00:43

Here's the mr-cs3 configuration:

router eigrp 138

redistribute static

passive-interface Vlan7

passive-interface Vlan254

passive-interface Vlan442

passive-interface Vlan520

passive-interface Vlan521

passive-interface Vlan522

network x.x.0.0

distribute-list 15 out Vlan3

no auto-summary

no eigrp log-neighbor-changes

!

ip classless

ip route x.x.42.112 255.255.255.240 x.x.42.98

ip route x.x.42.128 255.255.255.240 x.x.42.98

ip route x.x.42.144 255.255.255.240 x.x.42.98

ip route x.x.252.0 255.255.255.0 x.x.42.10

ip route x.x.253.0 255.255.255.0 x.x.42.10

ip route x.x.247.128 255.255.255.128 x.x.247.2

ip flow-export destination x.x.119.223 9996

no ip http server

ip pim rp-address x.x.27.1 override

!

logging x.x.100.139

logging x.x.110.210

access-list 15 permit x.x.0.0 0.0.255.255

access-list 15 permit x.x.247.0 0.0.0.255

access-list 15 deny any

access-list 30 permit x.x.99.186

access-list 30 permit x.x.8.17

access-list 30 permit x.x.5.210

access-list 30 permit x.x.5.194

access-list 30 permit x.x.5.178

access-list 30 permit x.x.31.0 0.0.0.255

access-list 30 permit x.x.100.0 0.0.0.255

access-list 30 permit x.x.102.0 0.0.1.255

access-list 30 permit x.x.110.0 0.0.0.255

access-list 30 permit x.x.134.0 0.0.0.255

access-list 30 permit x.x.241.0 0.0.0.255

access-list 30 permit x.x.253.0 0.0.0.255

access-list 30 deny any

access-list 40 permit x.x.100.45

access-list 40 permit x.x.102.151

access-list 40 permit x.x.100.139

access-list 40 permit x.x.5.210

access-list 40 permit x.x.5.194

access-list 40 permit x.x.5.178

access-list 40 permit x.x.31.153

access-list 40 permit x.x.31.154

access-list 40 permit x.x.31.150

access-list 40 permit x.x.31.151

access-list 40 permit x.x.110.0 0.0.0.255

access-list 40 deny any

access-list 100 permit ip x.x.64.0 0.0.0.255 x.x.0.0 0.0.255.255

access-list 100 permit icmp x.x.64.0 0.0.0.255 x.x.0.0 0.0.255.255

access-list 102 permit ip x.x.138.0 0.0.0.255 host x.x.137.20

access-list 102 permit ip x.x.213.0 0.0.0.255 host x.x.137.20

access-list 102 permit ip x.x.137.0 0.0.0.255 host x.x.137.20

access-list 102 permit tcp any host x.x.137.20 eq domain

access-list 102 permit tcp any host x.x.137.20 eq www

access-list 102 deny ip any host x.x.137.20

access-list 102 permit ip x.x.138.0 0.0.0.255 host x.x.137.14

access-list 102 permit ip x.x.213.0 0.0.0.255 host x.x.137.14

access-list 102 permit ip x.x.137.0 0.0.0.255 host x.x.137.14

access-list 102 permit tcp any host x.x.137.14 eq 443

access-list 102 permit tcp any host x.x.137.14 eq www

access-list 102 deny ip any host x.x.137.14

access-list 102 permit ip any x.x.215.0 0.0.0.255

access-list 102 permit ip any x.x.216.0 0.0.0.255

access-list 102 permit ip any x.x.213.0 0.0.0.255

access-list 102 permit ip any x.x.137.0 0.0.0.255

access-list 130 deny tcp any any eq 135

access-list 130 deny udp any any eq 135

access-list 130 permit ip any any

access-list 1020 deny FFFFFFFF 640

access-list 1020 permit FFFFFFFF

!

snmp-server engineID local 000000090200000021000000

snmp-server community snmaccess RO 40

snmp-server ifindex persist

snmp-server packetsize 8192

snmp-server enable traps chassis

snmp-server enable traps module

snmp-server enable traps envmon fan shutdown supply temperature status

snmp-server host x.x.31.150 swread chassis module envmon

!

radius-server source-ports 1645-1646

control-plane

!

!

!

dial-peer cor custom

!

!

!

!

line con 0

exec-timeout 20 0

password 7 1104181D1E

login authentication CON

line vty 0 4

access-class 30 in

exec-timeout 20 0

password 7 082C4D5600

login authentication VTY

line vty 5 15

access-class 30 in

exec-timeout 20 0

password 7 082C4D5600

login authentication VTY!

ntp clock-period 17179986

ntp update-calendar

ntp server x.x.31.3

ntp server x.x.31.2

no cns aaa enable

end

robward Fri, 10/19/2007 - 00:52

Here's the ct-cs1 configuration - the static route has been removed for now:

router eigrp 138

redistribute static

network x.x.0.0

no auto-summary

!

ip classless

!

no ip http server

!

logging x.x.100.139

logging x.x.110.210

access-list 15 permit x.x.0.0 0.0.255.255

access-list 15 permit x.x.93.0 0.0.0.255

access-list 15 permit x.x.245.0 0.0.0.255

access-list 15 permit x.x.246.0 0.0.0.255

access-list 15 permit x.x.247.0 0.0.0.255

access-list 15 permit x.x.0.0 0.0.63.255

access-list 15 permit x.x.247.128 0.0.0.127

access-list 15 deny any

access-list 30 permit x.x.99.186

access-list 30 permit x.x.8.17

access-list 30 permit x.x.5.210

access-list 30 permit x.x.5.194

access-list 30 permit x.x.5.178

access-list 30 permit x.x.31.0 0.0.0.255

access-list 30 permit x.x.100.0 0.0.0.255

access-list 30 permit x.x.102.0 0.0.1.255

access-list 30 permit x.x.110.0 0.0.0.255

access-list 30 permit x.x.134.0 0.0.0.255

access-list 30 permit x.x.241.0 0.0.0.255

access-list 30 permit x.x.253.0 0.0.0.255

access-list 30 deny any

access-list 40 permit x.x.100.45

access-list 40 permit x.x.102.151

access-list 40 permit x.x.100.139

access-list 40 permit x.x.5.210

access-list 40 permit x.x.5.194

access-list 40 permit x.x.5.178

access-list 40 permit x.x.31.153

access-list 40 permit x.x.31.154

access-list 40 permit x.x.31.150

access-list 40 permit x.x.31.151

access-list 40 permit x.x.110.0 0.0.0.255

access-list 40 deny any

access-list 100 permit ip x.x.64.0 0.0.0.255 x.x.0.0 0.0.255.255

access-list 100 permit icmp x.x.64.0 0.0.0.255 x.x.0.0 0.0.255.255

access-list 101 permit ip x.x.0.0 0.0.255.255 x.x.5.224 0.0.0.15

access-list 101 permit icmp x.x.0.0 0.0.255.255 x.x.5.224 0.0.0.15

access-list 130 deny tcp any any eq 135

access-list 130 deny udp any any eq 135

access-list 130 permit ip any any

!

snmp-server community snmaccess RO 40

snmp-server ifindex persist

snmp-server packetsize 8192

snmp-server enable traps chassis

snmp-server enable traps module

snmp-server enable traps envmon fan shutdown supply temperature status

snmp-server host x.x.31.150 swread

!

radius-server source-ports 1645-1646

!

control-plane

!

!

!

dial-peer cor custom

!

!

!

line con 0

exec-timeout 20 0

password 7 04560A1E06

login authentication CON

line vty 0 3

access-class 30 in

exec-timeout 20 0

password 7 09414F1110

login authentication VTY

transport input telnet

line vty 4

access-class 30 in

exec-timeout 20 0

password 7 09414F1110

login authentication VTY

line vty 5 15

access-class 30 in

exec-timeout 20 0

password 7 09414F1110

login authentication VTY

!

ntp clock-period 17179879

ntp update-calendar

ntp server x.x.31.3

ntp server x.x.31.2

no cns aaa enable

end

Kevin Dorrell Thu, 10/18/2007 - 04:58

What does your BGP 64750 do? Do you have any other BGP ASs in your topology, and do they have redistribution with EIGRP? Just a thought - the BGP might be part of the equation.

Kevin Dorrell

Luxembourg

robward Thu, 10/18/2007 - 05:06

The affected Routers are connected to both of the 6500's on Ten Gigabit links.

The static route is:

ip route x.x.252.0 255.255.255.0 x.x.42.10

I have EIGRP configured with 'redistribute static'.

Traceroutes look like each 6500 is trying to send the packet back to the other but only one of them (the original 6500) is routing for the x.x.42.x network that the ISA Firewall is on:

rb-cs1#traceroute x.x.252.74

Type escape sequence to abort.

Tracing the route to imap.x.x (x.x.252.74)

1 ct-cs1-rb-cs1.x.x (x.x.1.9) 0 msec

mr-cs3-rb-cs1.x.x (x.x.1.26) 0 msec

mr-cs3.x.x (x.x.110.3) 0 msec

2 mr-cs2-ct-cs1.x.x (x.x.1.6) 0 msec * *

3 mr-cs3-mr-cs2.x.x (x.x.1.14) 0 msec * *

4 * * *

5 * * *

6 * * *

7 * * *

8 * * *

9

For info mr-cs3 is the original 6500 that's routing for the x.x.42.x network. Rb-cs1 is the router in 'the middle' and ct-cs1 is the other router that has the static route applied.

I can post configurations if necessary but they are quite big these are heavily populated 6509's!

WRT BGP - this advertises our address range to our ISP. We receive only a default route from them via BGP. There are no other BGP Peerings but this one.

sundar.palaniappan Thu, 10/18/2007 - 12:53

Can you clarify a couple of things.

Does mr-cs3 has this static route 'ip route x.x.252.0 255.255.255.0 x.x.42.10' in it's config?

If it does then can you get to the x.x.252.0 network from mr-cs3?

robward Fri, 10/19/2007 - 00:42

Thanks for this gents!

Yes mr-cs3 does have the static route in its configuration but I've currently removed it from ct-cs1. Things work at the moment, the problem is when I add the static route to ct-cs1 and it's redistributed via EIGRP.

robward Tue, 10/23/2007 - 07:25

Bump, still stuck on this guys anyone got any ideas?

Kevin Dorrell Tue, 10/23/2007 - 07:46

You are adding a ip route x.x.252.0 255.255.255.0 x.x.42.10 on ct-cs1. You say that "the IP address of the ISA is not active on that router". Are you sure of that? It may not have a complete path to the ISA, but does it think is has a route?

Go to ct-cs1 and do show ip route x.x.42.10. What do you have? If it thunks it has a route, then it will redistribute, regardless of real reachability.

Kevin Dorrell

Luxembourg

robward Wed, 10/24/2007 - 01:35

ct-cs1new#sh ip route x.x.42.10

Routing entry for x.x.42.0/27

Known via "eigrp 138", distance 90, metric 3328, type internal

Redistributing via eigrp 138

Last update from x.x.1.6 on Vlan801, 5d19h ago

Routing Descriptor Blocks:

* x.x.1.10, from x.x.1.10, 5d19h ago, via Vlan802

Route metric is 3328, traffic share count is 1

Total delay is 30 microseconds, minimum bandwidth is 1000000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 2

x.x.1.6, from x.x.1.6, 5d19h ago, via Vlan801

Route metric is 3328, traffic share count is 1

Total delay is 30 microseconds, minimum bandwidth is 1000000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 2

mr-cs3 is currently routing for the x.x.42.0/27 subnet and ISA (x.x.42.10) is active on mr-cs3 at present so ct-cs1 can see two routes through the network to ISA which is what I'd expect to see.

However when I add the static route:

ip route x.x.252.0 255.255.255.0 x.x.42.10

to ct-cs1 this is when the problem occurs, even though mr-cs3 is routing for the x.x.42.0/27 subnet.

Kevin Dorrell Wed, 10/24/2007 - 03:55

I think there is already something wrong with the route from ct-cs1 to the subnet x.x.42.0/27 and onwards to the ISA. It's just you don't know about it because nobody is actually using ct-cs1 to get to the ISA. They wouldn't use the metric 3328+ route through ct-cs1new when they could quite happily use the metric 3072 routes through the other two.

But that all changes when ct-cs1 gets a static route and starts redistributing it through EIGRP 138. Now the access routers see three equally attractive routes, and distribute the load accordingly.

In theory, any packet that arrives at ct-cs1 from your access layer should be sent to mr-cs3. But in the sh ip route x.x.42.10, it shows that ct-cs1 has two routes: a correct one to mr-cs3 and an incorrect one to mr-cs2.

So, what happens to a packet that gets sent to mr-cs2? Well, under the old conditions, mr-cs2 had only one route to x.x.42.10, and that led ultimately to mr-cs3. But with ct-cs1 in place, does mt-cs2 always lead back to mr-cs3 probably not.

You probably know the "feasible successor" rule in EIGRP. It is designed to prevent loops. It says that the neighbor is a feasible successor if its AD is less than my current metric. One question that is often asked is "what happens if it is equal?" "What happens if my meighbor is the same distance from the destination as I am? Is he a feasible successor? The answer is no, he isn't. And it seems to me that we have a very similar situation here: three routers that have the same metric to the destination (because all three are redistributing a static), but only one of which has a real route to the destination.

OK, so what is the solution? I think that either you will have to make sure that ct-cs1 and mr-cs2 always route their ISA traffic directly to mr-cs3, and never to each other, or even indirectly via another router that has multiple routes .... or, more elegantly, reduce the re-distribution metric on the one that has the real route to the ISA, namely mr-cs3.

The problem is that by having an indirect route to x.x.252.0/24, and redistibuting it with the same metric as the router that has the real route, you are telling the rest of the network that all three routers can handle the traffic equally well. Which they cannot.

Kevin Dorrell

Luxembourg

robward Wed, 10/24/2007 - 04:41

Hi Kevin, that makes sense although ct-cs1 is not directly connected to mr-cs3. The two possible routes are via mr-cs2 and rb-cs1.

The show ip route command without the network address only appears to have one entry in the routing table.

So from what you've said you think I should add a higher AD i.e. 201 to the static route on ct-cs1?

Thanks for your help by the way!

Kevin Dorrell Wed, 10/24/2007 - 04:56

I would not do it that way. The AD is only a local concept within the router, and would not affect the decisions made by the other routers.

In you routers, you are redistributing static routes into EIGRP. Each of these routes will have a seed metric. What I am surprised at is that I don't see this default-metric in the router eigrp 138 section. The documentation says that redistributed "connected" routes get a metric of 0, but it is not clear if that applies to statics.

I would try something like default-metric 1000 25 255 1 1500 in the eigrp sections of both ct-cs1 and mr-cs2. That should put them at a significant disadvantage compared to the routes from mr-cs3.

http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cr/hirp_r/rte_eih.htm#wp999030

BTW, in you original posting, you said "I don't understand why the third route gives a hop count of 1 when the IP Address for ISA is not active on that router?" It is because it doesn't know whether the static route is activ, direct, or indirect. That is the hop count to the redistribution point.

Kevin Dorrell

Luxembourg

robward Wed, 10/24/2007 - 05:20

Thanks Kevin, I'll give that some thought as I'll have to assess the impact on the other networks that we'll be routing on ct-cs1.

I've done something similar with AD with backup static routes for our BGP peering by adding a default static route with an AD of 201 and redistributing this with EIGRP.

Under normal operation when our BGP peering with our ISP is in operation the BGP route with an AD of 200 is redistributed by EIGRP. If the BGP peering dissapears then the static route gets redistributed by EIGRP. This seems to work nicely.

Kevin Dorrell Wed, 10/24/2007 - 05:28

If you don't wany to touch the other redistributions, you can set the sed metric for this one only by setting a route-map:

ip access-list standard IVS

 permit x.x.254.0 0.0.0.255

route-map permit static->eigrp 10

 match ip address IVS

 set metric 1000 25 255 1 1500

route-map permit static->eigrp 20

! lets the rest of the routes through without modification of the metric

router eigrp 138

 redistribute static route-map static->eigrp

Kevin Dorrell

Luxembourg

robward Wed, 10/24/2007 - 05:32

Yes, that's the one!

Thanks I'll let you know how it goes, here's your points!

Actions

This Discussion