[c-nsp] [External] VPC + MLAG but more of a general question I guess

Wed Jul 13 12:03:31 EDT 2022

Just for the list, it turns out that the issue was that on the Nexus side the uplinks weren't in the same port channel and this is important when trying to trick the other side into thinking it's one system. 😉

Thanks, sorry for noise.

-----Original Message-----
From: cisco-nsp <cisco-nsp-bounces at puck.nether.net> On Behalf Of Drew Weaver
Sent: Friday, July 8, 2022 2:39 PM
To: 'Crist Clark' <yheffen at gmail.com>
Cc: 'cisco-nsp at puck.nether.net' <cisco-nsp at puck.nether.net>
Subject: Re: [c-nsp] [External] VPC + MLAG but more of a general question I guess

That isn’t actually what is occurring though.

Nothing is being blocked by STP and there are no runaway traffic loops.

From: Crist Clark <yheffen at gmail.com>
Sent: Friday, July 8, 2022 2:09 PM
To: Drew Weaver <drew.weaver at thenap.com>
Cc: Hunter Fuller <hf0002 at uah.edu>; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] [External] VPC + MLAG but more of a general question I guess

Because spanning tree.

If the DELL switches are paired, they are a single STP bridge. The vPC switches are a single STP bridge. If you have two independent links between those two bridges, one will block.

It will all work fine, and you’ll get redundancy, but only one link is available for use.

On Fri, Jul 8, 2022 at 10:45 AM Drew Weaver <drew.weaver at thenap.com<mailto:drew.weaver at thenap.com>> wrote:
Hello,

If we connect a host like a server or whatever to the C9336s using VPC each host has its own VPC ID.

So I guess the way I am thinking about this, potentially incorrectly (I might add) is that LAB-1 is a host and LAB-2 is a host. So that is why I gave each one their own VPC ID on the Cisco side.

From a technical standpoint why would each pair of switches need to know that the other pair is running VPC/MLAG at all, i.e. why does the VPC ID even matter?

So instead of thinking about it as one big switch made up of 4 actual switches I'm more thinking about it as two pairs of switches that happen to be connected together with port channels.

C9336s
LAB-1 is VPC po19/vpc19
LAB-2 is VPC po18/vpc18

On the Dell [OS6] side PO2 is VPC55 on both. Originally I had it setup exactly the same on both ends [VPC18 and VPC19] but the Dell side wouldn't learn MAC addresses across the peer-link when configured that way.

So assuming there is a technical reason that invalidates the current design would:

A) All four port-channels need to be configured as VPC 55 or
B) The two Dell switch port channels configured as VPC 55 and the two Cisco switches configured as VPC 19 OR 18

The reason I am sort of asking for more technical details as to why the VPC ID would matter outside of my specific scenario is because with the behavior of the Dell switches [bringing up po2 while simultaneously complaining it cannot possibly bring up PO2 because of a key mismatch] I'm having a hard time trusting anything they say.

Especially since they won't even try to explain why it's simultaneously complaining about the keys and also the port-channel is active.

Thanks,
-Drew

-----Original Message-----
From: Hunter Fuller <hf0002 at uah.edu<mailto:hf0002 at uah.edu>>
Sent: Friday, July 8, 2022 12:00 PM
To: Drew Weaver <drew.weaver at thenap.com<mailto:drew.weaver at thenap.com>>
Cc: cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>
Subject: Re: [External] [c-nsp] VPC + MLAG but more of a general question I guess

> If you have two Cisco switches in a VPC domain and then you connect another pair of switches downstream (that also run MLAG/VPC) is it required that all of the port-channels [for the partner network, not the peer-link] between those two sets of switches use the same VPC id?

I'm sorry, I just reread this, the answer is yes. Set all the mentioned ports on the C9336 to have the same vPC ID.

> Typically if a port channel configuration is invalid on the C9336 side it will put one of the ports into Stby to prevent loops but in this case the Cisco end doesn't see any problem with anything whatsoever.

It is still receiving valid LACPDUs from the remote switches so it is bundling those ports. The problem is in the far side, it should not be bundling the ports in this situation. The far side is correctly identifying the misconfiguration.

>   2.  The switch actually DID add the interfaces to PO2 even if it continually says that it can't do that.

Yeah, it shouldn't have.

> Should connecting a pair of MLAG switches downstream from a VPC domain be any different than connecting any other host to a VPC domain?

Well, no, it isn't different. Imagine if you had one switch, and you wanted its uplink to be a vPC. You would put all the 9336 ports in a vPC with the same ID.
Since you run MLAG on your downstream switches, they act as "one big switch" for the purpose of LACP. So you need to have the same vPC ID on all the 9336 ports because "they are all facing the same big switch" if that makes sense.

> My thinking is that the uplinks from each downstream switch really don't have anything to do with each other, which is why I configured them in separate VPCs on the Cisco side.

The fact that you are running MLAG on the downstream side, makes them have a lot to do with each other. They need to be in the same LAG.

> The second vendor is telling me that po2 from each downstream switch has to be in the same VPC on the Cisco side which isn't really clicking/making sense to me.

Yeah, I think you would do well to think of vPC and MLAG  as technologies that turn two switches into one big switch, for the purposes of that LAG. I even think of it this way - vPCs face a single "remote system" - this "system" can be made up of one switch, or multiple switches running MLAG/vPC..
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>
https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_cisco-2Dnsp&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=gXuN6PPAjglX8yH7eQuXJmqZXBzTPUlNZho0bpS3hWw&s=L5jysV9rbZys2_04V4gwi7PWxSyxT_UTSM76kwQk4tY&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_cisco-2Dnsp&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=o6GES1sizBXhjqpp_cCVd8LWSvu_eO-2CYuqS9pL5Cg&s=S4SdMo8dOpLYIgdJIRG4OBzH73DEra27ybMm7E6chHI&e=>
archive at https://urldefense.proofpoint.com/v2/url?u=http-3A__puck.nether.net_pipermail_cisco-2Dnsp_&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=gXuN6PPAjglX8yH7eQuXJmqZXBzTPUlNZho0bpS3hWw&s=MnoEWJ7Bcy-YU-9ynFHqF7cVS4PzniPo0jKmcpGgjFo&e=<https://urldefense.proofpoint.com/v2/url?u=http-3A__puck.nether.net_pipermail_cisco-2Dnsp_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=o6GES1sizBXhjqpp_cCVd8LWSvu_eO-2CYuqS9pL5Cg&s=VDt5ocAPRXyAfuOxtEpnnIuDvYV0CiAfu-1VbF-7_hE&e=>
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_cisco-2Dnsp&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=gXuN6PPAjglX8yH7eQuXJmqZXBzTPUlNZho0bpS3hWw&s=L5jysV9rbZys2_04V4gwi7PWxSyxT_UTSM76kwQk4tY&e=
archive at https://urldefense.proofpoint.com/v2/url?u=http-3A__puck.nether.net_pipermail_cisco-2Dnsp_&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=gXuN6PPAjglX8yH7eQuXJmqZXBzTPUlNZho0bpS3hWw&s=MnoEWJ7Bcy-YU-9ynFHqF7cVS4PzniPo0jKmcpGgjFo&e=