Two identifiers with different jobs
Every device in the fabric carries two identifiers, and mixing them up is a common source of confusion. The system IP names the device. The site ID names the place the device is in. Interface addresses, which change with each provider, name neither of these. In the lab, BR-01 has system IP 10.255.2.1 and site ID 101, BR-02 has 10.255.2.2 and 102, HUB-01 has 10.255.1.1 and 10, and HUB-02 has 10.255.1.2 and 20. The site IDs are teaching examples, not a rule.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
| Device | System IP | Site ID | Role |
|---|---|---|---|
| Manager | 10.255.0.10 | example | Management and monitoring |
| CTRL-01 (Controller) | 10.255.0.11 | example | Control plane |
| VAL-01 (Validator) | 10.255.0.12 | example | Device discovery and authentication |
| HUB-01 (WAN Edge) | 10.255.1.1 | 10 | Hub |
| HUB-02 (WAN Edge) | 10.255.1.2 | 20 | Hub |
| BR-01 (WAN Edge) | 10.255.2.1 | 101 | Branch |
| BR-02 (WAN Edge) | 10.255.2.2 | 102 | Branch |
What the system IP is used for
- Identity in OMP. Each route and TLOC an edge advertises is tied to its system IP as the originator, so the Controller and other edges know where it came from.
- The first part of a TLOC. A TLOC is the system IP plus a colour and an encapsulation, as the TLOC lesson explains. One system IP, several TLOCs.
- Router ID for fabric protocols. It is the device's ID in the control plane and in places such as BFD session lists, where it shows as the peer.
- A stable name for monitoring. The Manager lists devices by it, so it should not change when a provider changes the WAN address.
Because it names the device and not an interface, it stays the same when a link is added, re-addressed or replaced. That stability is the reason for having it. It is not an address on any subnet of the underlay, so picking one that falls in a range already used by the transport networks is legal but confusing; many designs keep a block for system IPs, as the 10.255.0.0/16 range does in this course's lab.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
What the site ID is used for
The site ID groups devices by location, and policy uses it. A control policy can say which sites see which routes, and a topology such as hub-and-spoke is written in terms of site lists. It is a number, so a clear scheme helps: one range for hubs, one for branches, one for data centres, for example. The ranges in this course are examples; check the limits and any reserved values for your release before choosing yours.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Two properties matter for design. Devices at the same location share a site ID. And the Controller uses the site ID to avoid sending a router its own site's routes back, so giving two different locations the same ID can hide routes between them.
Where the identifiers are configured
On small screens, swipe sideways or focus the diagram and use the arrow keys.
system
system-ip 10.255.2.1
site-id 101
organization-name LAB-EXAMPLE
sp-organization-name LAB-EXAMPLE
!
sdwan
...Fragment of an IOS XE SD-WAN configuration for BR-01, shortened, with a placeholder organisation name. Most networks push these settings from a Manager template or configuration group, and the exact keywords can differ by release, so check yours.
BR-01#show sdwan control personality vedge organization-name LAB-EXAMPLE system-ip 10.255.2.1 site-id 101 ...
BR-01#show sdwan omp peers PEER TYPE DOMAIN ID OVERLAY ID SITE ID STATE 10.255.0.11 vsmart 1 1 1 up
Verify identity and reachability separately
An up BFD session supports liveness of that tunnel path. Service-VPN applications require their own forwarding checks. A failed underlay ping to an unadvertised identity is not, by itself, a tunnel-failure test. If the same address is deliberately assigned to a management loopback in a service VPN, test it in that VPN and check its return route and policy.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
show sdwan bfd sessionsRead-only IOS XE Catalyst SD-WAN check: match the intended remote system IP and local/remote colours before reading the session state. One up session does not describe every transport or application.
For a service that still fails, verify the actual destination prefix in the intended service VPN, the return path and the applied policy; test from the intended client or source. Keep the existing local-properties identity check separate from this forwarding check. The examples use IOS XE Catalyst SD-WAN command style; exact fields depend on the selected platform and release. See Cisco's SD-WAN design guide for system identity, service-VPN loopbacks and BFD path monitoring.
Planning checklist
- Reserve a block for system IPs and keep a list of every one assigned, including controllers.
- Pick a site ID scheme by role or region and write it down before the first device is onboarded.
- Give each location one site ID; give devices at that location the same one.
- Avoid reusing a system IP from a retired device until it is removed from the Manager.
- Check your release's guide for the allowed values before settling the scheme.
Learn more: TLOC Components and Transport ReachabilityOrganization Name and Certificate DomainOMP Peers and Exchanges
Mistakes with identity
- Trying to ping the system IP across the underlay and concluding the router is down when it does not answer. It is an identity, not a transport address.
- Reusing one system IP on a replacement router while the old entry is still in the Manager, which causes conflicts.
- Giving each branch router in a redundant pair a different site ID. Policies written per site then treat one location as two.
- Giving two sites the same ID by copying a template, so that routes between them are suppressed.
Test yourself on identity
BR-01 has two WAN interfaces and system IP 10.255.2.1. A colleague asks which of its interface addresses is the system IP. What is the right answer?
A branch has a redundant pair of WAN Edges. How should they be numbered?
An underlay ping to BR-01's system IP 10.255.2.1 fails. That identity was not advertised into the underlay, and the intended BFD session is up. What can you conclude?