Hi,   Apologies but I don't want my previous answer to be taken literally wherein each leaf has different VNI mapping for the same vlan and expect it to communicate seamlessly. The point I was trying to make is how scalable the fabric can be without having an absolute dependency of a 4k vlan limit at the leaf. The use of different VNI will give you the boundaries/separation/segments as you desire from your design. This bog can be a good starter https://blogs.cisco.com/datacenter/digging-deeper-into-vxlan   -Raj   ... View more

The overall utilization is never an absolute real time view of the traffic on the wire and can lead to underestimating the actual traffic especially when output discards are seen. 10gig line rate will dequeue packets at a much higher clocking rate and if lets say you are bursting at 1.1 gig/sec rate, then that will be easily dequeued on a 10gig port without using any buffers. Buffers typically only come into play when packets wait to be put on the wire. Both 10gig and 1 gig will use the same general port buffers. The best solution as you have already found out is going to be using 10gig port. If you change port buffers and create more depth for packets to stay in the switch longer, you may have reduced drops or no drops depending on the burst and is not a guaranteed solution. ... View more

It is very likely that the reason for the error is due to atomic update which is enabled by default. Check this link if you are not familiar with atomic update- https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/security/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_Security_Configuration_Guide_7x/b_Cisco_Nexus_9000_Series_NX-OS_Security_Configuration_Guide_7x_chapter_01001.html#concept_945210FB9986499285C6A00065105AC9   Snippet below- An atomic update requires that an I/O module that receives an ACL update has enough available resources to store each updated ACL entry in addition to all pre-existing entries in the affected ACL. After the update occurs, the additional resources used for the update are freed. If the I/O module lacks the required resources, the device generates an error message and the ACL update to the I/O module fails.   Hope this helps.   -Raj     ... View more

Hi,   Your span config is set to sniff in both the Rx and Tx direction at the source and aggregating it and sending it to the sniffer.  Also the traffic rate show by show interface output is an average over a 30sec period which will never show the microburst traffic. Its highly likely that at regular intervals (sub second ) the aggregate traffic will be exceeding the line rate causing output discards. You will never see this if you just look at 30 second interval. This link about microburst detection can be helpful even though it is listed for catalyst- https://www.cisco.com/c/en/us/support/docs/lan-switching/switched-port-analyzer-span/116260-technote-wireshark-00.html   -Raj     ... View more

Peter,   Without knowing the existing qos configs and the additions you are making it would be difficult to provide a good explanation.  My understanding would be that the changes you are making does not fit into the 20% free space. Would be good to share existing config and new additions that is trowing this error.   -Raj   ... View more

Its generally not recommended to connect a switch to the Fex HIF port as it will cause the port to go error disabled due to BPDUgaurd config. You can circumvent it by configuring BPDUfilter under the interface but that is only recommended if your blade switch is single threaded else you could form a L2 loop and potentially cause a network meltdown. Be aware of your network design before taking this step. ... View more

If using Unicast mode then what you have will work to deploy OTV assuming the following - Routed Network between the Data Centre (Core) Could be any kind of Unicast Routed Network Also account for the additional 42byte OTV header which means that the interface MTU needs to be set accordingly If using multicast mode, the above mentioned plus also need to ensure that multicast routing is set correctly. There are some quick reference guides available but its not one size fits all approach. ... View more

The leaf switch imposes a limit on the number of vlans (4k). The fabric could allow you to have 16 million VNI segments depending on the scale of the deployment. If each leaf switch is configured with the same number of vlans say 1000 vlans and each is assigned to an unique VNI then in theory the number of VNI segments(in the fabric) = 1k x number of leaf switches. So we could very well scale beyond the 4k limit that traditional L2 design imposes and that is what can be achieved through the VXLAN design. Typical customer deployment tend to use the 1:1 mapping and stick to using the 4k limit at the fabric level but it can always and easily be exceeded as needed. Hope this helps. ... View more