Fabric inventory and rail identity
Compare stable endpoint identities with intended and observed connectivity.
help for the full list, or solutions for reference procedures. Simulated outputs do not validate your environment.Readable names help people find hardware, but names alone cannot prove where a cable lands. Keep the device identity, physical location, logical role, and observed peer as separate inventory fields.
Use an inventory that can be checked
The example below is a small fictional lab with two rails, amber and teal. The names are arbitrary; the fields are what make the record useful.
| Field | Example | Purpose |
|---|---|---|
| Device alias | lab-leaf-07 | Human-readable reference |
| Stable identity | Recorded switch GUID or serial | Survives renaming |
| Logical role | leaf, rail amber | Intended connectivity |
| Physical location | rack-03, U18 | Technician lookup |
| Local endpoint | port 12 | Exact connector |
| Intended peer | lab-node-04, adapter 1, port 1 | Design record |
| Observed peer | Discovered GUID and port | Live evidence |
A rail is a logical or physical grouping whose meaning comes from the design. A breakout lane number is not automatically a rail number.
Compare both endpoints
Resolve the local and remote identifiers before classifying a mismatch. An unexpected peer could be a mispatch, stale inventory, or an incorrectly mapped breakout connector.
Compare the intended rail and exact port at both ends. A connection can stay within a rail while still landing on the wrong endpoint. Conversely, whether a cross-rail link is invalid depends on the documented topology.
Preserve the evidence for a correction
Record capture time, both endpoint identities, expected peer, observed peer, and relevant link state. Update the physical record after a verified change so the next investigation does not rediscover the same discrepancy.
See topology and fabric troubleshooting.