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