cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
624
Views
3
Helpful
10
Replies

EIGRP and Loadbalancing

manojkreddy
Level 1
Level 1

Hi Guys,

i got a questions regarding loadbalancing on Cisco routers. say, I have two locations( SiteA and SiteB) connected by two E1(LinkA, LinkB of equal cost) Links and i am using load balancing on these two links. i am using VoIP between Site A and Site B,so voice packets are also routed via these two links. its everything ok if these two links are stable. what happens when one of the links(say Link A) is inconsistent. I mean if the LinkA is going up and down frequently ( say for every 30 seconds). I think IOS maintains a route corresponding to the failed link for some time before it is flushed. if there are voice packets to be routed through the link after the link fails and before the route is flushed from routing table,What does IOS do in this situation? will it route the packets on failed link? if so the packets are lost any way( packet loss is not tolerated as they are voice packets)? and what is the remedy for this? plz suggest me a solution for this.

how the IOS behaves in this situation and how the packets are routed to destination and still using loadbalancing and EIGRP? how can I do this?

plz help me.

regards

Manoj.

10 Replies 10

manojkreddy
Level 1
Level 1

forgive me if this question is cilly

manoj

Exactly not silly, both routers can immediatelly sense failures link faults because those are directly connected. I don't think a failed link to cause remarkable packet loss. Are load of these links almost equal no? Or which load-balancing method is at work now? With fast-switching only per-destination load-balancing is possible and in cases where most of the traffic flows between two ip addresses, one link will be utilized mostly. With cef, yoýu can achieve per-destination or per-packet load balancing. Can you give more info about your switching method? (sh ip int serialX)

thank s for ur reply kkalaycioglu!

this is not a situation arised in my network. while reading some documents about loadbalancing i got this doubt.

u said that router can sense the failure of a directly connected link. what if voice packets are not from a directly connected router.

can u give details about the IOS behaviour when i am using Fast switching and when i am using CEF.

Thank&Regards

Manoj

http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_configuration_guide_chapter09186a00800ca6c7.html document outlines IOS switching paths and http://www.cisco.com/en/US/products/hw/modules/ps2033/prod_technical_reference09186a00800afeb7.html will give you an understanding of CEF load-balancing mechanisms. (If you follow technical support->technology support-->IP switching-->>CEF path in CCO you can reach a wealth of info about these subjects). Anot her point is that: for your case Multilink PPP can be another good loadbalancing scheme. An example config:

int s0

encapsulation ppp

ppp multilink

multilink-group 1

int s01

encapsulation ppp

ppp multilink

multilink-group 1

interface multilink 1

ip address x.x.x.x z.z.z.z

ppp multilink

multilink-group 1

This way you'll assign ip address to a virtual interface named :multilink interface. MLPPP exactly load balances. With MLPPP you can use some other link-efficiency mechanisms which can be useful for VoIP . Example:http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800b75d2.html

Regards.

Note that you will lose some packets while the router is sensing the down link. For instance, there are some processes involved that have to be called to notify the routing table of the change in link status, that then has to notify cef, etc. All of this could take on the order of milliseconds to complete, losing a couple or three packets in the best case, and dozens in the worst case. There are also intentional debouncing timers, that prevent the router from noticing down links immediately, so the router doesn't react to outages under a few hundred milliseconds.

Note this is going to impact voice more than, say, ftp traffic, since voice packets are so sensative to variations in delay and loss, and also because voice packets are smaller, and transmitted more often, on avergage, than other applications.

:-)

Russ.W

thanks for ur reply Mr.White.

so, i have to suffer some loss incase of link one failure, when i am load balancing.

do we have any workaround to solve this problem?

Thanks

Manoj

My first step would be to measure how many packets you're actually losing with your current setup, and determine if that's acceptable, before I started tuning timers and doing other sorts of work on the network that may be potentially destabilizing. It's important under any conditions to have a good baseline to start from, and to work from that, rather than to try and minimize something you might already be in good shape on.

If you determine you need to reduce the packet loss further than what you are currently seeing, then you need to determine just how important this is. For instance, the media with the fastest down time reporting is sonet--is it worth switching your links to sonet to get faster convergence?

If you can't afford a switch to sonet, then use the medium that most makes sense after that. For instance, broadcast networks are always going to be slower to converge than point-to-point networks, simply by their nature. If you're using ethernet at the critical point, then you will need to rely on layer 3 timers at this point (until some new technolofgies come on line).

If you're running over point-to-point links, you should try and adjust any timers so any link failure is recognized as fast as possible--for instance, using end-to-end lmi, asynchronous lmi, and other techniques on frame relay, etc. That you are load sharing over unequal cost links is actually a good thing, since EIGRP will fall back to the second link (a feasible successor) with little or no processing, in a matter of milliseconds, once the primary link is declared down.

There's an entire field of study here, rather than a simple knob to turn, with lots of tradeoffs to take into consideration. You would need to look at the entire GRIP initiative, containing things like SSO+, GR, and NSF.

:-)

Russ.W

I will be implementing somewhat of the same configuration as Manoj. Remote site with two links one 128K and one 64K using two directly connected dedicated pt to pt frame relay. I also will be using VoIP and plan on enabling ip cef.

Debating on whether to do a per packet or per destination loadbalancing. According to the cef documentation per packet better utilizes the links although packets may arrive out of sequence. I am leaning towards per packet as it better utilizes our links however concerned about the Voip packets arriving out of seq

Any thoughts or suggestions

I would use per source/destination pair--the out of order packets are likely to make the overall network efficiency worse than doing per packet, and gaining the small amount of bandwidth involved. The only way to know for certain is to test it, of course, but that's where experience points.

:-)

Russ.W

Craig Norborg
Level 4
Level 4

By using EIGRP to do the load balancing you are going to have some spotty performance on something like VoIP no matter how you tune things.

If you really want to avoid problems like this, you should think of going with a hardware solution for multiplexing the T1's instead of doing it via software. My choice for flexibility and ease of use is the QuickEagle DL3800 multiplexer.

http://www.quickeagle.com/solutions/DL3800InverseMplx.asp

You should be able to do 3 or 4 T1's off a simple serial port, although if you want to go to a higher rate, you would need to get a HSSI. This unit will handle either. It handles 2 T1's like a champ.

With a unit like this if one T1 fails, you won't even see a blip at the remote end unless your bandwidth is over the capacity of a single T1. Very nice...

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco