cancel
Showing results for 
Search instead for 
Did you mean: 

SMLT to connect Physical Servers without LACP

SMLT to connect Physical Servers without LACP

cemcjk
New Contributor II

Hello, 

I already have a GTAC case opened on this but I wanted to see if anyone out there had a similar experience or some other knowledge; I've got two 5520s running 9.0.4.0, in a vIST pair - the vIST connection is fine and up on both sides. 

I'm planning on migrating a bunch of dual-homed physical hosts (servers) from EXOS switches, which are set up as mlag peers with static lag ports (no lacp), over to the VOSS switch pair. I've tried to make this pretty simple, each port on each member switch has an mlt interface per port (i.e int gig 1/1 is a member of mlt 1 on each switch, etc.) All the MLTs are set up as SMLTs and as far as I can tell, there's no issues, each switch can see the corresponding Local and Remote ports per (S)MLT. Today I went to test a single host by moving both it's connections over to the VOSS switches - and I saw what I thought was strange behavior; when both ports from the server were connected, IP reachability didn't work at all, but when only one link was connected (didn't matter which switch had the active link) - it worked, but obviously there's no redundancy there. 

Port speeds are exactly the same, and vlan membership was exactly the same on the ports (well, the MLTs). 

I keep seeing conflicting documentation and post regarding the necessity of LACP - there has to be a way to replicate the static MC-LAG nature of the EXOS setup in VOSS, right? 

The configuration was easy enough:

mlt enable x name "yy"

mlt member int gig x/y

mlt x encapsulation dot1q

int mlt x 

smlt

exit

mlt vlan [vlan zzz] [mlt xxx]

Anyone have any gotchas here or something I missed?

4 REPLIES 4

Phil_
New Contributor III

Its best practise to disable spanning-tree when configuring a splitted multi-link-trunk. 

interface gigabitEthernet 1/$port-id$
no spanning-tree mstp force-port-state enable
y
exit

If this doesnt resolve the issue, you should check the mac adress table and logs for potential mac flapping.

Best regards,
Philipp

Bentennysons
New Contributor

I was facing the same issue when migrating dual-homed servers without LACP. In my case, the problem was with VLAN-to-I-SID mapping in VOSS, which was blocking proper traffic forwarding. Since your setup works with a single link, it’s likely a hashing inconsistency or MAC/ARP learning issue when both links are active. I’d recommend checking the MLT hashing settings and making sure STP isn’t interfering. Also, verify that your servers are using static bonding pprints (mode 1 or 2) to match the static MLAG setup. Checking logs for any forwarding inconsistencies helped me pinpoint the issue.

EF
Contributor III

Hi

Two qestions, as you talk about vIST I suppose that all VLANs are associated to an I-SID, the second one is what kind of bonding are using your servers?

Regards

cemcjk
New Contributor II

EDIT: I forgot to add, the physical links were up on both ends on the SMLT ports. There were no errors or any indication of a problem. 

GTM-P2G8KFN