CloudLabBox
Try the free demo

Cisco NX-OS data centre lab 13 of 15

Troubleshooting a broken Nexus pod

A change window went badly and tenants are down. Work from symptoms to causes through six layered faults: a host in the wrong VLAN, two OSPF adjacencies, an iBGP session, a route that hides another and a one-way path.

Run this lab

It needs Lite: its 4 nodes are set to 5 vCPU and 7,680 MB in total. That fits the free demo too.

In your workspace: Shared, then Cisco Nexus NX-OS data centre guided labs, then 13 - Troubleshooting a broken Nexus pod

Try it free for 30 minutesRun it on Lite from £3 a day

The free demo needs no card and no email. Every lab plan includes every guided lab.

Level
Advanced
Time
About 75 minutes
Nodes need
5 vCPU, 7,680 MB
Smallest plan
Lite

The scenario

It's Monday morning at Ashgrove, and last night's change on N1 went badly. The engineer who did it left a note: "tidied up some MTUs and static routes, moved a port, might have touched BGP". Tenants in VLAN 10 can't reach anything. R1 and R2 weren't touched, and their configuration is correct: every fault is on N1.

This is how the pod should look:

ItemValue
H110.10.10.11/24 in VLAN 10 on Ethernet1/5, gateway 10.10.10.1 (N1's Vlan10)
OSPF to R1Area 0 on Ethernet1/1, 10.1.1.0/30, MTU 1500 on both ends
OSPF to R2Area 10, a stub area, on Ethernet1/2, 10.1.2.0/30
iBGP to R1AS 65000 between loopbacks, 10.255.0.1 and 10.255.0.11
N1 advertises10.10.10.0/24 into BGP
R1 advertises203.0.113.0/24 into BGP (its loopback1, 203.0.113.1)
R2Loopback10, 10.60.1.1/24

The goal: H1 reaches its gateway, then 10.60.1.1 and 203.0.113.1.

What you’ll practise

  • Work a fault from the bottom layer upwards
  • Find OSPF faults by reading neighbour state and interface settings
  • Tell an iBGP session that can't start from one that won't carry routes
  • Compare the RIB with BGP to find a route that wins wrongly
  • Prove the return path as well as the forward path

The tasks

  1. Start the lab
  2. Set your method
  3. H1 can't reach its gateway
  4. OSPF has lost both neighbours
  5. The iBGP session won't start
  6. BGP has the route, but traffic fails
  7. One-way traffic

The Lab Tasks pane has the scenario, these tasks, the checks to run, hints and the full solution.

Topology and devices

The network as it opens in EVE-NG, drawn from the lab’s own canvas, and the image each node runs.

Topology of Troubleshooting a broken Nexus pod4 nodes, 3 links. Every link is listed as text below the diagram.N1R1R2H1e5eth0e1Gi0/0e2Gi0/0
4 nodes, with the interface names each link uses.
Every link, as text
  • N1 e1 to R1 Gi0/0
  • N1 e2 to R2 Gi0/0
  • N1 e5 to H1 eth0
Nodes in Troubleshooting a broken Nexus pod, with the image each runs and the vCPU and RAM it’s set to
NodeDeviceImage in Add NodeSet to
N1Cisco Nexus 9000vnxosv9k-9300v-9.3.102 vCPU, 6,144 MB
R1Cisco IOSvvios-adventerprisek9-m.SPA.159-3.M61 vCPU, 512 MB
R2Cisco IOSvvios-adventerprisek9-m.SPA.159-3.M61 vCPU, 512 MB
H1Alpine Linuxclbalpinebase-alpine-base-3-20-31 vCPU, 512 MB

How to open this lab

  1. Sign in to your workspace at lab.cloudlabbox.com.

  2. In File Manager, open Shared, then the folder Cisco Nexus NX-OS data centre guided labs.

  3. Open 13 - Troubleshooting a broken Nexus pod and start its nodes, then open Lab Tasks for the scenario and the steps.

The lab is read-only. You can start the nodes and configure the devices, but changes to the topology can’t be saved. To change it, rebuild it in your own folder.

More Cisco NX-OS data centre labs

All Cisco NX-OS data centre labs

Related labs in other courses

CloudLabBox is independent of Cisco. The lab follows exam topics and isn’t vendor training material; vendor names identify the exams and the images in the workspace.