NHPREP — Hands-On CCNA, CCNP, CCIE Labs & Networking Courses

Objective

Design and configure the SD-Access underlay network using OSPFv2 (or IS-IS) so that fabric devices have stable, scalable IP connectivity. In this lesson we will build and verify an OSPFv2 underlay for a small fabric site, set proper MTU and multicast/PIM behavior required by VXLAN, and explain LAN Automation considerations. In production, a correct underlay prevents overlay failures (VXLAN LISP control-plane problems, multicast issues, and slow convergence). Example: a distributed campus with multiple fabric sites uses an OSPF underlay so all fabric nodes (CP/BN/EN) exchange reachability and transport VXLAN encapsulated traffic reliably.

Quick Recap

Reference the topology introduced in Lesson 1. This lesson does not add new physical devices beyond the same fabric nodes; we show explicit IP addressing for the underlay needed to run OSPF and support VXLAN/PIM.

ASCII Topology (exact IPs on every interface)

            +-----------------+
            |       CP1       |
            | Loopback0:      |
            | 10.0.0.1/32     |
            | Gi0/0: 192.168.10.1/30
            +--------+--------+
                     |
                     | 192.168.10.0/30
                     |
            +--------+--------+
            |    Transit1     |
            | Loopback0:      |
            | 10.0.255.1/32   |
            | Gi0/1: 192.168.10.2/30
            | Gi0/2: 192.168.10.6/30
            | Gi0/3: 192.168.10.10/30
            +---+---------+---+
                |         |
   192.168.10.4/30|         |192.168.10.8/30
                |         |
        +-------+--+   +--+--------+
        |   BN1    |   |   EN1     |
        |Loopback0:|   |Loopback0: |
        |10.0.0.2/32|   |10.0.0.3/32|
        |Gi0/0: 192.168.10.5/30
        +----------+   +-----------+

Device table

Device	Role
CP1	Control Plane node (CP)
BN1	Border Node (BN)
EN1	Edge Node (EN)
Transit1	Transit router/switch (inter-site transit)

All examples below use domain lab.nhprep.com and passwords Lab@123 where needed for management tasks.

Key Concepts (theory before CLI)

Underlay vs Overlay: The underlay is the IP fabric (OSPF/IS-IS, physical MTU, multicast) that carries encapsulated VXLAN packets. If the underlay is unstable, the overlay (LISP/VXLAN) fails even if overlay config is correct.
OSPF behavior: On broadcast and point-to-point links OSPF sends Hello packets (default 10s hello / 40s dead on broadcast; 1s/3s on special links). OSPF LSAs advertise prefixes; area 0 is backbone and must interconnect other areas. In large designs use multi-area OSPF to reduce LSDB sizes.
MTU and VXLAN: VXLAN adds ~50 bytes of overhead; underlay interfaces must support MTU > 1550. If MTU is too small, fragmentation breaks efficient VXLAN forwarding and may drop encapsulated packets.
Multicast and PIM: If VXLAN uses multicast for L2 flooding (or for fabric registration), underlay must run PIM sparse-mode and have an RP. Configure PIM on transit-facing interfaces to support multicast replication.
LAN Automation / IS-IS tradeoffs: LAN Automation can provision underlay automatically (IS-IS). If you choose OSPF manually, ensure consistent router-ids, loopbacks for node-ID, and proper area design. In production OSPF is common where teams already have OSPF expertise.

Tip: Think of the underlay as the roads and VXLAN as the truck. If the road is narrow (MTU) or frequently closed (convergence problems), the truck cannot deliver goods even if the truck is perfect.

Step-by-step configuration

Step 1: Configure loopbacks and physical interface IPs

What we are doing: Assign loopback0 addresses (used as stable router-ids and host routes) and set IPs on the point-to-point links between each fabric node and the transit. Loopback stability matters for OSPF router-id and for VXLAN/LISP node identification.

! On CP1
interface Loopback0
 ip address 10.0.0.1 255.255.255.255
!
interface GigabitEthernet0/0
 ip address 192.168.10.1 255.255.255.252
 no shutdown
!

! On Transit1
interface Loopback0
 ip address 10.0.255.1 255.255.255.255
!
interface GigabitEthernet0/1
 ip address 192.168.10.2 255.255.255.252
 no shutdown
!
interface GigabitEthernet0/2
 ip address 192.168.10.6 255.255.255.252
 no shutdown
!
interface GigabitEthernet0/3
 ip address 192.168.10.10 255.255.255.252
 no shutdown
!

