Virtual Connect LACP Long Timeout Option in VC4.01 Release

One of VC 4.01 features is an option to let users to configure LACP timeout to Long Timeout(30sec instead of default short timeout 1 sec). Sometimes data center switches would like their LACP neighbors to use Long Timeout and this feature will meet such requirement. One of the use cases is to help Cisco Nexus customers who wish to perform ISSU. One of ISSU requirements is all LACP timers need to be set as Long Timeout.

Before VC4.01, Nexus customers will see this on Nexus side when connecting with Virtual Connect.

N5K-1# show lldp neigh
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID Local Intf Hold-time Capability Port ID
ProCurveSwitch2900-24Gmgmt0 120 BR 14
N5K-2 Eth1/1 120 B Eth1/1
N5K-2 Eth1/2 120 B Eth1/2
Enc-FF-VC-1 SERIAL NO:TW201300H8 BAY:1Eth1/3 120 X1
Enc-FF-VC-1 SERIAL NO:TW201300H8 BAY:1Eth1/4 120 X2

N5K-1# show lacp interface e1/3 Interface Ethernet1/3 is up Channel group is 1 port channel is Po1

<snip>

Neighbor: 0x11 MAC Address= 0-24-81-f7-c6-f7 System Identifier=0x1,0-24-81-f7-c6-f7 Port Identifier=0x1,0x11 Operational key=2 LACP_Activity=active LACP_Timeout=short Timeout (1s) Synchronization=IN_SYNC Collecting=true Distributing=true Partner Admin State=(Ac-0:To-1:Ag-0:Sy-0:Co-0:Di-0:De-0:Ex-0) Partner Oper State=(Ac-1:To-1:Ag-1:Sy-1:Co-1:Di-1:De-0:Ex-0) N5K-1#

N5K-1# show lacp issu-impact
For ISSU to Proceed, Check the following:
1. The port-channel member port should be in a steady state.
2. Check if any of the port-channel member has fast timer enabled from the remote peer
.
The following ports are not ISSU ready
Eth1/3 , Eth1/4 ,

With 4.01, VC has the long timeout option now.

image

and this is how Nexus end should look like after VC set his end to do LACP Long Timeout.

N5K-1# show lacp interface e1/3 <snip> Neighbor: 0x11 MAC Address= 0-24-81-f7-c6-f7 System Identifier=0x1,0-24-81-f7-c6-f7 Port Identifier=0x1,0x11 Operational key=2 LACP_Activity=active LACP_Timeout=Long Timeout (30s) Synchronization=IN_SYNC Collecting=true Distributing=true Partner Admin State=(Ac-0:To-1:Ag-0:Sy-0:Co-0:Di-0:De-0:Ex-0) Partner Oper State=(Ac-1:To-0:Ag-1:Sy-1:Co-1:Di-1:De-0:Ex-0)

N5K-1# show lacp issu-impact
For ISSU to Proceed, Check the following:
1. The port-channel member port should be in a steady state.
2. Check if any of the port-channel member has fast timer enabled from the remote peer
.
All the port are ISSU ready


N5K-1#

Please Note:

1. If you still see Nexus show VC neighbor as “Short_Timeout” even after you set VC as Long, try to set VC back to Short and apply and then try to set VC back to Long again and apply to see if it can negotiate successfully.

2. Resetting LACP timer might have short traffic interruption for your application. I lost one ping during LACP timer changes on VC side while other times I didn’t lose any pings when doing the same LACP timer changes.

Advertisements

Virtual Connect IfInDiscards and IfOutDiscards Counters

Two of Virtual Connect interface counters: IfInDiscards and IfOutDiscards, are often seen as the indication of traffic packet drop issues. Actually, they are normal behavior inside VC operation. Please take a look at this VC advisory.

http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c03553035&printver=true

DESCRIPTION

The intent of this Customer Notice is to explain how rfc1213_IfOutDiscards and rfc1213_IfInDiscards function in a Virtual Connect environment. There are several normal traffic switching behaviors in Virtual Connect that will result in an accumulation of these Discard counters. This document describes the counter’s behaviors. The rfc1213_IfOutDiscards and rfc1213_IfInDiscards counter’s behavior is normal and harmless to the customer environment. The counters have no adverse affect on the performance of the Virtual Connect environment.

image

The VC advisory collection link is as below. I use Flexfabric as example as most of VC problems are not individual model number dependent.

http://h20566.www2.hp.com/portal/site/hpsc/public/psi/advisoriesResults/?sp4ts.oid=4144084&ac.admitted=1372869066291.876444892.199480143

 

Another useful link is Emulex CNA advisory link.

http://h20566.www2.hp.com/portal/site/hpsc/public/psi/mostViewedResults/?sp4ts.oid=4296125&ac.admitted=1372869573025.876444892.199480143

If you are using Proliant blade server G7 and above, the good chance is that you are using Emulex CNA(Intel G7 has NC553i as built-in LOM, AMD G7 has NC551i as built-in LOM, NC553m and NC551m are just Mezz card form factor for G7 with same architecture as “i”(built-in); Gen8 will have NC554 as FlexLOM, which uses same ASIC as NC553, just different form factor).  In many cases, the traffic issues are caused by end-point NIC/CNAs instead of Virtual Connect so it’s very important that you have up to date NIC/CNA firmware/driver.