Nexus 7000 vPC modification - avoiding type1 inconsistencies

Hi Everyone,
I need to configure some features on a pair of Nexus 7000's running 4.2(6) - one of them is Root Guard.
I am aware that when I enable Root Guard on the first vPC peer, the vPC will go into suspended state until I configure the other vPC peer identically.
This is causing me a big service disruption headache as I need to do this for a whole Data Centre.
I see on the Nexus 5k, you can do port-profiles which seems to enabled config synchronisation across vPC peers - so I assume the vPC would stay up due to both peers receiving config at exactly the same time - but this feature is not available on Nexus 7k.
Does anybody know for sure if I were to create a scheduled job to run at the same time on both vPC peers with identical config content - i.e. apply Root Guard to vPC - would this prevent the vPC going into suspend state?
If not, do you know of any other ways to prevent vPC going into suspend?
Thanks in advance for any advice!

Hi Raj,
thankyou for your response.
We have VPC between Core - Aggregation - all 7k and Aggregation to Access (5ks). VPC down from Core all the way to Access and also up all the way from Access to Core.
So from a STP point of view, the topology is a single switch for Core, Aggregation and Access - so no loops.
I agree this limits the potential for trouble if a switch is plugged into the access layer by mistake for example - but the customer is adamant they want it (RootGuard).
Thanks,
Oswaldo

Similar Messages

Nexus 7000 vPC suspended VLAN problem

I am trying to connect a Cat3560G switch to an N7K pair via a vPC. The VLANs I wish to trunk are being suspended, I am getting the following error messages:
2010 Jun 22 17:03:36 N7K-Core1 %ETHPORT-3-IF_ERROR_VLANS_SUSPENDED: VLANs 2,301 on Interface port-channel2 are being suspended. (Reason: Vlan is not allowed on Peer-link)
The VLANs do exist , but a STP instance isnt created for it (I am using RPVST);
N7K-Core1# sh vlan id 2
VLAN Name                             Status    Ports
2    VLAN0002                         active    Po2, Po75
N7K-Core1# sh spanning-tree vlan 2
ERROR: Spanning tree instance(s) for vlan does not exist.
Port       Vlans Err-disabled on Trunk
Eth1/9     none
Eth1/10    none
Eth1/17    2,301
Eth1/18    2,301
Eth1/25    2,301
Eth1/26    2,301
Eth2/2     none
Eth10/1    none
Eth10/2    2,301
Po2        2,301
Po75       2,301
Po99       none
The VLANs are allowed on the trunk (it by default allows all)
interface port-channel1
description * vPC Peer-Link *
vpc peer-link
spanning-tree port type network
I have turned off bridge assurance as a test but no no avail.
Any ideas?

I'm having the same issue between a pair of vPC'd 5020s going to a 6500 using a vPC.
All VLANs which are supposed to go over the trunk/vPC, are showing as err-disable on trunk. I've checked all configs and they are the same... allowed vlans match on all po interfaces and physical interfaces.
6509:
interface Port-channel78
description Connection to n5020s @ in the MDC
switchport
switchport trunk encapsulation dot1q
switchport trunk native vlan 2240
switchport trunk allowed vlan 2002-2006,2010,2014,2018,2022,2024,2026,2240
switchport trunk allowed vlan add 2244,2248,2252,2254,4050,4052,4054
switchport mode trunk
end
N5020-1:
interface port-channel100
description Uplink to dist01 @ A building
switchport mode trunk
switchport trunk native vlan 2240
switchport trunk allowed vlan 2002-2006,2010,2014,2018,2022,2024
switchport trunk allowed vlan add 2026,2240,2244,2248,2252,2254,4050
switchport trunk allowed vlan add 4052,4054
vpc 100
N5020-2:
interface port-channel100
description Uplink to dist01 @ A building
switchport mode trunk
switchport trunk native vlan 2240
switchport trunk allowed vlan 2002-2006,2010,2014,2018,2022,2024
switchport trunk allowed vlan add 2026,2240,2244,2248,2252,2254,4050
switchport trunk allowed vlan add 4052,4054
vpc 100
All member ports reflect the correct config.
Both 5020s have the same config for the peer-link:
interface port-channel2
description VPC Peer-link
vpc peer-link
spanning-tree port type network
Output form 'show interface trunk"
n5020-1# sh int tru
Port          Native Status        Port
              Vlan                  Channel
