PQ Show 007 – Cisco Nexus Deep Dive Part 2 – Virtual Port-Channel

13 July 2012 by 7 Comments

Tony Mattke, Chris Marget, and Jeff Fry join Ethan Banks for a discussion about deploying virtual port-channel technology with the Cisco Nexus 5K and 7K series of switches in this continuation of the Cisco Nexus deep-dive podcast series.

What We Discuss

  • What is vPC?
  • What are some use-cases for vPC?
  • vPC terminology: domains, peer links, vPC VLANs, keepalives.
  • The basics of building a vPC switch pair, including the number of links you need to employ for a peer link, and how to design the keepalive link.

Links

Cisco Virtual PortChannel Quick Configuration Guide

Podcast: Play in new window | Download (Duration: 44:27 — 20.4MB)

Filed Under: Podcasts, Priority Queue Tagged With: , , , , ,
About Ethan Banks

Ethan Banks, CCIE #20655, is a hands-on networking practitioner who has designed, built and maintained networks for higher education, state government, financial institutions, and technology corporations. Ethan is a host of the Packet Pushers Podcast, which has seen over one million unique downloads, and today reaches a global audience of over ten thousand listeners. Also a writer, Ethan covers network engineering and the networking industry for a variety of IT publications. He is also the editor for the independent community of bloggers at PacketPushers.net. Follow @ecbanks.

  • http://twitter.com/chrismarget chris marget

    - Erratum -

    I think I said something in this podcast (haven’t listened to it yet) about vPC’s peer-gateway feature relaxing the restrictions of the vPC loop avoidance mechanism…

    That’s not how it works at all.

    Instead, the peer-gateway feature causes the members of a vPC domain to share forwarding duty for each other’s MAC addresses in the same way that they share the HSRP MAC addresses.

    So, no sub-optimal path here, no failover concerns. The only weirdness you might notice is that you probably can’t reliably manage (telnet/ssh/snmp/etc…) switches using their SVI addresses. At least, not from within the SVI’s VLAN.

    • http://packetpushers.net/author/ecbanks Ethan Banks

      Hmm, I split this show in two because it was so long, and don’t remember you saying that. I think I would have noticed that, because I’m starting to catch up with you guys on the vPC stuff as I’m right in the midst of deploying it. But maybe it did sneak in there…been several days since I did the edit. If you listen to this show and notice it, shoot me an e-mail with the timestamp, and I’ll stick in an audio note. If it’s actually in the next installment, then the magic of editing will make it go away before I publish it.

      • http://twitter.com/chrismarget chris marget

        I just listened to PQ007. Yup, I said it at about 35 minutes into the show.

        I had this confused idea about the peer-gateway feature (which I’ve refused to use :) until Lucien Avramov’s presentation at CL12.

        To clear things up: Ignore the bad things I said about the peer-gateway feature. peer-gateway does *not* introduce problematic traffic paths, nor does it introduce a problem related to serves trying to reach non-existent MAC addresses during failures.

        It’s perfectly safe, the only weirdness would be related to management traffic bound for SVIs on vPC VLANs.

        Sorry!

    • http://pktmaniac.info Yandy Ramirez

      [quote]The only weirdness you might notice is that you probably can’t reliably manage (telnet/ssh/snmp/etc…) switches using their SVI addresses[/quote]

      I haven’t seen this issue yet, except for some logging “from” the device, in other words sending logs. What do you mean by reliably? I’m genuinely curious, just in case I see something. I’m deploying these things left and right and was just wondering.

      • http://twitter.com/chrismarget chris marget

        My concern centers around the fact that both switches perform L3 operations on frames addressed to each other’s L2 address.

        For packets that need to be routed away, no problem, you don’t really care which router you hit.

        For packets destined *to* a particular router, you may have a problem because you can’t control L2 delivery of the frame (etherchannel hash does it), and the wrong switch might receive the frame for L3 processing.

  • timothybward

    What I’d love to see is a PQ like show maybe once a month that does nothing but PICK A TECHNOLOGY and LIST USE CASES. A lot of times I see these technologies, and they are -really- cool, but I have a hard time linking them to use case.

    • http://packetpushers.net/author/ecbanks Ethan Banks

      I like that idea for PQ shows. Got some specific tech you’d like covered?