cancel
Showing results for 
Search instead for 
Did you mean: 

Mac-Address not shared across MLT

Mac-Address not shared across MLT

SteveT
New Contributor

Hi,

I have the below setup and running into an issue when bringing the MLT up between the two VSP7400’s which are in a V-IST cluster. We have a SMLT created on the V-IST cluster to a single static LAG “device : CIH 16804”.

 

We can devide the diagram in two parts, left is station1 , right is station2

 

Both Stations 7400’s are connected to each other on port 2 and 3 Via mlt as NNI

Both Stations 4900’s are connected respective stations 7400’s as shown in a complete mesh topology and each ports are NNI

 

VIST Cluster Settings are as shown in diagram .

 

Stations 4900’s are part of cluster within the station via V-IST ( no direct connection between ) Acting as FE switches

 

But Stations 7400’s are clustered as per ISW/CIH connectivity

 

Station1 and Station2 Both has Vlan 10,20,30,40,55,60,70,200 with unique i-sids , IPs and VRID’s

 

Station1 has ISW/Kiosks switch connectivity to 4900’s as shown with Static LAG on ISW and smlt on 4900’s

 

The issue we are facing is when we bring the link between 2 stations UP VSP7400-1-station1 to VSP74002-station2

 

VSP7400-1-station1 learns all the physical IPs for all VLANs on VSP7400-2-station1  from station VSP7400-2-station2. Because of this, the mac address not learned on VSP7400-1-station1 and therefore not reachable.

I do not understand why we cannot ping the IP address 10.71.200.3 for mac 48:9b:d5:85:a1:01 even though it is in the arp table.

Station 2 works perfectly fine can ping across station 2 7400’s IP and learns IP through MLT only.

 

VOSS 8.2.6 across all switches.

 

a56a728a78fb438089b39799e8ccd63f_8b5b1301-674d-4ad2-9605-062b239ee0c9.png
a56a728a78fb438089b39799e8ccd63f_7253514b-9eea-424b-b720-40580ae35f6e.png
a56a728a78fb438089b39799e8ccd63f_20610428-9b22-413a-b272-604b3f8d4a06.png
a56a728a78fb438089b39799e8ccd63f_af819cab-a80f-41a8-927f-77f57888a9be.png
a56a728a78fb438089b39799e8ccd63f_7108707d-5d0c-4789-885a-b4b52c543b2d.png

 

 

 

1 ACCEPTED SOLUTION

Miguel-Angel_RO
Valued Contributor II

Hi SteveT,

 

First thing to look at is the log file of the VSP7400 when you bring the link UP.

Could you share the result of the commands below on the four VSP7400 with a set before and after bringing up the link?:

  • show isis spbm
  • show virtual-ist
  • show vlan i-sid
  • and of course the relevant lines in the log output when bringing up the link up

Thanks

 

Mig

View solution in original post

4 REPLIES 4

SteveT
New Contributor

Hi Mig,

Yes, this one will stay imprinted, often the simple things get overlooked. Thanks for the assist, going back to basics cleared my mind.

Miguel-Angel_RO
Valued Contributor II

Indeed,

It is one common source issue to forget one vlan/i-sid in one cluster member.

The behavior seems strange because packets are arriving to a cluster member that hasn’t this specific i-sid and then it drops the packet.

The good news is that you’ll never forget this one 7f84df5f229a4e94a532e2ff6325d668_1f609.png , it took me days to figure what was happening in one network few years ago.

Mig

 

SteveT
New Contributor

Hi Mig,

 

Thank you very much for your prompt response, I had overlooked one of the L2VSNs between the clusters.

The issue is resolved by extending the missing L2VSN across clusters, forour design we have used different VLAN I-SID parings between v-IST clusters.

 

Kind regards,

Steve

Miguel-Angel_RO
Valued Contributor II

Hi SteveT,

 

First thing to look at is the log file of the VSP7400 when you bring the link UP.

Could you share the result of the commands below on the four VSP7400 with a set before and after bringing up the link?:

  • show isis spbm
  • show virtual-ist
  • show vlan i-sid
  • and of course the relevant lines in the log output when bringing up the link up

Thanks

 

Mig

GTM-P2G8KFN