Arista EOS Port-Channel & LACP Configuration Guide - 夜莺博客

Arista EOS Port-Channel & LACP Configuration Guide

Link aggregation on Arista EOS turns several physical Ethernet ports into one logical port channel, either statically or dynamically through LACP. Because the port channel is a first-class interface on EOS, you configure VLANs, SVIs or routed addresses directly on it, and the member ports simply join a channel group. This guide covers the channel-group modes, minimum links, LACP fallback, load-balancing profiles and the show commands you need to build and verify an EOS port channel.

Creating a Port Channel with LACP

Enter the member interfaces as a range and assign them to a channel group with a mode. active sends LACP PDUs and negotiates with the peer; passive only responds; on forces the channel without LACP (static). Two passive ends never form a bundle, so at least one side must be active.

switch(config)# interface ethernet 1-2
switch(config-if-Et1-2)# channel-group 10 mode active
switch(config-if-Et1-2)# exit
switch(config)# interface port-channel 10
switch(config-if-Po10)# switchport trunk allowed vlan 10,20,30
switch(config-if-Po10)# switchport mode trunk
switch(config-if-Po10)# no shutdown

Members can be added later to the same group; EOS applies the channel-group statement to each interface in the range:

switch(config)# interface ethernet 7-10
switch(config-if-Et7-10)# channel-group 10 mode active

Note the direction of configuration: the member interfaces carry almost nothing except the channel-group line. Everything that describes the logical link - VLAN membership, MTU, spanning-tree settings, QoS policy, switchport mode - belongs on Port-Channel10. EOS keeps the members' switchport configuration inherited from the port channel, and if you try to set a conflicting value on a member, the member's setting is used for the member's own state before it joins, then overridden once it bundles. That is a common source of "the port channel came up but VLAN 30 does not pass" tickets.

Channel-Group Modes and What Pairs with What

The mode is per member interface, which means it is possible to build a port channel where some members negotiate and others are forced. Keep the table below in mind before you copy a configuration from one rack to another:

Local mode Peer mode Result
active active LACP bundle, full negotiation, failure detection via PDUs
active passive LACP bundle; active side drives the negotiation
passive passive No bundle - neither side speaks first
on on Static bundle, no LACP. Members are bundled as long as link is up
on active / passive No bundle - LACP and static cannot interoperate

The on mode is worth a warning in a data centre: a static bundle has no protocol to detect a peer that stops forwarding on one member. Half-dead links stay in the bundle and black-hole a share of the traffic. If both ends are EOS, or the other end is any device that speaks LACP - including most servers, and Linux bonding in 802.3ad mode - prefer active.

EOS also lets you tune the LACP PDU rate. The default is the slow rate of one PDU every 30 seconds; the fast rate sends one per second and detects a broken peer much sooner:

switch(config)# interface ethernet 1-2
switch(config-if-Et1-2)# lacp rate fast

Fast rate is the right choice on server-facing bundles where a failed NIC or a hung bond driver should be caught in a second rather than half a minute. On fabric links it is often left at the default to keep PDU processing off the control plane, but the trade-off is yours to make and should be documented in the design.

Layer 2, Layer 3 and Subinterfaces on the Port Channel

An EOS port channel is a routed interface candidate exactly like a physical port. The two common shapes are a trunk carrying many VLANs (with SVIs elsewhere on the switch doing the routing) and a routed port with an address:

switch(config)# interface port-channel 21
switch(config-if-Po21)# no switchport
switch(config-if-Po21)# ip address 10.10.10.1/31
switch(config-if-Po21)# no shutdown

switch(config)# interface port-channel 21.100
switch(config-subif-Po21.100)# encapsulation dot1q 100
switch(config-subif-Po21.100)# ip address 10.100.0.1/30

Two things to remember when a port channel becomes a routed port. First, EOS allocates an internal VLAN for the routed port, and that internal VLAN cannot be configured by hand - which is why show vlan internal usage is the command to run when a VLAN "refuses" to be created. Second, subinterfaces take the MTU of the parent, so raise the parent's MTU to at least 1522 bytes if tagged frames will ever be larger than a standard Ethernet frame.

Minimum Links and LACP Fallback

Port channels can require a minimum number of member links or a minimum aggregate speed before the bundle comes up, which protects against a degraded bundle carrying production traffic:

switch(config)# interface port-channel 13
switch(config-if-Po13)# port-channel min-links 4
switch(config-if-Po13)# port-channel speed minimum 100 gbps

EOS also supports LACP fallback for devices such as servers or PXE boot targets that need simple connectivity before they are ready to negotiate LACP. With static fallback the port channel keeps one active member while the others wait in standby until a LACP PDU arrives; with individual fallback all members act as independent switch ports. Fallback prevents a booting host with a single active NIC from being stranded without a link.

switch(config)# interface port-channel 13
switch(config-if-Po13)# port-channel lacp fallback static
switch(config-if-Po13)# port-channel lacp fallback timeout 60
switch(config-if-Po13)# port-channel lacp fallback individual

Think of the modes by how much of the bundle is kept alive without LACP. Static fallback brings up exactly one member and leaves the rest in standby, so a booting host gets reachability without the risk of a broadcast storm across a half-configured bond. Individual fallback brings up every member as an independent port, which the host sees as separate links - useful for management access before the OS bond is configured, dangerous if the host already has an IP on each NIC, because the switch will happily forward traffic out of all of them. Use individual fallback only where you understand the host side.

Min-links and fallback interact: a bundle configured with min-links 4 will not come up for the fallback host at all if fallback is disabled, and during fallback the port channel is up with fewer members than min-links requires. Decide which one you want before rolling out a template to a whole rack.

LACP Port Priority and Load Balancing

When the channel has more eligible members than the peer can bundle, EOS puts the interfaces with the higher LACP port-priority numbers into standby first (the default priority is 32768, range 0-65535):

switch(config)# interface ethernet 4
switch(config-if-Et4)# lacp port-priority 1000

Traffic distribution across the members is controlled by a load-balance profile. The default profile uses standard fields; you can build custom profiles from src-ip, dst-ip, src-port, dst-port, protocol or dscp and attach them to a port channel:

switch(config)# load-balance policies
switch(config-load-balance-policies)# load-balance sand profile myLB
switch(config-sand-load-balance-profile-myLB)# fields ip src-ip protocol dst-port
switch(config)# interface port-channel 10
switch(config-if-Po10)# port-channel load-balance sand profile myLB

The reason to build a custom profile at all is imbalance. A bundle between two switches that carries a few very large flows - backup jobs, storage replication, a single elephant flow between two servers - will not distribute evenly if the hash only looks at source and destination IP addresses, because all those flows share the same five-tuple. Adding L4 ports and the protocol to the hash, or moving to a profile that includes the DSCP field, usually flattens the distribution. The opposite is also true: a hash that includes too many fields can reorder a single flow across members if a field is not stable, so always verify with counters after a change rather than assuming the first profile you try is the best one.

Verification Commands

switch# show port-channel 10
switch# show port-channel summary
switch# show port-channel detailed
switch# show lacp 10 internal
switch# show lacp 10 neighbor
switch# show lacp 10 peer
switch# show lacp counters
switch# show interfaces port-channel 10
switch# show interfaces port-channel 10 counters

In the LACP output, look for the member state letters: S = short timeout, G = aggregable, I = individual, C = collecting, D = distributing. A healthy member shows as Bundled with ALGs+CD state; if a member shows as individual or standby, check the peer configuration, LACP mode, and port priority. For the bigger picture of building redundancy on EOS, see our runbooks on Arista EOS VLAN trunk and port-channel configuration and Arista EOS MLAG, plus the multi-vendor view in our Dell OS10 port-channel guide.

Two verification habits separate a quick fix from a long afternoon. First, always look at both ends: show lacp 10 internal on your switch and show lacp 10 neighbor tell you what the peer thinks, and a mode mismatch shows up as one side bundled and the other side individual. Second, count bytes rather than links: show interfaces port-channel 10 counters for the aggregate and the per-member counters underneath reveal a member that is up but not passing traffic, which is exactly the state LACP-based bundles exist to avoid.

Port Channels in an MLAG Fabric

In a leaf-spine fabric built with MLAG, most server-facing port channels are not point-to-point at all: the server's two NICs land on two different switches, and the pair of switches presents itself as one LACP partner. The port-channel configuration on each leaf looks ordinary, but two extra pieces make it work. The MLAG peer link must be a port channel as well - usually a bundle of at least two links on fast rate - and the MLAG domain must be up before the server-facing bundles can come up, otherwise each leaf would try to be an independent LACP partner and the server would see its members split across two identities.

switch(config)# interface port-channel 1000
switch(config-if-Po1000)# switchport mode trunk
switch(config-if-Po1000)# switchport trunk allowed vlan 10-20
switch(config-if-Po1000)# no shutdown

switch(config)# mlag configuration
switch(config-mlag)# domain-id DC1
switch(config-mlag)# local-interface Vlan4094
switch(config-mlag)# peer-address 10.0.0.2
switch(config-mlag)# peer-link Port-Channel1000

When troubleshooting in this topology, always ask which side is the MLAG primary. A server bundle that reports half its members as standby with no error on the switch is often simply MLAG doing its job: the secondary has correctly put its member links into standby because the peer link is up. The related failure mode - both switches believing they are primary - is a dual-primary situation, and the LACP symptoms look identical to a misconfigured bundle until you check show mlag.

Change Control and Rollout Habits

Port-channel changes are deceptively disruptive because they touch live forwarding. Three habits keep the risk contained. Use configuration sessions so a bundle change can be reviewed and rolled back as a unit:

switch# configure session add-po41
switch(config-s-add-po41)# interface port-channel 41
switch(config-s-add-po41-if-Po41)# switchport trunk allowed vlan add 41
switch# show session-config named add-po41 diffs
switch# commit

Second, add members one at a time on a change window and verify after each addition - a member that refuses to bundle is easy to spot when it is the only thing that changed, and impossible to spot in a ten-port range. Third, document the intended mode, min-links, fallback setting and hash profile for every bundle type in the design, because the failure modes above all come from a member that was built from a different template than its neighbours.

Failure Modes Worth Recognising

  • Member stuck as individual: almost always a mode mismatch (on against active), an LACP key mismatch from a mis-typed channel-group number, or a member with a different speed or MTU than its siblings.
  • Bundle up, one VLAN missing: the allowed-VLAN list lives on the port channel, not the members; check show interfaces port-channel 10 switchport.
  • Bundle flaps when a second member is added: a member was configured for a different switchport mode before it joined; clear the member configuration and re-add it to the channel group.
  • Traffic pinned to one member: hash imbalance, not a broken link. Change the load-balance profile and measure again.

原文链接:https://arista.com/en/um-eos/eos-port-channels-and-lacp