LogoفارسیFA

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

iBGP over DMVPNHub as Route ReflectorCombined DMVPN and BGP Design

~4 min read · Updated Sep 27, 2026

Lab Objective

Configure iBGP across the DMVPN tunnel interfaces used in the previous two labs, designate the hub as a BGP route reflector for both spokes, and verify each spoke learns the other's LAN via the hub without requiring a direct iBGP session between the spokes themselves.

Lab Purpose

The route reflector lab covered earlier in this series solved iBGP's full-mesh requirement using a hub-and-spoke iBGP design conceptually, but on a generic topology. This lab combines that concept directly with DMVPN's own hub-and-spoke tunnel structure, showing how naturally the two designs complement each other — the same hub already serving as the tunnel hub can also serve as the BGP route reflector.

Lab Topology

Same DMVPN topology as the previous two
labs, with OSPF removed and iBGP configured
instead, all in AS 65100:

Hub ---- Tunnel0 (mGRE): 172.16.200.1/24
Spoke1 ---- Tunnel0: 172.16.200.2/24
Spoke2 ---- Tunnel0: 172.16.200.3/24

Task 1: Remove the Previous OSPF Configuration

Remove OSPF from all three routers.

Task 2: Configure iBGP Sessions Between the Hub and Each Spoke

Configure the hub with iBGP neighbor statements to both spokes over their tunnel addresses.

Task 3: Configure the Hub as a Route Reflector

Mark both spoke sessions on the hub as route-reflector-client.

Task 4: Advertise Each Spoke's LAN Into BGP

Advertise Spoke1's and Spoke2's respective LANs into BGP on each spoke router.

Task 5: Verify Each Spoke Learns the Other's LAN via the Hub

Confirm Spoke1 learns Spoke2's LAN and vice versa, despite no direct BGP session existing between the two spokes.

Solution and Verification

Hub(config)# no router ospf 1
Spoke1(config)# no router ospf 1
Spoke2(config)# no router ospf 1

-- Underlying tunnel reachability (NHRP
-- registration) is independent of the
-- routing protocol running over it --
-- removing OSPF does not affect the DMVPN
-- tunnel itself

Hub(config)# router bgp 65100
Hub(config-router)# neighbor 172.16.200.2 remote-as 65100
Hub(config-router)# neighbor 172.16.200.2 route-reflector-client
Hub(config-router)# neighbor 172.16.200.3 remote-as 65100
Hub(config-router)# neighbor 172.16.200.3 route-reflector-client

-- Both spokes marked as clients in a
-- single step, combining the neighbor
-- establishment and route reflector role
-- assignment together

Spoke1(config)# router bgp 65100
Spoke1(config-router)# neighbor 172.16.200.1 remote-as 65100
Spoke1(config-router)# network 192.168.11.0 mask 255.255.255.0

Spoke2(config)# router bgp 65100
Spoke2(config-router)# neighbor 172.16.200.1 remote-as 65100
Spoke2(config-router)# network 192.168.12.0 mask 255.255.255.0

-- Neither spoke has any BGP configuration
-- referencing the other -- only a session
-- toward the hub

Spoke1# show ip bgp

   Network             Next Hop        Metric  LocPrf  Weight  Path
*>i 192.168.12.0/24    172.16.200.3    0       100         0   i
-- Spoke1 learned Spoke2's LAN despite
-- having no direct session with Spoke2 --
-- the hub, acting as route reflector,
-- relayed this route exactly as
-- demonstrated conceptually in the earlier
-- route reflector lab

Spoke2# show ip bgp

   Network             Next Hop        Metric  LocPrf  Weight  Path
*>i 192.168.11.0/24    172.16.200.2    0       100         0   i
-- Confirmed symmetric -- Spoke2 similarly
-- learned Spoke1's LAN via the same
-- reflection mechanism

Spoke1-LAN-PC> traceroute 192.168.12.10

  1  172.16.200.1 (Hub)
  2  192.168.12.10
-- Traffic still transits the hub for
-- forwarding, exactly as with the earlier
-- EIGRP and OSPF over DMVPN labs -- BGP's
-- route reflection solves route
-- PROPAGATION, not the separate question of
-- direct spoke-to-spoke data path
-- optimization, which would require NHRP
-- shortcut/redirect as covered in the
-- Phase 3 DMVPN lab

Key Takeaway

DMVPN's physical hub-and-spoke tunnel topology and BGP's route reflector hierarchy map onto each other almost perfectly — the same router already serving as the NHRP hub is naturally positioned to also serve as the BGP route reflector, avoiding a full iBGP mesh across potentially dozens of spokes exactly as the standalone route reflector lab demonstrated on a simpler topology, while still requiring the separate NHRP shortcut mechanism if direct spoke-to-spoke data forwarding (rather than just spoke-to-spoke route knowledge) is also desired.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

Continue

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

Continue

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

Continue

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

Continue

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

Continue

Hands-On Lab: Configuring Cisco DNA Center Assurance-Style Health Scoring (Simulated via IP SLA and EEM)

This hands-on lab combines IP SLA monitoring with an EEM applet to simulate a simplified assurance-style health check, automatically classifying a link's health based on measured performance thresholds and logging a clear status change when the link degrades.

Continue
Previous ArticleNext Article