07-17-2012 02:38 AM - edited 03-04-2019 04:59 PM
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
!
Solved! Go to Solution.
07-17-2012 04:08 AM
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
07-17-2012 03:01 AM
I haven't fixed it, but I just worked out the route-map is stopping switch B from advertising all routes out inc connected!!!
07-17-2012 03:10 AM
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
07-17-2012 03:28 AM
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
07-17-2012 04:08 AM
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
07-17-2012 05:08 AM
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
07-17-2012 05:25 AM
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?
07-17-2012 05:27 AM
I just put a static more defined route in and it works, but I can't be adding a static for every route!!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide