I have done a few Arista deployments lately – they’re awesome, cheap, 10GbE switches. The EOS config is very similar to Cisco IOS, but there is one really important difference for my purposes, regarding VLAN assignments.
On a Cisco switch, you could run the following command:
switchport mode trunk
switchport trunk allowed vlan add 123,124,125
Aristas will let you run this command, without error, but it won’t do what you expect. As soon as you set a port to be a trunk, it allows all VLANs on it, without being told. So on an EOS switch, the configuration is:
switchport mode trunk
switchport trunk allowed vlan none
switchport trunk allowed vlan add 123,124,125
The recommended way of configuring your VLANs is to define which “trunk groups” a VLAN is in (under vlan configuration), then assign ports to trunk groups, but this IOS like method also works. You can (and should) verify the 802.1q trunking configuration of a port (or port-channel) by adding “trunk” after it:
show interface Eth7 trunk
Arista has this very concise and well written page on how to setup their virtual chassis MLAG configuration (like Cisco vPC, Brocade Trill, etc). One important key point it doesn’t note clearly at least – the MLAG peer link needs to ONLY have the peer-link VLAN on it, and the peer-link VLAN can’t go to the uplink switches, or you will get a spanning tree shutdown.
You should be able to just use that command, sans the “add”:
switchport trunk allowed vlan 123,124,125
switch…14:28:54#sh run all | grep -A 100 Port-Channel50 | grep allowed
switchport trunk allowed vlan 1-4094
…
switch…14:29:13(config-if-Po50)#switchport trunk allowed vlan 407
switch…14:29:22(config-if-Po50)#sh run all | grep -A 100 Port-Channel50 | grep allowed
switchport trunk allowed vlan 407
Regarding trunk groups, these are very handy to exclude a set of VLANs from the default trunk group (which is on by default and is also named “default”). As the referenced document states, the purpose of this trunk group is to keep that peer-link VLAN from being forwarded by default on newly configured trunks — Arista recommends turning off STP on this VLAN for maximum reliability within the MLAG pair.
There is some confusion here on what to allow on the peer-link itself, however. You should ONLY use the peer-link VLAN on the peer-link and nowhere else; the trunk group accomplishes this nicely. However, you do want all VLANs to traverse the peer-link, since during a failure scenario, you need to rely on the MLAG peer for switching during the partial MLAG port-channel failure.
This may clarify:
A user-defined trunk group is a subset of the default trunk group.
When a user-defined trunk group is created, it is removed from the default trunk group.
When you configure a trunk interface with a trunk group, you add them together, but the default is already there without being visible (unless you look at “show run all”).
Example logic:
trunk-group “default”: VLAN 1-4094
trunk-group “groupA”: VLAN 100-200
trunk-group “default” is now: VLAN 1-99,201-4094
An interface configured with trunk-group “groupA” effectively allows: VLAN 1-200 + VLAN 1-99,201-4094 (“groupA” + “default”)
An interface configured without any user-defined trunk-group will use “default”, and effectively allows: VLAN 1-99,201-4094
I hope this clarifies a bit!