Help in static and dynamic metric problem

[maokhoeun]

Please help to explai me

My diagram in attached file

[lgijssel]

Looks like you could try to use floating static routes for this case.

Floating static routes have a slightly larger administrative distance than the dynamic route so they will take over when the dynamic route fails and become the secondary path when the primary route comes back in.

configure your statics with a distance that is larger than eigrp

ip route xxxx mask gw 200 < 200 is your administrative distance. I would try this value first. You should not run eigrp over the secondary path for this to work. The following link provides some more info on eigrp:

http://www.cisco.com/en/US/tech/tk365/tk207/tsd_technology_support_sub-protocol_home.html

Regards,

Leo

[maokhoeun]

Dear lgijssel

if i use administrative 200 for static route like this, it can make my connection slower than we use default administrative distance(1) or not? i want to know the affect when we use the high administrative distance like this?

[lgijssel · Accepted solution]

No, it will not make your connection slower. The distance is used to pick the best route. By specifying a relatively high distance, you ensure that the route is only used as a last resort.

Regards,

Leo

[maokhoeun]

Ok thank Lgijssel

I will try to use like u said

[Georg Pauwen]

Hello,

in addition to what Leo said, you could also try and adjust the EIGRP hello and hold timers. Possibly the problem you are facing is just the, generally slow, failover process of EIGRP.

Try and configure the following on all your interfaces participating in EIGRP:

ip hello-interval eigrp 50 1

ip hold-time eigrp 50 3

These are the lowest possible values. As with regard to your question, yes, the routers exchange routing information with each other. The fact that the route over ISP 1 is preferred has to do with the fact that this link probably has a better metric...

HTH,

GP

[maokhoeun]

re: gpauwen

i see if u use (ip hello-interval eigrp 50 1 ,,

ip hold-time eigrp 50 3 ) like this, it will be used a lot of bandwidth of connection, so i can make slow our network, right?

[Georg Pauwen]

Hello,

with your topology, the database is very small, so changing the intervals should not be a problem.

Also, since EIGRP uses partial and incremental updates, routing information gets sent only when a topology change occurs...

Regards,

GP

[ruwhite]

EIGRP hellos are very small, so decreasing the EIGRP hello and hold times shouldn't be a big deal--although you can't go below 1 and 3. I normally recommand 3 second hello timers and 9 second hold timers, as a start.

Second, you should _always_ try and get layer 2 to tell you a link is down as fast as possible, rather than relying on the routing protocol to discover down neighbors. For instance, on frame relay, investigate asynchronous LMI and A bit signalling. On SONET, look at the various triggers and alarms available. For Ethernet and other mediums, you might look at BFD, for now:

http://www.cisco.com/en/US/partner/tech/tk365/technologies_white_paper0900aecd80243fe7.shtml

I saw a comment on this thread about EIGRP's "slow failover" time--in fact, EIGRP normally uses 5 second hellos and 15 second dead times, while OSPF normally uses 10 second hellos, and 40 second dead intervals, and IS-IS uses 10 second hellos with 40 second dead intervals, and BGP uses a 60 second keepalive timer. These timers aren't "slow," they are a balance between processing power and convergence times. Hello and hold intervals are configurable to adjust that balance in your network.

HTH.

:-)

Russ.W

[Georg Pauwen]

Hello Russ,

I wonder if I can ask you a question about this: for EIGRP, 5 and 15 for hello and holddown are the defaults for broadcast media, for slow WAN links, the defaults are 60 and 180 respectively, right ? I did some testing, and on an Ethernet-to-Ethernet link, with the values set to 60 and 180, it would take about exactly 60 seconds for the adjacency to be formed after a link down/up. With the values set to 1 and 3, respectively, they adjacency was almost immediate. Does that mean that in any case, the 'failover', or detection of a link problem, takes always at least as long as the value of the hello timer ?

Thanks for your valuable help in advance.

Regards,

GP

[ruwhite]

Sorry for taking a bit to answer--I don't always watch the forums, just occassionaly... :-)

Anyway, you are correct that the hello and hold timers impact the amount of time it takes us to discover neighbors, as well as to discover a lost neighbor. There's no real "magic" here, we don't wait dead interval before forming an adjacency on a broadcast link (like OSPF or IS-IS, for instance, which have their own reasons to do this), but it's just a matter of statistics. If your neighbor is only sending a hello every 60 seconds, then, statistically, you're not going to get a hello for at least 30 seconds after you connect to a link.

So, the total time down is generally going to be:

-- hold/2 to find link down

-- hello/2 to find link up

So, hello interval is just about always going to be your total down time. Pathological cases could be 2x hello interval. Best case, with layer 2 giving EIGRP the down notification will generally be about the hello interval, or less, depending on various factors.

I won't say that faster hello intervals won't impact overall down time, no matter what down detection you're using, but most people want failover to an alternate route, not fast bringup time, so that's what we've always concentrated on....

:-)

Russ.W

[maokhoeun]

ok! but for the large scale of network, u can not use this hello and hold down timer so small like this.

[ruwhite]

We've had no problems down to 1 and 3 seconds--we run into scaling problems elsewhere (and we're working on those as I'm typing this! :-) ) long before we hit any issues with hello timers, based on the lab tests and large EIGRP edployments I've seen.

:-)

Russ.W