Cisco SD-WAN OMP Routes Advertisement and VPN 1 Deployment
Contents
OMP Routes Types
The Overlay Management Protocol (OMP) is the control plane protocol used in Cisco SD-WAN to exchange routing, TLOC (Transport Locator), and policy information between SD-WAN edge devices (vEdges/cEdges) and the vSmart controller.
There are mainly 3 type of routes advertised via OMP:
1- TLOCs (Transport Locators) Routes
- TLOC (Transport Locator) routes are a fundamental part of Cisco SD-WAN’s control plane, facilitating the discovery and establishment of secure overlay tunnels between SD-WAN edge devices.
- TLOC route is uniquely identified by System-IP, Color, Encapsulation.
- These routes are advertised via the Overlay Management Protocol (OMP) and become active once a vEdge device is onboarded with the vSmart controller.
Below example of TLOC route received on vEDGE-1 (from peer 10.10.0.12 which is vSmart), and it’s identified by:
- System-IP: 10.120.0.12 (for vEDGE-2)
- Color: mpls
- Encapsulation: IPsec
and we can see the private/public IP (172.16.12.1) which will be used to form IPsec tunnel from vEDGE-1 to this TLOC on vEDGE-2.
They are many other attributes like preference, which can be used for OMP route preference etc.
LearnDuty-vEdge1# show omp tlocs received
---------------------------------------------------
tloc entries for 10.120.0.12
mpls
ipsec
---------------------------------------------------
RECEIVED FROM:
peer 10.10.0.12
status C,I,R
loss-reason not set
lost-to-peer not set
lost-to-path-id not set
Attributes:
attribute-type installed
encap-key not set
encap-proto 0
encap-spi 264
encap-auth sha1-hmac,ah-sha1-hmac
encap-encrypt aes256
public-ip 172.16.12.1
public-port 12346
private-ip 172.16.12.1
private-port 12346
public-ip ::
public-port 0
private-ip ::
private-port 0
bfd-status up
domain-id not set
site-id 12
overlay-id not set
preference 0
tag not set
stale not set
weight 1
version 3
gen-id 0x80000001
carrier default
restrict 1
groups [ 0 ]
border not set
unknown-attr-len not setCode language: CSS (css)We discussed OMP TLOC routes in the vEDGE onboarding process post below:
2- OMP Routes
This is what we will be focusing on in this article.
An OMP route represents a prefix in a specific VPN (virtual routing and forwarding instance) on an SD-WAN edge device.
OMP routes include details such as:
- Prefix: The IP address and subnet.
- VPN ID: Identifies the VPN to which the prefix belongs.
- TLOC: The next-hop information for reaching the prefix.
Each OMP route is associated with one or more TLOCs that indicate the transport paths available to reach that route.
For example following route 10.10.2.0/24 is received from vEDGE-2 via MPLS and Public-Internet TLOC:
LearnDuty-vEdge1# show omp routes
---------------------------------------------------
omp route entries for vpn 1 route 10.10.2.0/24
---------------------------------------------------
RECEIVED FROM:
peer 10.10.0.12
path-id 19
label 1004
status C,I,R
loss-reason not set
lost-to-peer not set
lost-to-path-id not set
Attributes:
originator 10.120.0.12
type installed
tloc 10.120.0.12, mpls, ipsec
ultimate-tloc not set
domain-id not set
overlay-id 1
site-id 12
preference not set
tag not set
origin-proto connected
origin-metric 0
as-path not set
unknown-attr-len not set
RECEIVED FROM:
peer 10.10.0.12
path-id 20
label 1004
status C,I,R
loss-reason not set
lost-to-peer not set
lost-to-path-id not set
Attributes:
originator 10.120.0.12
type installed
tloc 10.120.0.12, public-internet, ipsec
ultimate-tloc not set
domain-id not set
overlay-id 1
site-id 12
preference not set
tag not set
origin-proto connected
origin-metric 0
as-path not set
unknown-attr-len not setCode language: PHP (php)3- Service Routes
OMP can advertise service routes, such as next-hop addresses for specific services like firewalls or load balancers, available in the SD-WAN fabric.
Topology
We will continue on the same topology including 3 sites with 2 transport color (MPLS and public-internet) in the underlay, the SDWAN Controllers and WAN EDGE nodes are already onboarded, and we will explore the OMP route in this post:
VPN 1 Deployment and verification of OMP route advertisement
I- VPN 1 Deployment on vEDGE-1
- Configuration:
LearnDuty-vEdge1# conf t
Entering configuration mode terminal
LearnDuty-vEdge1(config)# vpn 1
LearnDuty-vEdge1(config-vpn-1)# interface ge0/2
LearnDuty-vEdge1(config-interface-ge0/2)# ip address 10.10.1.1/24
LearnDuty-vEdge1(config-interface-ge0/2)# no shutdown
LearnDuty-vEdge1(config-interface-ge0/2)# commit
Commit complete.
LearnDuty-vEdge1# show ip routes
Codes Proto-sub-type:
IA -> ospf-intra-area, IE -> ospf-inter-area,
E1 -> ospf-external1, E2 -> ospf-external2,
N1 -> ospf-nssa-external1, N2 -> ospf-nssa-external2,
e -> bgp-external, i -> bgp-internal
Codes Status flags:
F -> fib, S -> selected, I -> inactive,
B -> blackhole, R -> recursive
PROTOCOL NEXTHOP NEXTHOP NEXTHOP
VPN PREFIX PROTOCOL SUB TYPE IF NAME ADDR VPN TLOC IP COLOR ENCAP STATUS
---------------------------------------------------------------------------------------------------------------------------------------------
0 0.0.0.0/0 static - ge0/1 192.10.11.2 - - - - F,S
0 10.110.0.11/32 connected - system - - - - - F,S
0 172.16.11.0/24 connected - ge0/0 - - - - - F,S
0 172.16.12.0/24 static - ge0/0 172.16.11.2 - - - - F,S
0 172.16.13.0/24 static - ge0/0 172.16.11.2 - - - - F,S
0 192.10.11.0/24 connected - ge0/1 - - - - - F,S
0 222.2.2.0/24 static - ge0/0 172.16.11.2 - - - - F,S
1 10.10.1.0/24 connected - ge0/2 - - - - - F,S- OMP Route Advertisement verification:
Checking the output of “show omp peers” on vEDGE1, we can see that the “S” (routes sent) count incremented by 2, indicating that the configured interface part of VPN 1 connected route is advertised to OMP peer (vSmart), count is 2 because we have 2 transport (2 TLOCs color: mpls and public-internet) and route sent for both:
vEDGE-1 Output:
LearnDuty-vEdge1# show omp peers
R -> routes received
I -> routes installed
S -> routes sent
DOMAIN OVERLAY SITE
PEER TYPE ID ID ID STATE UPTIME R/I/S
------------------------------------------------------------------------------------------
10.10.0.12 vsmart 1 1 10 up 0:00:11:06 0/0/2Code language: PHP (php)Checking the same from vSmart side, we see the “R” count incremented by 2 for vEDGE-1, but, the connected route isn’t sent to any other vEDGEs, since we didn’t configure VPN 1 yet on other WAN nodes.
vSmart:
LearnDuty-vSmart# show omp peers
R -> routes received
I -> routes installed
S -> routes sent
DOMAIN OVERLAY SITE
PEER TYPE ID ID ID STATE UPTIME R/I/S
------------------------------------------------------------------------------------------
10.110.0.11 vedge 1 1 11 up 0:00:11:50 2/0/0
10.120.0.12 vedge 1 1 12 up 0:01:07:56 0/0/0
10.130.0.13 vedge 1 1 13 up 0:01:07:50 0/0/0
Code language: PHP (php)II- VPN 1 Deployment on vEDGE-2
- Configuration
LearnDuty-vEdge2# conf t
Entering configuration mode terminal
LearnDuty-vEdge2(config)# vpn 1
LearnDuty-vEdge2(config-vpn-1)# interface ge0/2
LearnDuty-vEdge2(config-interface-ge0/2)# ip address 10.10.2.0/24
LearnDuty-vEdge2(config-interface-ge0/2)# no shutdown
LearnDuty-vEdge2(config-interface-ge0/2)# commit
Commit complete.- OMP Routes verification:
From the following output, we can see that vEDGE-2 is sending its connected route, also received 2 routes (representing the connected route from vEDGE-1 from 2 TLOC transport MPLS, public internet), and theses route are installed in routing table:
LearnDuty-vEdge2# show omp peers
R -> routes received
I -> routes installed
S -> routes sent
DOMAIN OVERLAY SITE
PEER TYPE ID ID ID STATE UPTIME R/I/S
------------------------------------------------------------------------------------------
10.10.0.12 vsmart 1 1 10 up 0:01:16:57 2/2/2Code language: PHP (php)
We can verify the installed OMP routes:
- 10.10.1.0/24 is received via OMP protocol.
LearnDuty-vEdge2# show ip routes
Codes Proto-sub-type:
IA -> ospf-intra-area, IE -> ospf-inter-area,
E1 -> ospf-external1, E2 -> ospf-external2,
N1 -> ospf-nssa-external1, N2 -> ospf-nssa-external2,
e -> bgp-external, i -> bgp-internal
Codes Status flags:
F -> fib, S -> selected, I -> inactive,
B -> blackhole, R -> recursive
PROTOCOL NEXTHOP NEXTHOP NEXTHOP
VPN PREFIX PROTOCOL SUB TYPE IF NAME ADDR VPN TLOC IP COLOR ENCAP STATUS
---------------------------------------------------------------------------------------------------------------------------------------------
0 0.0.0.0/0 static - ge0/1 192.10.12.2 - - - - F,S
0 10.120.0.12/32 connected - system - - - - - F,S
0 172.16.11.0/24 static - ge0/0 172.16.12.2 - - - - F,S
0 172.16.12.0/24 connected - ge0/0 - - - - - F,S
0 172.16.13.0/24 static - ge0/0 172.16.12.2 - - - - F,S
0 192.10.12.0/24 connected - ge0/1 - - - - - F,S
0 222.2.2.0/24 static - ge0/0 172.16.12.2 - - - - F,S
1 10.10.1.0/24 omp - - - - 10.110.0.11 mpls ipsec F,S
1 10.10.1.0/24 omp - - - - 10.110.0.11 public-internet ipsec F,S
1 10.10.2.0/24 connected - ge0/2 - - - - - F,S
Code language: PHP (php)
On the other side, vEDGE-1 is also receiving the OMP routes for the connected subnet on vEDGE-2 “10.10.2.0/24”:
LearnDuty-vEdge1# show ip routes
Codes Proto-sub-type:
IA -> ospf-intra-area, IE -> ospf-inter-area,
E1 -> ospf-external1, E2 -> ospf-external2,
N1 -> ospf-nssa-external1, N2 -> ospf-nssa-external2,
e -> bgp-external, i -> bgp-internal
Codes Status flags:
F -> fib, S -> selected, I -> inactive,
B -> blackhole, R -> recursive
PROTOCOL NEXTHOP NEXTHOP NEXTHOP
VPN PREFIX PROTOCOL SUB TYPE IF NAME ADDR VPN TLOC IP COLOR ENCAP STATUS
---------------------------------------------------------------------------------------------------------------------------------------------
0 0.0.0.0/0 static - ge0/1 192.10.11.2 - - - - F,S
0 10.110.0.11/32 connected - system - - - - - F,S
0 172.16.11.0/24 connected - ge0/0 - - - - - F,S
0 172.16.12.0/24 static - ge0/0 172.16.11.2 - - - - F,S
0 172.16.13.0/24 static - ge0/0 172.16.11.2 - - - - F,S
0 192.10.11.0/24 connected - ge0/1 - - - - - F,S
0 222.2.2.0/24 static - ge0/0 172.16.11.2 - - - - F,S
1 10.10.1.0/24 connected - ge0/2 - - - - - F,S
1 10.10.2.0/24 omp - - - - 10.120.0.12 mpls ipsec F,S
1 10.10.2.0/24 omp - - - - 10.120.0.12 public-internet ipsec F,S
Code language: PHP (php)III- VPN 1 Deployment on vEDGE-3
- Configuration:
LearnDuty-vEdge3(config)# vpn 1
LearnDuty-vEdge3(config-vpn-1)# interface ge0/2
LearnDuty-vEdge3(config-interface-ge0/2)# ip address 10.10.3.1/24
LearnDuty-vEdge3(config-interface-ge0/2)# no shutdown
LearnDuty-vEdge3(config-interface-ge0/2)# commit
Commit complete.- OMP routes verification:
From vEDGE-3, we see that 4 OMP routes were received (corresponding to connected routes subnets from vEDGE-1 and vEDGE-2 via both transport colors), and the route are installed in the routing table:
LearnDuty-vEdge3# show omp peers
R -> routes received
I -> routes installed
S -> routes sent
DOMAIN OVERLAY SITE
PEER TYPE ID ID ID STATE UPTIME R/I/S
------------------------------------------------------------------------------------------
10.10.0.12 vsmart 1 1 10 up 0:01:35:17 4/4/2Code language: PHP (php)
We check routing table on vEDGE-3 and we confirm omp routes are properly installed and pointing to the corresponding vEDGEs TLOCs:
LearnDuty-vEdge3# show ip routes
Codes Proto-sub-type:
IA -> ospf-intra-area, IE -> ospf-inter-area,
E1 -> ospf-external1, E2 -> ospf-external2,
N1 -> ospf-nssa-external1, N2 -> ospf-nssa-external2,
e -> bgp-external, i -> bgp-internal
Codes Status flags:
F -> fib, S -> selected, I -> inactive,
B -> blackhole, R -> recursive
PROTOCOL NEXTHOP NEXTHOP NEXTHOP
VPN PREFIX PROTOCOL SUB TYPE IF NAME ADDR VPN TLOC IP COLOR ENCAP STATUS
---------------------------------------------------------------------------------------------------------------------------------------------
0 0.0.0.0/0 static - ge0/1 192.10.13.2 - - - - F,S
0 10.130.0.13/32 connected - system - - - - - F,S
0 172.16.11.0/24 static - ge0/0 172.16.13.2 - - - - F,S
0 172.16.12.0/24 static - ge0/0 172.16.13.2 - - - - F,S
0 172.16.13.0/24 connected - ge0/0 - - - - - F,S
0 192.10.13.0/24 connected - ge0/1 - - - - - F,S
0 222.2.2.0/24 static - ge0/0 172.16.13.2 - - - - F,S
1 10.10.1.0/24 omp - - - - 10.110.0.11 mpls ipsec F,S
1 10.10.1.0/24 omp - - - - 10.110.0.11 public-internet ipsec F,S
1 10.10.2.0/24 omp - - - - 10.120.0.12 mpls ipsec F,S
1 10.10.2.0/24 omp - - - - 10.120.0.12 public-internet ipsec F,S
1 10.10.3.0/24 connected - ge0/2 - - - - - F,SCode language: PHP (php)Same way, we can verify omp routes for the connected subnet are received on the other vEDGEs:
vEDGE-1:
LearnDuty-vEdge1# show omp peers
R -> routes received
I -> routes installed
S -> routes sent
DOMAIN OVERLAY SITE
PEER TYPE ID ID ID STATE UPTIME R/I/S
------------------------------------------------------------------------------------------
10.10.0.12 vsmart 1 1 10 up 0:02:22:32 4/4/2
LearnDuty-vEdge1# show ip routes
Codes Proto-sub-type:
IA -> ospf-intra-area, IE -> ospf-inter-area,
E1 -> ospf-external1, E2 -> ospf-external2,
N1 -> ospf-nssa-external1, N2 -> ospf-nssa-external2,
e -> bgp-external, i -> bgp-internal
Codes Status flags:
F -> fib, S -> selected, I -> inactive,
B -> blackhole, R -> recursive
PROTOCOL NEXTHOP NEXTHOP NEXTHOP
VPN PREFIX PROTOCOL SUB TYPE IF NAME ADDR VPN TLOC IP COLOR ENCAP STATUS
---------------------------------------------------------------------------------------------------------------------------------------------
0 0.0.0.0/0 static - ge0/1 192.10.11.2 - - - - F,S
0 10.110.0.11/32 connected - system - - - - - F,S
0 172.16.11.0/24 connected - ge0/0 - - - - - F,S
0 172.16.12.0/24 static - ge0/0 172.16.11.2 - - - - F,S
0 172.16.13.0/24 static - ge0/0 172.16.11.2 - - - - F,S
0 192.10.11.0/24 connected - ge0/1 - - - - - F,S
0 222.2.2.0/24 static - ge0/0 172.16.11.2 - - - - F,S
1 10.10.1.0/24 connected - ge0/2 - - - - - F,S
1 10.10.2.0/24 omp - - - - 10.120.0.12 mpls ipsec F,S
1 10.10.2.0/24 omp - - - - 10.120.0.12 public-internet ipsec F,S
1 10.10.3.0/24 omp - - - - 10.130.0.13 mpls ipsec F,S
1 10.10.3.0/24 omp - - - - 10.130.0.13 public-internet ipsec F,S
Code language: PHP (php)VPN 1 Connected Subnets Reachability
If we test the connectivity between the R1, R2 and R3 in VPN1, the connectivity works, since vEDGEs knows about the connected routes via OMP
When testing traceroute, we can see that the underlay (vpn0) hops aren’t seen, since packet is tunnel (ipsec), we see the following when pinging from R1 to R2:
R1#traceroute 10.10.2.2
Type escape sequence to abort.
Tracing the route to 10.10.2.2
VRF info: (vrf in name/id, vrf out name/id)
1 10.10.1.1 17 msec 11 msec 20 msec
2 10.10.2.1 40 msec 56 msec 40 msec
3 10.10.2.2 68 msec 71 msec *
R1#Code language: PHP (php)VPN1 Static Routes Advertisement via OMP
At this stage, only directly connected routes are shared via OMP (to vsmart, and eventually from vsmart to other vEDGEs), let’s make a bit more interesting,
For example currently, PC1 in Site-1 to PC3 in Site-2, it won’t work, since first, vEDGEs still don’t have route to the PCs subnets (can be static for illustration purpose), also OMP didn’t reflect these routes between vEDGEs (via vSmart).
Configuration:
Under VPN 1 mode, we simply add static routes on the vEDGEs for destination prefixes pointing to corresponding next-hop:
Well, it’s quite straight forward, we add static route to destination subnet under VPN1:
LearnDuty-vEdge1(config)# vpn 1
LearnDuty-vEdge1(config-vpn-1)# ip route 192.168.1.0/24 10.10.1.2
LearnDuty-vEdge1(config-vpn-1)# commitCode language: PHP (php)LearnDuty-vEdge2(config)# vpn 1
LearnDuty-vEdge2(config-vpn-1)# ip route 192.168.2.0/24 10.10.2.2
LearnDuty-vEdge2(config-vpn-1)# commitCode language: PHP (php)
Verification:
We can verify that OMP routes propagated properly:
- On vEDGE-1, we see the static route prefix (192.168.2.0/24) configured on vEDGE-2 VPN1 received as OMP route:
LearnDuty-vEdge1# show ip routes
Codes Proto-sub-type:
IA -> ospf-intra-area, IE -> ospf-inter-area,
E1 -> ospf-external1, E2 -> ospf-external2,
N1 -> ospf-nssa-external1, N2 -> ospf-nssa-external2,
e -> bgp-external, i -> bgp-internal
Codes Status flags:
F -> fib, S -> selected, I -> inactive,
B -> blackhole, R -> recursive
PROTOCOL NEXTHOP NEXTHOP NEXTHOP
VPN PREFIX PROTOCOL SUB TYPE IF NAME ADDR VPN TLOC IP COLOR ENCAP STATUS
---------------------------------------------------------------------------------------------------------------------------------------------
0 0.0.0.0/0 static - ge0/1 192.10.11.2 - - - - F,S
0 10.110.0.11/32 connected - system - - - - - F,S
0 172.16.11.0/24 connected - ge0/0 - - - - - F,S
0 172.16.12.0/24 static - ge0/0 172.16.11.2 - - - - F,S
0 172.16.13.0/24 static - ge0/0 172.16.11.2 - - - - F,S
0 192.10.11.0/24 connected - ge0/1 - - - - - F,S
0 222.2.2.0/24 static - ge0/0 172.16.11.2 - - - - F,S
1 10.10.1.0/24 connected - ge0/2 - - - - - F,S
1 10.10.2.0/24 omp - - - - 10.120.0.12 mpls ipsec F,S
1 10.10.2.0/24 omp - - - - 10.120.0.12 public-internet ipsec F,S
1 10.10.3.0/24 omp - - - - 10.130.0.13 mpls ipsec F,S
1 10.10.3.0/24 omp - - - - 10.130.0.13 public-internet ipsec F,S
1 192.168.1.0/24 static - ge0/2 10.10.1.2 - - - - F,S
1 192.168.2.0/24 omp - - - - 10.120.0.12 mpls ipsec F,S
1 192.168.2.0/24 omp - - - - 10.120.0.12 public-internet ipsec F,S
(END)Code language: PHP (php)
Same for vEDGE-2, receiving 192.168.1.0/24 via OMP:
LearnDuty-vEdge2# show ip routes
Codes Proto-sub-type:
IA -> ospf-intra-area, IE -> ospf-inter-area,
E1 -> ospf-external1, E2 -> ospf-external2,
N1 -> ospf-nssa-external1, N2 -> ospf-nssa-external2,
e -> bgp-external, i -> bgp-internal
Codes Status flags:
F -> fib, S -> selected, I -> inactive,
B -> blackhole, R -> recursive
PROTOCOL NEXTHOP NEXTHOP NEXTHOP
VPN PREFIX PROTOCOL SUB TYPE IF NAME ADDR VPN TLOC IP COLOR ENCAP STATUS
---------------------------------------------------------------------------------------------------------------------------------------------
0 0.0.0.0/0 static - ge0/1 192.10.12.2 - - - - F,S
0 10.120.0.12/32 connected - system - - - - - F,S
0 172.16.11.0/24 static - ge0/0 172.16.12.2 - - - - F,S
0 172.16.12.0/24 connected - ge0/0 - - - - - F,S
0 172.16.13.0/24 static - ge0/0 172.16.12.2 - - - - F,S
0 192.10.12.0/24 connected - ge0/1 - - - - - F,S
0 222.2.2.0/24 static - ge0/0 172.16.12.2 - - - - F,S
1 10.10.1.0/24 omp - - - - 10.110.0.11 mpls ipsec F,S
1 10.10.1.0/24 omp - - - - 10.110.0.11 public-internet ipsec F,S
1 10.10.2.0/24 connected - ge0/2 - - - - - F,S
1 10.10.3.0/24 omp - - - - 10.130.0.13 mpls ipsec F,S
1 10.10.3.0/24 omp - - - - 10.130.0.13 public-internet ipsec F,S
1 192.168.1.0/24 omp - - - - 10.110.0.11 mpls ipsec F,S
1 192.168.1.0/24 omp - - - - 10.110.0.11 public-internet ipsec F,S
1 192.168.2.0/24 static - ge0/2 10.10.2.2 - - - - F,SCode language: PHP (php)As a result, ping is now successful between PC1 and PC3:
We can do the same for site-3 on to reach srv_vpn1:
LearnDuty-vEdge3(config)# vpn 1
LearnDuty-vEdge3(config-vpn-1)# ip route 172.16.2.0/24 10.10.3.2
LearnDuty-vEdge3(config-vpn-1)# commit
LearnDuty-vEdge3# show ip routes vpn 1
Codes Proto-sub-type:
IA -> ospf-intra-area, IE -> ospf-inter-area,
E1 -> ospf-external1, E2 -> ospf-external2,
N1 -> ospf-nssa-external1, N2 -> ospf-nssa-external2,
e -> bgp-external, i -> bgp-internal
Codes Status flags:
F -> fib, S -> selected, I -> inactive,
B -> blackhole, R -> recursive
PROTOCOL NEXTHOP NEXTHOP NEXTHOP
VPN PREFIX PROTOCOL SUB TYPE IF NAME ADDR VPN TLOC IP COLOR ENCAP STATUS
---------------------------------------------------------------------------------------------------------------------------------------------
1 10.10.1.0/24 omp - - - - 10.110.0.11 mpls ipsec F,S
1 10.10.1.0/24 omp - - - - 10.110.0.11 public-internet ipsec F,S
1 10.10.2.0/24 omp - - - - 10.120.0.12 mpls ipsec F,S
1 10.10.2.0/24 omp - - - - 10.120.0.12 public-internet ipsec F,S
1 10.10.3.0/24 connected - ge0/2 - - - - - F,S
1 172.16.2.0/24 static - ge0/2 10.10.3.2 - - - - F,S
1 192.168.1.0/24 omp - - - - 10.110.0.11 mpls ipsec F,S
1 192.168.1.0/24 omp - - - - 10.110.0.11 public-internet ipsec F,S
1 192.168.3.0/24 omp - - - - 10.120.0.12 mpls ipsec F,S
1 192.168.3.0/24 omp - - - - 10.120.0.12 public-internet ipsec F,S
Code language: PHP (php)and we can test reachability same way:
Looks good, so far, one point worth mentioning is on the vSmart controller, the OMP routes are received and sent, but never installed, which make sense:
LearnDuty-vSmart# show omp peers
R -> routes received
I -> routes installed
S -> routes sent
DOMAIN OVERLAY SITE
PEER TYPE ID ID ID STATE UPTIME R/I/S
------------------------------------------------------------------------------------------
10.110.0.11 vedge 1 1 11 up 0:01:43:23 4/0/8
10.120.0.12 vedge 1 1 12 up 0:01:43:32 4/0/8
10.130.0.13 vedge 1 1 13 up 0:01:43:37 4/0/8Code language: PHP (php)Next, we will Configure SDWAN templates and policies (Feature template and apply via device templates), first, will convert existing configuration via templates and add VPN 2 through templates…