Eth1/1        2240    trnk-bndl     Po100
Eth1/2        1       trnk-bndl     Po200
Eth1/17       2240    trnk-bndl     Po78
Eth1/18       2240    trnk-bndl     Po78
Eth1/19       2240    trnk-bndl     Po87
Eth1/20       2240    trnk-bndl     Po87
Po78          2240    trunking      --
Po87          2240    trunking      --
Po100         2240    trunking      --
Po200         1       trunking      --
Port          Vlans Allowed on Trunk
Eth1/1        2002-2006,2010,2014,2018,2022,2024,2026,2240,2244,2248,2252,2254,4
050,4052,4054
Eth1/2        180-183
Eth1/17       180-183
Eth1/18       180-183
Eth1/19       2002-2006,2010,2014,2018,2022,2024,2026,2240,2244,2248,2252,2254,4
050,4052,4054
Eth1/20       2002-2006,2010,2014,2018,2022,2024,2026,2240,2244,2248,2252,2254,4
050,4052,4054
Po78          180-183
Po87          2002-2006,2010,2014,2018,2022,2024,2026,2240,2244,2248,2252,2254,4
050,4052,4054
Po100         2002-2006,2010,2014,2018,2022,2024,2026,2240,2244,2248,2252,2254,4
050,4052,4054
Po200         180-183
Port          Vlans Err-disabled on Trunk
Eth1/1        2002-2004,2006,2010,2014,2018,2022,2024,2026,2240,2244,2248,2252,2
254,4050,4052,4054
Eth1/2        180-183
Eth1/17       180-183
Eth1/18       180-183
Eth1/19       2002-2004,2006,2010,2014,2018,2022,2024,2026,2240,2244,2248,2252,2
254,4050,4052,4054
Eth1/20       2002-2004,2006,2010,2014,2018,2022,2024,2026,2240,2244,2248,2252,2
254,4050,4052,4054
Po78          180-183
Po87          2002-2004,2006,2010,2014,2018,2022,2024,2026,2240,2244,2248,2252,2
254,4050,4052,4054
Po100         2002-2004,2006,2010,2014,2018,2022,2024,2026,2240,2244,2248,2252,2
254,4050,4052,4054
Po200         180-183
Port          STP Forwarding
Eth1/1        none
Eth1/2        none
Eth1/17       none
Eth1/18       none
Eth1/19       none
Eth1/20       none
Po78          none
Po87          none
Po100         none
Po200         none
Thank you,
Chris Perkins
INX Inc.

Nexus 7000 - unexpected shutdown of vPC-Ports during reload of the primary vPC Switch

Dear Community,
We experienced an unusual behavior of two Nexus 7000 switches within a vPC domain.
According to the attached sketch, we have four N7Ks in two data centers - two Nexus 7Ks are in a vPC domain for each data center.
Both data centers are connected via a Multilayer-vPC.
We had to reload one of these switches and I expected the other N7K in this vPC domain to continue forwarding over its vPC-Member-ports.
Actually, all vPC ports have been disabled on the secondary switch until the reload of the first N7K (vPC-Role: primary) finished.
Logging on Switch B:
20:11:51 <Switch B> %VPC-2-VPC_SUSP_ALL_VPC: Peer-link going down, suspending all vPCs on secondary
20:12:01 <Switch B> %VPC-2-PEER_KEEP_ALIVE_RECV_FAIL: In domain 1, VPC peer keep-alive receive has failed
In case of a Peer-link failure, I would expect this behavior if the other switch is still reachable via the Peer-Keepalive-Link (via the Mgmt-Port), but since we reloaded the whole switch, the vPCs should continue forwarding.
Could this be a bug or are there any timers to be tuned?
All N7K switches are running on NX-OS 6.2(8)
Switch A:
vpc domain 1
peer-switch
role priority 2048
system-priority 1024
peer-keepalive destination <Mgmt-IP-Switch-B>
delay restore 360
peer-gateway
auto-recovery reload-delay 360
ip arp synchronize
interface port-channel1
switchport mode trunk
switchport trunk allowed vlan <x-y>
spanning-tree port type network
vpc peer-link
Switch B:
vpc domain 1
peer-switch
role priority 1024
system-priority 1024
peer-keepalive destination <Mgmt-IP-Switch-A>
delay restore 360
peer-gateway
auto-recovery reload-delay 360
ip arp synchronize
interface port-channel1
switchport mode trunk
switchport trunk allowed vlan <x-y>
spanning-tree port type network
vpc peer-link
Best regards

Problem solved:
During the reload of the Nexus 7K, the linecards were powerd off a short time earlier than the Mgmt-Interface. As a result of this behavior, the secondary Nexus 7K received at least one vPC-Peer-Keepalive Message while its peer-link was already powerd off. To avoid a split brain scenario, the VPC-member-ports have been shut down.
Now we are using dedicated interfaces on the linecards for the VPC-Peer-Keepalive-Link and a reload of one N7K won't result in a total network outage any more.

Nexus 7000 with VPC and HSRP Configuration

