Trunking between EXOS and S3

[michayos]

We recently deployed a stack of five 5420F series switches and configured a trunk back to our MDF which is an old Enterasys S3.  All VLANs over the trunk are tagged on both ends with no untagged traffic configured over the trunk.  The same VLANs are configured on both ends of the trunk so the allowed traffic matches up on both ends of the trunk.

For whatever reason, only traffic from the default VLAN 1 flows over the trunk.  Any traffic for any of the other VLAN's are failing.

I have trunks between some old "B5K" series Enterasys switches working with newer X450 series switches but only when one of the VLAN's are untagged.

Has anyone seen an issue with the older Enterasys switches requiring one VLAN to be untagged on trunks to newer EXOS based switches?  Does anyone know if this is required for trunks between the Enterasys S-series switches and EXOS based switches?

From a technical side, I have a LAG setup to manage the trunk on the S3 and sharing enabled to manage the trunk in EXOS on the 5420F stack.

Thanks  in advance for any help privided!

[Stefan_K_]

Interesting problem - never heard of it or had this issue as far as I can remember.

Some questions from my side: 

• You said between SecureStack and EXOs it's working if one VLAN is untagged. Is this also the case for the S3? Or is the traffic still failing, even if you have one VLAN untagged?
• On the S3 do you see discarded frames?
• On the S3 did you tag the VLANs on the lag.0.x Port only or also on the physical ports?
• How is the PVID configured? 

Port-Mirrors + tcpdump on both ends might also be helpful.

Best regards
Stefan

[michayos]

• This is the first time we've tried trunking between the S3 and and an EXOS based switch so I don't have any previous experience or knowledge related to this specific situation.
• I have 2 sites where trunks between "B5K" series Enterasys switches are working with newer EXOS based X450 series switches when one VLAN is untagged over the trunk
• The discards counters aren't increasing on the LAG or the physical ports in the lag.
• VLAN's are tagged on both the LAG and ports
• PVID related setting example
• set vlan egress 1,4,5 tg.1.49-50 tagged
• Set port lacp port tg.1.50,2.50 aadminkey 1
• Set port lacp port tg.1.50,2.50 en
• Set lacp aadminkey lag.0.1 1
• Set vlan egress 1,4,5 lag.0.1 tagged

[Stefan_K_]

Your LAG Ports are tg.1.50 and tg.2.50, but you tagged your VLANs on tg.1.49-50. I know, what it should be enough to tag it on lag.0.1, but I saw some cases where it didnt work until i tagged the VLANs on all the physical ports of the LAG.

Can you also make sure that the lag is up correctly?
show lacp lag.0.1

Is spanning-tree in use? 

[michayos]

I grabbed those commands from a setup template script I use and modify where needed so some of the commands don't match up.

The VLAN's are tagged on the LAG in the last line in the above example.  Regarding the issue between the S3 and the 5420, I'm actually using lag.0.2 witha number of vlans going over the trunk so the following is a partial example.

set lacp aadminkey lag.0.2 2
set port lacp port tg.2.10 aadminkey 2
set port lacp port tg.2.12 aadminkey 2
set port lacp port tg.2.10 enable
set port lacp port tg.2.12 enable
set vlan egress 9 lag.0.1-4;tg.2.2,4,6,8,10,12,18,20 tagged

I've never used the sh lacp command before and that points out the problem though I don't know why.  The lags are all configured the same as far as I can see but with different ports.  So what did I miss?

sh lacp lag.0.2
Global Link Aggregation state: enabled
Single Port LAGs: disabled

Aggregator: lag.0.2
Actor Partner
System Identifier: 20:b3:99:57:dc:a7 d8:84:66:05:09:c9
System Priority: 32768 32768
Admin Key: 2
Oper Key: 2 1
Attached Ports: None.
Standby Ports: None.