diff --git a/ansible_collections/arista/avd/examples/cv-pathfinder/README.md b/ansible_collections/arista/avd/examples/cv-pathfinder/README.md index 07f3e07a486..ad6383ec0a9 100644 --- a/ansible_collections/arista/avd/examples/cv-pathfinder/README.md +++ b/ansible_collections/arista/avd/examples/cv-pathfinder/README.md @@ -321,30 +321,24 @@ examples/cv-pathfinder/group_vars/WAN//cv_pathfinder_settings.yml --8<-- ``` -1. `cv_pathfinder_regions` is used to declare the Regions, Sites and their location in the WAN network +1. `cv_pathfinder_regions` is used to declare the Regions, Sites, and their location in the WAN network 2. `cv_pathfinder_global_sites` is used to add location for "Global" Pathfinders. -3. `wan_route_servers` define the Pathfinders each router should connect to. It - is possible to have this variable for instance at a group level to have - per-region Pathfinders. -4. `wan_ipsec_profiles` is used to control IP Security configuration, these +3. `wan_route_servers` defines the Pathfinders each router should connect to. This variable can also be used to have per-region pathfinders, for instance, at a group level. +4. `wan_ipsec_profiles` is used to control IP Security configuration; these settings are required. -5. For lab purposes Flow tracking is enabled on uplinks and downlinks. Make sure +5. For lab purposes, Flow tracking is enabled on uplinks and downlinks. Make sure to verify the scalability of CloudVision depending on your network in Production. -6. `bgp_peer_groups` using listen range to establish sessions between WAN - routers and the Pathfinders. `wan_rr_overlay_peers` control connection - between Pathfinders which is a full mesh. +6. `bgp_peer_groups` uses listen range to establish sessions between WAN routers and the Pathfinders. `wan_rr_overlay_peers` controls the connection between Pathfinders, which is a full mesh. 7. When a carrier is not trusted (like the Internet ones), AVD requires an - ingress ACL on the WAN interfaces. Each carrier is tied to a path-group + ingress ACL on the WAN interfaces. Each carrier is tied to a path-group. 8. More on virtual topologies after the snippet. -9. Application classification is used to configure `application_profiles` used - to match categories of traffic in the policies, in order to apply them a - virtual topology. +9. Application classification is used to configure `application_profiles` that match traffic categories in the policies and apply them to a virtual topology. #### Virtual topologies -The cornerstone of CV Pathfinder solution are the Virtual Topologies. -The Virtual Topologies are grouped in Policies, a policy is a list of match +The cornerstone of the CV Pathfinder solution is the Virtual Topologies. +The Virtual Topologies are grouped into Policies. A policy is a list of match statements, each matching a specific `application profile` and applying a `profile` (the Virtual Topology) to this traffic. A policy may or may not have any default match. If no default match is configured, unmatched traffic is @@ -355,11 +349,11 @@ internet-exit policy (not in this example). The load balancing policy defines which path-groups can be used for the traffic. As explained above, the `wan_virtual_topologies` variable must be global. AVD -decides for each device, based on the locally present path-groups, how to -configure the policies (e.g. if some traffic being matched is configured to only be -sent over the `MPLS` path-group but there is no local WAN interface connected -to `MPLS` then the match statement, profile and load-balance policy is not -generated by AVD on the device). +decides how to configure the policies for each device based on the locally present +path groups. For example, if some traffic being matched is configured to only be sent over +the `MPLS` path group but there is no local WAN interface connected to `MPLS`, then +the match statement, profile, and load-balance policy are not generated by AVD on the +device. For this example, we define two policies, one for each VRF BLUE and RED. @@ -412,12 +406,12 @@ examples/cv-pathfinder/group_vars/WAN//l3_interface_profiles.yml ### Tenants -The tenants are defined globally, in this example we create SVIs in BLUE and RED -VRFs for testing purposes. +The tenants are defined globally. In this example, we create SVIs in the BLUE and +RED VRFs for testing purposes. -Notice that the `vrf_vni` is configured for BLUE and RED VRFs, this is -potentially different from the `wan_vni` configured under -`wan_virtual_topologies.vrfs`. The former is used for EVPN while the latter is +Notice that the `vrf_vni` is configured for the BLUE and RED VRFs. This +potentially differs from the `wan_vni` configured under +`wan_virtual_topologies.vrfs`. The former is used for EVPN, while the latter is used for DPS. ```yaml title="group_vars/WAN/tenants.yml" @@ -440,17 +434,17 @@ examples/cv-pathfinder/group_vars/PATHFINDERS.yml !!! Note For convenience in the example, both the WAN routers and the LAN devices - (borders, leaf, ...) are defined in the same group_vars file. It would be + (borders, leaf, etc.) are defined in the same group_vars file. It would be possible to separate them. As general principles: -- WAN routers should configure as `uplink_switches` the LAN devices. +- WAN routers should configure the LAN devices as `uplink_switches`. - Each WAN router is assigned to a site. When two routers are part of a node_group, HA will be configured. ### Site 1 -The following diagrams describe the Site1 physical, LAN and HA tunnels connectivity. +The following diagrams describe the connectivity of Site 1's physical, LAN, and HA tunnels. === "Physical" @@ -464,7 +458,7 @@ The following diagrams describe the Site1 physical, LAN and HA tunnels connectiv === "HA Tunnels" - By default AVD is using all uplink interfaces for the LAN_HA path groups. EOS then establish an IPsec tunnel between all pairs of local and remote connections, in this scenario there are four tunnels created for the LAN_HA path group. + By default, AVD uses all uplink interfaces for the LAN_HA path groups. EOS then establishes an IPsec tunnel between all pairs of local and remote connections. In this scenario, four tunnels are created for the LAN_HA path group. ![Figure: Site 1 HA Tunnels](images/site1-ha.png){: style="height:700px"} @@ -474,7 +468,7 @@ examples/cv-pathfinder/group_vars/SITE1.yml --8<-- ``` -1. The uplink type `p2p-vrfs` is used to connect to the LAN switches +1. The uplink type `p2p-vrfs` is used to connect to the LAN switches. 2. `cv_pathfinder_transit_mode` defaults to `none` and the site is considered an `edge` site. To use it as transit, the variable must be set to `region` as it is the case here. ### Site 2 @@ -585,4 +579,4 @@ For any question reach out to AVD maintainer over [Github discussions](https://g - AVD version - Python version - EOS version in your lab (if relevant) -- Whether you are using CVaaS or CV on prem (and in this case the version) +- Whether you are using CVaaS or CV on-premises (and, in this case, the version)