Dynamic Path Selection (DPS) is a WAN Routing System feature that allows two sites to forward the application traffic on the right path, like an MPLS network or the Internet, based on an application’s specific load balancing policy. DPS tunnels are in the underlay fabric mentioned in the previous section.

Adaptive Virtual Topology (AVT) builds on top of the DPS feature, which allows it to choose a direct path to a destination or service or a multi-hop path traversing one or more transit WAN Routing System routers to reach a destination or service.

The network has sites connected by various SP networks. These SP networks map to specific path group names in EOS. So, if the path group name is the same, the routers can establish direct DPS paths over the SP network.

The earlier example shows two zones with 4 sites (1 hub and 3 spokes) in each zone. There are three path groups:

1. MPLS-1
2. MPLS-2
3. Internet (doesn’t differentiate between Internet-1 and Internet-2 as they are connected)

The AVT feature breaks down the network into virtual topologies adapted using the best paths suitable for applications (traffic group). A virtual topology is influenced by:

• The application group (e.g., latency-sensitive, critical, etc.)
• The service that is needed (firewall, etc.)

In the diagram earlier (Figure 2), AVT might select the MPLS-1 and the Internet path groups for traffic traversing from Branch-1 (R5) to Branch-3 (R7). AVT can choose the following paths:

• R5 -> R7 (direct path)
• R5-> H1 -> R7 (multi-hop path).

A BGP path selection exchanges the NLRI between all the routers in the network through the route reflectors, helping the routers auto-discover each other. Currently, every neighboring router exchanges advertisements, but the implementation may restrict the advertisements to only the concerned routers within a zone.

A BGP path-selection NLRI carries information about how to reach a router’s VTEP by advertising the router’s service provider (SP) routable IP address. The SP routable address can be a public IP address in the case of an ISP or a private IP address in the case of private networks, for example, based on MPLS. After routers auto-discover other peer routers and their corresponding WAN reachability information, they can establish tunnels with the peer routers over various underlying service provider networks. One can refer to this fabric of routers interconnected with tunnels as the underlay fabric or simply as the underlay.

The CloudVision Pathfinder software running on the RR receives a full view of the WAN network. Each router contributes BGP-LS updates to learn the topology view. The BGP RR receives the BGP-LS updates and passes on the node and link information to CloudVision Pathfinder. Each link also publishes a set of metrics.

CloudVision Pathfinder is responsible for computing paths from every source to every other destination in the WAN network. AVTs classify different types of traffic and require varying quality of service treatment in the WAN. Each AVT may have different constraints and objective functions to satisfy. The CloudVision Pathfinder software is responsible for computing the paths from different sources to every destination that satisfies the constraints and objective functions configured for each AVT.

A DPS tunnel between two routing nodes is composed of individual paths. The number of paths depends on the number of public WAN interfaces and their types. A source node can take any of those paths to reach an adjacent node. The individual paths have their metrics, and the router periodically updates each of these metrics.

The end-to-end paths computed by CloudVision Pathfinder are called multi-hop DPS paths. They consist of node router IDs and the individual paths between them. Each router receives traffic-engineered policies that express the multi-hop paths.

The multi-hop paths are then sent to each router through the RR using BGP SR-TE. Every node gets multi-hop paths to reach every destination in each AVT (i.e., a multi-hop path is specific to an AVT and satisfies the constraints and objective functions set forth by that AVT).

CloudVision Pathfinder includes the end-to-end metrics and multi-hop paths and sends periodic updates as metrics change.

CloudVision Pathfinder will recompute the routing table and distribute updates using BGP when reachability or metrics change.

To simplify managing networking policies, divide the enterprise network hierarchically into regions, zones, sites, etc.

For example, an enterprise might have US, Europe, and Asia regions. Divide the US region further into East and West Coast (or states) zones. A zone comprises several sites: a branch, a campus, a data center, a point-of-presence (POP), or a cloud network. A site can have a few routers identified by their device number.

The full hierarchy is as follows:

• Region
• Zone
• Site
• Device

