Ether channeling on Debian lenny having 2.6 kernel
Used an O2 with an inbuilt Ethernet port (100 Mbps with full duplex support ) and another NE2000 based card (10 Mbps with half duplex support). These two are connected to a Catalyst 2960G switch of CISCO.These steps have to be followed to the tee:-
1. apt-get install ifenslave-2.6
2. Note the interfaces available for bonding (eth0, eth1 etc)
3. bring down these interfaces ifconfig eth0 down
4. Stop the network services /etc/init.d/networking stop
5. edit /etc/network/interfaces
6. comment out the entries for all interfaces eth0, eth1 etc
7. Add the following new entry:-
auto bond0
iface bond0 inet static
address
netmask 255.255.255.0
network
gateway
slaves eth0 eth1
bond_mode 0 # u can use any mode from 0 to 6
bond_miimon 100
bond_downdelay 200
bond_updelay 200
8. ifconfig bond0 up
9. /etc/init.d/networking start
The debian Ethernet bonding guidelines have been followed from:-
www.debianhelp.co.uk/bonding.htm
As far as my experiments go, I have not made any change in the switch end. The wikis and other sites I have consulted also don’t speak anything to do at switch end.
The main features of the various bond mode are described for reference:-
Mode Description Function
0 Round Robin Packets transmitted in round robin fashion over the available interfaces, provides loadbalancing and fault tolerance
1 Active Backup One active at a time. Only fault tolerance
2 Balance XOR Load balancing and fault tolerance.
Observation:-
However, on actual testing, fault tolerance did not work
3 Broadcast Fault tolerance. Transmits everything on all slave interfaces.
Observation:-
Using this config, If I ping another server, I get duplicate replies, i.e., (DUP) is written in ping replies.
4. 802.3 ad Dynamic Link aggregation. This is classic IEEE 802.3ad dynamic link aggregation. Requires 802.3ad support in switch and driver support for receving speed and duplex of each slave.
Observations:-
Removing eth1 from link did not disrupt the ping, however, removing eth0 from ping disrupted the ping. Activity seems to be happening on both eth0 and eth1 when connected. However, eth1 alone is not able to initiate the traffic nor receive replies. (perhaps because in my case eth1 is operating in half-duplex mode)
5 Balance TLB Transmit Load Balancing. Incoming traffic is received on active slave. Outgoing traffic is balanced according to load on each slave.
Observation:
Disconnecting either eth1 or eth0 stops the ping.
6 Balance ALB Provides both Transmit and Receive Load Balancing.
TRUNKING BETWEEN TWO SWITCHES (Cisco 2960 G) or trunking between a switch and a server with two or more network cards.
Each Etherchannel can consist of 8 ports, so the effective bandwidth achievable is 800 Mbps or 8 Gbps. There can be 6 etherchannel groups maximum.
Pagp,LACP & ON modes in the switch
We can configure ether channel in three modes, Port Aggregation Protocol (Pagp), Link Aggregation control Protocol (LACP) and an ‘on’ mode. Both ends of the etherchannel should be in the same mode. Pagp is a cisco proprietary protocol. LACP is IEEE 802.3 ad dynamic link aggregation protocol.
In case of Pagp and LACP, the system negotiates with other end to determine which ports should be active in the etherchannel. Incompatible ports are suspended. In case of ‘on’ mode, no such negotiations take place and all the ports are expected to be in the channel. If the ports at other end are not in ‘on’ mode, packet loss can occur.
Step by step procedure for configuring L2 Etherchannels:-
First Create a channelgroup
1. Config t
2. Switch port mode access
# if the etherchannels were between two switches, it would be switch port mode trunk
3. Switchport access VLAN 7
# assuming that these ports belong to vlan 7.If the ports are to be trunked to another switch, skip this step
5. no shut
# channel group can take values from 1-6. The parameter mode_name can take the following values:-
1. If you are planning to use PAgp
(a) Channel-group 2 mode auto
(b) Channel-group 2 mode desirable
2. If you are planning to use LACP
(a) Channel-group 2 mode active
(b) Channel-group 2 mode passive
3. If you are planning to use mode ON
(a) Channel-group 2 mode on
7. end
8. sh run
# verify your config.
9. To verify the channel-group assigned to ports run:-
sh run int Port-channel 1
10. To verify if etherchanneling is correctly setup, run:-
sh etherchannel 1 summary
Output will same as given below in last line (P) should be there.
*********************************************************************** Flags: D - down P -
bundled in port-channel I - stand-alone s - suspended
H - Hot-standby (LACP
only) R -
Layer3 S - Layer2 U - in use f - failed to allocate
aggregator
M - not in use, minimum links not met u - unsuitable for bundling
w - waiting to be
aggregated Number of
channel-groups in use: 34 Number of aggregators: 34
Group Port-channel Protocol
Ports ------+-------------+-----------+----------------------------------------------- 41
Po41(SU) LACP Gi9/27(P) Gi10/39(P)
*************************************************************************
The various modes are explained in detail here1:-
auto—Enables PAgP only if a PAgP device is detected. It places the port into a passive negotiating state, in which the port responds to PAgP packets it receives but does not start PAgP packet negotiation.
•desirable—Unconditionally enables PAgP. It places the port into an active negotiating state, in which the port starts negotiations with other ports by sending PAgP packets.
•on—Forces the port to channel without PAgP or LACP. In the on mode, an EtherChannel exists only when a port group in the on mode is connected to another port group in the on mode.
•non-silent—(Optional) If your switch is connected to a partner that is PAgP-capable, configure the switch port for nonsilent operation when the port is in the auto or desirable mode. If you do not specify non-silent, silent is assumed. The silent setting is for connections to file servers or packet analyzers. This setting allows PAgP to operate, to attach the port to a channel group, and to use the port for transmission.
•active—Enables LACP only if a LACP device is detected. It places the port into an active negotiating state in which the port starts negotiations with other ports by sending LACP packets.
•passive—Enables LACP on the port and places it into a passive negotiating state in which the port responds to LACP packets that it receives, but does not start LACP packet negotiation
EtherChannel Configuration Guidelines 2
If improperly configured, some EtherChannel ports are automatically disabled to avoid network loops and other problems. Follow these guidelines to avoid configuration problems:
•Do not try to configure more than 6 EtherChannels on the switch.
•Configure a PAgP EtherChannel with up to eight Ethernet ports of the same type.
•Configure a LACP EtherChannel with up to16 Ethernet ports of the same type. Up to eight ports can be active, and up to eight ports can be in standby mode.
•Configure all ports in an EtherChannel to operate at the same speeds and duplex modes.
•Enable all ports in an EtherChannel. A port in an EtherChannel that is disabled by using the shutdown interface configuration command is treated as a link failure, and its traffic is transferred to one of the remaining ports in the EtherChannel.
•When a group is first created, all ports follow the parameters set for the first port to be added to the group. If you change the configuration of one of these parameters, you must also make the changes to all ports in the group:
–Allowed-VLAN list
–Spanning-tree path cost for each VLAN
–Spanning-tree port priority for each VLAN
–Spanning-tree Port Fast setting
•Do not configure a port to be a member of more than one EtherChannel group.
•Do not configure an EtherChannel in both the PAgP and LACP modes. EtherChannel groups running PAgP and LACP can coexist on the same switch. Individual EtherChannel groups can run either PAgP or LACP, but they cannot interoperate.
•Do not configure a Switched Port Analyzer (SPAN) destination port as part of an EtherChannel.
•Do not configure a secure port as part of an EtherChannel or the reverse.
•Do not configure a port that is an active or a not-yet-active member of an EtherChannel as an IEEE 802.1x port. If you try to enable IEEE 802.1x on an EtherChannel port, an error message appears, and IEEE 802.1x is not enabled.
•If EtherChannels are configured on switch interfaces, remove the EtherChannel configuration from the interfaces before globally enabling IEEE 802.1x on a switch by using the dot1x system-auth-control3 global configuration command.
•For Layer 2 EtherChannels:
–Assign all ports in the EtherChannel to the same VLAN, or configure them as trunks. Ports with different native VLANs cannot form an EtherChannel.
–If you configure an EtherChannel from trunk ports, verify that the trunking mode (ISL or IEEE 802.1Q) is the same on all the trunks. Inconsistent trunk modes on EtherChannel ports can have unexpected results.
–An EtherChannel supports the same allowed range of VLANs on all the ports in a trunking Layer 2 EtherChannel. If the allowed range of VLANs is not the same, the ports do not form an EtherChannel even when PAgP is set to the auto or desirable mode.
–Ports with different spanning-tree path costs can form an EtherChannel if they are otherwise compatibly configured. Setting different spanning-tree path costs does not, by itself, make ports incompatible for the formation of an EtherChannel
Testing Etherchannel by enabling bonding on server and LACP on switch.
As debian Ethernet bonding supports 802.3 ad (mode 4), I guess, we can configure two ports in the switch in LACP mode active and the network interface in the server as mode 4 and then test the connection.
Result:
The lights in the switch did not turn green after the cables were connected. I suspect that I am using the onboard card in FDUP and the add on PCI card in half duplex. This might be the issue as it is explained in point No. 4 of etherchannel configuration guidelines.
Refrences :
1 & 2 : http://www.cisco.com/en/US/docs/switches/lan/catalyst2960/software/release/12.2_25_see/configuration/guide/swethchl.html
3. http://en.wikipedia.org/wiki/IEEE_802.1X
1 comment:
Today did Etherchanelling between four ports of NAS controller-A and 4 Ports in the Cisco Switch (Port-Channel 1). A similar etherchanelling was done between NAS controller-B and 4 Ports in Cisco Switch (Port-Channel 2).
The mode used in the NAS end was 'on' therefore, 'on' mode was used at switch end too.
cable pull tests confirmed link availability
Post a Comment