04-23-2016 04:49 AM - edited 03-08-2019 05:28 AM
I am trying to change the static routes below to internal but they still show up as external on the routers that receive these routes. What else do I need to do?
Thanks,
Diego
!
router eigrp 100
redistribute static route-map EIGRP-STATIC-OUT
network 10.10.3.0 0.0.0.255
no auto-summary
eigrp stub connected static
!
ip route 192.168.1.0 255.255.255.0 10.10.3.254
ip route 192.168.2.0 255.255.255.0 10.10.3.254
!
ip prefix-list EIGRP-STATIC-OUT seq 10 permit 192.168.1.0/24
ip prefix-list EIGRP-STATIC-OUT seq 20 permit 192.168.2.0/24
!
!
route-map EIGRP-STATIC-OUT permit 10
match ip address prefix-list EIGRP-STATIC-OUT
set metric-type internal
!
Solved! Go to Solution.
04-23-2016 10:35 AM
Not sure if you can change EIGRP metric type with route-map. See table-2 in this link:
http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/49111-route-map-bestp.html
HTH
04-23-2016 10:35 AM
Not sure if you can change EIGRP metric type with route-map. See table-2 in this link:
http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/49111-route-map-bestp.html
HTH
04-24-2016 01:42 PM
That is a very useful link, thank you very much. But it seems like the set metric-type command is not very useful for most routing protocols.
I don't have to use a route-map, I just thought that was the easiest way. Are there other options?
Thanks,
Diego
04-25-2016 05:54 AM
The reason eigrp does this is to prevent routing loops so by changing this you need to be careful not to introduce more issues to the network that could cause serious problems, eigrp uses router ids to prevent loops between internal/external
Did you try change the distance under the protocol for those routes
router eigrp 100
distance 90 192.168.1.0 0.0.0.255
distance 90 192.168.2.0 0.0.0.255
04-25-2016 06:09 AM
Hello Mark,
Interesting that you mention the distance command. The reason that I find myself trying to change the route type to internal is that I need to use the techniques mentioned in this article http://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/13673-14.html but found that none of the techniques work if the route type is external.
So its a kind of catch-22 type of thing. It seems like there are basically no options that allow me to modify external type routes in EIGRP??
Rgds,
Diego
04-25-2016 06:43 AM
I have read that before its an issue and I do believe its to do with preventing loops I haven't labbed this but I would have thought you could still force it somehow even if it wasn't best practice but I do see where Cisco are coming from not allowing it to an extent, potentially it could cause more problems than fixes in certain cases
EIGRP is very flexible within its own AS but I have found the same thing with external routes , I just read as well on another link the distance syntax I gave you will not work on ext routes either unfortunately
Out of curiosity why is there a requirement to modify these routesis it causing an issue there may be another fix for the problem
04-25-2016 11:15 AM
So let's say you have two or more routers that are neighbors on a LAN but that each is connected to different and separate WANs. You need each router to listen on the LAN and advertise to its WAN but don't want to advertise any other router's WAN subnets to your WAN.
It would be great to just use "distance 255 1.1.1.1 0.0.0.0" to block out advertisements from the guy you don't want but if some of his WAN subnets are external then you are out of luck.
So do we setup and maintain subnet lists to use in distribute-lists commands?
Or do we turn off multicast and hard-code neighbors? (is this even possible?)
Neither of these options seem elegant nor simple nor fool proof and just a pain in the neck.
All this because Cisco is being Big Brother like trying to keep us out of trouble? Unless you are running IS-IS that is. Weird.
Rgds,
Diego
04-26-2016 04:59 AM
Hello
Are you trying to not to receive external routes between eigrp peers?
- If so the easiest way would to give each peer the same RID as this would negate any external routes tagged with the same RID value from entering.
- if you wish for you statics to be seen as internal simply apply the network command to the eigrp process for those statics
res
Paul
04-26-2016 05:23 AM
we have setups like that remotely where we would have 2 providers 2 routers that would be lan neighbours through eigrp we then redistribute into BGP and use route maps with matched access-lists and block local routes that originate on each router from being re-advertised back into each other to prevent loops if I get you right on that last post
Pauls option maybe a lot easier though its not something I have tried before
04-26-2016 04:17 PM
Guys I really appreciate the input, it is very helpful. However, we are missing the point here. I know there are various was of achieving what I am looking for but I was hoping to do it in a simple and concise way. The "distance 255 1.1.1.1 0.0.0.0" command would have been excellent. I thought maybe that I wasn't using the command correctly or that maybe I needed one or two extra config steps.
I really don't want to start maintaining lists and static routes and messing with RIDs and so on. I am disappointed that Cisco seems to give us very little options in dealing with external routes but if that is the only way then I will have to deal with it.
Thank you very much.
Diego
07-09-2019 03:36 PM
Hi tato,
I know this is an old thread, but I was looking for the same information as you. As yourself, I couldn't find a way to change the metric-type of EIGRP routes using route-maps. In my desperation, I found a good solution for my use case. Maybe it can be useful for you too.
What I did, is using summary-addresses. Summary-addresses are redistributed as EIGRP internal routes.
My use case is that I needed to avoid some asymmetric traffic in a network. I have 2 Data Centers, and each one has it's own WAN exit. EIGRP is injecting a default route only (0/0) to the DCs. So, each DC chooses it's local WAN exit due to the administrative distances of the routes. My customer wanted to use just the WAN exit in the main Data Center. The issue is that the routes are redistributed like this:
IP_Cloud1 --> 0/0 --> WAN1 <--> EIGRP <--> DC1 <--> MP-BGP <--> DC2 <--> WAN2 <-- 0/0 IP_Cloud2
When WAN1 inserts the 0/0 route to EIGRP in DC1, it's already an external route. Same with DC2 and WAN2. It has an AD of 170.
When DC1 and DC2 share the default routes they are receiving from EIGRP, it's done using MP-BGP (this is an ACI pod). MP-BGP has an AD of 200; so that's why always the EIGRP local route is inserted in the routing table of the DC switches.
What I did is: in the WAN router interface that is attached directly to to my DC switches, I added a summary-address with an AD of 254 (if it's 255, it won't be advertised). This will create an entry in the WAN router, but since the AD of 254 is still worse than the AD of the route that this router is receiving from a different layer (which is 170 because it's being also learnt from EIGRP from a different device), the WAN router is still installing the route that it's receiving from EIGRP locally, but now, the route that it announces into my DC switches, is an internal route.
show ip route on DC switches, before ip summary address configuration:
0.0.0.0/0, ubest/mbest: 1/0
*via 10.2.1.2, vlan224, [170/51712], 00:00:17, eigrp-default, external
show ip route on DC switches, after ip summary address configuration:
0.0.0.0/0, ubest/mbest: 1/0
*via 10.2.1.2, vlan224, [90/768], 00:00:27, eigrp-default, internal
Now I just need to make some modifications in the ACI fabric to change the AD for EIGRP internal routes, and I will have solved the problem. Anyway, just wanted to give this information for whoever needs it.
PD: I know it's not an elegant solution, and it will not scale very well because it would be a pain to add hundreds or thousands of subnets in the interface configuration, but it works for me since I only need to advertise a default route.
Best,
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