router(config)#router adaptive-virtual-topology 
router(config-adaptive-virtual-topology)#topology role <transit zone | edge | pathfinder> 
router(config-adaptive-virtual-topology)#region <region name> id <region id>
router(config-adaptive-virtual-topology)#zone <zone name> id <zone id>
router(config-adaptive-virtual-topology)#site <site name> id <site id>

• Pathfinder-created paths are called multi-hop DPS paths. They consist of node router IDs and the individual paths between them. Traffic-engineered policies express the multi-hop paths and can be sent to each router.
• The multi-hop paths are then sent to each router through the RR using BGP SR-TE. Every node gets multi-hop paths to reach every destination in each AVT (i.e., a multi-hop path is specific to an AVT and satisfies the constraints and objective functions set forth by that AVT).
• Profiles are defined globally and applied to selected VRFs.
• Apply all the policies to the AVT profile. For example:
  • Path Selection
  • Internet Exit
• Make path selection definitions in the router path-selection command.

router(config-adaptive-virtual-topology)#profile <avt-name>
      !! feature configurations
router(config-profile-AVT)#path-selection load-balance <voice-lb>

router(config)#router path-selection 
router(config-dynamic-path-selection)#path-group mpls-group id 2
router(config-path-group-mpls-group-2)#local interface ethernet 2
router(config-mpls-group-interface-Ethernet2)#peer dynamic 
router(config-peer-dynamic-mpls-group)#path-group internet-group id 3
router(config-path-group-internet-group-3)#local interface ethernet 3
router(config-internet-group-interface-Ethernet3)#peer dynamic 
router(config-peer-dynamic-internet-group)#peer static router-ip 11.0.1.1
router(config-peer-router-ip-11.0.1.1-internet-group)#ipv4 address 10.0.3.1
router(config-peer-router-ip-11.0.1.1-internet-group)#

router(config)#router path-selection 
router(config-dynamic-path-selection)#load-balance policy voice-load-balance
router(config-load-balance-policy-voice-load-balance)#latency 50
router(config-load-balance-policy-voice-load-balance)#path-group mpls-group 
router(config-load-balance-policy-voice-load-balance)#path-group internet-group priority 2
router(config-load-balance-policy-voice-load-balance)#

AVT policies can be used across VRFs as shown below:

router adaptive-virtual-topology
policy production
 	match application-profile <profile-name> [ <after | before> <profile-name> ]
		avt profile <avt-name>
                        dscp <value>
                        traffic-class <value>

match application-profile <profile-name>
	avt profile <avt-name>


                       ………...
match application-profile default
		avt profile <avt-name>

Application profile creation uses the deep packet inspection module.

Configuring a traffic class and DSCP values is available. If only a traffic class is configured for an AVT, the outer and inner DSCP values are rewritten based on the traffic-class-to-DSCP map configured if DSCP rewrite is enabled. If a DSCP value is configured for an AVT, the outer and inner DSCP values are rewritten based on the configured DSCP value if DSCP rewrite is enabled. The AVT ID and DSCP values used for the flow in one direction are also used for the reverse flow.

WAN Routing System’s AVT Sample Configuration:

router adaptive-virtual-topology
	profile voice
		load-balance voice-load-balance
	profile critical-data 
		load-balance critical-data-load-balance
	profile default-avt
		load-balance default-load-balance
policy production 
		match application-profile voice-app-profile 
                		profile voice
                		dscp 62
                		tc 1
match application-profile critical-data-app-profile 
		profile critical-data
match application-profile default
		profile default-avt

Also, note that DPS is applied to the default VRF in the WAN Routing System deployments for connectivity to CloudVision Pathfinder. The BGP session to CloudVision Pathfinder runs over a DPS session applied to the default VRF. For all other customer overlay VRFs DPS is applied to the AVTs.

You can apply an AVT policy with the following command:

router adaptive-virtual-topology
         vrf <vrf> 
                     policy <avt-policy-name>
                     profile <avt-name> avt-id <avt-id>

router adaptive-virtual-topology
vrf red
   avt policy production 
   avt profile voice id 1
   avt profile critical-data id 2
   avt profile default-avt id 3

