Ivan --
To echo was Kostia asked -- can you provide the error? I was the creator of the sandbox and have probably reserved it ~150 times since it went live.
The error that you're receiving around licensing is expected. DCNM has some demo licensing that we're utilizing for this sandbox and you should have full functionality in the sandbox even when it says you're out of compliance.
Now -- the lack of synch is another issue. If the DevNet_Fabric is discovered correctly (from the topology view, the switches will be grey, but the interconnect lines will be green; from the tabular view each device will show as being "ok"), DCNM has found the backing topology (instantiated inside of CML2), which is required. DCNM uses the serial numbers of the devices as the "key" for the database, and those serials change with every instance reserved, so DCNM loses itself for a second until everything comes back online and then it just assumes that things have changed. A by-product of this that we must do a "re-synch" to reconcile the state of the devices against what is stored within the DCNM database. This is why the devices are grey within the topology view, because the state is unknown.
If you're performing a resynch -- and the devices come back as "red" or out of synch -- you can figure out what is going on by clicking on "save and deploy" in the upper right hand corner of the topology view. DCNM will perform a deep synch and compare against the applied configuration on each switch. This may take several minutes -- but will return a window showing what needs to be changed within each device to make it "compliant" with the database config. I have a hunch that it is out of compliance with four lines. If you click the link under the "4 lines" on each device -- it will show that the default route for the mgmt VRF needs to be removed. This happens every now and then within the reservations -- and I've not been able to pinpoint why (I've worked with TMEs and we haven't isolated the case since we're not using DCNM as it should have been used, since we're changing the devices on the fly).
If this is indeed the case, you have two options depending on what you'd like to do. One causes the devices to conform to the config database, the other causes the database to conform to the devices.
(a) You can complete the save and deploy action and remove the 0/0 route. This will cause the devices to remove the route, meaning that you can't access the devices directly from your VPN workstation, only the jumphost in the sandbox.
(b) I have published a repository for sample code that will accompany the learning labs that I'm writing. This has a fix for this issue and will push new "policy" to DCNM, which will add the 0/0 route to the config database and cause the devices to show up in synch.
If you choose (b) -- the process is as follows:
1. Clone the repository found at https://github.com/CiscoDevNet/dcnm-labs-sample-code
git clone https://github.com/CiscoDevNet/dcnm-labs-sample-code
2. Move to the "ansible" directory within the clone repo
cd ansible
3. Create a python virtual environment
python3 -m venv venv
4. Activate the virtual environment (will vary based on OS -- providing for MacOS or Linux)
source venv/bin/activate
5. Install the requirements via pip
pip install -r requirements.txt
6. Move to the "dcnm-00_setup" folder
cd dcnm-00_setup
7. Run the Ansible playbook to create a template for the mgmt VRF 0/0 route and deploy it as policy to the switches (-v on the command is optional)
ansible-playbook fix_default.yaml -v
This will cause DCNM to track the 0/0 route on the management VRF and bring the fabric into synch.
This process will be formally documented as a setup Learning Lab when I finish writing the rest of the bits on Ansible and Terraform.
Please let me know if the above steps don't work for you.
Thanks!
q.
