Verifying spoke-to-spoke ADVPN communication
To verify spoke-to-spoke ADVPN communication, run the following CLI commands on Spoke 1:
execute ping-options source <IP of interface on Spoke 1> execute ping <IP of interface on Spoke 2> get vpn ipsec tunnel summary
The following shows the expected output for this example:
Branch1 # exec ping-options source 10.20.1.2 Branch1 # exec ping 10.20.1.3 PING 10.20.1.3 (10.20.1.3): 56 data bytes 64 bytes from 10.20.1.3: icmp_seq=0 ttl=254 time=27.7 ms 64 bytes from 10.20.1.3: icmp_seq=2 ttl=255 time=17.4 ms 64 bytes from 10.20.1.3: icmp_seq=3 ttl=255 time=17.5 ms 64 bytes from 10.20.1.3: icmp_seq=4 ttl=255 time=17.4 ms --- 10.20.1.3 ping statistics --- 5 packets transmitted, 4 packets received, 20% packet loss round-trip min/avg/max = 17.4/20.0/27.7 ms Branch1 # get vpn ipsec tunnel summary 'fabric_vpn_1_0' 10.198.3.2:0 selectors(total,up): 1/1 rx(pkt,err): 25/0 tx(pkt,err): 26/2 'fabric_vpn_1' 10.198.5.2:0 selectors(total,up): 1/1 rx(pkt,err): 8032/0 tx(pkt,err): 8022/2 'fabric_vpn_2' 10.198.6.2:0 selectors(total,up): 1/1 rx(pkt,err): 7462/0 tx(pkt,err): 7478/1
fabric_vpn_1_0 is created for Spoke 1 to Spoke 2 communication.
On Spoke 1, verify the IPsec VPN tunnel between Spokes 1 and 2 by going to Dashboard > Network and clicking the IPsec widget to expand it:
On Spoke 1, verify the performance SLA has been updated by going to Network > SD-WAN and clicking the Performance SLAs tab:
The first fabric_vpn_1 corresponding to the spoke-to-hub VPN tunnel is shown as green and up. The second fabric_vpn_1 corresponding to the spoke-to-spoke VPN tunnel fabric_vpn_1_0 is shown as red and down since 10.20.1.1 is the IP address corresponding to the hub’s loopback interface which is not present on another spoke.