An AVT policy classifies different application groups into the corresponding AVT and specifies what action profiles to apply on that AVT. The action profile selects different attributes for the traffic/flow classified into the AVT. For example, the action profile could select the type of load balancing across different links and the traffic class for the packets classified into the AVT. It can also set the internet-exit policy for flows belonging to the AVT that need to exit into the Internet.

profile control-plane
      path-selection load-balance control-plane-lb
   !

 policy defaultAvtPolicy
      match application-profile CONTROL_PLANE
         avt profile control-plane
      !

vrf default
      avt policy defaultAvtPolicy
      avt profile control-plane id 1
   !

The route reflector must be configured with all the AVT policies, including the one for load balancing for CloudVision Pathfinder to build all the topologies. This configuration is used purely to construct topologies on CloudVision Pathfinder and has no bearing on its data path.

router path-selection 
	path-group mpls-group id 10
	!
	path-group internet-group id 20
	!
	load-balance policy voice-load-balance
   latency 50
   path-group mpls-group
   path-group internet-group priority 2 
	load-balance policy critical-data-load-balance
   path-group mpls-group
   path-group internet-group priority 2 
load-balance policy default-load-balance
   path-group internet-group 

router adaptive-virtual-topology
!! role is pathfinder
role pathfinder
            
	!! Define all the AVT profiles
	profile voice
		path-selection load-balance voice-load-balance 
	profile critical-data 
		path-selection load-balance critical-data-load-balance
	profile default-avt
		path-selection load-balance default-load-balance

	!! Define the AVT policy 
policy production 
	           match application-profile voice-app-profile 
                		avt profile voice
           match application-profile critical-data-app-profile 
		           avt profile critical-data
           match application-profile default
		          avt profile default-avt

!! Apply the AVT policy on the VRF
vrf red
		avt policy production 
	!! Create the AVTs in the VRFs
	avt profile voice id 1
	avt profile critical-data id 2

You can use the path-selection command on the transit and the edge routers to enable the import of the AVT node and DPS link information to BGP LS. The RR doesn’t need the path-selection command.

router bgp 1
   address-family link-state
      path-selection

The WAN Routing System router and the RR play different roles in BGP LS for processing the DPS information. You can use the following new command to specify the role:

router bgp 1
   address-family link-state
      path-selection role [ producer | consumer | propagator ]

The CloudVision Pathfinder software calculates multi-hop DPS paths between WAN Routing System network routers. Since a router only needs those paths, which are the headend, it is a big waste of control plane bandwidth if the RR sends all such paths to every router. Each DPS policy is attached with a route-target extended community to identify the headend router for ease of route filtering. BGP SR-TE automatically adds this route-target extended community parameter. This is the IPv4 address format route-target extended community, which contains the IPv4 address of the intended headend router for which this policy route is meant.

Adding an outbound route filtering configuration on the RR is recommended to send selective routes to each router. In particular, you should define a route map for each neighbor router to match the route-target extended community with the neighbor router’s VTEP address. Attach the route map to the corresponding neighbor’s outbound direction. Here’s an example of configuration:

ip extcommunity-list ngb1 permit rt 1.1.1.1:00
route-map rm1 permit 10
   match extcommunity ngb1
router bgp 100
   address-family ipv4 sr-te
      neighbor 1.1.1.1 activate
neighbor 1.1.1.1 route-map rm1 out

Both the RR and the routers must enable the IPv4 SR-TE address family like so:

router bgp 1
   address-family ipv4 sr-te
      neighbor <NEIGHBOR> activate

This configuration enables the reception of both the regular SR policy and the new DPS policy tunnel types in the BGP SR-TE NLRI. The BGP SR-TE draft requires the SR policy tunnel type to be present in the message. Arista has relaxed this requirement for the WAN Routing System. A message containing either an SR or DPS policy is accepted upon reception.

This configuration also enables the transmission of the DPS policy tunnel type in the BGP SR-TE NLRI.

The RR aggregates all the AVT nodes and the DPS link information sent by the WAN Routing System routers and propagates it to other RRs. It does not need to propagate all the information back to the WAN Routing System routers. To save control plane bandwidth, we highly recommend configuring the following command on the RR to avoid sending BGP LS updates to the routers:

router bgp 65010
   address-family link-state
      neighbor EDGE missing-policy direction out action deny

