Nexus 7000 - Moving vPC keep alive

Unanswered Question
May 22nd, 2012

We have two Nexus 7010 switches running a vPC domain between the two switches.  On one of the 7010B, the peer keep alive (from the mgmt VRF) is connected to a 3560B *and* that 3560B also has a data connection back to the same 7010B.  Everything is fine with that setup.

Our second 7010A, the peer keep alive link is also connected to a coresponding 3560A switch.  However, that 3560A switch is not connected to 7010A.

I want to move the uplink from the 3560A from where it is to the 7010A which will break the keep alive.  However, I will not be breaking the vPC peer link as it is a pair of 10G connections between the two 7010 switches.

I have read that the vPC won't come up unless the peer keep alive is present, but it wasn't clear about taking down the keep alive link momentarily.  Moving the cable would be quick, but I know the mac table will need to update since 7010B switch will now see the keep alive across it's peer link instead of some other direction.

Can I take the peer keep alive link down providing the peer link stays up?

We are running kickstart and system version 5.0(3).

Thanks!

/alan

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (0 ratings)
krun_shah Tue, 05/22/2012 - 19:10

Are both 3560 switches layer 2 switches? If so is vlan that is used for keepalive link on 3560s allowed on link between 7010B and 3560B ? Taking down peer keepalive lonk should not be a problem it is only used for health check between two peers on udp messges your peerlink should be operational. Peerkeepalive link is used at begining when vpc domain is initialized

Sent from Cisco Technical Support iPhone App

Jeremy Waldrop Wed, 05/23/2012 - 03:08

Our standard for vpc peer keep alive config is to create a dedicated vrf on both N7Ks and then directly connect the N7Ks together using either 1G copper/1G fiber.

The interface that is used for the vpc peer keep alive IP is added to the dedicated vrf and configured as a routed port with an address like 1.1.1.1/30 on one end and 1.1.1.2/30 on the other.

With this setup you don't have to depend on another switch and sometimes the only other copper ports in the data center are the Nexus 2ks that are hanging off of the N7Ks.

alan.ambers Thu, 05/24/2012 - 05:32

Krun and Jeremy -

With some additional research, I found the document "Cisco NX-OS virtual PortChannel: Fundamental Desing Concepts with NXOS 5.0.  In it I found what Krun was talking about that it is ok to disconnect the peer keep alive when everything else is working.

However, I found something that seems to contradict what Jeremy said.  On page 6, it says:  The keepalive can be carried over a routed infrastructure; It does not need to be a direct point-to-point link, and in fact, it is desirable to carry the peer-keepalive traffic on a different network instead of on a straight point-to-point link. (emphasis added).

All of the diagrams in that document show the keepalive link above the rest of the network in a cloud which indicates a seperate network which a seperate vrf would be.

So my question is, why does that document suggest that it doesn't be on a straight point-to-point link?

Just for the record, we only have a single supervisor in each N7K which I suspect may make a difference.

Thanks!

/alan

krun_shah Thu, 05/24/2012 - 05:58

Peer keepalive works on UDP port 3200 over IP with 1 sec interval and 5 sec timeout.

Iit is not requirement to have peer-keepalive destination IP in same subnet but if you do not have it in same subnet then you need to make sure you route it properly and your IP routed infrastructure that carries keeplive satisfies above requirement to make sure not a single event cause on that IP infrastructure causes keeplives to loose packets since peer-keepalive is UDP it is not reliable delivery method.

Recommendation in past i heard was to use your managemet ports as peer-keepalive. But one problem happens during ISSU with dual sup, the each supervisor reboots and after it comes up role of active and standby gets switch at the end. So If you did not connect two managment ports(one from each supervisor) to your management network then you will loose keepalives during software upgrade because supervisor switch over occurs and new maangement port becomes active.

So second recomendation is to create one peer-keepalive vrf so that it will have its own address space, if you have M1 1 gig card in each switch then connect one cable between switch and assign IP address (like 1.1.1.1-2/30) and put it in peer-keepalive vrf. With this set up during ISSU you do not loose peer keepalives because line cards does not need to reboot and your peer-keepalive UDP traffic will not depend on any other switch or router.    

vismishr Thu, 05/24/2012 - 07:14

Hi Alan ,

To answer your question

Can I take the peer keep alive link down providing the peer link stays up?

Yes you could bring down vpc peer keep-alive link ,Peer-keepalive is only essential at the time when peer-link goes down or comes up.You will see this message on operational primary switch when keepalive link fail.

%VPC-2-PEER_KEEP_ALIVE_RECV_FAIL: In domain 1, VPC peer keep-alive receive has failed

but there will be no role change plus you will also see

vPC keep-alive status           : peer is not reachable through peer-keepalive

on both the devices.

But you need to make you redundancy more robust by following the best practices suggested by Cisco.

http://www.cisco.com/en/US/docs/switches/datacenter/sw/4_2/nx-os/interfaces/configuration/guide/if_vPC.html#wp1558628

Regards

Vishwa

Actions

Login or Register to take actions

This Discussion

Posted May 22, 2012 at 6:48 AM
Stats:
Replies:5 Avg. Rating:
Views:2978 Votes:0
Shares:0

Related Content

Discussions Leaderboard