One more vPC Question

[visitor68]

The scenario is two Nexus 5K vPC domains connected to each other in a bow tie.      

If you went into switch 1 and did a "sh etherchannel" or "sh port-channel" or whatever the devil the command is, would it show the uplinks in the peer switch (2) as being part of the channel or just its own local uplinks?

[glen.grant]

   No it only shows the local ports in the channel , you would need to use cdp to see what the other end ports are .

[visitor68]

Glen, thats what I thought. So, this illustration of the two ellipticals cutting across all connecting lines is inaccurate because it makes people think that all those ports are in the same port channel, when they are not.

This would be a more accurate representation.

[glen.grant]

  thats not really correct they could all be in the same port channel  , you asked if they showed in one box if they showed all the others , they do not , it just shows the locals .  In your drawing they could all be in say  port channel 2 with all the links as part of the same vpc.  Thats the beauty of vpc  you have one common non looped spanning tree domain . We have a very similar setup and all our links are in  port channel2 with a common vpc on all those links .  Thats how you get all active links without having a spanning tree blocked link .

[visitor68]

i dont get what youre saying. The bottom line is that the two uplinks on switch 2 are NOT available for forwarding by switch 1. So, from a data plane perspective, the 4 uplinks on switches 1 and 2 are NOT in the same port channel.

[glen.grant]

  Not really sure what you are saying.  What you are basically showing is a double sided vpc setup .  Even though they are separate boxes you can put all those uplinks into the same port channel on each box  and then make the port channels all the same vpc number .  All links are then active for traffic  .  Say you have a server hung off of each of the bottom 2 boxes , you can make the server in a active active setup and traffic will flow up both sides of that setup .  This doc may explain it better than I am .

http://www.cisco.com/en/US/docs/switches/datacenter/sw/design/vpc_design/vpc_best_practices_design_guide.pdf

[visitor68]

Glen, I hear ya and I got that part. Now lets take your scenario a step further...

when switch 1 gets the frame to send, it will only have TWO uplinks at its disposal - its own two uplinks. It will NOT have the uplinks on switch 2 as candidates for sending, even though they are supposedly in the "same port-channel". In other words, from a data plane perspective, all parts are NOT in the same channel. If they were, like any other port-channel, all ports would be candidates for sending the traffic, but they are not.

If, on the other hand, switches 1 and 2 were stacked (assuming Nexus could stack), THEN all 4 uplinks (2 on sw 1, and 2 on sw 2) would be eligible candidates for forwarding.

Clearer?

[Jon Marshall]

Essentially you are correct in that switch1 will only use it own ports to send traffic to the upper pair of Nexus switches.

But it is misleading to say it is not the same port channel because it is even from a data plane perspective because all ports are forwarding ie. STP has not blocked any member ports.  I do understand your point that with a stacked pair of switches, for example, any of the available links could be used and this is not the case here or maybe a better way of putting it is it is not the case from switch1's perspective.

If, as Glen suggested, you look at it from the perspective of a device connected to switch1 and switch2 with an active/active configuration there are four links available, all forwarding traffic.

I actually think the first diagram you posted explains how a double sided vPC works far more clearly than the second ie. from a logical perspective it is just one high bandwidth path.

Jon

[visitor68]

I guess we will have to agree to disagree.

[Jon Marshall]

I didn't think we were disagreeing

Jon