The show adaptive-virtual-topology flow command shows the path each flow takes in the overlay. Flows are displayed in both forward and reverse directions. Load balancing is done only in the forward direction, which shows valid AVT, interface, next-hop VTEP, and path ID. The reverse flow shows these fields as n/a because load balancing is unavailable. The Path Type: ID column identifies the path taken by the flow. Users can find the path information in the show adaptive-virtual-topology path output.

VRF     AVT      Source            Destination       Protocol Interface   Nexthop VTEP  Transit Path Type:ID
------- -------- ----------------- ----------------- -------- ----------- ------------- ------- -----------
vrf1    platinum 20.0.0.2:47803    20.0.1.2:56000    17       Ethernet3   11.0.3.1      no      multihop:1
vrf1    n/a      20.0.1.2:56000    20.0.0.2:47803    17       n/a         n/a           no      n/a
vrf1    platinum 20.0.0.2:47804    20.0.1.2:56000    17       Ethernet3   11.0.1.1      no      direct:2
vrf1    n/a      20.0.1.2:56000    20.0.0.2:47804    17       n/a         n/a           no      n/a
vrf1    platinum 20.0.0.2:47797    20.0.1.2:56000    17       Ethernet3   11.0.3.1      no      multihop:1
vrf1    n/a      20.0.1.2:56000    20.0.0.2:47797    17       n/a         n/a           no      n/a
default balance  11.0.0.1:179      11.0.2.1:45215    6        Ethernet5   11.0.2.1      no      direct:1
default n/a      11.0.2.1:45215    11.0.0.1:179      6        n/a         n/a           no      n/a

The show adaptive-virtual-topology path command displays direct and multi-hop paths for every valid VRF and AVT in the system. Users can filter the output by VRF, AVT, or destination.

A path becomes considered valid if it constitutes a direct or multi-hop path received from RR containing valid VRF and AVT information. A path is marked as active when it gets programmed to the platform. Each path receives identification through Path Type: ID. The Destination column displays the end node to which overlay routes lead. The NextHop column indicates the initial hop in a path. The Hop List reveals the path labels within the hop stack, with the first path label appearing as the local DPS path name.

Router ID: 11.0.0.1
Role: edge
Region: us, Region ID: 1
Zone: texas, Zone ID: 101
Site: austin, Site ID: 1001

Code: * - valid, > - active, d - direct path, m - multihop path

VRF: vrf1, VNI: 100
AVT: platinum, AVT ID: 11
Application profile(s): default
    Path Type:ID  Destination   Nexthop VTEP  Priority   MTU  Latency   Jitter     Loss Hop List
    ------------- ------------- ------------- -------- ----- -------- -------- -------- ---------
*   direct:3      11.0.1.1      11.0.1.1             2  1464  3.497ms  1.140ms  0.0000% path3
*>  direct:2      11.0.1.1      11.0.1.1             1  1464  1.746ms  1.035ms  0.0000% path2
*>  multihop:1    11.0.1.1      11.0.3.1             1  1464  6.812ms  3.243ms  0.0000% path4,2
*   multihop:2    11.0.1.1      11.0.3.1             2  1464  5.756ms  3.464ms  0.0000% path4,5
*   multihop:3    11.0.1.1      11.0.3.1             2  1464  4.807ms  2.757ms  0.0000% path5,2
*   multihop:4    11.0.1.1      11.0.3.1             2  1464  3.751ms  2.978ms  0.0000% path5,5
*>  direct:4      11.0.3.1      11.0.3.1             1  1464  2.433ms  1.547ms  0.0000% path4
*   direct:5      11.0.3.1      11.0.3.1             2  1464  4.010ms  1.225ms  0.0000% path5

VRF: default (underlay)
AVT: balance, AVT ID: 10
Application profile(s): default
    Path Type:ID  Destination   Nexthop VTEP  Priority   MTU  Latency   Jitter     Loss Hop List
    ------------- ------------- ------------- -------- ----- -------- -------- -------- ---------
*>  direct:1      11.0.2.1      11.0.2.1             1  1464  3.613ms  6.471ms  0.0000% path1

