Mailing List Archive

I think I am kinda confused about what you are doing.

> VPC ID 18
> C9336-1 -> Downstream-Switch1
> C9336-2 -> Downstream-Switch1
>
> VPC ID 19
> C9336-1 -> Downstream-Switch2
> C9336-2 -> Downstream-Switch2

If the downstream switches operate as a MCLAG pair (basically a "vPC"
but not Cisco, whatever technology that may be), then this config
would be incorrect, you would want to use the same vPC ID on every
link.

If Downstream-Switch1 and Downstream-Switch2 have no "shared brain" at
all, then your config is correct to provide uplink redundancy for
these two switches.

Are you using the same Port-channel number on both 9336 also?

If all your ducks are in a row as above, then you are obviously
experiencing maybe a cosmetic bug on your Downstream-Switchx, but you
are apparently also either experiencing either a problem with the
LACPDUs that the 9336 is generating, or the other vendor switch is
experiencing a problem consuming them.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

> 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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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@uah.edu>
Sent: Friday, July 8, 2022 12:00 PM
To: Drew Weaver <drew.weaver@thenap.com>
Cc: cisco-nsp@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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@gmail.com>
Sent: Friday, July 8, 2022 2:09 PM
To: Drew Weaver <drew.weaver@thenap.com>
Cc: Hunter Fuller <hf0002@uah.edu>; cisco-nsp@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@thenap.com<mailto:drew.weaver@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@uah.edu<mailto:hf0002@uah.edu>>
Sent: Friday, July 8, 2022 12:00 PM
To: Drew Weaver <drew.weaver@thenap.com<mailto:drew.weaver@thenap.com>>
Cc: cisco-nsp@puck.nether.net<mailto:cisco-nsp@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@puck.nether.net<mailto:cisco-nsp@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-nsp<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 http://puck.nether.net/pipermail/cisco-nsp/<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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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@puck.nether.net> On Behalf Of Drew Weaver
Sent: Friday, July 8, 2022 2:39 PM
To: 'Crist Clark' <yheffen@gmail.com>
Cc: 'cisco-nsp@puck.nether.net' <cisco-nsp@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@gmail.com>
Sent: Friday, July 8, 2022 2:09 PM
To: Drew Weaver <drew.weaver@thenap.com>
Cc: Hunter Fuller <hf0002@uah.edu>; cisco-nsp@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@thenap.com<mailto:drew.weaver@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@uah.edu<mailto:hf0002@uah.edu>>
Sent: Friday, July 8, 2022 12:00 PM
To: Drew Weaver <drew.weaver@thenap.com<mailto:drew.weaver@thenap.com>>
Cc: cisco-nsp@puck.nether.net<mailto:cisco-nsp@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@puck.nether.net<mailto:cisco-nsp@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@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=
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/