[c-nsp] nexus 5xx vpc peer keepalives

scott owens scottowens12 at gmail.com
Fri Apr 30 18:35:30 EDT 2010


Tony,

Read this as well ( it talks about NOT using the mgmt0 for peer keep alives
) - we are trying this too

http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/layer2/Cisco_Nexus_5000_Series_NX-OS__chapter8.html

After figure 6, step 3 there is this text ;
Note   	
VLAN 900 must not be trunked across the vPC peer-link because it carries the vPC
peer-keepalive messages. There must be an alternative path between
switches NX-5000-1 and
NX-5000-2 for the vPC peer-keepalive messages.

The problem we are encountering is that if we drop the peer vlan from
the 5k to 5k link then we get weird errors as well.



I will STRONGLY suggest that you test any possible failure scenario that you
can think of.
Are you using the 5Ks/ FEXs in dual homed fashion ?

I have an open case with Cisco on the use of






Message: 7
> Date: Fri, 30 Apr 2010 10:45:52 -0500
> From: "Tony Varriale" <tvarriale at comcast.net>
> To: "nsp-cisco" <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] Nexus 5xxx VPC peer keepalives
> Message-ID: <25315F3D0266408E937BFBD54192307D at flamdt01>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
>        reply-type=original
>
> ----- Original Message -----
> From: "Church, Charles" <Charles.Church at harris.com>
> To: "nsp-cisco" <cisco-nsp at puck.nether.net>
> Sent: Wednesday, April 28, 2010 12:35 PM
> Subject: [c-nsp] Nexus 5xxx VPC peer keepalives
>
>
> > Anyone,
> >
> > Coming up on a design issue with our upcoming first deployment of Nexus
> > 5010s and 5020s in a new datacenter.   It's recommended in the following
> > doc to use the mgmt0 interface for peer keepalive messages:
> >
> >
> http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/layer2/Cisco_Nexus_5000_Series_NX-OS__chapter8.html#concept_47F7274E5FDA489884D0488BC491B066
> >
> > We're doing a true out of band management approach on this new network,
> so
> > the mgmt0 interfaces all home back to an OOB switch/router (4507)  which
> > houses the NMS gear, etc.  My concern is that a reload (or failure of
> some
> > type) on this OOB switch could cause a 'dual active' situation on all the
> > Nexus pairs of devices .  (6 pairs of 5010s, and the pair of 5020s that
> > aggregate the 5010 pairs).  I don't think I want that to happen.  So the
> > alternative seems to be a back to back non-VPC-peer link between the two
> > devices using a VLAN interface, but I hate the idea of using a 10 gig
> port
> > just for keepalives.  There are what appears to be additional copper mgmt
> > ports on the boxes, but they're covered up, and not in the CLI.  Any way
> > to utilize those?  Any other possibilities I'm overlooking?  Or am I
> stuck
> > getting 1 gig copper SFPs and crossover cables for keepalives?
> >
> > Thanks,
> >
> > Chuck
>
> There are specific rules and actions that are taken when specific failures
> occur and it's important to understand them.  Also, if this is your first
> go
> at this, I would highly recommend testing the scenarios so you can get
> comfortable.  Part of the value in Nexus is the vPC.  Unless you have a
> very
> specific reason that is broken by the vPC, get comfortable with it.  The
> dual active scenario isn't that bad.
>
> Oddly enough, I was testing a 350mbps multicast stream in a similiar
> environment today.  2 5ks that were dual active - workstation on a single
> attached 2k.  The keepalive link was down between those 5ks and had
> connection to network via peer link only.  The 2nd 5k had only 1 uplink to
> 7k-1.  The source of the multicast was on a 2k hanging off 7k-2 and a
> separate set of 5ks.
>
> All multicast packets were received and in order (reliable multicast
> testing
> with sequencing).
>
> tv
>
>
>
> ------------------------------
>
> _______________________________________________
> cisco-nsp mailing list
> cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
>
> End of cisco-nsp Digest, Vol 89, Issue 102
> ******************************************
>


More information about the cisco-nsp mailing list