The following AVT commands show packet/byte counters for egress traffic and display how the AVT flow distribution is working.

VRF  AVT    First Hop Path   Interfaces   Flows *     Bytes   Packets    Rate
—--  —----  —-------- —----- —---------   —------  —-------  —-------  —------
red  voice  11.0.1.1  path1  eth1          1000   23213123      5646    1 Gb/s 
red  voice  11.0.1.1  path2  eth2           343    8938424       128    2 Mb/s
red  voice  11.0.1.1  path3  eth3         45645   32482348       245    9 Gb/s
red  voice  11.0.2.1  path5  eth1          1010   23214123      5746  500 Kb/s
red  voice  11.0.2.1  path7  eth2          3445    7938424       129    5 Mb/s
blue data   11.0.2.1  path5  eth1          1000    1232112      3322  2.5 Kb/s
blue data   11.0.2.1  path6  eth2           343     782342      1637   350 b/s
* Flows = Active Flows

A set of counters is provided to check common mishaps happening in the data plane. The list includes, for instance, counters for packet drops, lookup failures, and missing flow cache:

• show platform sfe counters module AvtEgress

  Name                             Owner       Counter Type Unit       Count
  -------------------------------- ---------   ------------ ---------- -----
  Avt-lookup-miss                  AvtEgress   module       packets    0
  Avt-lookup-fail                  AvtEgress   module       packets    0
  LbId-lookup-fail                 AvtEgress   module       packets    0
  invalid-lbid                     AvtEgress   module       packets    0
  no-Avt-FlowCache                 AvtEgress   module       packets    0
  no-FlowCache                     AvtEgress   module       packets    0
  no-Path                          AvtEgress   module       packets    0
  AvtUtilPkt-Data                  AvtEgress   module       packets    0
  AvtUtilPkt-Error                 AvtEgress   module       packets    0
  Avt-Counter-lookup-fail          AvtEgress   module       packets    0
  Avt-Counter-Memory-Allocations   AvtEgress   module       memoryBloc 0
  Avt-Counter-Memory-Deallocations AvtEgress   module       memoryBloc 0
  avt-fast-reroute                 AvtEgress   module       packets    0
  avt-ingress-transit              AvtEgress   module       packets    0
  avt-ingress-transitfib_bypass    AvtEgress   module       packets    0

• show platform sfe counters module dpsEgress

  Name                             Owner       Counter Type Unit       Count
  -------------------------------- ---------   ------------ ---------- -----
  dpsEgress-Uninitialized          dpsEgress   module       packets    0
  dpsEgress-No_Space               dpsEgress   module       packets    0
  dpsEgress-VNI_Lookup_Fail        dpsEgress   module       packets    0
  dpsEgress-Tun_Lookup_Fail        dpsEgress   module       packets    0

• show platform sfe counters module dps

  Name                             Owner       Counter Type Unit       Count
  -------------------------------- ---------   ------------ ---------- -----
  LbId-lookup-fail                 dps         module       packets    0
  invalid-lbid                     dps         module       packets    0
  no-Dps-FlowCache                 dps         module       packets    0
  no-FlowCache                     dps         module       packets    0
  no-Path                          dps         module       packets    0
  Failed-Frag                      dps         module       packets    0
  Failed-Linearize                 dps         module       packets    0
  Frag pkt counter                 dps         module       packets    0

The following commands can be used to verify an AVT node and the DPS link information conveyed through BGP LS:

show bgp link-state node [ detail ]
show bgp link-state link [ detail ]

# show bgp link-state node 
BGP routing table information for VRF default
Router identifier 0.0.0.1, local AS number 300
BRIB status codes: * - valid, > - active, q - Queued for advertisement
NLRI codes: Proto - IGP Protocol
            I L1 - IS-IS Level-1, I L2 - IS-IS Level-2
            ID - Identifier (IGP Instance ID)
            RRID - Remote Node Router ID
            DPS - Dynamic Path Selection
        Type   Proto  ID    Router ID        NLRI Specific      Peer        Path
 * >    node   DPS    0     12.0.0.1         -                   -           -

