ATM IMA vs IPCEF BGP loadbalancing

Unanswered Question
Jul 7th, 2009

I currently have sites with 2 T1 connections to an MPLS cloud. Termed in a single router by the provider. We currently are running IP CEF and max paths 2 in BGP to ensure we are load balancing. We have equal cost paths however, the load balancing doesnt appear to work too efficiently. (fyi per-destination) We are told we should go ATM IMA to mux the 2 T1 connections to ensure we are utilizing the bandwith. We plan on doing voice and video over these links soon. Does anyone have any experience with ATM IMA and is it worth doing or should the software methods of load balancing be sufficient?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Giuseppe Larosa Tue, 07/07/2009 - 08:37

Hello Roland,

CEF based per destination load balancing works well when the number of traffic flows is relative high (50).

So the answer depends from your traffic patterns.

If for example there are only a few high volume traffic flows you can see one link much more used then the other.

ATM IMA will use its own methods to perform load balancing that you can roughly think as equivalent to per packet load sharing: the ATM cells that make the AAL5 PDU that carries the IP packet inside are sent over the member links in a round robin fashion and then reassembled at the other end.

There is a little increase in delay and you pay a price in terms of bandwidth efficiency:

in addition to cell tax (you can have one almost empty cell) that can be very big for small packets in comparison to frame based WAN, there is also the IMA signalling overhead.

An ATM cell can transport 48 bytes there are also for AAL5SNAP and AAL5 CRC 12 bytes of overhead so an IP packet of 80 bytes requires two cells an ip packet of 90 bytes requires 3 cells.

if you see a 60% / 40% ratio in usage in the two current links I would stay with the current setup.

if one link is used 90% and the other one 10% it can be wise to try to use ATM IMA or also PPP multilink or FR multilink.

Hope to help


rperrelli Tue, 07/07/2009 - 10:03

Thanks for your response Guiseppe, do you know how atm ima handels voip by any chance (with the reassembling of information at the far end)? We obviously will QOS it. FYI based on what you said we are leaning towards going ATM ima. (our provider doesn't offer MLFR) ima is there only option.

Giuseppe Larosa Tue, 07/07/2009 - 12:10

Hello Roland,

voip packets are small but considering the overhead I think they take two cells to be transmitted so one cell via link1 and one cell via link2.

But looking around I've found some old guidelines about Voip over ATM:

the idea is to use aal5mux instead of aal5snap that has less overhead.


But I don't know if this can be interesting for you it needs specific configuration also on the other side.

Of course you should be able to use modular QoS on the ATM IMA interface to provide better treatment to voice cells by putting them in a LLQ.

Hope to help


Joseph W. Doherty Tue, 07/07/2009 - 11:03

I've worked with ATM IMA, for 2 or more links to MPLS, seems to work fine although not too keen about the lost bandwidth to ATM overhead.

I've also worked with MLPPP to MPLS, and this too seems to work well for several T-1s or E-1s.

Both the forgoing running full spread of traffic types from VoIP and vidconf, to user and server backups.

Two issues with non-packet-by-packet CEF, load balancing isn't as good and individual flows limited to one link's bandwidth.

Another issue, though, is achieving good load balancing using BGP since it so often wants to use one best path even when it knows of more than one. Max paths alone doesn't always overcome this, although it, with the hidden command "bgp bestpath as-path multipath-relax" can make a huge difference.

Also, if you're doing BGP, depending on your platform and IOS, you might also want to consider OER/PfR. Even when you have "idea" link load sharing via routing, this technology can dynamically balance based on actual link load (and other criteria).


This Discussion