! On BN1
interface Loopback0
 ip address 10.0.0.2 255.255.255.255
!
interface GigabitEthernet0/0
 ip address 192.168.10.5 255.255.255.252
 no shutdown
!

! On EN1
interface Loopback0
 ip address 10.0.0.3 255.255.255.255
!
interface GigabitEthernet0/0
 ip address 192.168.10.9 255.255.255.252
 no shutdown
!

What just happened: Each device now has a persistent Loopback0 used as a router-id and OSPF LSDB identifier. Point-to-point subnets between nodes and transit are configured so OSPF adjacency can form. Using /30 links simplifies neighbor formation and conserves addressing.

Real-world note: Loopbacks are vital in multi-device fabrics — controller-based systems (like Catalyst Center) often reference loopback addresses when provisioning.

Verify:

! On CP1
show ip interface brief

Expected output:

Interface              IP-Address      OK? Method Status                Protocol
Loopback0              10.0.0.1        YES manual up                    up
GigabitEthernet0/0     192.168.10.1    YES manual up                    up

! On Transit1
show ip interface brief

Expected output:

Interface              IP-Address      OK? Method Status                Protocol
Loopback0              10.0.255.1      YES manual up                    up
GigabitEthernet0/1     192.168.10.2    YES manual up                    up
GigabitEthernet0/2     192.168.10.6    YES manual up                    up
GigabitEthernet0/3     192.168.10.10   YES manual up                    up

Step 2: Enable OSPFv2 underlay and set router-ids

What we are doing: Configure OSPF process, set router-id to loopback0, advertise point-to-point links into OSPF. This provides the underlay routing plane so fabric nodes can reach each other's loopbacks.

! On CP1
router ospf 1
 router-id 10.0.0.1
 network 192.168.10.0 0.0.0.3 area 0

! On Transit1
router ospf 1
 router-id 10.0.255.1
 network 192.168.10.0 0.0.0.3 area 0
 network 192.168.10.4 0.0.0.3 area 0
 network 192.168.10.8 0.0.0.3 area 0

! On BN1
router ospf 1
 router-id 10.0.0.2
 network 192.168.10.4 0.0.0.3 area 0

! On EN1
router ospf 1
 router-id 10.0.0.3
 network 192.168.10.8 0.0.0.3 area 0

What just happened: OSPF process 1 is now running on every device; each router uses its loopback as the router-id and advertises the directly connected subnets into area 0. OSPF will exchange Hello messages on the point-to-point links, build adjacencies, and flood LSAs so all routers learn each other’s routes.

Real-world note: For large campus fabrics you will often use multi-area OSPF to limit LSDB size. Ensure area 0 forms the backbone and all non-backbone areas connect to it.

Verify:

! On CP1
show ip ospf neighbor

Expected output:

Neighbor ID     Pri State           Dead Time   Address         Interface
10.0.255.1        1 FULL/ -         00:00:32    192.168.10.2    GigabitEthernet0/0

! On Transit1
show ip ospf neighbor

Expected output:

Neighbor ID     Pri State           Dead Time   Address         Interface
10.0.0.1         1 FULL/ -         00:00:34    192.168.10.1    GigabitEthernet0/1
10.0.0.2         1 FULL/ -         00:00:36    192.168.10.5    GigabitEthernet0/2
10.0.0.3         1 FULL/ -         00:00:34    192.168.10.9    GigabitEthernet0/3

! On any router
show ip route ospf

Expected output (Transit1 example):

O   10.0.0.1/32 [110/2] via 192.168.10.1, GigabitEthernet0/1
O   10.0.0.2/32 [110/2] via 192.168.10.5, GigabitEthernet0/2
O   10.0.0.3/32 [110/2] via 192.168.10.9, GigabitEthernet0/3

Step 3: Adjust MTU for VXLAN and enable PIM sparse-mode on transit links

What we are doing: Increase interface MTU to >1550 to accommodate VXLAN overhead and enable PIM sparse-mode on transit-facing links to support multicast replication if VXLAN uses multicast for broadcast/unknown-unicast flooding.

! On CP1
interface GigabitEthernet0/0
 ip mtu 1600
 ip pim sparse-mode

! On Transit1 (all transit-facing interfaces)
interface GigabitEthernet0/1
 ip mtu 1600
 ip pim sparse-mode
!
interface GigabitEthernet0/2
 ip mtu 1600
 ip pim sparse-mode
!
interface GigabitEthernet0/3
 ip mtu 1600
 ip pim sparse-mode

! On BN1
interface GigabitEthernet0/0
 ip mtu 1600
 ip pim sparse-mode