Hi Guys,
I would like to know how to implement HSRP with the following setup:
There are 2 Nexus 7000 connected with VPC Peer link. Each of the Nexus 7000 has a FEX attached to it.
The server has two connections going to the FEX on each Nexus 7k (VPC). FEX's are not dual homed as far as I now they are not supported currently.
R(A)              R(S)
|                     |
7K Peer Link 7K
|                     |
FEX              FEX
Server connected to both FEX
The question is we have two routers connected to each of the Nexus 7k in HSRP (active and one is standby). How can I configure HSRP on the nexus switches and how the traffic will routed from the Standby Nexus switch to Active Nexus switch (I know HSRP works differently here as both of them can forward packets). Will the traffic go to the secondary switch and then via the peer link to the active switch and then to the active router ? (From what I read the packet from end hosts which will go via the peer link will get dropped)
Has anyone implemented this before ?
Thanks

Hi Kuldeep,
If you intend to put those routers on a non-vpc vlan, you may create a new inter-switch trunk between the N7K and allow that non-vpc vlan . However if those will be on a VPC vlan, best to create two links to the N7K pair and create a VPC, otherwise configure those ports as orphan ports which will leverage the VPC peer link .
HTH
Jay Ocampo

Nexus 7000 and 2000. Is FEX supported with vPC?

I know this was not supported a few months ago, curious if anything has changed?

Hi Jenny,
I think the answer will depend on what you mean by is FEX supported with vPC?
When connecting a FEX to the Nexus 7000 you're able to run vPC from the Host Interfaces of a pair of FEX to an end system running IEEE 802.1AX (802.3ad) Link Aggregation. This is shown is illustration 7 of the diagram shown on the post Nexus 7000 Fex Supported/Not Supported Topologies.
What you're not able to do is run vPC on the FEX Network Interface that connect up to the Nexus 7000 i.e., dual-homing the FEX to two Nexus 7000. This is shown in illustrations 8 and 9 of under the FEX topologies not supported on the same page.
There's some discussion on this in the forum post DualHoming 2248TP-E to N7K that explains why it's not supported, but essentially it offers no additional resilience.
From that post:
The view is that when connecting FEX to the Nexus 7000, dual-homing does not add any level of resilience to the design. A server with dual NIC can attach to two FEX so there is no need to connect the FEX to two parent switches. A server with only a single NIC can only attach to a single FEX, but given that FEX is supported by a fully redundant Nexus 7000 i.e., SE, fabrics, power, I/O modules etc., the availability is limited by the single FEX and so dual-homing does not increase availability.
Regards

Catalyst 6500 - Nexus 7000 migration

Hello,
I'm planning a platform migration from Catalyst 6500 til Nexus 7000. The old network consists of two pairs of 6500's as serverdistribution, configured with HSRPv1 as FHRP, rapid-pvst and ospf as IGP. Futhermore, the Cat6500 utilize mpls/l3vpn with BGP for 2/3 of the vlans. Otherwise, the topology is quite standard, with a number of 6500 and CBS3020/3120 as serveraccess.
In preparing for the migration, VTP will be discontinued and vlans have been manually "copied" from the 6500 to the N7K's. Bridge assurance is enabled downstream toward the new N55K access-switches, but toward the 6500, the upcoming etherchannels will run in "normal" mode, trying to avoid any problems with BA this way. For now, only L2 will be utilized on the N7K, as we're avaiting the 5.2 release, which includes mpls/l3vpn. But all servers/blade switches will be migrated prior to that.
The questions arise, when migrating Layer3 functionality, incl. hsrp. As per my understanding, hsrp in nxos has been modified slightly to better align with the vPC feature and to avoid sub-optimal forwarding across the vPC peerlink. But that aside, is there anything that would complicate a "sliding" FHRP migration? I'm thinking of configuring SVI's on the N7K's, configuring them with unused ip's and assign the same virtual ip, only decrementing the prio to a value below the current standby-router. Also spanning-tree prio will, if necessary, be modified to better align with hsrp.
From a routing perspective, I'm thinking of configuring ospf/bgp etc. similar to that of the 6500's, only tweaking the metrics (cost, localpref etc) to constrain forwarding on the 6500's and subsequently migrate both routing and FHRP at the same time. Maybe not in a big bang style, but stepwise. Is there anything in particular one should be aware of when doing this? At present, for me this seems like a valid approach, but maybe someone has experience with this (good/bad), so I'm hoping someone has some insight they would like to share.
Topology drawing is attached.
Thanks
/Ulrich

In a normal scenario, yes. But not in vPC. HSRP is a bit different in the vPC environment. Even though the SVI is not the HSRP primary, it will still forward traffic. Please see the below white paper.
http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9402/white_paper_c11-516396.html
I will suggest you to set up the SVIs on the N7K but leave them in the down state. Until you are ready to use the N7K as the gateway for the SVIs, shut down the SVIs on the C6K one at a time and turn up the N7K SVIs. When I said "you are ready", it means the spanning-tree root is at the N7K along with all the L3 northbound links (toward the core).
I had a customer who did the same thing that you are trying to do - to avoid down time. However, out of the 50+ SVIs, we've had 1 SVI that HSRP would not establish between C6K and N7K, we ended up moving everything to the N7K on a fly during of the migration. Yes, they were down for about 30 sec - 1 min for each SVI but it is less painful and waste less time because we don't need to figure out what is wrong or any NXOS bugs.
HTH,
jerry

