Cisco VXLAN troubleshooting

ERROR after you configure EVPN

No VLAN id configured, unable to generate auto RD

This is because your NVE interface is down. Shutdown your NVE loopback and NVE interface, then unshut your loopback followed by NVE interface.

Border leaf receiving advertisement from external router and advertising to spine. Spine not advertising to other leafs. After review of the bgp l2vpn evpn routing table, its indicates “Path type: internal, path is invalid(no RMAC or L3VNI), no labeled nexthop”.

Why is this happening? Well because you don’t have the L3VNI configured properly. On the Border Leaf, verify that you have the L3VNI VLAN defined, the vni assigned to the VLAN and the interface VLAN defined with vrf and ip forward.


vlan 2500
vn-segment 50000

vrf context PROD
vni 50000
rd auto
address-family ipv4 unicast
route-target both auto
route-target both auto evpn
address-family ipv6 unicast
route-target both auto
route-target both auto evpn

interface Vlan2500
description L3VNI-SVI
no shutdown
mtu 9216
vrf member PROD
no ip redirects
ip forward
no ipv6 redirects

interface nve1
no shutdown
host-reachability protocol bgp
source-interface loopback1
member vni 50000 associate-vrf


If your wondering why you can’t get the nodes past “QUEUED” in CML, its because the images aren’t loaded.

  1. make sure your refplat-xxx-fcs file is mounted under CD/DVD drive
  2. Log in with sysadmin to port ip:9090
  3. Open up terminal and type in sudo /usr/local/bin/

How to configure appliance mode on AWS Transit Gateway

In order to configure the TGW attachment in appliance mode you must perform this from the AWS CLI. Go to the IAM role and create an access key and record your secret key. Then configure your AWS CLI client and use these keys to be able to access the AWS CLI. When in the AWS CLI, enter the following:

aws ec2 modify-transit-gateway-vpc-attachment --options "ApplianceModeSupport=enable" --transit-gateway-attachment-id <YOUR TGW ATTACHMENT HERE> --region <YOUR REGION HERE>

Replace <xxx> with actuals.

Port Tracking aka Fabric-Track in Cisco ACI

Port-Tracking is a simple on/off fabric-wide best practice configuration in the Cisco ACI Fabric.

Why would you want to enable this?

Reason 1 – In the event all uplinks from leaf to spine are down from some type of uplink failure, port-tracking will shut down all downlinks for a specified period of time. By default, all ports continue to operate even though the switch loses fabric connectivity. As a result, dual homed servers and routed connections continue to operate and blackhole traffic.

Reason 2 – During code upgrades, after a switch reboots, downlinks ports become operational before switch is re-joined to the fabric, and may incur packet loss. Port-Tracking ensures ports stay down usually until switch is properly recognized by the fabric and then properly enables the downlink ports.

A bug CSCvs10395 has been released for Port-tracking in January 2020 where if a failure of a REST call between the leaf switch and internal leaf switch REST server fails (rare) it will bring down all of the downlinks for the specified period of time. The switch will recover but an outage on all downlinks will be experienced.

Remediation step – disable port-tracking if in affected release or upgrade to 4.2(3j) or later.