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 AWE-7200R and CloudEOS router 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.

Dynamic Path Selection (DPS) is a AWE-7200R and CloudEOS router 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 AWE-7200R and CloudEOS router 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).

The CloudVision Pathfinder software running on the RR receives a full view of the AWE-7200R and CloudEOS router 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 AWE-7200R and CloudEOS router network. AVTs classify different types of traffic and require varying quality of service treatment in the AWE-7200R and CloudEOS router. 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 AWE-7200R and CloudEOS router 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.

AWE-7200R and CloudEOS router 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 AWE-7200R and CloudEOS router 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 AWE-7200R and CloudEOS router 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 AWE-7200R and CloudEOS router 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 AWE-7200R and CloudEOS router 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 AWE-7200R and CloudEOS router Routing System routers and propagates it to other RRs. It does not need to propagate all the information back to the AWE-7200R and CloudEOS router 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 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 ProtoIDRouter IDNLRI SpecificPeerPath
 * >node DPS0 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 ProtoIDRouter IDNLRI SpecificPeerPath
 * >link DPS0 12.0.0.1 RRID: 12.0.0.2- -
 WAN ID: Local 1 Remote 1
 WAN Group ID: Local 100
 * >link DPS0 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
EndpointColor Distinguisher Next HopMetricLocPref WeightPath
 * >12.0.0.2eng:voiceAvt12.0.0.112.0.0.3- 100 0 i
 * >12.0.0.2eng:dataAvt 12.0.0.112.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 AWE-7200R and CloudEOS router 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

NLRIVTEP EndpointPath GroupWAN IDUDP Port
 *ipv4Dps 12.0.0.1/3210.1.1.1MPLS 14793
 *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