cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1103
Views
0
Helpful
7
Replies

EIGRP Route-map stopping redistributing

ktwaddell
Level 1
Level 1

Morning All,

I've added a router-map on my back-up L3 3750 (B) switch which has a link to main L3 3750 (A) and a link to wan cloud running EIGRP on both links, I put a route-map (see below) to set the metric on all EIGRP routes, when I shut the main link down on Switch A with the route-map installed on switch B it's putting out the routes from Switch A into the cloud and I can't work out why.

Any help please?

Thanks

Kevin

Switch B

router eigrp 90

distribute-list route-map loopguard out

network 10.202.128.0 0.0.31.255

network 172.16.0.0

offset-list 9 in 4000 Vlan5

!

ip classless

access-list 9 permit any

route-map loopguard permit 10

match source-protocol eigrp 90

set metric 100

set tag 5

!

1 Accepted Solution

Accepted Solutions

Hello Kevin,

Oh, I see. I have tested the route-map in the meanwhile and found out that it is indeed capable of setting the tag even if used in distribute-list. Regarding the changes to the metric, I got very confusing results - the set metric B D L R M seems to have a partial effect but it behaves erratically (the Bandwidth parameter is not properly set nor minimized, the Delay is not properly set nor added to). I do not suppose that the set metric was ever planned to work in distribute-list. If it did, you could easily subvert the whole concept of loop protection in EIGRP, anyway.

So to set the tag - yes, you can use the route-map. In order to increase the metric, you should use the offset-list instead. I must admit I do not understand this comment:

I use the offset command going out, but other switches still had routes  from this switch has a FS with EIGRP and that is what I am truing to  stop.

Can you perhaps upload a picture of your topology also showing a route that you want to increase the metric for, and how you want the routing to behave?

Oh, and an important thing. Do not use the match source-protocol in your route-map. This statement is usable only for external EIGRP networks that have been redistributed into EIGRP earlier. Each redistributed route in EIGRP carries the information about where it was redistributed from, and the match source-protocol command allows you to filter the routes based on their original protocol. However, as internal EIGRP routes do not have this information present, this match command does not match any of them. That is the primary reason why your current distribute-list stopped advertising any routes from your switch.

Best regards,

Peter

View solution in original post

7 Replies 7

ktwaddell
Level 1
Level 1

I haven't fixed it, but I just worked out the route-map is stopping switch B from advertising all routes out inc connected!!!

Hello,

You are talking about redistribution but there is no redistribution configured here at all. The route-map you are referencing is used in distribute-list - a mechanism used to filter any routes already carried in a particular routing protocol.

I do not believe that it is correct or even supported to modify the metric in a route-map used in a distribute-list. This route-map should refer to different match criteria to filter out unwanted networks but it should not modify the attributes of networks that are allowed to be distributed further. In addition, your route-map is not compatible with EIGRP even if it was used in redistribution, anyway: in EIGRP, you cannot configure the resulting metric (a single number), but you need to always configure the EIGRP component metrics (bandwidth, delay, reliability, load, MTU).

I will check if the route-map is capable of modifying some of the advertised route attributes if used in a distribute-list, but until then, I recommend removing the set commands from this route-map.

Best regards,

Peter

Hi Peter

I based the command going from this link

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t8/feature/guide/gteigrpr.html#wp1058210

The switch wouldn't let me use the redistribution command.

You post makes alot of sense and it explains why it stops all traffic and why I cant get it to work

I use the offset command going out, but other switches still had routes from this switch has a FS with EIGRP and that is what I am truing to stop.

Any ideas?

Thanks

Kev

Hello Kevin,

Oh, I see. I have tested the route-map in the meanwhile and found out that it is indeed capable of setting the tag even if used in distribute-list. Regarding the changes to the metric, I got very confusing results - the set metric B D L R M seems to have a partial effect but it behaves erratically (the Bandwidth parameter is not properly set nor minimized, the Delay is not properly set nor added to). I do not suppose that the set metric was ever planned to work in distribute-list. If it did, you could easily subvert the whole concept of loop protection in EIGRP, anyway.

So to set the tag - yes, you can use the route-map. In order to increase the metric, you should use the offset-list instead. I must admit I do not understand this comment:

I use the offset command going out, but other switches still had routes  from this switch has a FS with EIGRP and that is what I am truing to  stop.

Can you perhaps upload a picture of your topology also showing a route that you want to increase the metric for, and how you want the routing to behave?

Oh, and an important thing. Do not use the match source-protocol in your route-map. This statement is usable only for external EIGRP networks that have been redistributed into EIGRP earlier. Each redistributed route in EIGRP carries the information about where it was redistributed from, and the match source-protocol command allows you to filter the routes based on their original protocol. However, as internal EIGRP routes do not have this information present, this match command does not match any of them. That is the primary reason why your current distribute-list stopped advertising any routes from your switch.

Best regards,

Peter

Hi Peter

I did remove the Match Source-protocol and stuck a any any acl and was getting replys like you was.

I have been trying to avoid why I needed to do it this way, has I knew it would get more confusing, the new network on a MPLS type cloud, but its more like a LAN in that spanning-tree can affect the design.

I am trying to get all routes out of switch B so low down the list that they aren't a feasible successor in any of the switches routing tables, so I used an offset list going out into the cloud, but it kept keeping switch B in there.

I am going to try the old weighted static route between switchs A and B and take out of EIGRP and see if that works.

Will let you know

Thanks

Kev

Well that didn't work, since when does a static route come last in the routing order

router eigrp 90

network 10.202.128.0 0.0.31.255

network 172.16.0.0

offset-list 9 in 4000 Vlan5

!

ip classless

ip route 172.16.0.0 255.255.0.0 10.202.138.17

spct-hbroughton-sw2#sh ip route 172.16.191.248

Routing entry for 172.16.190.0/23

  Known via "eigrp 90", distance 170, metric 285856, type external

  Redistributing via eigrp 90

  Last update from 10.202.128.1 on Vlan5, 00:01:10 ago

  Routing Descriptor Blocks:

  * 10.202.128.1, from 10.202.128.1, 00:01:10 ago, via Vlan5

      Route metric is 285856, traffic share count is 1

      Total delay is 1166 microseconds, minimum bandwidth is 10000 Kbit

      Reliability 255/255, minimum MTU 1500 bytes

      Loading 1/255, Hops 1

I am so having a blonde day today, any ideals?

I just put a static more defined route in and it works, but I can't be adding a static for every route!!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card