# show bgp link-state node detail 
BGP routing table information for VRF default
Router identifier 0.0.0.1, local AS number 300
BGP routing table entry for node: BGP DPS, Identifier: 0
Router ID: 12.0.0.1
 Paths: 1 available
  Local
    - from - (0.0.0.0)
      Origin IGP, metric -, localpref -, weight 0, received 01:01:09 ago, valid, local, best, imported (DPS)
      Role: edge
      Region ID: 1
      Zone ID: 101
      Site ID: 1001
      VNI: 200 AVT ID: 2
      VNI: 100 AVT ID: 2
      VNI: 100 AVT ID: 1
      VNI: 200 AVT ID: 1
      Flags: []

# show bgp link-state link 
BGP routing table information for VRF default
Router identifier 0.0.0.1, local AS number 300
BRIB status codes: * - valid, > - active, q - Queued for advertisement
NLRI codes: Proto - IGP Protocol
            I L1 - IS-IS Level-1, I L2 - IS-IS Level-2
            ID - Identifier (IGP Instance ID)
            RRID - Remote Node Router ID
            DPS - Dynamic Path Selection
        Type   Proto  ID    Router ID        NLRI Specific              Peer    Path
 * >    link   DPS    0     12.0.0.1         RRID: 12.0.0.2              -       -
                                             WAN ID: Local 1 Remote 1
                                             WAN Group ID: Local 100
 * >    link   DPS    0     12.0.0.1         RRID: 12.0.0.2              -       -
                                             WAN ID: Local 2 Remote 2
                                             WAN Group ID: Local 101

# show bgp link-state link detail
BGP routing table information for VRF default
Router identifier 0.0.0.1, local AS number 300
BGP routing table entry for link: BGP DPS, Identifier: 0
Local node router ID: 12.0.0.1, Remote node router ID: 12.0.0.2
 Paths: 1 available
  Local
    - from - (0.0.0.0)
      Origin IGP, metric -, localpref -, weight 0, received 01:09:43 ago, valid, local, best, imported (DPS)
      IGP metric: 0
      Segment label: 5
      Path MTU: 1464
      Path latency: 24049
      Path jitter: 1843
BGP routing table entry for link: BGP DPS, Identifier: 0
Local node router ID: 12.0.0.1, Remote node router ID: 12.0.0.2
 Paths: 1 available
  Local
    - from - (0.0.0.0)
      Origin IGP, metric -, localpref -, weight 0, received 01:09:43 ago, valid, local, best, imported (DPS)
      IGP metric: 0
      Segment label: 6
      Path MTU: 1464
      Path latency: 24030
      Path jitter: 1862

The existing show bgp sr-te command allows for an overview of all SR-TE routes, encompassing both the regular SR policy and the new DPS policy. To discern the tunnel type a route carries, reference the Color and Distinguisher columns. If a route carries a DPS policy, the Color column indicates which VRF and AVT this route belongs to in the <VRF name>:<AVT name> format. The Distinguisher column displays the source router ID in IPv4 address format.

#show bgp sr-te 
BGP routing table information for VRF default
Router identifier 0.0.0.1, local AS number 300
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP
                    S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast
                    % - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop
        Endpoint      Color         Distinguisher Next Hop        Metric  LocPref Weight  Path
 * >    12.0.0.2      eng:voiceAvt  12.0.0.1      12.0.0.3        -       100     0       i
 * >    12.0.0.2      eng:dataAvt   12.0.0.1      12.0.0.3        -       100     0       i

#show bgp sr-te detail
BGP routing table information for VRF default
Router identifier 0.0.0.1, local AS number 300
BGP routing table entry for Endpoint: 12.0.0.2, VNI: 100, VRF: eng, AVT: voiceAvt (1), Router: 12.0.0.1
 Paths: 1 available
  Local
    12.0.0.3 from 12.0.0.3 (0.0.0.3)
      Origin IGP, metric -, localpref 100, weight 0, received 00:00:16 ago, valid, internal, best
      Extended Community: Route-Target-IP:12.0.0.1:0
      Rx SAFI: SR TE Policy
      Tunnel encapsulation attribute: DPS policy
         Preference: 100
         Segment List: Label Stack: [9 8], latency: 51.423 msec, jitter: 4.083 msec, MTU: 1464 bytes, priority: 1
         Segment List: Label Stack: [7 5], latency: 51.771 msec, jitter: 3.974 msec, MTU: 1464 bytes, priority: 1
         Segment List: Label Stack: [9 5 5], latency: 75.948 msec, jitter: 6.885 msec, MTU: 1464 bytes, priority: 1
