I've tried the following topology & configuration below and I'm not seeing my IP IDs or Fragment Offsets differ between each hop:     Here are the ICMP Requests from N9K-3 to N9K-5 as they get fragmented:   ############################ #### SENDING N9K, N9K-3 #### ############################ These come out fragmented themselves as I'm sending with a size of 4000 and the SVI here has default MTU (1500): N9K-3# ethanalyzer local interface inband display-filter ip limit-c 0 Capturing on inband 2019-03-11 13:29:32.354015 172.23.2.1 -> 1.1.1.1 IP Fragmented IP protocol (proto=ICMP 0x01, off=0, ID=ee69) 2019-03-11 13:29:32.354104 172.23.2.1 -> 1.1.1.1 IP Fragmented IP protocol (proto=ICMP 0x01, off=1480, ID=ee69) 2019-03-11 13:29:32.354160 172.23.2.1 -> 1.1.1.1 ICMP Echo (ping) request ########################## ##### FRAGMENTING N9K #### ########################## N9K-4# ethanalyzer local interface inband display-filter ip limit-c 0 Original packet arriving fragmented as sent by N9K-3: Capturing on inband 2019-03-11 18:59:31.678237 172.23.2.1 -> 1.1.1.1 IP Fragmented IP protocol (proto=ICMP 0x01, off=0, ID=ee69) 2019-03-11 18:59:31.678309 172.23.2.1 -> 1.1.1.1 IP Fragmented IP protocol (proto=ICMP 0x01, off=1480, ID=ee69) 2019-03-11 18:59:31.678344 172.23.2.1 -> 1.1.1.1 ICMP Echo (ping) request Fragmenting further in order to send out of Tunnel2 (MTU of 1000): 2019-03-11 18:59:31.678991 172.23.2.1 -> 1.1.1.1 IP Fragmented IP protocol (proto=ICMP 0x01, off=0, ID=ee69) 2019-03-11 18:59:31.679228 172.23.2.1 -> 1.1.1.1 IP Fragmented IP protocol (proto=ICMP 0x01, off=976, ID=ee69) 2019-03-11 18:59:31.679298 172.23.2.1 -> 1.1.1.1 IP Fragmented IP protocol (proto=ICMP 0x01, off=1480, ID=ee69) 2019-03-11 18:59:31.679364 172.23.2.1 -> 1.1.1.1 IP Fragmented IP protocol (proto=ICMP 0x01, off=2456, ID=ee69) 2019-03-11 18:59:31.679446 172.23.2.1 -> 1.1.1.1 IP Fragmented IP protocol (proto=ICMP 0x01, off=2960, ID=ee69) 2019-03-11 18:59:31.679529 172.23.2.1 -> 1.1.1.1 ICMP Echo (ping) request ########################## ##### RECEIVING N9K-5 #### ########################## N9K-5# ethanalyzer local interface inband display-filter ip limit-c 0 Capturing on inband 2019-03-11 18:05:30.499740 172.23.2.1 -> 1.1.1.1 IP Fragmented IP protocol (proto=ICMP 0x01, off=0, ID=ee69) 2019-03-11 18:05:30.499925 172.23.2.1 -> 1.1.1.1 IP Fragmented IP protocol (proto=ICMP 0x01, off=976, ID=ee69) 2019-03-11 18:05:30.500004 172.23.2.1 -> 1.1.1.1 IP Fragmented IP protocol (proto=ICMP 0x01, off=1480, ID=ee69) 2019-03-11 18:05:30.500056 172.23.2.1 -> 1.1.1.1 IP Fragmented IP protocol (proto=ICMP 0x01, off=2456, ID=ee69) 2019-03-11 18:05:30.500153 172.23.2.1 -> 1.1.1.1 IP Fragmented IP protocol (proto=ICMP 0x01, off=2960, ID=ee69) 2019-03-11 18:05:30.500214 172.23.2.1 -> 1.1.1.1 ICMP Echo (ping) request Notice all offsets above line up with the second half of the "fragmenting N9Ks" output. I'll unicast you to get specific configurations / setup in the event something differs and I can gladly test again -- We can circle back to the forum with the "answer" at the end.   Thank you, ... View more

