First, the essential ideas
- Control, data and management planes
- The control plane determines forwarding information; the data plane forwards packets using that information. The management plane configures and observes the system. Actual distribution of these functions depends on the architecture.
- Controller
- A controller provides coordinated management or control through software interfaces. Logical centralization does not require one physical server or mean that every user packet traverses that server.
- Northbound and southbound API
- An application programming interface, API, is a defined software interaction. Northbound interfaces connect applications with the controller; southbound interfaces connect the controller with managed devices. These are architectural relationships, not compass directions.
- Underlay and overlay
- The underlay supplies the underlying network reachability. An overlay creates logical connectivity over it, commonly using encapsulation. An overlay cannot bypass the need for an adequate underlying path.
- Fabric
- A fabric is a coordinated network architecture. In Cisco SD-Access, fabric commonly refers to the overlay across its routed underlay, with defined edge, border and control-plane roles. Not every fabric is the same product or topology.
- Intent and assurance
- Intent describes the desired outcome or policy. Assurance compares evidence with that desired outcome. A request being accepted is not the same as the intended behavior being verified.
- Loopback and source selection
- A router loopback is a logical interface useful as a stable address. Selecting it as the ping source tests the return path to that address, not just the directly connected transit subnet.
Treat the controller's policy request and the user's packet as two different journeys. One expresses and installs desired behavior; the other uses the forwarding state. A third journey brings observations back. Mixing them makes a dashboard seem more powerful than the actual network beneath it.
See the idea
Intent goes down; evidence comes back
A controller request, a device change and verified behavior are separate facts in one managed workflow.
Express the intent
The application uses a northbound interface to request or inspect controller-managed behavior. Acceptance alone is not completion.
What this model leaves out: This is a conceptual management pipeline, not user traffic or the two-router lab. No controller is instantiated, and a successful request does not prove forwarding.
Full visual explanation and references
An operations application communicates with a controller, which communicates with a managed router. Evidence returns through the same declared management relationships.
This is a conceptual management pipeline, not user traffic or the two-router lab. No controller is instantiated, and a successful request does not prove forwarding.
- Express the intent
The application uses a northbound interface to request or inspect controller-managed behavior. Acceptance alone is not completion.
www.cisco.com - Coordinate device state
The controller uses supported southbound mechanisms to interact with the router. User packets follow the data plane, not this management diagram.
www.cisco.com - Check returned evidence
Device observations and controller task details return to the operator. Separate endpoint tests are still needed to verify intended user behavior.
www.cisco.com
One idea at a time
Start with something familiar.
Write three questions beside the same change: what did we ask for, what did the devices install, and what did the test flow do? Use a different piece of evidence for each. This makes controller-based operation understandable without assuming the controller handles every packet.
Why learn this?
Automation can repeat a correct design consistently, but it can also distribute a wrong variable rapidly. Good operators learn both the software workflow and the forwarding fundamentals needed to recognize a wrong result.
An everyday comparison
A transit planner sets routes and schedules while vehicles move passengers. Reports from stations help check whether service matches the plan. The planning office is important, but passengers do not ride through the office.
What happens in a network
The controller coordinates intent and configuration; forwarding devices carry the traffic; telemetry and tests supply feedback. These relationships explain why a completed software request and a healthy user journey are not identical.
Where the comparison stopsA network's control functions may remain distributed among devices, and availability behavior depends on the product. The analogy does not prove that forwarding continues forever after every controller failure.
Follow one worked example
- Classify the request path.
An inventory application queries a controller northbound API. The controller communicates with managed devices through southbound mechanisms.
Why: Northbound and southbound describe the relationship to the controller, not a specific mandatory protocol.
- Classify the packet path.
A fabric edge encapsulates selected endpoint traffic toward another fabric location over reachable underlay addresses.
Why: The underlay transports the encapsulated packet; the controller is not automatically an inline hop.
- Classify the evidence.
A task result, installed route and endpoint test answer three separate questions. The small lab checks only the routed prerequisite path.
Why: Scope-correct evidence prevents a successful ping being misreported as successful overlay policy.
Your first small task
Sort these into intent, installed state or behavior: an approved policy request; a device's routing-table entry; a source-specific ping result. Then identify which item alone proves an application login works.
Show a hint
A packet can arrive at a server whose application denies the user. Keep transport evidence narrower than authorization.
Check the expected result
The request is intent, the route is installed state, and the ping is limited behavior. None alone proves an application login.
Pause and explain it in your own words
Must every user packet travel through the controller?
Show a hint
Separate the software control relationship from the data-forwarding path.
Show the explanation
No. Devices generally forward using installed state. The specific product determines control distribution and failure behavior, so neither universal inline forwarding nor indefinite controller independence should be assumed.
Short answer
What should you understand today?
Controller-based networking coordinates intent, configuration and evidence through software interfaces. Devices still forward traffic. An overlay supplies logical connectivity over a reachable underlay; a fabric combines specific roles and mechanisms. Controller success, underlay success and endpoint application success require different evidence.
Before you begin
Learning targets
- Review connected routes, static routes, router loopbacks and privileged EXEC mode.
- Use GNS3 2.2 with two separately entitled CSR1000v IOS XE 17.3 nodes, or the labeled paper alternative.
- Keep direct consoles available and the project disconnected from production, Cloud and NAT nodes.
- Explain automation's impact, benefits, risks and changed operational responsibilities.
- Compare traditional per-device management with controller-based management and API relationships.
- Describe control/data separation, underlay, overlay and fabric without conflating their roles.
- Build a small routed prerequisite path, fault one link, restore it and verify both source-specific directions.
Words you will meet
Open a word when you need its meaning. You do not need to memorize the whole list before reading.
Control, data and management planes
The control plane determines forwarding information; the data plane forwards packets using that information. The management plane configures and observes the system. Actual distribution of these functions depends on the architecture.
Controller
A controller provides coordinated management or control through software interfaces. Logical centralization does not require one physical server or mean that every user packet traverses that server.
Northbound and southbound API
An application programming interface, API, is a defined software interaction. Northbound interfaces connect applications with the controller; southbound interfaces connect the controller with managed devices. These are architectural relationships, not compass directions.
Underlay and overlay
The underlay supplies the underlying network reachability. An overlay creates logical connectivity over it, commonly using encapsulation. An overlay cannot bypass the need for an adequate underlying path.
Fabric
A fabric is a coordinated network architecture. In Cisco SD-Access, fabric commonly refers to the overlay across its routed underlay, with defined edge, border and control-plane roles. Not every fabric is the same product or topology.
Intent and assurance
Intent describes the desired outcome or policy. Assurance compares evidence with that desired outcome. A request being accepted is not the same as the intended behavior being verified.
Loopback and source selection
A router loopback is a logical interface useful as a stable address. Selecting it as the ping source tests the return path to that address, not just the directly connected transit subnet.
Automation changes repetition and responsibility
Automation can collect inventory, generate consistent configuration, apply approved changes and repeat tests across devices. It reduces repetitive typing but does not remove the need for correct source data, review, credentials, version control or rollback planning. A faulty template can enlarge the blast radius compared with one mistaken manual command. Begin with read-only collection, small scopes and measurable outcomes before expanding changes.
- Human responsibilities shift toward data quality, testing, permissions and exception handling.
- Automation impact is explicitly covered here for v1.1 objective 6.1.
Compare management approaches fairly
Traditional networks often configure and inspect each device through its own CLI or management interface. Control protocols can still operate automatically and distributedly; traditional does not mean every forwarding decision is manual. Controller-based management offers a coordinated inventory, policy view and programmable workflow. It adds dependencies such as controller availability, compatibility, credentials and task processing. Neither approach removes the need to understand the device state.
- Centralized policy does not guarantee atomic changes across all devices.
- Use the product's supported ownership model to avoid competing configuration writers.
Separate planes and API directions
The data plane performs forwarding; control functions establish the information used for that forwarding; management functions configure and observe. A controller may coordinate these functions without physically hosting every routing protocol. Northbound APIs expose controller capabilities to applications. Southbound mechanisms communicate with devices and may include model-driven interfaces or other supported protocols. REST is not inherently northbound, and OpenFlow is not mandatory in every SDN system.
- API direction is relative to the architectural role, not the method name.
- A response status must be interpreted with task and device evidence.
Underlay reachability supports overlay behavior
The underlay connects infrastructure locations using physical links and IP forwarding. The overlay adds logical connectivity, commonly by encapsulating an original packet or frame with headers that reach remote tunnel endpoints. More headers also require an appropriate MTU, the maximum packet size supported by the path. Basic reachability is necessary but not sufficient: endpoint mapping, segmentation, policy and packet-size handling must also work.
- A successful small ping does not validate large encapsulated packets.
- Do not repair an underlay outage by randomly changing overlay policy.
Fabric names carry architectural context
A fabric coordinates connectivity across defined roles. Cisco SD-Access includes fabric edges for endpoint attachment, control-plane nodes for mappings and borders for external connectivity. Other architectures may use different protocols and topology. Leaf-spine describes a physical connectivity pattern, not a universal synonym for every controller-managed campus. Overlay separation is also not encryption by itself.
- Name the exact product before asserting its control or failure behavior.
- This lesson describes fabrics but does not certify a complete fabric design.
Verify intent, state and behavior independently
Begin with the approved target and expected result. Inspect controller task state where a controller exists, then device state and the precise test flow. Preserve negative cases when the policy includes denial. Compare the same tests after rollback. The chapter owns v1.1 6.1, 6.2 and 6.3 instruction, including APIs and plane separation. Announced v2.0 5.3 receives partial controller and automation coverage, supplemented by later automation lessons.
- Current v1.1 remains applicable through 2 February 2027; v2.0 begins 3 February.
- An authored procedure and static validation are not a claim of observed device execution.
Real-world walkthrough
A completed policy task with a broken prerequisite path
In a fictional campus change, a policy workflow finishes but users across two fabric locations cannot communicate. A routed uplink was left administratively down during maintenance. The operator initially suspects the new overlay policy because that is the most recent dashboard event.
- Record the intended source, destination and policy, then separate task status from actual forwarding evidence.
- Check the infrastructure path and relevant interface states before editing the overlay.
- Compare the failed location's underlay reachability with the baseline and identify the administratively down link.
- Restore only the approved link state through the owning workflow, then verify infrastructure and endpoint tests.
- Keep the final report precise: the cause was a prerequisite path; the full overlay still needs its own evidence.
Guided GNS3 lab
Verify the routed prerequisite without inventing a fabric
Configure two loopback endpoints over one routed link, prove both source-specific paths, introduce one shutdown fault and restore it. This is a practical underlay prerequisite exercise, not controller or overlay configuration.
Addressing plan
| Device | Interface | Address | Purpose |
|---|---|---|---|
| R1 | GigabitEthernet1 | 192.0.2.1/30 | Transit link to R2. |
| R2 | GigabitEthernet1 | 192.0.2.2/30 | Transit link to R1. |
| R1 | Loopback0 | 10.55.0.1/32 | Stable source and destination for the prerequisite test. |
| R2 | Loopback0 | 10.55.0.2/32 | Remote test endpoint, not a configured VXLAN endpoint. |
Set up the lab
- Start from disposable nodes, verify image rights and save a stopped-project baseline.
- Map actual interfaces and record show version. These instructions require the CSR GigabitEthernet1 naming.
- Keep direct GNS3 consoles open; do not save the fault or connect to external networks.
- Without entitled images, trace routes and source selection on paper. A separately entitled CML equivalent requires port mapping and its own observations.
Configure the first infrastructure endpoint
In GNS3, right-click R1 and choose Console before typing. Use the fresh-node console and configure the transit address and loopback. Add an exact /32 route for the other loopback so the intended path is explicit.
enable
show version
configure terminal
interface GigabitEthernet1
ip address 192.0.2.1 255.255.255.252
no shutdown
interface Loopback0
ip address 10.55.0.1 255.255.255.255
exit
ip route 10.55.0.2 255.255.255.255 192.0.2.2
endWhat each command means
enable- Enter privileged EXEC on this authorized lab device; stop if access is not authorized.
show version- Record the actual platform and release.
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
interface GigabitEthernet1- Select the only transit link.
ip address 192.0.2.1 255.255.255.252- Assign R1's /30 transit address.
no shutdown- Enable the isolated transit link.
interface Loopback0- Create the stable logical endpoint.
ip address 10.55.0.1 255.255.255.255- Assign R1's /32 loopback.
exit- Return to global configuration.
ip route 10.55.0.2 255.255.255.255 192.0.2.2- Route the remote /32 through R2.
end- Return to privileged EXEC without saving or undoing the accepted changes.
- What you should see
- Expect accepted syntax; routing success still depends on R2 and the link.
- Why this step matters
- An exact destination route and source address keep the prerequisite test bounded.
Configure the reverse infrastructure path
In GNS3, right-click R2 and choose Console before typing. Configure the peer link and its loopback, including the route back to R1's selected source. A return route is necessary for the later sourced ping.
enable
show version
configure terminal
interface GigabitEthernet1
ip address 192.0.2.2 255.255.255.252
no shutdown
interface Loopback0
ip address 10.55.0.2 255.255.255.255
exit
ip route 10.55.0.1 255.255.255.255 192.0.2.1
endWhat each command means
enable- Enter privileged EXEC on this authorized lab device; stop if access is not authorized.
show version- Record R2's actual release.
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
interface GigabitEthernet1- Select the R1-facing transit port.
ip address 192.0.2.2 255.255.255.252- Assign the peer /30 address.
no shutdown- Enable the peer link.
interface Loopback0- Create R2's logical endpoint.
ip address 10.55.0.2 255.255.255.255- Assign R2's /32 loopback.
exit- Return to global configuration.
ip route 10.55.0.1 255.255.255.255 192.0.2.1- Install the return route toward R1's loopback.
end- Return to privileged EXEC without saving or undoing the accepted changes.
- What you should see
- Expect both routers to have their planned local and remote endpoint routes.
- Why this step matters
- The reverse path is part of the requirement, not an optional convenience.
Capture R1's baseline
In GNS3, right-click R1 and choose Console before typing. Inspect state before sending a bounded ping sourced from Loopback0. Do not substitute the default transit source and assume it tests the same route.
show ip interface brief
show ip route 10.55.0.2
ping 10.55.0.2 source Loopback0 repeat 3What each command means
show ip interface brief- Check the transit and loopback addresses and interface states.
show ip route 10.55.0.2- Inspect the installed remote endpoint route.
ping 10.55.0.2 source Loopback0 repeat 3- Test the exact loopback-to-loopback path.
- What you should see
- Expect up/up interfaces and replies after neighbor resolution; record actual observations.
- Why this step matters
- A sourced test checks the return route to the intended stable address.
Capture the reverse baseline
In GNS3, right-click R2 and choose Console before typing. Read its remote route and repeat the reverse test with R2's loopback selected as source. Stop if either baseline direction fails before introducing a fault.
show ip route 10.55.0.1
ping 10.55.0.1 source Loopback0 repeat 3What each command means
show ip route 10.55.0.1- Inspect R2's route back to R1.
ping 10.55.0.1 source Loopback0 repeat 3- Test the reverse sourced path.
- What you should see
- Expect reverse replies; neither result proves an overlay or user application.
- Why this step matters
- Two directions expose asymmetric routing assumptions before any planned fault.
Introduce one isolated link fault
In GNS3, right-click R1 and choose Console before typing. Shut only the transit interface in this disconnected project. Preserve the resulting interface and ping evidence without changing routes or loopbacks.
configure terminal
interface GigabitEthernet1
shutdown
end
show ip interface brief
ping 10.55.0.2 source Loopback0 repeat 3What each command means
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
interface GigabitEthernet1- Select the sole exercise transit link.
shutdown- Introduce the reversible administrative link fault.
end- Return to privileged EXEC without saving or undoing the accepted changes.
show ip interface brief- Record the administratively down transit state.
ping 10.55.0.2 source Loopback0 repeat 3- Repeat the original source-specific test.
- What you should see
- Expect the test to fail with the path down; retain actual output rather than inventing loss counts.
- Why this step matters
- The single known fault demonstrates a dependency that controller policy cannot wish away.
Restore the prerequisite and retest
In GNS3, right-click R1 and choose Console before typing. Apply the exact inverse and wait for link readiness. Inspect interface and route state before repeating the original sourced ping.
configure terminal
interface GigabitEthernet1
no shutdown
end
show ip interface brief
show ip route 10.55.0.2
ping 10.55.0.2 source Loopback0 repeat 3What each command means
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
interface GigabitEthernet1- Select the faulted interface only.
no shutdown- Restore the documented baseline administrative state.
end- Return to privileged EXEC without saving or undoing the accepted changes.
show ip interface brief- Check that the transit link has recovered.
show ip route 10.55.0.2- Check the installed endpoint route again.
ping 10.55.0.2 source Loopback0 repeat 3- Repeat the baseline path after repair.
- What you should see
- Expect restored state and replies; unresolved results require investigation, not a success claim.
- Why this step matters
- Repair is complete only when behavior matches the pre-fault requirement.
Verify reverse recovery and stop safely
In GNS3, right-click R2 and choose Console before typing. Repeat the reverse sourced test, then preserve the before/fault/repair notes. Stop both disposable nodes from GNS3; do not erase configuration or claim controller verification.
show ip route 10.55.0.1
ping 10.55.0.1 source Loopback0 repeat 3What each command means
show ip route 10.55.0.1- Confirm the reverse endpoint route remains installed.
ping 10.55.0.1 source Loopback0 repeat 3- Confirm reverse recovery after R1's repair.
- What you should see
- Expect the reverse baseline to recover. Controller, overlay and MTU tests remain unperformed.
- Why this step matters
- The final report must distinguish a recovered prerequisite from the complete architecture described.
Verify
- Record both releases, the single cable mapping and all four addresses.
- Require successful sourced baseline tests in both directions before faulting.
- Capture the exact administrative fault and the unchanged test destination and source.
- After repair, inspect route and interface state and repeat both directions.
- State explicitly that no controller task, VXLAN, LISP, segmentation or application result was measured.
Troubleshoot
- If direct peer reachability works but sourced loopback ping fails, inspect the return /32 route and selected source.
- If a command is rejected, stop and verify the declared platform and release; do not claim unsupported overlay features were tested.
- If the link remains down, inspect both mapped ports and GNS3 node state before changing routes.
- If a controller dashboard says success in a separate deployment, gather device and endpoint evidence rather than using this lab result as proof.
GNS3 does not provide Cisco images. A license or entitlement must permit the image in the selected environment; do not share or redistribute image files. Cisco Modeling Labs is an official alternative. Its supplied Cisco reference images are licensed for use within CML, not automatically for export to GNS3. An unlicensed learner must use the explicitly labeled paper alternative, not report simulated Cisco execution.
- Restore no shutdown on R1 GigabitEthernet1 and preserve both recovery tests.
- Stop the disposable project and retain the baseline snapshot; do not erase shared devices.
- Do not share Cisco images or report a deployed fabric from this prerequisite exercise.
Practice set
Answer before you reveal
01Which plane forwards ordinary user packets?
Control and management functions influence that information but are not automatically inline user-packet hops.
02What makes an API northbound?
The architectural relationship defines the direction. REST can also be used elsewhere and is not a direction by itself.
03Can an overlay work without its required underlay path?
Logical independence of endpoint addressing does not eliminate the physical and routed transport dependency.
04What risk grows when a bad template is automated?
Consistency is helpful only when the intended values, scope, permissions and verification are correct.
05What did this lab actually demonstrate?
It did not instantiate a controller, overlay, fabric policy or production automation system.
06Why select Loopback0 as the ping source?
A default transit source may hide a missing route to the loopback, producing a misleadingly successful test.
Knowledge check
Quiz: prove the reasoning
Keep these
Technical takeaways
- Separate intent, installed state and tested behavior.
- Automation can improve consistency and amplify a mistake.
- Northbound and southbound are controller-relative relationships.
- Underlay reachability is necessary but not sufficient for an overlay.
- Fabric terminology depends on the named architecture.
- Do not relabel a small routed lab as a controller deployment.