Broadcom LiveLink : Receiving MAC flaps with Cisco Nexus 7000

We are migrating from using two Nortel 8600's running VRRP at the distribution to Cisco Nexus 7K's using HSRP. So we have a server connected to two 3750G switches which then connect to the Nexi (previously the 8600's). As soon as we connected the 3750's to the Nexus and moved the gateway to Nexus, LiveLink forces all the servers to alternate traffic between NIC1 and NIC2.
Since LiveLink is a teaming application, it uses virtual mac for nic1 and nic2, but the virtual mac associated with the IP address moves to the active link.
LiveLink is used to check the availability of the gateway by polling the gateway out of each interface using an ARP request.
The problem does not exhibit itself in our Cisco VSS environment, and with Nortel's VRRP. I tried running VRRP on the Nexus but no joy.
Anyone know of a bug that could cause this issue?

Unfortunately we have LiveLink enabled on most of our Windows servers in our data centers. One of my colleagues sent me this bug issue. I'm not sure if this is the cause, but it's worth trying. We will update the NxOs (currently on 5.1.1) next week and see if that fixes the problem.
•CSCtl85080
Symptom: Incomplete Address Resolution Protocol (ARP) entries are observed on a Cisco Nexus 7000 Series switch, along with partial packet loss and a memory leak.
Conditions: This symptom might be seen when ARP packets have a nonstandard size (that is, greater than 64 bytes).
Workaround: This issue is resolved in 5.1.3.

Similar Messages

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

FCoE with Cisco Nexus 5548 switches and VMware ESXi 4.1

Can someone share with me what needs to be setup on the Cisco Nexus side to work with VMware in the following scenario?
Two servers with two cards dual port FCoE cards with two ports connected to two Nexus 5548 switches that are clusterd together. We want to team the ports together on the VMware side using IP Hash so what should be done on the cisco side for this to work?
Thanks...

Andres,
The Cisco Road Map for the 5010 and 5020 doesn't include extending the current total (12) FEX capabities. The 5548 and 5596 will support more (16) per 55xxk, and with the 7K will support upto 32 FEX's.
Documentation has been spotty on this subject, because the term 5k indicates that all 5000 series switches will support extended FEX's which is not the case only the 55xx will support more than 12 FEX. Maybe in the future the terminology for the 5k series should be term 5000 series and 5500 series Nexus, there are several differences and advancements between the two series.

HP Servers NIC Teaming with Cisco Nexus 2000/5000

I have number of HP switches that will be connected to Cisco Nexus 2000/5000 switches.
In HP Servers, there are multiple options for NIC teaming. I like to connect each port in a NIC card to two different Nexus 2000 switches extension to Nexus 5000 switches. Nexus 5000 switches will be configured as VPC for clustering.
Wanted to know what whould be the best NIC teaming option from the followng HP Server's NIC Teaming options:
Automatic
802.3ad Dynamic with Fault Tolerence
Switch-assisted load balancing with Fault Tolerance (SLB)
Transmit load balancing with Fault Tolerance (TLB)
Transmit Load Balancing with Fault tolerance and preference order
Network Fault Tolerance Only (NFT)
Network Fault Tolerance with Preference Order

Nexus switches only support LACP (802.3ad) or ON mode. So, to match your server config with your switch, the first option is the best one to use. I think, SLB is a Microsoft propriety protocol.
HTH

Highest supported Brocade DCX firmware version to be interoperable with Cisco Nexus 5020

A Cisco Nexus 5020 (FCoE) switch is connected to Brocade DCX-B switch.
5020 is at latest firmware level of 5.0.2.N2.1
Brocade is at firmware level of 6.2.1b
If we need to upgrade brocade firmware, what is the maximum revision we can go to? Is there some documentation available for interoperability between the code levels of the two hardwares?

Hi Anwarul,
Please refer to "Table 7-10 Nexus InterOp Matrix" near the end of this link:
http://www.cisco.com/en/US/docs/switches/datacenter/mds9000/interoperability/matrix/Matrix7.html
Regards,
Ken

Error Received MAC Mavericks with CS5.1... FILE.OPEN will not work

I was just told CS5.1 is no longer supported by Adobe chat and to use this venu, so here it goes.
1) Operating System: MAC 10.9 Mavericks
2) Photoshop Version: 5.1
3) Problem:
      * FILE>OPEN selection from the dropdown menu in the upper left Task Bar of the Graphical User Interface will not work.
   - Problem Description:
      * Selecting FILE>OPEN presents an error box with the message "Could not complete your request because of a program error."