Hey Hans,   Have you checked out our Nexus 9000 TCAM Carving guide by chance? I think this will likely sort some of your questions.   There are no specific TCAM best practices between PACL vs. RACL aside from the ones listed in the document.  All deployments are different and one customer may need tons of RACL whereas you may not use RACL at all.   To answer your question -- That is correct; carving the  ing-ifacl region in TCAM will allow you to configure PACLs on L2 ports.   Hope that helps.     ... View more

Marcio,   Unfortunately, there is currently no support for MLD Snooping across any NX-OS platform. However, I've seen many customers deploy Dell's VxRail solution by simply allowing the L2 IPv6 traffic to flood on the VLAN without any issues.    Hope that helps. ... View more

Marcos,   PBR support for the Nexus 9300-EX series started with 7.0(3)I5(x). For a stable release that includes PBR support, I'd recommend 7.0(3)I7(5a). The I7 train is the proposed, upcoming long-lived release for the Nexus 9000 platform.   You can actually see this recommendation here:   " Customers with newer deployments and future upgrade plans are encouraged to look at Cisco NX-OS Release 7.0(3)I7(5a) and any later 7.0(3)I7(x) maintenance releases as primary candidates as they become available."   Here's the PBR Configuration Guide for 7.0(3)I7(x). I'd go over the Guidelines and Limitations as well. Hope that helps! ... View more

Hi there,   Those commands are for IOS devices such as Catalyst which is why they dont work on your Nexus devices as they are running NX-OS, not IOS.   If you want to view packets live on the CPU, save control plane captures as .pcaps and analyze in Wireshark later, etc, you can use Ethanalyzer.   Here's a quick guide written for the Nexus 7000 (same commands apply for the Nexus 3000) to get you started:   https://www.cisco.com/c/en/us/support/docs/switches/nexus-7000-series-switches/116136-trouble-ethanalyzer-nexus7000-00.html   Hope that helps, ... View more

Hey AM,   It looks like you have fairly constant STP Disputes on this switch which would explain the debugs regarding cist/msti root election. I would open a TAC case to have a Nexus engineer trace the source of the STP Disputes for you.   Spanning-tree Dispute s are triggered when the BPDU received from our connecting device is inferior (worse) however it has the Designated role and state as Learning and/or Forwarding. In simpler terms, there's another switch in your network that is claiming to be the STP root even though it has a higher STP priority.   Hope that helps. ... View more

Hey AM,   Are these constant syslogs or were you running debugs? Can you share the following:   show vpc role show run vpc show run spanning-tree show span vlan 1 show logging level spanning-tree show span det | i ieee|occur|exec|from show run int po1 show cdp neigh int po1 show logging log | i i stp | last 50 Thank you, ... View more

Hey Kashan,   What platform and what NX-OS version do you have? I can look into this with a few more specifics.         ... View more

Allyson,   Unfortunately, the Nexus 9000 series does not support Fabricpath and there is no roadmap to add this in. The Nexus 9000s are frequently deployed in a Spine/Leaf layer fashion using VXLAN BGP EVPN instead.   Hope that helps. ... View more

Hi there,   For end of support/end of life announcements on the Nexus 7010, you can visit this Website: https://www.cisco.com/c/en/us/support/switches/nexus-7000-10-slot-switch/model.html   Currently there are no announcements for the 6.2 release train.   Hope that helps. ... View more

Hi,   Unfortunately the Nexus 3000 series do not support SVI (interface VLAN) statistics in certain versions of code hence why the counter appears as zero in your outputs - This cannot be modified with any configuration also in these affected versions.   This behavior is documented in CSCve41919 - The SVI statistics capability was added on 7.0(3)I6(2), 7.0(3)I7(1) and the BU golden release of 7.0(3)I4(7).    Hope that helps!       ... View more

Hi,   The Cisco Recommended Release for the Nexus 5600 series is NX-OS  7.3(3)N1(1). I'd recommend you upgrade the chassis to this release train prior to putting into production.   Hope that helps!     ... View more