06-11-2008 06:59 AM - edited 03-03-2019 10:19 PM
I have a WAN link with high latency, usually around 950ms on my 'ping' replies. I'm using EIGRP but my neighbor adjacency drops of occasionally. Would using static routes solve this problem? My only concern is that I have two links connecting to the site, without a dynamic route will I be able to keep redundancy?
06-11-2008 07:24 AM
Jonathan
Rather than revert to static routes you may want to consider increasing the hello times on the routers for EIGRP.
You could use static routes if you wanted to. Are both links being used all the time or is one active and one passive - you can use a floating static for the passive link.
Jon
06-11-2008 05:00 PM
Thanks, I didn't think about using a floating static. Both links will not be used at the same time.
06-11-2008 05:39 PM
950ms latency!? What are the properties and utilization of these links? What type of queue management (e.g. FIFO, WFQ, etc.)?
Reason I ask, I wonder if EIGRP packets are being overly delayed.
06-12-2008 08:18 PM
I'm using FIFO. What type of queue do you recommend? Yes, the latency is high, nothing i can do about that. We are talking modem, ATM's and satellite links. Shooting data across the world.
06-13-2008 02:56 AM
Ah, satellite; certainly explains high latency.
If supported, and if the platform can provide it without overtaxing itself, I prefer FQ or WFQ to FIFO to minimize one (or a couple) of bandwidth heavy flows from overly delaying or causing synchronous tails drops with other traffic. It might also help with EIGRP.
06-13-2008 12:16 PM
Thanks, I will give it try.
06-27-2008 08:14 AM
You may also try using LLQ and put your EIGRP traffic in the PQ. That should keep your EIGRP adjacencies up.
06-30-2008 05:13 PM
I'm not familiar with alot of queuing methods. Is this a difficult setup and does it need to be implemented on the local and remote router.
06-30-2008 05:49 PM
Difficulty depends on how complex the queuing configuration. If you don't have a form of FQ, try it first.
If the interface is a serial of 2 Mbps or less, try:
interface serial #
fair-queue
If the interface is faster than 2 Mbps, try CBWFQ:
policy-map CBWFQ
interface FastEthernet #
service-policy output CBWFQ
If the interface is faster than the capacity of the link, "shape" to the capacity, e.g.
interface FastEthernet #
traffic-shape rate ### (in bps)
Placement is on both ends outbound.
07-01-2008 07:04 PM
Wow, everyone is giving me some great ideas. I plan on trying WRED combined with traffic-shaping this weekend and monitoring the status for any improvement or degrade.
06-30-2008 06:06 PM
As a former tech controller there isn't much you can do to reduce the latency over a satellite link. Queuing methods will only help if the link is saturated, and will provide little help overall in your current situation.
Mark
06-30-2008 06:13 PM
Go Waterwalker! I have given up on the latency issue, can't do anything about the transmission medias in use. The link is also saturated, I using Netflow to monitor it and sometimes I get burst at 110%. Working on getting the bandwidth increased but until that red tape gets conquered, maybe queuing will keep things stable.
07-01-2008 04:08 AM
I would definitely recommend a good queuing strategy to help with congestion. Just remember that it won't replace an upgrade in bandwidth, but like you said keep things more stable and it should help. Good Luck!
Mark
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