Unicast traffic in Cisco IOS devices is usually forwarded by the CEF mechanism, which by default will load balance traffic across multiple equal-cost paths.
Multicast traffic is not so lucky. Multicast flows are attracted to receivers by routers in the path. If a subscription needs to be sent upstream toward a multicast source, and multiple equal-cost paths exist, PIM will send the subscription to the upstream router with the highest IP address.
Load Balancing Mulicast Flows
In the scenario below, R1 has two equal-cost paths to the 192.168.10.0/24 network, but R1 will send all PIM joins for all 8 flows in the direction of R3, because of R3's higher IP address. The result will be that all 8 multicast flows traverse the R3-R1 link, and the R2-R1 link sits idle.
The fix to balance multicast traffic across both links is to enable one of the EMCP multicast multipathing mechanisms. The simple ip multicast multipath directive in global configuration mode will enable load sharing using the S-Hash algorithm. Much like load sharing in EtherChannels, this is a deterministic hashing mechanism that considers the source IP (for (S,G)) or RP IP (for (*,G)) when performing RPF calculations. Unlike the EtherChannel case (which requires determinism to maintain the ordered delivery LAN invariant), determinism is required here because the RPF calculation performed at PIM-join time must select the same upstream interface as the one used when performing the RPF check on incoming multicast data packets in the future.
In our case, with eight groups evenly distributed across four servers, we're done. But what if there's only one server talking on many groups? Load balancing with S-hash would force all subscriptions for that one server onto one upstream link even though multiple links are available. The next step in load balancing is ip multicast multicast s-g-hash basic. It load balances RPF decisions by taking both the Source IP and the multicast Group address into account, and will satisfactorily balance the few-producers-many-groups scenario.
Polarization
Consider a multi-tier network like the one depicted below. R1, R2 and R3 each have two choices (interfaces) when performing RPF lookups for sources on the 192.168.10.0/24 network. For simplicity, I've labeled them "0" and "1".
It doesn't matter whether we use s-hash or s-g-hash algorithm in this example. Assume we've selected one, and applied it to all seven routers. R1 balances the load beautifully: half of the flows are subscribed via upstream link "0" to R2, and the other half are subscribed via upstream link "1" to R3.
What will R2 and R3 do? Remember that the hashing scheme is deterministic. This means that R2 will request all multicast flows from R4. Determinism: Every flow going through R2 is a "link 0 flow", so R2 will always choose R4, because R2's RPF lookup is using the same criteria as R1's. Likewise, R3 will send all join requests to R7. The R5-R2 and R6-R3 links will sit idle.
Polarization Fix
To balance the load equally we need to use different path selection criteria at each routing tier, and ECMP has a mechanism to do this. We can add the next-hop router address to the hashing mix to re-balance the subscription load at each tier. This works because each router in the topology has a unique perspective on the the next hop address. This is implemented with ip multicast multipath s-g-hash next-hop-based in global configuration mode.
glbp? why not? what you think about?
ReplyDelete