Monday, February 10, 2014

Layer 2 | Layer 3 Etherchannel | Load balancing

Lessons learned:

Etherchannel:
Used to aggregate bandwidth of physical links –

Consists of two parts:
1.       Port channel interface
a.       Logical interface the bundles the physical links
2.       Member interfaces
a.       Physical interfaces
The channel can be any type of interface
                Layer2, layer3, trunk or tunnel
Can also configure access ports in a bundle. This is mostly used for server NIC teaming, etc.

Etherchannel negotiation:
# channel-group (#) mode (mode)
Mode determines hot negotiation occurs.
On = no negotiation
Desirable / auto = Cisco PagP – initiate or listen for PagP
Active / passive = Active – send LACP request  / Passive – listen for LACP request

Note:
If negotiation is set to ON, This will speed up bringing up the channel because there’s not protocol negotiation, this could however cause a layer 2 loop. If there’s a mis-configuration of one or more of the member interfaces
Once quick way to tell if a lops occurs is to look at the switch CPU process – it will spike to 100%
Compatible modes
On
On
Desirable
Desirable
Desirable
Auto
Active
Active
Passive
Passive



Etherchannel load balancing:

There are several load balancing algorithms that will run over a channel. With the default LB algorithm being – “Source MAC address”
Load balancing methods
Source MAC Address
Destination MAC Address
Source IP
Destination IP
Combinations of the 4

You can modify the load balancing method on each port channel with the following command:
#port-channel load-balance (method)

Member Interfaces:
Note: if you notice a single member interface is handling most of the traffic you can correct this by changing your load-balancing method. These do NOT need to match on either side of the channel. Each side can be configured for different method depending on the goal.

The LB method is based on a flow-by-flow behavior.
Example: If one of your port channels is configure as an access PC towards a server. The upstream switch receiving the frames from the server will see only one MAC address – the one assigned to the NIC of the Server.
The Switch will then say – for all frames coming from the server (for Example) use the first link in the port-channel to forward. The result is the first link will constantly have high-utilization.

Etherchannel Order of operations:

1.       Set member interfaces to defaults
a.       ex: # interface range gi0/1 – 2
b.      default interface
2.       Verify default interface cfgs – Note: the interface defaults will vary depending on model type (ex: 3550 or 3560)
3.       Default interfaces on peer switch member ports
4.       Use Interface range to configure member ports then shut down member ports
a.       Note: If the channel fails to negotiate or has a different config on one side vs the other – you open yourself up to the possibility of a layer 2 loop.
5.       Configure channel-group – use same interface range CMD to config channel-group number and negotiation mode.
6.        Once complete – bring up member interfaces first, this should also bring up the port-channel.
7.       Verify channel
a.       # Show etherchannel summary
8.       Verify spanning-tree (if configured as a trunk). From a spanning-tree perspective you should only see the port channel as forwarding. If you see the member interfaces then there’s a misconfiguration on one of the interfaces.
9.       You can then verify traffic over the link.
a.       # sh mac address-table dynamic address (MAC ADD)
b.      # show link utilization. Look at the interface counters of the member ports.
                                                               i.      #EX: #sh interface Gi0/1 | packets input|packets out

Note: If you need make changes to the port-channel, best practice is to make the changes to the member interface and port-channel at the same time.
EX: interface range gi0/1 – 2, PC1

Negotiation problems:
The advantage of using negotiation protocols is if there’s a misconfiguration of one of the member interfaces. The protocol can detect this and remove the member from the channel.
There’s a default feature on the switch to help as well.
# errordisable recovery cause channel-misconfig
This command try’s prevent issues when one side of the channel does not match the other.

Layer 3 Etherchannel:
You can also configure a L# channel.

Issues the no switchport command on the member interfaces first, if not it can cause an order of operations issue.
IP address and other logical options go on the Port-channel interface.

Order of operations:
Remove all previous configs – default interface the switchports.
Shut down member links.
Verify the member interfaces are configured as routed interfaces (no switchport)
Configure member interfaces via the interface range command. Configure channel group and set the mode as “on”.
No shut the member interfaces – this should also bring up the port-channel.


Note: the mode of the Port-channel will be inherited from the member interfaces. 

No comments:

Post a Comment