One of the first steps in building your ACI Fabric is to go through Fabric Discovery. While Fabric Discovery is usually a straightforward process, there are various issues that may prevent you from discovering an ACI switch. This article will cover possible reasons for not seeing the first leaf switch entry under Fabric > Inventory > Fabric Membership
Go through the initial setup script of APIC1
APIC1, Spines, and Leaves are all running the same ACI version
The version can vary a little; however, its best to have the same exact version to be 100% sure.
Ensure that transceivers used are supported for the switch hardware and current version (check Transceiver Matrix here)
Configured CIMC IP address for the APIC Controllers (Guide)
APIC1 connected to at least 1 leaf switch
Part I: Checking CIMC Configurations
Some CIMC settings are crucial for fabric discovery to function properly. While these settings are usually set to the proper values from the factory, sometimes this is not the case. Follow these steps to confirm proper CIMC settings.
1. Login to the CIMC GUI by typing its ip address on an internet browser
2. Navigate to Admin > Network > Network Settings and confirm that the "NIC Mode" is set to "Dedicated"
Fabric Discovery relies heavily on the exchange and comparison of LLDP information. Go through the below steps to make sure that LLDP is working correctly and each device has the correct information.
1. An APIC may be connected up to two different leaves; however, they run in an active/standby mode. The APIC will only attempt to discover the leaf that is connected to its active interface. The troubleshooting effort should therefore be focused on the leaf connected to the active interface. The below command can be run in order to find out which leaf is active.
apic1# cat /proc/net/bonding/bond0 | grep Active Currently Active Slave: eth2-2
From the above output, we are able to tell that the active interface is the eth2-2. Therefore, we should focus on the leaf that is connected to eth2-2.
2. Now, we are ready to start checking the lldp information. On the active leaf, copy/paste the following command:
If you do not see any output at all OR if you do not see any output for the leaf interface connected to APIC1, then you are good to move on to Part III.
Below are the possible wiringIssues output and a brief description on what it signifies:
Adjacent node belongs to a different fabric
APIC UUID mismatch (duplicate APIC ID)
- Leaf to Leaf, Spine to non-leaf, Leaf fabric port to non-spine etc.
Adjacent node is not part of fabric
No LLDP adjacency on fabric port (normal if not connected)
Mismatch of infra-vlan value
Most of the above possible output for wiringIssues are self explanatory. The most commonly hit output from above is "infra-vlan-mismatch." See Resolving Infra-Vlan Mismatch section to correct this issue.
Resolving Infra-VLAN Mismatch
Infra-VLAN mismatch indicates that the two devices are advertising a different infra-vlan between each other. This is often caused by a non properly wiped switch. In order to remedy an infra-vlan-mismatch issue, perform the following:
Physically disconnect all undiscovered leaf or spine switches from the APIC and any other leaf or spine switches
Login to the CLI of the undiscovered leaf switch and clean the switch by running the command "setup-clean-config.sh"
After the command completes, run vsh -c "reload"
Repeat steps #2 and #3 for other undiscovered leaf or spine switch
After all the undiscovered switches have been cleaned and reloaded, physically connect back the leaf/spine switches to the fabric
Part III: Check for issues with APIC DHCP
In order for a entry for the leaf switch to show up under the Fabric Membership folder, the APIC needs to properly process the DHCP Discover message that the leaf switch sends. There is a commonly hit bug (CSCvf12024) for the APIC DHCP that will prevent the above behavior. In order to check if you are running into this issue, run this command on APIC1 CLI:
grep "No subnet declaration for bond0" /var/log/dme/log/dhcpd.bin.log
5402||18-01-22 23:06:12.890+00:00||dhcp||ERROR||||ISC dhcpd: No subnet declaration for bond0. (no IPv4 addresses).||../svc/dhcpd/src/gen/ifc/beh/imp/./DhcpdSvc.cc||53
If you see an output similar to above, you are most likely hitting this bug. Apply the workaround by running this command on APIC1 CLI:
acidiag restart dhcpd
This article covers the most commonly hit issues that prevents the first leaf from being discovered. If the first leaf is still not discovered after following the above troubleshooting steps, open an ACI TAC case and they will be more than happy to assist! I hope the article helped.
Hi We have a Nexus5648 running on 7.3(3)N1(1) and a few Nexus2348 switches have FEX uplinks to the N5K in production. I am planning to add one more new Nexus 2348 to the Nexus 5648 via FEX. Just waned to confirm if production outage is exp...
Hi, Can someone clear me the below questions regarding Standard contracts and Taboo contracts : 1) As i get tell now that when i create a standard contract filters, i can choose actions at subject for filters (deny or permit)Based on this ...
Hello,I am facing a weird situation with a thin client (HP) T630 that does not connect to a FEX N2K-2348UPQ, these clients have fiber(1gig) NIC cards. HP has a similar model T620 which connects without any issues. These connections work fine in our ...
I am trying to understand how exact ACI DHCP relay works. After reading the ACI DHCP relay technote, I still have questions.
So I did the following tests, with dhcp_server in epg-A (tn-A, app-A, ctx-A, BD-A, subnet-[A]), and dhcp_client ...