ESXi 4.1 NIC Teaming's Load-Balancing Algorithm,Nexus 7000 and UCS

Hi, Cisco Gurus:
Please help me in answering the following questions (UCSM 1.4(xx), 2 UCS 6140XP, 2 Nexus 7000, M81KR in B200-M2, No Nexus 1000V, using VMware Distributed Switch:
Q1. For me to configure vPC on a pair of Nexus 7000, do I have to connect Ethernet Uplink from each Cisco Fabric Interconnect to the 2 Nexus 7000 in a bow-tie fashion? If I connect, say 2 10G ports from Fabric Interconnect 1 to 1 Nexus 7000 and similar connection from FInterconnect 2 to the other Nexus 7000, in this case can I still configure vPC or is it a validated design? If it is, what is the pro and con versus having 2 connections from each FInterconnect to 2 separate Nexus 7000?
Q2. If vPC is to be configured in Nexus 7000, is it COMPULSORY to configure Port Channel for the 2 Fabric Interconnects using UCSM? I believe it is not. But what is the pro and con of HAVING NO Port Channel within UCS versus HAVING Port Channel when vPC is concerned?
Q3. if vPC is to be configured in Nexus 7000, I understand there is a limitation on confining to ONLY 1 vSphere NIC Teaming's Load-Balancing Algorithm i.e. Route Based on IP Hash. Is it correct?
Again, what is the pro and con here with regard to application behaviours when Layer 2 or 3 is concerned? Or what is the BEST PRACTICES?
I would really appreciate if someone can help me clear these lingering doubts of mine.
God Bless.
SiM

Sim,
Here are my thoughts without a 1000v in place,
Q1. For me to configure vPC on a pair of Nexus 7000, do I have to connect Ethernet Uplink from each Cisco Fabric Interconnect to the 2 Nexus 7000 in a bow-tie fashion? If I connect, say 2 10G ports from Fabric Interconnect 1 to 1 Nexus 7000 and similar connection from FInterconnect 2 to the other Nexus 7000, in this case can I still configure vPC or is it a validated design? If it is, what is the pro and con versus having 2 connections from each FInterconnect to 2 separate Nexus 7000? //Yes, for vPC to UCS the best practice is to bowtie uplink to (2) 7K or 5Ks.
Q2. If vPC is to be configured in Nexus 7000, is it COMPULSORY to configure Port Channel for the 2 Fabric Interconnects using UCSM? I believe it is not. But what is the pro and con of HAVING NO Port Channel within UCS versus HAVING Port Channel when vPC is concerned? //The port channel will be configured on both the UCSM and the 7K. The pro of a port channel would be both bandwidth and redundancy. vPC would be prefered.
Q3. if vPC is to be configured in Nexus 7000, I understand there is a limitation on confining to ONLY 1 vSphere NIC Teaming's Load-Balancing Algorithm i.e. Route Based on IP Hash. Is it correct? //Without the 1000v, I always tend to leave to dvSwitch load balence behavior at the default of "route by portID".
Again, what is the pro and con here with regard to application behaviours when Layer 2 or 3 is concerned? Or what is the BEST PRACTICES? UCS can perform L2 but Northbound should be performing L3.
Cheers,
David Jarzynka

Nexus 7000-Error Message

Hi
We are having 2 nexus switches configured in the network as core with HSRP configured between them..The access switches are connected withdual 10G links to both core switches with VPC configured in Nexus..In both core switches 10G module is used for uplink termination..In one of the core switch for this 10 G module we get the follwoing error
Module-1 reported minor temperature alarm. Sensor=20 Temperature=101 MinThreshold=100 2011 Dec 22 08:10:19 CORE-SEC %PLATFORM-2-MOD_TEMPOK:
Module-1 recovered from minor temperature alarm. Sensor=20 Temperature=99 MinThreshold=100 even though the room temprature is 23 Degree still we get this error wherein as per the nexus documenation allowed room temparature is 0-40 Degree (Operating temperature: 32º to 104ºF (0º to 40ºC) `
show module`
Mod Ports Module-Type                      Model                            Status
1    8      10 Gbps Ethernet XL Module      N7K-M108X2-12L        ok
2    32    1/10 Gbps Ethernet Module        N7K-F132XP-15          ok
3    48    10/100/1000 Mbps Ethernet XL Mod N7K-M148GT-11L    ok
5    0      Supervisor module-1X            N7K-SUP1                      active *
As per the nexus module documentation for module1 the allwed temparature is 0-40degree wherein the actual room temparatue is 23degree..below is the exception message for module1
exception information --- exception instance 1 ----
Module Slot Number: 1
Device Id         : 49
Device Name       : Temperature-sensor
Device Errorcode : 0xc3114203
Device ID         : 49 (0x31)
Device Instance   : 20 (0x14)
Dev Type (HW/SW) : 02 (0x02)
ErrNum (devInfo) : 03 (0x03)
System Errorcode : 0x4038001e Module recovered from minor temperature alarm
Error Type       : Minor error
PhyPortLayer     :
Port(s) Affected :
DSAP             : 39 (0x27)
UUID             : 24 (0x18
Same module exists in second Nexus 7000 which is in same datacenter but not getting this alarm..
can anyone please suggest on the same..Software details are as below
Software
BIOS:      version 3.22.0
kickstart: version 5.1(3)
system:    version 5.1(3)
BIOS compile time:       02/20/10
kickstart image file is: bootflash:///n7000-s1-kickstart.5.1.3.bin
kickstart compile time: 12/25/2020 12:00:00 [03/11/2011 07:42:56]
system image file is:    bootflash:///n7000-s1-dk9.5.1.3.bin
system compile time:     1/21/2011 19:00:00 [03/11/2011 08:37:35]

Hi Sameer
Temperature alarm means that one particular sensor on the linecard warms up to 101 degree.
This can be caused by damaged sensor or problems with cooling in that particular part of chassis.
You can check temperature on the module using following command:
show environment temperature module 1
Tru to move the module to another slot. If the issue reoccure - open a TAC case.
HTH,
Alex

Nexus 7000, 2000, FCOE and Fabric Path

Hello,
I have a couple of design questions that I am hoping some of you can help me with.
I am working on a Dual DC Upgrade. It is pretty standard design, customer requires a L2 extension between the DC for Vmotion etc. Customer would like to leverage certain features of the Nexus product suite, including:
Trust Sec
VDC
VPC
High Bandwidth Scalability
Unified I/O
As always cost is a major issue and consolidation is encouraged where possible. I have worked on a couple of Nexus designs in the past and have levergaed the 7000, 5000, 2000 and 1000 in the DC.
The feedback that I am getting back from Customer seems to be mirrored in Cisco's technology roadmap. This relates specifically to the features supported in the Nexus 7000 and Nexus 5000.
Many large enterprise Customers ask the question of why they need to have the 7000 and 5000 in their topologies as many of the features they need are supported in both platforms and their environments will never scale to meet such a modular, tiered design.
I have a few specific questions that I am hoping can be answered:
The Nexus 7000 only supports the 2000 on the M series I/O Modules; can FCOE be implemented on a 2000 connected to a 7000 using the M series I/O Module?
Is the F Series I/O Module the only I/O Module that supports FCOE?
Are there any plans to introduce the native FC support on the Nexus 7000?
Are there any plans to introduce full fabric support (230 Gbps) to the M series I/O module?
Are there any plans to introduce Fabric path to the M series I/O module?
Are there any plans to introduce L3 support to the F series I/O Module?
Is the entire 2000 series allocated to a single VDC or can individual 2000 series ports be allocated to a VDC?
Is Trust Sec only support on multi hop DCI links when using the ASR on EoMPLS pwire?
Are there any plans to inroduce Trust Sec and VDC to the Nexus 5500?
Thanks,
Colm

Hello Allan
The only IO card which cannot co-exist with other cards in the same VDC is F2 due to specific hardware realisation.
All other cards can be mixed.
Regarding the Fabric versions - Fabric-2 gives much bigger throughoutput in comparing with Fabric-1
So in order to get full speed from F2/M2 modules you will need Fab-2 modules.
Fab2 modules won't give any advantages to M1/F1 modules.
http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9402/data_sheet_c78-685394.html
http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9402/prodcut_bulletin_c25-688075.html
HTH,
Alex

EtherChannel problem on Nexus 7000

Dear NetPro gurus,
One of my customer is trying to setup an EtherChannel (LACP) on a pair of Nexus 7000. However, doesn't matter what we do, the port Eth 1/17 always become suspended. We have tried swapping fiber cables and also swapping SFPs, but no help.
The 1st Nexus 7010 - called 'VIWLRCA'
The 2nd Nexus 7010 - called 'VIWLRCB'
Originally port eth 1/17 are left as 'normal' trunk port, and we can see eth 1/17 shows up fine under 'show interface brief'
viwlrca-PROD# sh run int eth 1/17
interface Ethernet1/17
switchport
switchport mode trunk
udld disable
no shutdown
viwlrca-PROD# sh run int eth 1/18
interface Ethernet1/18
switchport
switchport mode trunk
udld disable
channel-group 20 mode active
no shutdown
viwlrca-PROD# sh int brief
Ethernet      VLAN    Type Mode   Status Reason                   Speed     Port
Interface                                                                    Ch #
Eth1/17       1       eth trunk up      none                        10G(S) --
Eth1/18       1       eth trunk up      none                        10G(S) 20
Eth1/19       --      eth routed down    SFP not inserted           auto(S) --
Eth1/20       --      eth routed down    SFP not inserted           auto(S) --
Eth1/21       --      eth routed down    Administratively down      auto(S) --
Eth1/22       --      eth routed down    Administratively down      auto(S) --
Eth1/23       --      eth routed down    Administratively down      auto(S) --
Eth1/24       --      eth routed down    Administratively down      auto(S) --
Eth2/25       --      eth routed down    Administratively down      auto(D) --
Eth2/26       --      eth routed down    Administratively down      auto(D) --
Eth2/27       --      eth routed down    SFP not inserted           auto(D) --
Eth2/28       --      eth routed down    SFP not inserted           auto(D) --
Eth2/29       --      eth routed down    SFP not inserted           auto(D) --
Eth2/30       --      eth routed down    SFP not inserted           auto(D) --
Eth2/31       --      eth routed down    SFP not inserted           auto(D) --
Eth2/32       --      eth routed down    SFP not inserted           auto(D) --
viwlrca-PROD#
But as soon as I add the Eth 1/17 back onto PortChannel 20
The Eth 1/17 becomes "Suspended" straight away
viwlrca-PROD# sh int brief
Ethernet      VLAN    Type Mode   Status Reason                   Speed     Por
t
Interface                                                                    Ch
Eth1/17       1       eth trunk down    suspended                  auto(S) 20
Eth1/18       1       eth trunk up      none                        10G(S) 20
Eth1/19       --      eth routed down    SFP not inserted           auto(S) --
Eth1/20       --      eth routed down    SFP not inserted           auto(S) --
Eth1/21       --      eth routed down    Administratively down      auto(S) --
Eth1/22       --      eth routed down    Administratively down      auto(S) --
Eth1/23       --      eth routed down    Administratively down      auto(S) --
Eth1/24       --      eth routed down    Administratively down      auto(S) --
Eth2/25       --      eth routed down    Administratively down      auto(D) --
Eth2/26       --      eth routed down    Administratively down      auto(D) --
Eth2/27       --      eth routed down    SFP not inserted           auto(D) --
Eth2/28       --      eth routed down    SFP not inserted           auto(D) --
Eth2/29       --      eth routed down    SFP not inserted           auto(D) --
Eth2/30       --      eth routed down    SFP not inserted           auto(D) --
Eth2/31       --      eth routed down    SFP not inserted           auto(D) --
Eth2/32       --      eth routed down    SFP not inserted           auto(D) --
viwlrca-PROD#
viwlrca-PROD# sh port-channel summary
Flags: D - Down        P - Up in port-channel (members)
        I - Individual H - Hot-standby (LACP only)
        s - Suspended   r - Module-removed
        S - Switched    R - Routed
        U - Up (port-channel)
        M - Not in use. Min-links not met
Group Port-       Type     Protocol Member Ports
      Channel
20    Po20(SU)    Eth      LACP      Eth1/17(s)   Eth1/18(P)
viwlrca-PROD#
Config on Primary Nexus:-
viwlrca-PROD# sh run
!Command: show running-config
!Time: Tue Mar 22 06:04:26 2011
version 5.1(1a)
hostname PROD
cfs eth distribute
feature udld
feature interface-vlan
feature lacp
feature vpc
feature vtp
username admin password 5 $1$pkJaKHZW$Sx4wpDG5xXYkD.QfDk/Cg. role vdc-admin
no ip domain-lookup
ip domain-name vfc.com
crypto key param rsa label viwlrca-PROD.vfc.com modulus 2048
snmp-server user admin vdc-admin auth md5 0x05f7328e3b39a70be09abc3056ec2819 pri
v 0x05f7328e3b39a70be09abc3056ec2819 localizedkey
vrf context management
spanning-tree pathcost method long
spanning-tree port type edge bpduguard default
spanning-tree loopguard default
spanning-tree vlan 1-3967,4048-4093 priority 4096
interface Vlan1
interface Vlan161
ip address 172.30.161.2/24
interface Vlan162
ip address 172.30.162.2/24
interface Vlan163
ip address 172.30.163.2/24
interface Vlan164
ip address 172.30.164.2/24
interface Vlan165
ip address 172.30.165.2/24
interface Vlan190
ip address 172.30.190.2/24
interface port-channel20
switchport
switchport mode trunk
interface Ethernet1/17
switchport
switchport mode trunk
udld disable
channel-group 20 mode active
no shutdown
interface Ethernet1/18
switchport
switchport mode trunk
udld disable
channel-group 20 mode active
no shutdown
interface Ethernet1/19
interface Ethernet1/20
interface Ethernet1/21
interface Ethernet1/22
interface Ethernet1/23
interface Ethernet1/24
interface Ethernet2/25
interface Ethernet2/26
interface Ethernet2/27
interface Ethernet2/28
interface Ethernet2/29
interface Ethernet2/30
interface Ethernet2/31
interface Ethernet2/32
interface Ethernet2/33
interface Ethernet2/34
interface Ethernet2/35
interface Ethernet2/36
interface Ethernet3/25
interface Ethernet3/26
interface Ethernet3/27
interface Ethernet3/28
interface Ethernet3/29
interface Ethernet3/30
interface Ethernet3/31
interface Ethernet3/32
interface Ethernet3/33
interface Ethernet3/34
interface Ethernet3/35
interface Ethernet3/36
line vty
viwlrca-PROD#
Config for Secondary Nexus 7000
VIWLRCB-PROD# sh run
!Command: show running-config
!Time: Tue Mar 22 09:19:22 2011
version 5.1(1a)
hostname PROD
cfs eth distribute
feature interface-vlan
feature lacp
feature vpc
feature vtp
username admin password 5 $1$Lc486EOm$EtKhZWuxGjWWokfeuUsMk. role vdc-admin
no ip domain-lookup
ip domain-name vfc.com
crypto key param rsa label VIWLRCB-PROD.vfc.com modulus 2048
snmp-server user admin vdc-admin auth md5 0xeb607b54234985ed6740c5fdbb8d84c6 pri
v 0xeb607b54234985ed6740c5fdbb8d84c6 localizedkey
vrf context management
spanning-tree pathcost method long
spanning-tree port type edge bpduguard default
spanning-tree loopguard default
spanning-tree vlan 1-3967,4048-4093 priority 8192
interface Vlan1
interface port-channel20
switchport
switchport mode trunk
interface Ethernet1/17
switchport
switchport mode trunk
channel-group 20 mode active
no shutdown
interface Ethernet1/18
switchport
switchport mode trunk
channel-group 20 mode active
no shutdown
interface Ethernet1/19
interface Ethernet1/20
interface Ethernet1/21
interface Ethernet1/22
interface Ethernet1/23
interface Ethernet1/24
interface Ethernet2/25
interface Ethernet2/26
interface Ethernet2/27
interface Ethernet2/28
interface Ethernet2/29
interface Ethernet2/30
interface Ethernet2/31
interface Ethernet2/32
interface Ethernet2/33
interface Ethernet2/34
interface Ethernet2/35
interface Ethernet2/36
interface Ethernet3/25
interface Ethernet3/26
interface Ethernet3/27
interface Ethernet3/28
interface Ethernet3/29
interface Ethernet3/30
interface Ethernet3/31
interface Ethernet3/32
interface Ethernet3/33
interface Ethernet3/34
interface Ethernet3/35
interface Ethernet3/36
line vty
VIWLRCB-PROD#
Cheers,
Hunt

Quick troubleshoot:
Default all interfaces in newly created port-channel as well as the port-channel interface, then delete port-channel interface. Recreate port-channel without the LACP protocol:
interface e1/17,e1/18
switchport
channel-group 20 mode on
no shutdown
exit
interface port-channel20
switchport
switchport mode trunk
no shutdown
exit
show port-channel summ
show int trunk
HTH,
Sean

WCCP on Nexus 7000

Hi,
Does anyone know if there will be a performance hit on the Nexus 7000 when doing both inbound and outbound WCCPv2 redirect on the same interface?
We are migrating WAAS from 6K to 7K and consolidating 4x 6Ks into two new 7K’s core/agg. On the 6k setup we are redirecting at the core on the Agg uplinks which we won’t have in the new design. I am looking for a common traffic aggregation point in the new design and the only place I can think of is the actual WAN interface itself.
WAN ---- WCCP in/out ---- N7K ---- Access/Svrs
|
WAE
Cheers,
Rich

Both inbound and outbound redirects are performed in hardware on the Nexus 7000 so there is no real performance penalty in doing both in and out on the same interface.
Note that you need to ensure you have "ip wccp redirect exclude in" configured on the interface connected to the WAE on the N7K to avoid a redirect loop. This function is also performed in hardware on the Nexus 7000.
Regards
Rob

Nexus 7000 Platform Logging

Hello,
We recently had a power supply failure in one of our Nexus 7000s, and I noticed that the syslog for the Platform is only present in the default VDC, and not in any of the other VDCs syslogs. Is this by design, or is there a logging level I can turn up in another VDC to capture this log? Thanks for any input
syslog from default VDC -
2013 Mar 18 23:10:34 %PLATFORM-2-PS_CAPACITY_CHANGE: Power supply PS3 changed i
ts capacity. possibly due to power cable removal/insertion (Serial number xxxxxxxx)
nothing in the VDC where I would like to get the logging
default VDC logging level -
xxx7K02# show log level platform
Facility        Default Severity        Current Session Severity
platform                5                       5
0(emergencies)          1(alerts)       2(critical)
3(errors)               4(warnings)     5(notifications)
6(information)          7(debugging)
xxx7K02#
loggging from the specific VDC where we have management tools.
xxx-LOW# show log level platform
Facility        Default Severity        Current Session Severity
platform                5                       5
0(emergencies)          1(alerts)       2(critical)
3(errors)               4(warnings)     5(notifications)
6(information)          7(debugging)
xxx-LOW#

Hello Carl,
What version of code are you running on your Nexus 7k?
The expected behavior is:
"When a hardware issue occurs, syslog messages are sent to all VDCs."
http://www.cisco.com/en/US/docs/switches/datacenter/sw/nx-os/virtual_device_context/configuration/guide/vdc_mgmt.html#wp1170241
Dave

Dell Servers with Nexus 7000 + Nexus 2000 extenders

<< Original post by smunzani. Answered by Robert. Moving from Document section to Discussions>>
Team,
I would like to use some of the existing Dell Servers for new network design of Nexus 7000 + Nexus 2000 extenders. What are my options for FEC to the hosts? All references of M81KR I found on CCO are related to UCS product only.
What's best option for following setup?
N7K(Aggregation Layer) -- N2K(Extenders) -- Dell servers
Need 10G to the servers due to dense population of the VMs. The customer is not up for dumping recently purchased dell boxes in favor of UCS. Customer VMware license is Enterprise Edition.
Thanks in advance.

To answer your question, the M81KR-VIC is a Mezz card for UCS blades only. For Cisco rack there is a PCIe version which is called the P81. These are both made for Cisco servers only due to the integration with server management and virtual interface functionality.
http://www.cisco.com/en/US/prod/collateral/ps10265/ps10493/data_sheet_c78-558230.html
More information on it here:
Regards,
Robert

Ask the Expert: Basic Introduction and Troubleshooting on Cisco Nexus 7000 NX-OS Virtual Device Context

With Vignesh R. P.
Welcome to the Cisco Support Community Ask the Expert conversation.This is an opportunity to learn and ask questions of Cisco expert Vignesh R. P. about the Cisco® Nexus 7000 Series Switches and support for the Cisco NX-OS Software platform .
The Cisco® Nexus 7000 Series Switches introduce support for the Cisco NX-OS Software platform, a new class of operating system designed for data centers. Based on the Cisco MDS 9000 SAN-OS platform, Cisco NX-OS introduces support for virtual device contexts (VDCs), which allows the switches to be virtualized at the device level. Each configured VDC presents itself as a unique device to connected users within the framework of that physical switch. The VDC runs as a separate logical entity within the switch, maintaining its own unique set of running software processes, having its own configuration, and being managed by a separate administrator.
Vignesh R. P. is a customer support engineer in the Cisco High Touch Technical Support center in Bangalore, India, supporting Cisco's major service provider customers in routing and MPLS technologies. His areas of expertise include routing, switching, and MPLS. Previously at Cisco he worked as a network consulting engineer for enterprise customers. He has been in the networking industry for 8 years and holds CCIE certification in the Routing & Switching and Service Provider tracks.
Remember to use the rating system to let Vignesh know if you have received an adequate response.
Vignesh might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Data Center sub-community discussion forum shortly after the event. This event lasts through through January 18, 2013. Visit this forum often to view responses to your questions and the questions of other community members.

Hi Vignesh
Is there is any limitation to connect a N2K directly to the N7K?
if i have a an F2 card 10G and another F2 card 1G and i want to creat 3 VDC'S
VDC1=DC-Core
VDC2=Aggregation
VDC3=Campus core
do we need to add a link between the different VDC's
thanks

LMS 4.2.2 Interface utilisation on Nexus 7000

Hi All,
I'm trying to poll some interfaces for their utilization on a nexus 7000 through LMS 4.2.2.
When I create a poller fot the specific instances, the LMS recognises the instances, but after activating the poller I get the error "No Such Instance - The specified instance is not available".
No info is displayed when I generate an interface utilization report for the specific nexus.
When I activate the automonitor for interface utilization, the interfaces on the nexus are polled.
On the cisco website there are some features listed which LMS does not support on the Nexus 7000, but polling is not in that list (neither in the supported feature list).
Any tips?
Thanks for your help.
Joris

Any Idea..??

Nexus 7000 vPC modification - avoiding type1 inconsistencies

Similar Messages

Maybe you are looking for