Equal cost path load balancing with EIGRP and multicasting

[robyn]

I have a client with this problem -- load-balancing is not working on equal cost paths from Site 2 to Site 1. It does work from Site 1 to Site 2. Everything I read says EIGRP will automatically load-balance on equal cost paths. And PIM, from my understanding, draws its routing information from EIGRP. The core problem appears to be that only one of the VCs at Site 2 is associated with the multicast group.

My 2 sites are: Site 1 has a 2620 with IP+ 12.2.02T, a 4 port IMA card, and (2) ATM T1s. Site 2 has a 7204VXR with IP 12.2.04T, a 1 port ATM OC3SMI adapter, a ATM OC3 with (2) VCs to the (2) T1s at Site 1. IMA is not yet supported in the carrier's network which is why we are trying to get load balancing to work.

These two sites are two of 68 sites on a partial mesh ATM network. All sites with multi-T1s have the same problem. In addition to EIGRP they are running PIM Sparse-Dense. A good portion of the traffic is multicast. A sho ip mroute interface ATMX/x.X on the 7204VXR (Site 2) shows only one of the VCs to the other site, indicating that only one VC is associated with the multicast group. Again, this seems to be the core problem.

Since the paths are equal I am stumped as to why this isn't working and can't figure out how it can be fixed.

[ruwhite]

Is unicast traffic load sharing, and multicast not? I'm not certain we can load share multicast traffic, but we should be load sharing unicast traffic if the links are truly equal cost. It might be useful to include a show ip eigrp topo and show ip route for one of the routes that you think we should be load sharing towards.

Russ.W

[robyn]

The unicast traffic does not need to load share since there is so little of it.

SITE 1-rtr#sh ip eigrp topology 10.20.18.0 255.255.255.0

IP-EIGRP (AS 200): Topology entry for 10.20.18.0/24

State is Passive, Query origin flag is 1, 2 Successor(s), FD is 2199552

Routing Descriptor Blocks:

10.0.4.29 (ATM1/0.1), from 10.0.4.29, Send flag is 0x0

Composite metric is (2199552/1687552), Route is Internal

Vector metric:

Minimum bandwidth is 1544 Kbit

Total delay is 21160 microseconds

Reliability is 10/255

Load is 1/255

Minimum MTU is 1500

Hop count is 3

10.0.4.33 (ATM1/1.1), from 10.0.4.33, Send flag is 0x0

Composite metric is (2199552/1687552), Route is Internal

Vector metric:

Minimum bandwidth is 1544 Kbit

Total delay is 21160 microseconds

Reliability is 5/255

Load is 1/255

Minimum MTU is 1500

Hop count is 3

Site 2_rtr#sh ip mroute interface atm2/0.12 | begin 233.0.0.4

Outgoing interface list:

ATM2/0.18, Forward/Sparse-Dense, 09:56:29/00:03:21, Int limit 1000 kbps

ATM2/0.15, Forward/Sparse-Dense, 2d04h/00:02:36, Int limit 1000 kbps

ATM2/0.6, Forward/Sparse-Dense, 2d05h/00:02:47, Int limit 1000 kbps

ATM2/0.14, Forward/Sparse-Dense, 2d14h/00:03:28, Int limit 1000 kbps

ATM2/0.9, Forward/Sparse-Dense, 3d03h/00:03:26, Int limit 1000 kbps

ATM2/0.19, Forward/Sparse-Dense, 1w2d/00:02:50, Int limit 1000 kbps

ATM2/0.5, Forward/Sparse-Dense, 3w1d/00:03:20, Int limit 1000 kbps

ATM2/0.4, Forward/Sparse-Dense, 3w2d/00:02:58, Int limit 1000 kbps

ATM2/0.7, Forward/Sparse-Dense, 4w2d/00:03:00, Int limit 1000 kbps

ATM2/0.12, Forward/Sparse-Dense, 2d03h/00:02:57, Int limit 1000 kbps

Site 2_rtr#sh ip mroute interface atm2/0.12 | begin 233.0.0.3

ATM2/0.10, Forward/Sparse-Dense, 05:28:27/00:02:32, Int limit 1000 kbps

ATM2/0.12, Forward/Sparse-Dense, 2d03h/00:02:57, Int limit 1000 kbps

Notice that ATM2/0.12 show up in both lists indicating that the second sub-interface is not being recognized.

[ruwhite]

Okay--I'm not versed enough on multicast routing to tell you the answer this one. We'll wait and see if someone else who knows more about multicast can answer it, and I'll ask some people internally if they can pitch in and answer it.

Russ.W

[ruwhite]

I've talked to some of the multicast guys, and there isn't any way to load share multicast traffic across two links; when there are two equal cost rpf paths, the one with the higher ip address will be chosen as the best path, and all traffic shipped down that path. Only unicast traffic can be load shared based on equal cost paths.

Russ.W

[robyn]

Darn! Is this a function, or should I say non-function, of multicast? Or, is there a possibility of getting this to work if I change routing protocols? Say, OSPF instead of EIGRP and/or MOSPF instead of PIM? Static routes aren't practical because there are too many sites. If nothing else, is there a way to get the second route recognized so when the first route is at capacity traffic will start to flow over the second route? This isn't really load balancing, but it would work.

[ruwhite]

It's a "non-function" of multicast.... It doesn't matter what unicast routing protocol is used, it should act the same way. There's no way to flow over to another link when one is full, as far as I know, for unicast or multicast.

Sorry.... No good answers today. :-)

Russ.W

[robyn]

FYI for all looking at this thread: I resolved the problem using Multi-link PPP and Virtual Templates.