4) Trouble Shooting:
   - Fully reinstalled photoshop.
   - Fully updated photoshop.
   - Updated the computers version of Java (Java 7 Update 45).
   - Adjusted the security settings for the operating system.
5) Misc Information
   - I just purchased this Photoshop and registered with it a week ago.
What can I do?

Known problem with Mavericks. In view deselect CoverFlow option for say List.

Ask the Expert: Scaling Data Center Networks with Cisco FabricPath

With Hatim Badr and Iqbal Syed
Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about the Cisco FabricPath with Cisco technical support experts Hatim Badr and Iqbal Syed. Cisco FabricPath is a Cisco NX-OS Software innovation combining the plug-and-play simplicity of Ethernet with the reliability and scalability of Layer 3 routing. Cisco FabricPath uses many of the best characteristics of traditional Layer 2 and Layer 3 technologies, combining them into a new control-plane and data-plane implementation that combines the immediately operational "plug-and-play" deployment model of a bridged spanning-tree environment with the stability, re-convergence characteristics, and ability to use multiple parallel paths typical of a Layer 3 routed environment. The result is a scalable, flexible, and highly available Ethernet fabric suitable for even the most demanding data center environments. Using FabricPath, you can build highly scalable Layer 2 multipath networks without the Spanning Tree Protocol. Such networks are particularly suitable for large virtualization deployments, private clouds, and high-performance computing (HPC) environments.
This event will focus on technical support questions related to the benefits of Cisco FabricPath over STP or VPC based architectures, design options with FabricPath, migration to FabricPath from STP/VPC based networks and FabricPath design and implementation best practices.
Hatim Badr is a Solutions Architect for Cisco Advanced Services in Toronto, where he supports Cisco customers across Canada as a specialist in Data Center architecture, design, and optimization projects. He has more than 12 years of experience in the networking industry. He holds CCIE (#14847) in Routing & Switching, CCDP and Cisco Data Center certifications.
Iqbal Syed is a Technical Marketing Engineer for the Cisco Nexus 7000 Series of switches. He is responsible for product road-mapping and marketing the Nexus 7000 line of products with a focus on L2 technologies such as VPC & Cisco FabricPath and also helps customers with DC design and training. He also focuses on SP customers worldwide and helps promote N7K business within different SP segments. Syed has been with Cisco for more than 10 years, which includes experience in Cisco Advanced Services and the Cisco Technical Assistance Center. His experience ranges from reactive technical support to proactive engineering, design, and optimization. He holds CCIE (#24192) in Routing & Switching, CCDP, Cisco Data Center, and TOGAF (v9) certifications.
Remember to use the rating system to let Hatim and Iqbal know if you have received an adequate response.
They 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 Unified Computing discussion forum shortly after the event. This event lasts through Dec 7, 2012.. Visit this support forum often to view responses to your questions and the questions of other Cisco Support Community members.

Hi Sarah,
Thank you for your question.
Spanning Tree Protocol is used to build a loop-free topology. Although Spanning Tree Protocol serves a critical function in these Layer 2 networks, it is also frequently the cause of a variety of problems, both operational and architectural.
One important aspect of Spanning Tree Protocol behavior is its inability to use parallel forwarding paths. Spanning Tree Protocol forms a forwarding tree, rooted at a single device, along which all data-plane traffic must flow. The addition of parallel paths serves as a redundancy mechanism, but adding more than one such path has little benefit because Spanning Tree Protocol blocks any additional paths
In addition, rooting the forwarding path at a single device results in suboptimal forwarding paths, as shown below, Although a direct connection may exist, it cannot be used because only one active forwarding path is allowed.
Virtual PortChannel (vPC) technology partially mitigates the limitations of Spanning Tree Protocol. vPC allows a single Ethernet device to connect simultaneously to two discrete Cisco Nexus switches while treating these parallel connections as a single logical PortChannel interface. The result is active-active forwarding paths and the removal of Spanning Tree Protocol blocked links, delivering an effective way to use two parallel paths in the typical Layer 2 topologies used with Spanning Tree Protocol.
vPC provides several benefits over a standard Spanning Tree Protocol such as elimination of blocker ports and both vPC switches can behave as active default gateway for first-hop redundancy protocols such as Hot Standby Router Protocol (HSRP): that is, traffic can be routed by either vPC peer switch.
At the same time, however, many of the overall design constraints of a Spanning Tree Protocol network remain even when you deploy vPC such as
1.     Although vPC provides active-active forwarding, only two active parallel paths are possible.
2.     vPC offers no means by which VLANs can be extended, a critical limitation of traditional Spanning Tree Protocol designs.
With Cisco FabricPath, you can create a flexible Ethernet fabric that eliminates many of the constraints of Spanning Tree Protocol. At the control plane, Cisco FabricPath uses a Shortest-Path First (SPF) routing protocol to determine reachability and selects the best path or paths to any given destination in the Cisco FabricPath domain. In addition, the Cisco FabricPath data plane introduces capabilities that help ensure that the network remains stable, and it provides scalable, hardware-based learning and forwarding capabilities not bound by software or CPU capacity.
Benefits of deploying an Ethernet fabric based on Cisco FabricPath include:
• Simplicity, reducing operating expenses
– Cisco FabricPath is extremely simple to configure. In fact, the only necessary configuration consists of distinguishing the core ports, which link the switches, from the edge ports, where end devices are attached. There is no need to tune any parameter to get an optimal configuration, and switch addresses are assigned automatically.
– A single control protocol is used for unicast forwarding, multicast forwarding, and VLAN pruning. The Cisco FabricPath solution requires less combined configuration than an equivalent Spanning Tree Protocol-based network, further reducing the overall management cost.
– A device that does not support Cisco FabricPath can be attached redundantly to two separate Cisco FabricPath bridges with enhanced virtual PortChannel (vPC+) technology, providing an easy migration path. Just like vPC, vPC+ relies on PortChannel technology to provide multipathing and redundancy without resorting to Spanning Tree Protocol.
Scalability based on proven technology
– Cisco FabricPath uses a control protocol built on top of the powerful Intermediate System-to-Intermediate System (IS-IS) routing protocol, an industry standard that provides fast convergence and that has been proven to scale up to the largest service provider environments. Nevertheless, no specific knowledge of IS-IS is required in order to operate a Cisco FabricPath network.
– Loop prevention and mitigation is available in the data plane, helping ensure safe forwarding that cannot be matched by any transparent bridging technology. The Cisco FabricPath frames include a time-to-live (TTL) field similar to the one used in IP, and a Reverse Path Forwarding (RPF) check is also applied.
• Efficiency and high performance
– Because equal-cost multipath (ECMP) can be used the data plane, the network can use all the links available between any two devices. The first-generation hardware supporting Cisco FabricPath can perform 16-way ECMP, which, when combined with 16-port 10-Gbps port channels, represents a potential bandwidth of 2.56 terabits per second (Tbps) between switches.
– Frames are forwarded along the shortest path to their destination, reducing the latency of the exchanges between end stations compared to a spanning tree-based solution.
    – MAC addresses are learned selectively at the edge, allowing to scale the network beyond the limits of the MAC addr

Ask the Expert: Configuration, Design, and Troubleshooting of Cisco Nexus 1000

With Louis Watta
Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about design, configuration, and troubleshooting of Cisco Nexus 1000V Series Switches operating inside VMware ESXi and Hyper-V with Cisco expert Louis Watta. Cisco Nexus 1000V Series Switches deliver highly secure, multitenant services by adding virtualization intelligence to the data center network. With Cisco Nexus 1000V Series Switches, you can have a consistent networking feature set and provisioning process all the way from the virtual machine access layer to the core of the data center network infrastructure.
This is a continuation of the live Webcast.
Louis Watta is a technical leader in the services organization for Cisco. Watta's primary background is in data center technologies: servers (UNIX, Windows, Linux), switches (MDS, Brocade), storage arrays (EMC, NetApp, HP), network switches (Cisco Catalyst and Cisco Nexus), and enterprise service hypervisors (VMware ESX, Hyper-V, KVM, XEN). As a Technical Leader in Technical Services, Louis currently supports beta and early field trials (EFTs) on new Cisco software and hardware. He has more than 15 years of experience in a wide variety of data center applications and is interested in data center technologies oriented toward data center virtualization and orchestration. Prior to Cisco, Louis was a system administrator for GTE Government Systems. He has a bachelor of science degree in computer science from North Carolina State University. .
Remember to use the rating system to let Louis know if you have received an adequate response.
Louis might not be able to answer each question because of the volume expected during this event. Remember that you can continue the conversation on the Data Center community Unified Computing shortly after the event.
This event lasts through Friday, JUne 14, 2013. Visit this forum often to view responses to your questions and the questions of other Cisco Support Community members.
Webcast related links:
Slides
FAQ
Webcast Video Recording

Right now there is only a few features that are not supported on N1Kv on Hyper-V
They are VXLAN and QOS Fair Weighted Queuing. We are currently demoing VXLAN functionality at Microsoft TechEd Conference this week in New Orleans. So VXLAN support should be coming soon. I can't give you a specific timeline.
For Fair Weighted Queuing I'm not sure. In the VMware world we take advantage of NETIOC infrastructure. In the MS world they do not have a NETIOC infrastructure that we can use to create a similar feature.
Code base parity (as in VMware and Hyper-V VSMs running NXOS 5.x) will happen with the next major N1KV release for ESX.
Let me know if that doesn't answer your question.
thanks
louis

Cisco Nexus 7604

what AC power supplies are compatible with Cisco Nexus 7604 ( i mean part numbers ) ?
Also if i want to get STM cards for Cisco Nexus 7604 , what are the compatible Cards ( Part numbers ) ?

Oh sorry, see table-2 in this link:
http://www.cisco.com/c/en/us/products/collateral/routers/7604-router/product_data_sheet0900aecd8027cc3e.html

Interoperability between Cisco Nexus 5548UP and IBM FC3171

Dear Techies,
We have a Cisco Nexus Switch 5548UP already in our environment with DS-SFP-FC8G-SW installed. We are planning to procure IBM Pure Flex Chassis without FC Switch, since we already have Nexus that can provide this facility. But in order to connect IBM Flex with Cisco Nexus we are planning to use IBM FC3171 Switch with IBM 44X1964 Transceivers which will act as a Mediator/Pass Through Switch for connecting IBM and Cisco.
If any expert knows OR have used this scenario, please let me know since I am interested to know if it will work in this scenario or not.
Regards,
Farhan.

Dear prkrishn
I am working on the Data Center Solution between two Data Center, details underneath
DC 1 Site
1. 2 x DC Core Switch (Nexus 7009) - will be used for Servers, Application, IBM V7000, Database, etc.
2. 2 x Network Core Switch (Cisco 6509) - Handle Campus and Inter Building connection.
3. IBM V7000 (SAN)
DC 2 Site
1. 2 x DC Core Switch (Nexus 7009) - will be used for Servers, Application, IBM V7000, Database, etc.
2. 2 x Network Core Switch (Cisco 6509) - Handle Campus and Inter Building connection.
3. IBM V7000 (SAN)
With the above mention setup, can I configure FCIP between DC1 & DC2 using Nexus 7009? or I need FCIP capable Switch such as IBM SAN Switch (SAN06-BR), I was wondering if I can configure FCIP on Nexus 7009 DC Switch.
Hoping for your kind response at earliest.
Kind Regards,
Arnold

Nexus 7000 route leak from GRT (default VRF) to other VRF's

Hello
We have a Nexus 7000 infrastructure whereby we have had multiple VDC's and VRF's deployed. A requirement has now come about whereby one of these VRF's needs to be able to see our GRT (default VRF) so we need to leak the GRT routes into the VRF and vice versa.
I have been doing a lot of reading and I am happy with the how this works with inter-VRF route leaking but I seem to missing a few things in respect of how this works with the GRT.
I have also read on another forum that this is not supported. See link below.
https://supportforums.cisco.com/document/133711/vrf-configuration-and-verification-nexus-7000
Does anyone have experience of this? I can also see how this works in IOS and I have GNS3 and got this working.
We use BGP currently so we are able to use MP-BGP if required.
Any help would be very useful.

Hi,
In Table 14 of the Cisco Nexus 7000 Series NX-OS Verified Scalability Guide the verified limit is specified as 1000 per system i.e., across all VDCs for NX-OS release 5.2, 6.0 and 6.1.
There is a footnote associated with this number which states:
With each new VDC configured, the number of configurable VRFs per system is reduced by two as each VDC has a default VRF and management VRFs that are not removable. For example, with 8 configured VDCs on Cisco NX-OS Release 5.2, you can configure up to 984 VRFs per system (either all in one VDC or across VDCs).
Regards

High process in nexus 7000

Hello,
My name is Benjamin and I have problems with my Nexus 7000. It have high cpu process, I think that is not normal., what do you think?
# sh process cpu sort
PID    Runtime(ms) Invoked   uSecs 1Sec    Process
8259      1848785 56524183     32   27.6% in.dcos-telnetd
4717          231        96   2413   24.7% netstack
3536    402542882 64927941   6199    3.0% platform
4573    501774551 35371572 14185    1.0% xbar_driver_usd
4714          107        22   4871    1.0% arp
    1       179754   5381666     33    0.0% init
    2            2       300      9    0.0% kthreadd
    3         3342    559942      5    0.0% migration/0
    4      1936854 444724651      4    0.0% ksoftirqd/0
    5       143477   2220884     64    0.0% watchdog/0
    6         2042    349180      5    0.0% migration/1
    7      1452663 372943404      3    0.0% ksoftirqd/1
     1      111    111 11 1         1
    907878660006976000800707766999960776799987777777777678687773
    603310880008399000100504278989780308288903490180025795804831
100 **      ***    *** ** *    **** *    ***
90 **      *** * *** ** *    *##* *    ***             *
80 ** * * *** ** *#***#**    *##* *    ###* * *   * ** * *
70 ##*************##**##*******##*******###*******************
60 ###########################################################
50 ###########################################################
40 ###########################################################
30 ###########################################################*
20 ###########################################################*
10 ############################################################
    0....5....1....1....2....2....3....3....4....4....5....5....
              0    5    0    5    0    5    0    5    0    5
               CPU% per minute (last 60 minutes)
              * = maximum CPU%   # = average CPU%

I solved my issue, it was a bug problem:
Some of the telnet sessions do not get cleared with recursive telnet
Bug: CSCtk56774
Workaround: to issue "clear user admin" command
Regards

Ask the Expert: Different Flavors and Design with vPC on Cisco Nexus 5000 Series Switches

Welcome to the Cisco® Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about Cisco® NX-OS.
The biggest limitation to a classic port channel communication is that the port channel operates only between two devices. To overcome this limitation, Cisco NX-OS has a technology called virtual port channel (vPC). A pair of switches acting as a vPC peer endpoint looks like a single logical entity to port channel attached devices. The two devices that act as the logical port channel endpoint are actually two separate devices. This setup has the benefits of hardware redundancy combined with the benefits offered by a port channel, for example, loop management.
vPC technology is the main factor for success of Cisco Nexus® data center switches such as the Cisco Nexus 5000 Series, Nexus 7000 Series, and Nexus 2000 Series Switches.
This event is focused on discussing all possible types of vPC along-with best practices, failure scenarios, Cisco Technical Assistance Center (TAC) recommendations and troubleshooting
Vishal Mehta is a customer support engineer for the Cisco Data Center Server Virtualization Technical Assistance Center (TAC) team based in San Jose, California. He has been working in TAC for the past 3 years with a primary focus on data center technologies, such as the Cisco Nexus 5000 Series Switches, Cisco Unified Computing System™ (Cisco UCS®), Cisco Nexus 1000V Switch, and virtualization. He presented at Cisco Live in Orlando 2013 and will present at Cisco Live Milan 2014 (BRKCOM-3003, BRKDCT-3444, and LABDCT-2333). He holds a master’s degree from Rutgers University in electrical and computer engineering and has CCIE® certification (number 37139) in routing and switching, and service provider.
Nimit Pathak is a customer support engineer for the Cisco Data Center Server Virtualization TAC team based in San Jose, California, with primary focus on data center technologies, such as Cisco UCS, the Cisco Nexus 1000v Switch, and virtualization. Nimit holds a master's degree in electrical engineering from Bridgeport University, has CCNA® and CCNP® Nimit is also working on a Cisco data center CCIE® certification While also pursuing an MBA degree from Santa Clara University.
Remember to use the rating system to let Vishal and Nimit know if you have received an adequate response.
Because of the volume expected during this event, Vishal and Nimit might not be able to answer every question. Remember that you can continue the conversation in the Network Infrastructure Community, under the subcommunity LAN, Switching & Routing, shortly after the event. This event lasts through August 29, 2014. Visit this forum often to view responses to your questions and the questions of other Cisco Support Community members.

Hello Gustavo
Please see my responses to your questions:
Yes almost all routing protocols use Multicast to establish adjacencies. We are dealing with two different type of traffic –Control Plane and Data Plane.
Control Plane: To establish Routing adjacency, the first packet (hello) is punted to CPU. So in the case of triangle routed VPC topology as specified on the Operations Guide Link, multicast for routing adjacencies will work. The hellos packets will be exchanged across all 3 routers and adjacency will be formed over VPC links
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/operations/n5k_L3_w_vpc_5500platform.html#wp999181
Now for Data Plane we have two types of traffic – Unicast and Multicast.
The Unicast traffic will not have any forwarding issues, but because the Layer 3 ECMP and port channel run independent hash calculations there is a possibility that when the Layer 3 ECMP chooses N5k-1 as the Layer 3 next hop for a destination address while the port channel hashing chooses the physical link toward N5k-2. In this scenario,N5k-2 receives packets from R with the N5k-1 MAC as the destination MAC.
Sending traffic over the peer-link to the correct gateway is acceptable for data forwarding, but it is suboptimal because it makes traffic cross the peer link when the traffic could be routed directly.
For that topology, Multicast Traffic might have complete traffic loss due to the fact that when a PIM router is connected to Cisco Nexus 5500 Platform switches in a vPC topology, the PIM join messages are received only by one switch. The multicast data might be received by the other switch.
The Loop avoidance works little different across Nexus 5000 and Nexus 7000.
Similarity: For both products, loop avoidance is possible due to VSL bit
The VSL bit is set in the DBUS header internal to the Nexus.
It is not something that is set in the ethernet packet that can be identified. The VSL bit is set on the port asic for the port used for the vPC peer link, so if you have Nexus A and Nexus B configured for vPC and a packet leaves Nexus A towards Nexus B, Nexus B will set the VSL bit on the ingress port ASIC. This is not something that would traverse the peer link.
This mechanism is used for loop prevention within the chassis.
The idea being that if the port came in the peer link from the vPC peer, the system makes the assumption that the vPC peer would have forwarded this packet out the vPC-enabled port-channels towards the end device, so the egress vpc interface's port-asic will filter the packet on egress.
Differences: In Nexus 5000 when it has to do L3-to-L2 lookup for forwarding traffic, the VSL bit is cleared and so the traffic is not dropped as compared to Nexus 7000 and Nexus 3000.
It still does loop prevention but the L3-to-L2 lookup is different in Nexus 5000 and Nexus 7000.
For more details please see below presentation:
https://supportforums.cisco.com/sites/default/files/session_14-_nexus.pdf
DCI Scenario: If 2 pairs are of Nexus 5000 then separation of L3/L2 links is not needed.
But in most scenarios I have seen pair of Nexus 5000 with pair of Nexus 7000 over DCI or 2 pairs of Nexus 7000 over DCI. If Nexus 7000 are used then L3 and L2 links are required for sure as mentioned on above presentation link.
Let us know if you have further questions.
Thanks,
Vishal

I have a long-existing iPhone 4s with one apple id and started a job where I received a macbook with another apple id. how do i get my phone to sync with the Mac Pro and secondly how do i get my music on there?

i have a long-existing iPhone 4s with one apple id and started a job where I received a macbook with another apple id. how do i get my phone to sync with the Mac Pro and secondly how do i get my music on there?

No not bothered about sycing apps etc it is all about calendars and maybe notes. IN terms of how its done I just want it the easiest way and preferably so that if an entry is made on one calendar then it populates the other.
Thgius is beacuse I have my work diary on outlok, which I then link with my ical. I want to make sure that information is then shared with her.
Chris

Large amount of traffic with 152x mesh and mac-flap

We have just had a Mesh designed by an external company, and when we plugged it in we began have large numbers of mac-flap notification and more than 700mb of traffic sent across our data network.
Our setup includes 2 5508 controllers and 9 152x APs
3 APs (RAP) with their 5.8 antennas are within close proximity on a vertical pole pointing to the other 6 about 1000mtrs away in an arc. With their ethernet ports plugged into the same switch (native vlan 111) as WLC1 (which is LAG'd to two ports)
Vlan 111 for management of Mesh
Vlan 201 for WLAN
DHCP scope on DC on Vlan 100 (helper address from router)
Q, will the closeness of the 5.8 antennas cause any problems with mac-flap or is likely to be the controllers with their LAG connections or something totally different?
Thanks for any help

Andrew,
the proximity of the antennas shouldn't cause the mac-flap notification, nor should the LAG connection cause this. That's more and indication that the client is flopping between ports on the switch, which generally happens when you are not configured for LAG on the WLC, nor a port-channel on the switch.
the mac address that is being reported in the mac-flap. Is it a client or is it the MAPs?
If it's one of hte MAPs, you may want to check the antennas of the RAPs, since the MAPs sholdl stabliaze once AWPP has run and optimized the path to the network. If they are flapping I would look at possible RF or antenna issues.
HTH,
Steve
Please remember to rate helpful posts or to mark the question as answered so that it can be found later.

Broadcom LiveLink : Receiving MAC flaps with Cisco Nexus 7000

Similar Messages

Maybe you are looking for