BGP routing table entry for Endpoint: 12.0.0.2, VNI: 100, VRF: eng, AVT: dataAvt (2), Router: 12.0.0.1
 Paths: 1 available
  Local
    12.0.0.3 from 12.0.0.3 (0.0.0.3)
      Origin IGP, metric -, localpref 100, weight 0, received 00:00:16 ago, valid, internal, best
      Extended Community: Route-Target-IP:12.0.0.1:0
      Rx SAFI: SR TE Policy
      Tunnel encapsulation attribute: DPS policy
         Preference: 100
         Segment List: Label Stack: [10 9], latency: 51.584 msec, jitter: 4.137 msec, MTU: 1464 bytes, priority: 1
         Segment List: Label Stack: [8 6], latency: 51.912 msec, jitter: 4.047 msec, MTU: 1464 bytes, priority: 1
         Segment List: Label Stack: [10 6 6], latency: 75.817 msec, jitter: 6.781 msec, MTU: 1464 bytes, priority: 1

#show bgp sr-te endpoint <endpoint> path-selection color-vrf <avt vrf name> avt <avt name> [router <source router IP>] [detail]

#show bgp sr-te endpoint 12.0.0.2 path-selection color-vrf eng avt dataAvt router 12.0.0.1 
BGP routing table information for VRF default
Router identifier 0.0.0.1, local AS number 300
BGP routing table entry for Endpoint: 12.0.0.2, VNI: 100, VRF: eng, AVT: dataAvt (2), Router: 12.0.0.1
 Paths: 2 available
  Local
    12.0.0.3 from 12.0.0.3 (0.0.0.3)
      Origin IGP, metric -, localpref 100, weight 0, received 00:00:27 ago, valid, internal, best
      Extended Community: Route-Target-IP:12.0.0.1:0
      Rx SAFI: SR TE Policy

This command also offers a detail keyword to display more information. Its format is the same as the show bgp sr-te [detail] command.

show bgp neighbors <neighbor_address> [ ipv4 | ipv6 ] sr-te ( policies | received-policies | advertised-policies ) [ detail ]

BGP path selection is used to convey information among WAN Routing System routers for dynamic DPS tunnel establishment. The following command can be used to verify the tunnel information.

show bgp path-selection [detail]

#show bgp path-selection
BGP routing table information for VRF default
Router identifier 0.0.0.1, local AS number 300
Route status code: * - valid, S - Stale, q - Queued for advertisement

    NLRI      VTEP           Endpoint        Path Group    WAN ID  UDP Port
 *  ipv4Dps   12.0.0.1/32    10.1.1.1        MPLS               1      4793
 *  ipv4Ipsec 12.0.0.1/32    -               -                  -         -

#show bgp path-selection detail
BGP routing table information for VRF default
Router identifier 0.0.0.1, local AS number 300
Bgp routing table entry for ipv4Dps VTEP 12.0.0.3/32
 Paths: 1 available
  Local
    - from - (0.0.0.0)
      Origin IGP, metric -, localpref -, weight 0, received 00:01:57 ago, valid, local
      Tunnel encapsulation attribute: Dynamic path selection
        Endpoint: 10.0.0.1, Path group name: internet, WAN ID: 1, UDP port: 4793
      Extended community: route target
        Role: edge, region ID: 1, zone ID: 101, site ID: 1001
Bgp routing table entry for ipv4Ipsec VTEP 12.0.0.3/32
 Paths: 1 available
  Local
    - from - (0.0.0.0)
      Origin IGP, metric -, localpref -, weight 0, received 00:00:01 ago, valid, internal
      Tunnel encapsulation attribute: IP security
        Initial contact: true, Rekey counter: 1010101010, Nonce length: 25
        DH group: 1, DH key length: 18
        Encryption algo: aes128, Authentication algo: sha1