Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Results Summary and Analysis

Comprehensive validation testing was performed to verify the architecture, functionality, and traffic flows described in this validated design. The following key results were observed:

  1. The devices listed in Table 9: Devices Under Test are the devices validated using Junos OS releases listed in this validated design.
  2. Validation testing confirmed that Apstra Data Center Director 6.2 supports the EVPN-VXLAN architecture described in this validated design, including the deployment of a Bridged Overlay (BO) fabric with Anycast IRB gateways hosted on the Border Leaf switches as described in EVPN VXLAN Data Center Fabric. Apstra applies crb-proxy-mac configuration on leaf switches to avoid packet drops due to ARP refresh. See CRB Proxy MAC Option for Bridged Overlay Fabric.
  3. In RFC 7432, service carving is the technical term used to describe the default EVPN Designated Forwarder (DF) election mechanism using the modulo math algorithm. In an active-standby deployment, service carving splits VLANs between both links (for example, leaf switch-1 handles VLAN 10, leaf switch-2 handles VLAN 20). This forces both links to remain physically up, breaking the intended primary-backup model and causing split-brain routing that leads to traffic failover issues. To overcome this issue, the df-election-granularity per-esi knob is designed to override default behavior of RFC 7432, which then disables per-VLAN service carving and keeps only one leaf link active. The following configuration should be applied to all multi-homed leaf switches.
set interfaces interface-name esi df-election-granularity per-esi
  1. The automated deployment of the Blueprint was carried out using Terraform especially useful when lots of Virtual Network (VN), switching zone and Routing zone must be created.

Note: Apstra allows deployment of bulk Virtual Network, switching zone and routing zone using Import CSV option in the User Interface, see Apstra user guide. However, for the virtual network where leaf devices assigned to the Virtual Network (VN) do not require IRB, the disabling of IRB must be performed from the User Interface for each Virtual Network. Alternatively, scripts were used to bulk disable IRB on leaf switches which operate as layer 2 switches.

  1. End-to-end testing successfully validated connectivity and traffic forwarding for:
  • JCNR-to-JCNR communication
  • SR-IOV-to-SR-IOV communication
  • JCNR-to-SR-IOV communication
  • Inter-subnet communication
  • Inter-tenant communication

  1. Validation confirmed that the Off-Ramp Gateway acts as the centralized routing and policy enforcement point within the solution. The Off-Ramp Gateway performs inter-network routing, inter-VRF route leaking, inter-tenant connectivity, and route exchange between the JCNR MPLS-over-UDP domain and the SR-IOV Q-in-Q domain.

  2. Validation also confirmed the separation of control-plane and data-plane functions:

  • The vRR provides scalable BGP route distribution and VPN route reflection.
  • The EVPN-VXLAN fabric provides transport reachability.
  • The Off-Ramp Gateway provides centralized inter-VRF routing, policy enforcement, and service integration.
  • JCNR provides the tenant overlay using MPLS over UDP tunnels.

Overall, the validated design demonstrated a scalable and operationally consistent multi-tenant Telco Cloud architecture supporting both cloud-native JCNR workloads and high-performance SR-IOV workloads while maintaining tenant isolation and centralized policy control.

For a detailed test results report including Scale test numbers, see the Test Report Brief for more information on the tests performed.