OSPF load balancing across multiple port channels

ciscojburgon · ‎10-01-2014

I have googled/searched for this everywhere but haven't been able to find a solution. Forgive me if I leave something out but I will try to convey all relevant information. Hopefully someone can provide some insight and many thanks in advance.

I have three switches (A, B, and C) that are all running OSPF and LACP port channelling among themselves on a production network. Each port channel interface contains two physical interfaces and trunks a single vlan (so a vlan connecting each switch over a port channel). OSPF is running on each vlan interface.

Switch A - ME3600

Switch B - 3550

Switch C - 3560G

This is just a small part of a much larger topology. This part forms a triangle, if you will, where A is the source and C is the destination. A and C connect directly via a port channel and are OSPF neighbors. A and B connect directly via a port channel and are OSPF neighbors. B and C connect directly via a port channel and are OSPF neighbors. Currently, all traffic from A to C traverses B. I would like to load balance traffic sourced from A with a destination of C on the direct link and on the links through B. If all traffic is passed through B, traffic is evenly split on the two interfaces on the port channel. If all traffic is pushed onto the direct A-C link, traffic is evenly balanced on the two interfaces on that port channel. If OSPF load balancing is configured on the two vlans from A (so A-C and A-B), the traffic is divided to each port channel but only one port on each port channel is utilized while the other one passes nothing. So half of each port channel remains unused. The port channel on B-C continues to load balance, evenly splitting the traffic received from half of the port channel from A.

A and C port channel load balancing is configured for src-dst-ip. B is a 3550 and does not have this option, so it is set to src-mac.

Relevant configuration:

Switch A:

interface Port-channel1

description Link to B

port-type nni

switchport trunk allowed vlan 11

switchport mode trunk

interface Vlan11

ip address x.x.x.134 255.255.255.254

interface Port-channel3

description Link to C

port-type nni

switchport trunk allowed vlan 10

switchport mode trunk

interface Vlan10

ip address x.x.x.152 255.255.255.254

Switch B:

interface Port-channel1

description Link to A

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 11

switchport mode trunk

interface Vlan11

ip address x.x.x.135 255.255.255.254

interface Port-channel2

description Link to C

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 12

switchport mode trunk

interface Vlan12

ip address x.x.x.186 255.255.255.254

Switch C:

interface Port-channel1

description Link to B

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 12

switchport mode trunk

interface Vlan12

ip address x.x.x.187 255.255.255.254

interface Port-channel3

description Link to A

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 10

switchport mode trunk

interface Vlan10

ip address x.x.x.153 255.255.255.254

Joseph W. Doherty · ‎10-02-2014

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

I suspect the issue you're seeing is both OSPF ECMP, using CEF (?), and Etherchanneling, using ip-src-dest, are effectively hashing into two paths, using similar attributes, so that might be why you're seeing only one port-channel link being used for traffic that's already been OSPF'ed ECMP.

To better understand the issue, you might read: http://www.cisco.com/c/en/us/support/docs/ip/express-forwarding-cef/116376-technote-cef-00.html

In your case, think of the routing split and the Etherchannel split, as if there were two CEF routers in series.

What might help in your case is to use a different Etherchannel hashing algorithm, perhaps just ip-src or ip-dest.

ciscojburgon · ‎10-02-2014

Thanks. It would seem this configuration is passing traffic exactly the way it's supposed to, it's just not what I'm trying to do. I will try to wrap my head around the polarization problem. It seems the ME-3600 doesn't have mls configuration options (image file is me360x-universalk9-mz.122-52.EY3.bin), so I might be somewhat limited in that area. I did try some different port channel load balancing options but the only thing I could get to happen was moving traffic to the other half of the port channel.

ciscojburgon · ‎10-03-2014

This is more FYI. 10.82.4.0/24 is a subnet on switch C. The path to it is split across vlans 10 and 11 but once it hits the port channel interfaces only one side of each is chosen. I'd like to avoid creating more vlan interfaces but right now that appears to be the only way to load balance equally across the four interfaces out of switch A.

ME3600#sh ip route 10.82.4.0

Routing entry for 10.82.4.0/24

Known via "ospf 1", distance 110, metric 154, type extern 1

Last update from x.x.x.153 on Vlan10, 01:20:46 ago

Routing Descriptor Blocks:

x.x.x.153, from 10.82.15.1, 01:20:46 ago, via Vlan10

Route metric is 154, traffic share count is 1

* x.x.x.135, from 10.82.15.1, 01:20:46 ago, via Vlan11

Route metric is 154, traffic share count is 1

ME3600#sh ip cef 10.82.4.0

10.82.4.0/24

nexthop x.x.x.135 Vlan11

nexthop x.x.x.153 Vlan10

ME3600#sh ip cef 10.82.4.0 internal

10.82.4.0/24, epoch 0, RIB[I], refcount 5, per-destination sharing

sources: RIB

ifnums:

Vlan10(1157): x.x.x.153

Vlan11(1192): x.x.x.135

path 093DBC20, path list 0937412C, share 1/1, type attached nexthop, for IPv4

nexthop x.x.x.135 Vlan11, adjacency IP adj out of Vlan11, addr x.x.x.135 08EE7560

path 093DC204, path list 0937412C, share 1/1, type attached nexthop, for IPv4

nexthop x.x.x.153 Vlan10, adjacency IP adj out of Vlan10, addr x.x.x.153 093A4E60

output chain:

loadinfo 088225C0, per-session, 2 choices, flags 0003, 88 locks

flags: Per-session, for-rx-IPv4

16 hash buckets

< 0 > IP adj out of Vlan11, addr x.x.x.135 08EE7560

< 1 > IP adj out of Vlan10, addr x.x.x.153 093A4E60

< 2 > IP adj out of Vlan11, addr x.x.x.135 08EE7560

< 3 > IP adj out of Vlan10, addr x.x.x.153 093A4E60

< 4 > IP adj out of Vlan11, addr x.x.x.135 08EE7560

< 5 > IP adj out of Vlan10, addr x.x.x.153 093A4E60

< 6 > IP adj out of Vlan11, addr x.x.x.135 08EE7560

< 7 > IP adj out of Vlan10, addr x.x.x.153 093A4E60

< 8 > IP adj out of Vlan11, addr x.x.x.135 08EE7560

< 9 > IP adj out of Vlan10, addr x.x.x.153 093A4E60

<10 > IP adj out of Vlan11, addr x.x.x.135 08EE7560

<11 > IP adj out of Vlan10, addr x.x.x.153 093A4E60

<12 > IP adj out of Vlan11, addr x.x.x.135 08EE7560

<13 > IP adj out of Vlan10, addr x.x.x.153 093A4E60

<14 > IP adj out of Vlan11, addr x.x.x.135 08EE7560

<15 > IP adj out of Vlan10, addr x.x.x.153 093A4E60

Subblocks:

None