! On EN1
interface GigabitEthernet0/0
 ip mtu 1600
 ip pim sparse-mode

What just happened: Interfaces increased MTU to 1600, providing headroom for VXLAN (≈50 bytes overhead). PIM sparse-mode is enabled where multicast may traverse; this allows Rendezvous Point (RP) based multicast if required by the fabric for unknown-unicast/broadcast replication.

Real-world note: If your WAN/MPLS transport supports MTU >1550 (as is common in managed MPLS), set MTU accordingly. If not, you must implement MTU adjustments or avoid VXLAN multicast methods.

Verify:

! On Transit1
show ip pim interface

Expected output:

Interface                 PIM Enabled/Mode     DR IP Address
GigabitEthernet0/1       Yes/Sparse            192.168.10.2
GigabitEthernet0/2       Yes/Sparse            192.168.10.6
GigabitEthernet0/3       Yes/Sparse            192.168.10.10

! On CP1
show interface GigabitEthernet0/0 | include MTU

Expected output:

  MTU 1600 bytes, BW 1000000 Kbit/sec, DLY 10 usec,

Step 4: (Optional) LAN Automation and IS-IS vs OSPF decision

What we are doing: Explain when to use LAN Automation (IS-IS) versus manual OSPF configuration and how to prepare for automation. No specific CLI is required here because LAN Automation will provision underlay if used.

If you plan to use LAN Automation (IS-IS), seed devices into Catalyst Center and ensure loopbacks and SNMP/SSH credentials are configured for discovery.
If you remain with OSPF, standardize router-ids and area design. Prepare device templates for consistent MTU/PIM/OSPF settings.

What just happened: This is a design step — choosing automation impacts how you configure underlay and how consistent the network will be. LAN Automation (IS-IS) helps when fabric scale is large; OSPF is a solid manual choice when teams already use it.

Real-world note: In very large campus fabrics, LAN Automation (IS-IS) reduces configuration drift and speeds provisioning. But it requires familiarity and trust in the automation tooling.

Verify:

! Verify OSPF process exists (if using OSPF)
show ip protocols

Expected output:

Routing Protocol is "ospf 1"
  Routing for Networks:
    192.168.10.0 0.0.0.3 area 0
    192.168.10.4 0.0.0.3 area 0
    192.168.10.8 0.0.0.3 area 0
  Router ID 10.0.255.1
  Number of areas in this router is 1. 1 normal 0 stub 0 nssa

Verification Checklist

Check 1: OSPF neighbors are FULL on all transit links
- Verify with show ip ospf neighbor and expect FULL state between Transit1 and each fabric node.
Check 2: Loopback host routes are present in OSPF route table on every node
- Verify with show ip route ospf and expect O E2 or O entries for 10.0.0.x/32 prefixes.
Check 3: MTU is set >1550 and PIM is enabled on transit-facing interfaces
- Verify with show interface <if> | include MTU and show ip pim interface.

Common Mistakes

Symptom	Cause	Fix
OSPF neighbor stuck in INIT	Mismatched network types or ACL blocking OSPF Hello/Dead packets	Check interface IPs and ACLs; ensure OSPF allowed and interfaces up
VXLAN traffic drops / fragmentation	Interface MTU left at default (1500) causing encapsulated packets to fragment or be dropped	Set `ip mtu 1600` on underlay interfaces or enable jumbo frames on physical transport
Multicast replication not working	PIM not enabled on transit links or RP not configured	Enable `ip pim sparse-mode` on transit interfaces and configure RP as required
Router-id keeps changing	No loopback configured, using interface IP that can flap	Configure Loopback0 and `router-id <loopback>` under OSPF

Key Takeaways

The underlay must be stable and correctly sized (MTU, multicast, routing) before enabling overlay services like VXLAN/LISP — underlay problems cause overlay breakage.
Use Loopback0 as a stable router-id and configure point-to-point links with /30s to keep OSPF neighbor formation predictable.
MTU >1550 and PIM sparse-mode on transit-facing links are essential for VXLAN-based fabrics; verify these at the start.
Choose automation (LAN Automation/IS-IS) or manual OSPF based on scale and operational comfort — automation simplifies provisioning at scale but requires initial investment.

Warning: In production, always validate MTU and multicast behavior end-to-end (including WAN/MPLS) before enabling overlay, and stage changes (parallel build) to avoid disruption.

This completes Lesson 3: Underlay Network Design. In the next lesson we'll configure the fabric control-plane peering (LISP) and show how the underlay carries control-plane messages between CP and BNs.