The set up consists of:
- A Switch running an OF-DPA based OpenFlow 1.3 Indigo agent.
- A Ryu Controller communicating with the switch using OpenFlow 1.3 protocol.
- IXIA ports connected to ports 1 through port 5 of the switch.
- Port 1 receiving a long lived IPv4 traffic at 60% of the line rate with DestIP: 192.168.5.1 and SrcIP: 1.1.1.1.
- Port 2 receiving a long lived IPv4 traffic at 60% of the line rate with DestIP: 192.168.5.2 and SrcIP: 2.2.2.2.
- Port 5 receiving IPv4 traffic at 10% of the line rate with DestIP: 192.168.5.3 and incremental SrcIP.
- Port 3 and port 4 as egress ports connected to IXIA.
Scenario A, the problem
The Ryu Controller configures an ECMP group in the switch with ports 3 and 4 as the next hops in the group to load balance traffic sent to this group.
This ECMP group is referenced by a Unicast Routing entry that routes all traffic destined to subnet 192.168.5.0 to this ECMP group.
Ports 1, 2 and 5 are the ingress ports receiving traffic from IXIA.
Traffic from port 5 is hashed and distributed across egress ports 3 and 4. This traffic is load balanced across the ECMP next hops.
Traffic from both port 1 and port 2 are hashed only to egress port 4. This results in port 4 getting subscribed beyond 120% of its transmit capacity and results in loss of traffic.
This is verified by the drops in the traffic captured on IXIA connected to ports 3 and 4.
Scenario B, the solution
I Scenario A, egress port 4 gets congested as the ingress traffic from both port 1 and 2 hash to it. To solve the problem a more specific flow entry is installed that redirects one of the traffic streams to the port 3.
The Ryu Controller adds a flow entry in the ACL Policy table that matches traffic destined to 192.168.5.2 and routes it to port 3.
Thus the congested port 4 is relieved of excess traffic which is now re-routed to port 3 through traffic engineering.
