Cisco SD-WAN verify connectivity in Service VPN
There are a number of things you can check to see if you have connectivity in a service VPN between two vEdge routers.
We use service VPN 10 on routers vEdge1 and vEdge3:
VPN
First, check the VPN settings:
vEdge1# show run vpn 10 vpn 10 interface ge0/3 ip address 10.2.0.254/24 no shutdown ! omp advertise connected
vEdge3# show run vpn 10 vpn 10 interface ge0/3 ip address 10.3.0.254/24 no shutdown ! omp advertise connected
- Each router has an IP address.
- The interface is not shut.
- Advertise the directly connected routes to OMP.
Interface
Make sure the interface is reachable:
vEdge1# ping vpn 10 10.2.0.254 Ping in VPN 10 PING 10.2.0.254 (10.2.0.254) 56(84) bytes of data. 64 bytes from 10.2.0.254: icmp_seq=1 ttl=64 time=0.075 ms
vEdge3# ping vpn 10 10.3.0.254 Ping in VPN 10 PING 10.3.0.254 (10.3.0.254) 56(84) bytes of data. 64 bytes from 10.3.0.254: icmp_seq=1 ttl=64 time=0.054 ms
OMP
On each router, check if you have OMP routes.
Advertised routes
Make sure OMP advertises your service VPN prefix:
vEdge 1
vEdge1# show omp routes vpn 10 advertised Code: C -> chosen I -> installed Red -> redistributed Rej -> rejected L -> looped R -> resolved S -> stale Ext -> extranet Inv -> invalid Stg -> staged U -> TLOC unresolved VPN PREFIX --------------------------- 10 10.2.0.0/24
vEdge 3
vEdge3# show omp routes vpn 10 advertised Code: C -> chosen I -> installed Red -> redistributed Rej -> rejected L -> looped R -> resolved S -> stale Ext -> extranet Inv -> invalid Stg -> staged U -> TLOC unresolved VPN PREFIX --------------------------- 10 10.3.0.0/24
Received routes
Make sure you receive the service VPN prefix from the other vEdge router.
vEdge1
Here you can see that 10.3.0.0/24 originated from vEdge3 (172.16.1.3):
vEdge1# show omp routes vpn 10 received | begin 10.3.0.0 omp route entries for vpn 10 route 10.3.0.0/24 --------------------------------------------------- RECEIVED FROM: peer 172.16.1.103 path-id 1 label 1003 status C,I,R loss-reason not set lost-to-peer not set lost-to-path-id not set Attributes: originator 172.16.1.3 type installed tloc 172.16.1.3, biz-internet, ipsec ultimate-tloc not set domain-id not set overlay-id 1 site-id 3 preference not set tag not set origin-proto connected origin-metric 0 as-path not set unknown-attr-len not set
vEdge 3
Here you can see that 10.2.0.0/24 originated from vEdge3 (172.16.1.1):
vEdge3# show omp routes vpn 10 received | begin 10.2.0.0 omp route entries for vpn 10 route 10.2.0.0/24 --------------------------------------------------- RECEIVED FROM: peer 172.16.1.103 path-id 1 label 1003 status C,I,R loss-reason not set lost-to-peer not set lost-to-path-id not set Attributes: originator 172.16.1.1 type installed tloc 172.16.1.1, biz-internet, ipsec ultimate-tloc not set domain-id not set overlay-id 1 site-id 2 preference not set tag not set origin-proto connected origin-metric 0 as-path not set unknown-attr-len not set
Routing Table
Now check the routing table.
vEdge1
vEdge1# show ip route vpn 10 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 --------------------------------------------------------------------------------------------------------------------------------------------- 10 10.2.0.0/24 connected - ge0/3 - - - - - F,S 10 10.3.0.0/24 omp - - - - 172.16.1.3 biz-internet ipsec F,S
vEdge3# show ip routes vpn 10 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 --------------------------------------------------------------------------------------------------------------------------------------------- 10 10.2.0.0/24 omp - - - - 172.16.1.1 biz-internet ipsec F,S 10 10.3.0.0/24 connected - ge0/3 - - - - - F,S
Both routers installed the routes they learned from each other through OMP.
Test reachability
Finally, see if you can ping from one vEdge router to another in the service VPN:
vEdge1# ping vpn 10 10.3.0.254 Ping in VPN 10 PING 10.3.0.254 (10.3.0.254) 56(84) bytes of data. 64 bytes from 10.3.0.254: icmp_seq=1 ttl=64 time=42.8 ms 64 bytes from 10.3.0.254: icmp_seq=2 ttl=64 time=28.0 ms 64 bytes from 10.3.0.254: icmp_seq=3 ttl=64 time=40.9 ms 64 bytes from 10.3.0.254: icmp_seq=4 ttl=64 time=42.5 ms 64 bytes from 10.3.0.254: icmp_seq=5 ttl=64 time=45.3 ms ^C --- 10.3.0.254 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 28.060/39.942/45.391/6.111 ms
vEdge3# ping vpn 10 10.2.0.254 Ping in VPN 10 PING 10.2.0.254 (10.2.0.254) 56(84) bytes of data. 64 bytes from 10.2.0.254: icmp_seq=1 ttl=64 time=36.6 ms 64 bytes from 10.2.0.254: icmp_seq=2 ttl=64 time=27.9 ms 64 bytes from 10.2.0.254: icmp_seq=3 ttl=64 time=28.4 ms 64 bytes from 10.2.0.254: icmp_seq=4 ttl=64 time=29.4 ms 64 bytes from 10.2.0.254: icmp_seq=5 ttl=64 time=30.4 ms ^C --- 10.2.0.254 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 27.941/30.587/36.625/3.138 ms
Misc
If you have any missing OMP routes, make sure you don't have any policies in place that prevent routes from being advertised.