I have a site running EIGRP that has two possible gateways. Currently, one of the gateways is a 10MB PTP that I want to use as the primary.
I have a 1.5 MB PTP that I would like to use as a backup (only if the 10mb fails).
Here is my question - I put in a static route for the 10 MB PTP and a static route for the 1.5 MB PTP with a cost of 2.
ip route 0.0.0.0 0.0.0.0 18.104.22.168 (10 MB)
ip route 0.0.0.0 0.0.0.0 192.168.27.8 2 (1.5 MB)
If my primary static route fails - will the secondary route propogate into the routing table or will this have to be manually done?
I would like it to automatically propogate. All other entries in the routing table are propogated by EIGRP.
Thanks in advance for any responses.
The secondary static route will be redistributed automatically into EIGRP, as soon as the primary static route becomes unavailable.
The secondary route will be added to the routing table if the primary route is no longer reachable. And if the primary route comes back up then the secondary route will be replaced in the routing table by the primary route.
When you say "propogate" i'm assuming that you mean entered into the local routers routing table ?
By the way usually a floating static is given an AD around the 250 mark rather than 2. Up to you though.
yes. it will automatically propagate to the back up. EIGRP uses RTP and DUAL to do its computations and allows for four back-up F.S by default and can take max of six.
all the best
Since you are talking about configuring 2 local static routes the discussion about what EIGRP does is interesting but does not affect your situation. These are local routes and not EIGRP routes - at least as far as the local router is concerned. Your post is not clear whether the static routes are redistributed into EIGRP or not.
There have been several responses that say yes the second static route with AD of 2 will be put into the routing table. I think we need to clarify this a bit. Jon says it will happen if the first route next hop (22.214.171.124) becomes unreachable. That is not entirely right. It depends on what kind of interface it is and whether the router THINKS the next hop is reachable (not necessarily whether it is really reachable). This is an issue when the outbound interface is Ethernet. There are many circumstances where a static route points to a next hop out an Ethernet interface, where the next hop is really not reachable but the Ethernet interface stays up and the old static route remains in the table. There is an alternative to configure Object Tracking in conjunction with static routes to address this potential issue.
"It depends on what kind of interface it is and whether the router THINKS the next hop is reachable (not necessarily whether it is really reachable)."
Agreed and i actually had a post on this a while back that i had to lab up for this very reason. However JP did say they were PTP links and that is why i felt it was okay to say the route would be removed.
I assume both of these links are on the same router. I think it is important that you take into consideration what will cause the first static route to be removed from the routing table.
The first route will only be removed if the interface used in the FIB is removed as an eligible interface for forwarding, meaning the interface will have to go down or is unavailable. It is a common misconception that if the next-hop IP address is unreachable, the static route will be removed from he routing table. If the far end interface is down or unreachable, but the near end interfaces is UP/UP, the first static route will stay in the routing table and the router will blackhole traffic.
Ideally, I would avoid the static route on the primary link if possible and use a routing protocol on your primary link to pass a default route which would resolve most blackhole scenarios. If this is an internet connection most service providers will pass you a default route via BGP or RIP to avoid these scenerios. Then, I would use a floating static for your secondary link.
Other possibilities would be to use "keep alives" on the primary link to make certain that the near end interface fails if the far end fails. This scenario is especially problematic with frame-relay.
Lastly, EIGRP only redistributes the route that is actually in the routing table.
Thanks to everyone for replying so quickly. I should mention that I am running EIGRP on a multi-layer switch. Niether link is directly connected to the switch.
Reading through the posts it looks like I am not utilizing EIGRP. I should allow for EIGRP to complete the routing table and have my core switch redistribute static routes.
If I understand EIGRP correcty, EIGRP should recongnize the two links and use the 10MB link due to metric and put the 1.5MB link in the topology table. I just want to make sure they are NOT load balancing . . . I only want to use the 10 mb link until disaster strikes and I have to use the 1.5 mb link.
If neither link is directly connected to the switch then my comments about possibly needing to use Object Tracking are even more important.
We do not have enough detail about your environment to be sure how (or whether) you are utilizing EIGRP. But even if you are using EIGRP for routing many routes in the network, when you start talking about configuring local static routes, then considerations of how EIGRP does things no longer control the behavior.
If EIGRP is running over both the 10Mb and the 1.5Mb links then it will certainly recognize the differences and prefer the 10Mb. It is not clear from what you have posted so far whether EIGRP is running over those links.
You and I have similar perspective about the implications of how to use static routes. You are willing to make an assumption about the PTP links while I thought that lacking information about them should take a more cautious approach and qualify the actions. I believe that we are saying similar things from slightly different perspectives.
I will highly suggest the use of object-tracking (i.e. icmp, http or dns).
Jon also has a good point regarding the use of 250 rather than 2 while using floating static routes.