Purpose:

  • This article helps to debug the SLA traffic between both branches to branches and the branches to controllers.

 

 Use cases:

  • To identify the flow of SLA traffic between the SD-WAN devices
  • Isolate the issue when the SLA path is down between the devices.

                

Points to be remembered

  • The SLAM debug needs to be executed on both sides.
  •  As SLA generates more traffic, debug needs to be disabled to avoid the utilization of disk space.

 

Topology:

  • Here, we will use two branches, Branch-01 and Branch-03, as references.

 

Pre-requisites:

Shell

vsh connect vsmd

show vsf tenant all brief >>> to get the tenant-ID

show vsf tunnel branch-table detail | grep -i <remote-branch-name>   >>>>>>>>>> To get the secure tunnel ptvi id

show vsf tunnel access-circuits ptvi <ptvi-id> <tenant-id> detail | grep -i V4UDP     >>>>>To get access circuit which is having issue



Procedure:

On Branch-01


 1) Get the Tenant-ID



2) Get the secure tunnel ptvi-id number

 

 

3)Get the access circuit details using the ptvi and tenant information.



Perform the same on the remote-site (Branch-03).


After getting the information of the tenant-ID, Ackt-ID, remote-site follow the below procedure to enable the debug

Step-1 Enable the packet-trace



Step-2 Set the packet-trace specific to the intended remote-site, which we are debugging.


Note: value for fc_ef=4 and fc_nc=0


Perform the same on the remote site (Branch-03)


Output:

 Branch-01 (Local-site)

 



 
Branch-03(Remote-site)



 Disable the debug (Must)

  • After collecting the logs, please follow the instructions below on both sides to disable the debug.

 

test vsf packet-trace vxlan-transit disable

set sd-wan slam pkt-trace 1 2 105 17 4 0 >>>last value should be ( 0 Disable;1Enable)