Blog Viewer

EVPN VPWS Validation on ACX7000

By Suneesh Babu posted 11-05-2022 10:58

  

Junos EVPN-VPWS feature supports 8,000 instances with 4,000 VLAN-UnAware and 4,000 VLAN-Aware Service Types on ACX7000 Platforms.                          

Introduction

This is the second article in the ACX7k Metro Validation Series:

In this article, we validate the EVPN-VPWS feature and its scale on ACX7100-32C with 22.2R1 Junos-EVO image.

RFC-8214 describes the VPWS support with EVPN. EVPN-VPWS is a point-to-point ethernet service based on BGP MPLS  connecting Customer Edge Devices (CEs) across a Provider Edge (PE) Network. The PEs of the network are connected over MPLS technology signalled via LDPRSVP or SR-MPLS.

JUNOS supports EVPN-VPWS functionality with the “evpn-vpws” Instance Type.

In this test, we create 8,000 EVPN VPWS Instances on ACX7100-32C:

  • 4,000 VLAN-Unaware Service Types
  • 4,000 VLAN-Aware Service Types.

The same scale is tested on ACX7100-48L as well as on ACX7509.

But the ACX7024 Scale is not covered in this article (same features but different scale are expected on this platform).

Please note that despite sharing the same ACX moniker, the ACX7000 products are different products than ACX500/710/1000/1100/2100/2200/4000/5000/5400/6000. They are powered by different Packet Forwarding Engines (PFE), and support different feature sets and scales.

The Key Performance Indicators (KPI) tested are:

EVPN VPWS KPI Scale
Number of VPWS instances 8,000
Number of VLAN-Unaware Service Types 4,000
Number of VLAN-Aware Service Types 4,000
Number of VLANs 12,000
Number of Interfaces 12,000
  

Metro EVPN-VPWS Topology

Test topology consists of three routers:

  • an ACX7100-32C is PE1
  • an ACX7100-48L is the PE2
  • PTX10008 is P1  

CEs are simulated using a traffic generator.  PEs are connected to CEs using 4x 100G links and to the core using 8x 100G links, which are bundled in 2x LAGs each having four links.

The ACX7100-32C is the Device Under Test (DUT). The underlay transport used for testing is SR-MPLS with both OSPF and ISIS protocols individually. In this validation, we also covered LDP as the underlay transport. The CE-bound interface configurations are of SP-Style (see glossary).

Figure 1: Lab topology
 
In this test, we configured 8,000 EVPN-VPWS instances: 4,000 are with VLAN-Unaware and the remaining are VLAN-Aware. Each VLAN-Unaware has one VLAN and for each VLAN-Aware, we have two VLANs. Bidirectional traffic in iMIX mode at 99.9% offer-load flows for all the EVPN-VPWS services. A total of ~798 Gbps traffic is transiting through the DUT.

Base Configuration

regress@PE1> show configuration protocols |display inheritance no-comments
bgp {
    group IBGP {
        type internal;
        local-address 12.1.1.1;
        family inet {
            unicast;
        }
        family evpn {
            signaling;
        }
        neighbor 12.1.1.3 {
            export nhself;
        }
    }
}
mpls {
    interface ae0.0;
    interface ae1.0;
}        
ospf {
    source-packet-routing {
        node-segment ipv4-index 101;
        srgb start-label 45000 index-range 2000;
    }
    area 0.0.0.0 {
        interface lo0.0 {
            passive;
        }
        interface ae0.0 {
            interface-type p2p;
        }
        interface ae1.0 {
            interface-type p2p;
        }
    }
}

regress@PE1>

EVPN-VPWS Routing-Instance Configuration

VLAN-Unaware EVPN-VPWS routing-instance is configured as follows:

interfaces {
    et-0/0/0 {
        flexible-vlan-tagging;
        encapsulation flexible-ethernet-services;
        unit 1 {
            encapsulation vlan-ccc;
            vlan-id 1;
            family ccc;
        }
    }
}
routing-instances {
    METRO_EVPN_VPWS_1 {
        instance-type evpn-vpws;
        protocols {
            evpn {
                interface et-0/0/0.1 {
                    vpws-service-id {
                        local 1001;
                        remote 2001;
                    }
                }
                flexible-cross-connect-vlan-unaware;
                group G1 {
                    interface et-0/0/0.1;
                    service-id {
                        local 1001;
                        remote 2001;
                    }
                }
            }
        }
        interface et-0/0/0.1;
        route-distinguisher 12.1.1.1:1;
        vrf-target target:65000:1;
    }
}

VLAN-Aware EVPN-VPWS routing-instances with two VLANs are as follows:

interfaces {
    et-0/0/2 {
        flexible-vlan-tagging;
        encapsulation flexible-ethernet-services;
        unit 1 {
            encapsulation vlan-ccc;
            vlan-id 1;
        }
    }
    et-0/0/0 {
        flexible-vlan-tagging;
        encapsulation flexible-ethernet-services;
        unit 2001 {
            encapsulation vlan-ccc;
            vlan-id 2001;
            family ccc;
        }
    }
}
routing-instances {
    METRO_EVPN_VPWS_4001 {
        instance-type evpn-vpws;
        protocols {
            evpn {
                interface et-0/0/2.1 {
                    vpws-service-id {
                        local 1001;
                        remote 2001;
                    }
                }
                interface et-0/0/0.2001 {
                    vpws-service-id {
                        local 1002;
                        remote 2002;
                    }
                }
                flexible-cross-connect-vlan-aware;
            }
        }
        interface et-0/0/2.1;
        interface et-0/0/0.2001;
        route-distinguisher 12.1.1.1:4001;
        vrf-target target:65000:4001;
    }
}

EVPN-VPWS CE Bound Interface Schema

The four CE-bound 100G interfaces are logically split across routing-instances as described in this chart:

PE1 PE2 Port Service Type VRF VLAN Association Traffic Load
et-0/0/0 et-0/0/48:0 P1 VLAN-Unaware 1-2000 1-2000 49.95%
et-0/0/1 et-0/0/48:1 P2 VLAN-Unaware 2001-4000 1-2000 49.95%
et-0/0/2 et-0/0/48:2 P3 VLAN-Aware 4001-6000 1-2000 99.9%
et-0/0/3 et-0/0/48:3 P4 VLAN-Aware 6001-8000 1-2000 99.9%
et-0/0/0 et-0/0/48:0 P1 VLAN-Aware 4001-6000 2001-4000 49.95%
et-0/0/1 et-0/0/48:1 P2 VLAN-Aware 6001-8000 2001-4000 49.95%

  

EVPN-VPWS Verification

The first step to verify the EVPN-VPWS service is to make sure that the PE devices are having BGP established with evpn-signalling. As shown below from PE1, BGP is in "established" state for the Peer PE2 (12.1.1.3) and bgp.evpn.0 table got populated with Type-1 Infra routes.

regress@PE1> show bgp summary
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 1 Peers: 1 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0               
                      35          1          0          0          0          0
inet6.0
                       0          0          0          0          0          0
bgp.evpn.0           
                   12000      12000          0          0          0          0
inet6.3              
                       0          0          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
12.1.1.3              65000       8011       8008       0       0          35 Establ
  inet.0: 1/35/35/0
  bgp.evpn.0: 12000/12000/12000/0
  METRO_EVPN_VPWS_1.evpn.0: 1/1/1/0
  METRO_EVPN_VPWS_2.evpn.0: 1/1/1/0
  METRO_EVPN_VPWS_3.evpn.0: 1/1/1/0
  ...
  METRO_EVPN_VPWS_3998.evpn.0: 1/1/1/0
  METRO_EVPN_VPWS_3999.evpn.0: 1/1/1/0
  METRO_EVPN_VPWS_4000.evpn.0: 1/1/1/0
  METRO_EVPN_VPWS_4001.evpn.0: 2/2/2/0
  METRO_EVPN_VPWS_4002.evpn.0: 2/2/2/0
  METRO_EVPN_VPWS_4003.evpn.0: 2/2/2/0
  ...
  METRO_EVPN_VPWS_7998.evpn.0: 2/2/2/0
  METRO_EVPN_VPWS_7999.evpn.0: 2/2/2/0
  METRO_EVPN_VPWS_8000.evpn.0: 2/2/2/0
  __default_evpn__.evpn.0: 0/0/0/0

regress@PE1>

VLAN Unaware EVPN-VPWS Verification

As shown below, the interface et-0/0/0.1 is bound to EVPN-VPWS instance METRO_EVPN_VPWS_1 with a single VLAN with vlan-id 1.

regress@PE1> show evpn vpws-instance METRO_EVPN_VPWS_1
Instance: METRO_EVPN_VPWS_1, Instance type: EVPN VPWS FXC
  Route Distinguisher: 12.1.1.1:1
  Number of local interfaces: 1 (1 up)

    Interface name  ESI                            Mode          Role       Status     Control-Word    Flow-Label-Tx    Flow-Label-Rx
    et-0/0/0.1      00:00:00:00:00:00:00:00:00:00single-homed    Primary    Up         No              No               No
        Local SID: 1001 Advertised Label: 16
        Remote SID: 2001
            PE addr         ESI                           Label  Mode           Role     TS                      Status
            12.1.1.3        00:00:00:00:00:00:00:00:00:00 16     single-homed   Primary  2022-10-21 02:40:19.916 Resolved
  Number of protect interfaces: 0

regress@PE1>

The routes of METRO_MAC_VRF_1 instance are shown below.

regress@PE1> show route table METRO_EVPN_VPWS_1.evpn.0

METRO_EVPN_VPWS_1.evpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1:12.1.1.1:1::0::1001/192 AD/EVI
                   *[EVPN/170] 2d 16:59:40
                       Indirect
1:12.1.1.3:1::0::2001/192 AD/EVI
                   *[BGP/170] 2d 16:55:47, localpref 100, from 12.1.1.3
                      AS path: I, validation-state: unverified
                    >  to 15.1.1.2 via ae0.0, Push 45103
                       to 15.1.2.2 via ae1.0, Push 45103

regress@PE1>

 

VLAN-Aware EVPN-VPWS Verification

In VLAN-Aware EVPN-VPWS case, the entire VLAN information is bound to that instance.

regress@PE1> show evpn vpws-instance METRO_EVPN_VPWS_4001
Instance: METRO_EVPN_VPWS_4001, Instance type: EVPN VPWS FXC VLAN AWARE
  Route Distinguisher: 12.1.1.1:4001
  Number of local interfaces: 2 (2 up)

    Interface name  ESI                            Mode          Role       Status     Control-Word    Flow-Label-Tx    Flow-Label-Rx
    et-0/0/0.2001   00:00:00:00:00:00:00:00:00:00single-homed    Primary    Up         No              No               No
        Local SID: 1002 Advertised Label: 4016
        Remote SID: 2002
            PE addr         ESI                           Label  Mode           Role     TS                      Status
            12.1.1.3        00:00:00:00:00:00:00:00:00:00 4016   single-homed   Primary  2022-10-21 02:40:23.424 Resolved

    Interface name  ESI                            Mode          Role       Status     Control-Word    Flow-Label-Tx    Flow-Label-Rx
    et-0/0/2.1      00:00:00:00:00:00:00:00:00:00single-homed    Primary    Up         No              No               No
        Local SID: 1001 Advertised Label: 4016
        Remote SID: 2001
            PE addr         ESI                           Label  Mode           Role     TS                      Status
            12.1.1.3        00:00:00:00:00:00:00:00:00:00 4016   single-homed   Primary  2022-10-21 02:40:23.424 Resolved
  Number of protect interfaces: 0

regress@PE1>

The BGP route table of the instance includes routes belonging to VLANs of the aware instance.

regress@PE1> show route table METRO_EVPN_VPWS_4001.evpn.0

METRO_EVPN_VPWS_4001.evpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1:12.1.1.1:4001::0::1001/192 AD/EVI
                   *[EVPN/170] 2d 17:01:18
                       Indirect
1:12.1.1.1:4001::0::1002/192 AD/EVI
                   *[EVPN/170] 2d 17:01:25
                       Indirect
1:12.1.1.3:4001::0::2001/192 AD/EVI
                   *[BGP/170] 2d 16:57:30, localpref 100, from 12.1.1.3
                      AS path: I, validation-state: unverified
                       to 15.1.1.2 via ae0.0, Push 45103
                    >  to 15.1.2.2 via ae1.0, Push 45103
1:12.1.1.3:4001::0::2002/192 AD/EVI      
                   *[BGP/170] 2d 16:57:30, localpref 100, from 12.1.1.3
                      AS path: I, validation-state: unverified
                       to 15.1.1.2 via ae0.0, Push 45103
                    >  to 15.1.2.2 via ae1.0, Push 45103

regress@PE1>

The following output captures the number of instances, vlan-unaware and vlan-aware in the DUT.

regress@PE1> show evpn vpws-instance |match "(1 up)" | count
Count: 4000 lines

regress@PE1> show evpn vpws-instance |match "(2 up)" | count
Count: 4000 lines

regress@PE1> show bgp summary |match "evpn.0" | count 
Count: 8003 lines

regress@PE1>

Traffic flows are load-balanced across the LAG bundles and the LAG member interfaces as shown below

PE1                               Seconds: 30                  Time: 19:46:21

Interface    Link  Input packets        (pps)     Output packets        (pps)

 ae0           Up  6672538985109   (31797317)    6562622375572   (31273400)
 ae1           Up  6452705368593   (30750384)    6562622460395   (31274253)
 esi           Up              0          (0)                0          (0)
 et-0/0/0      Up  3281521334639   (15638860)    3281521039897   (15638591)
 et-0/0/1      Up  3281521210490   (15638642)    3281521065394   (15638962)
 et-0/0/2      Up  3281099910919   (15633867)    3281099930514   (15633920)
 et-0/0/3      Up  3281099946314   (15633783)    3281099945857   (15633649)
 et-0/0/4      Up              0          (0)             8460          (0)
 et-0/0/5    Down              0          (0)                0          (0)
 et-0/0/6      Up  1740727408250    (8295101)    1647217803561    (7849444)
 et-0/0/7      Up  1659520685579    (7908298)    1634093396240    (7787043)
 et-0/0/8      Up  1690694107451    (8056796)    1647217784947    (7849711)
 et-0/0/9      Up  1581596783829    (7537122)    1634093390824    (7787202)
 et-0/0/10     Up  1696433009095    (8084274)    1647217832273    (7849813)
 et-0/0/11     Up  1617688474851    (7709175)    1634093403093    (7787259)
 et-0/0/12     Up  1624252786691    (7740317)    1647217809682    (7849859)
 et-0/0/13     Up  1514331097956    (7216618)    1634093415347    (7787322)

Generating Scale Configuration

The Python Script is having three components:

  • a Jinja File capturing the various configuration templates,
  • a Params File capturing the various user variables
  • a script using the two input files above and generating the required configurations and committing them in the router.

Note: The configs are generated as per the CE-bound interface schema.

Configuration Template

The template contains configurations for both interfaces which are part of the routing instances and routing instance configurations.

# Routing Instance Configuration
# File Name: evpn_vpws_jinja.j2
# Version: 1.0
groups {{group_name}} {
    interfaces {
        {{ifd_name}} {
            flexible-vlan-tagging;
            encapsulation flexible-ethernet-services;
            {%- for unit_id, vlan_id in ifl_variables %}
            unit {{unit_id}} {
                {%- if vlan_unaware_service %}
                vlan-id {{vlan_id}};
                encapsulation vlan-ccc;
                family ccc;
                {%- endif %}
                {%- if vlan_aware_service %}
                encapsulation vlan-ccc;
                vlan-id {{vlan_id}};
                {%- endif %}
            }
            {%- endfor %}
        }
    }
    routing-instances {
        {%- for vrf_id, ifl_name, vlan_id in evpn_vpws_variables %}
        METRO_EVPN_VPWS_{{vrf_id}} {
            instance-type evpn-vpws;
            interface {{ifl_name}};
            route-distinguisher {{router_id}}:{{vrf_id}};
            vrf-target target:{{local_as_no}}:{{vrf_id}};
            protocols {
                evpn {
                    interface {{ifl_name}} {
                        vpws-service-id {
                            local {{vpws_local_service_id}};
                            remote {{vpws_remote_service_id}};
                        }
                    }
                    {%- if vlan_unaware_service %}
                    {%- if enable_fxc %}
                    group G1 {
                        interface {{ifl_name}};
                        service-id {
                            local {{vpws_local_service_id}};
                            remote {{vpws_remote_service_id}};
                        }
                    }
                    flexible-cross-connect-vlan-unaware;
                    {%- endif %}
                    {%- endif %}
                    {%- if vlan_aware_service %}
                    {%- if enable_fxc %}
                    flexible-cross-connect-vlan-aware;
                    {%- endif %}
                    {%- endif %}
                }
            }
        }
        {%- endfor %}
    }
}

Configuration Parameters

---
# This file contains the parameters for evpn vpws configuration building
# File Name: evpn_params.yaml
# Version: 1.0

#Host Name
host: 'PE1.englab.juniper.net'

#UserName and Password
username: 'regress'
password: 'xxxxx'

#Config Group Name
group_name: 'METRO_EVPN_VPWS'

#vrfname creation
vrf_id: 1

#maximum evpn instances
vrf_max: 10

#interface name
ifd_name: 'et-0/0/0'

#ifl_start unit
ifl_start_unit: 1

#vlan_id start
vlan_id_start: 1

#My AS no
local_as_no: 65000

#My Router ID
router_id: '12.1.1.1'

#EVPN Service Type:
enable_fxc: True 
vlan_unaware_service: False
vlan_aware_service: True

#VPWS Service ID
vpws_local_service_id: 1001  # At PE1
vpws_remote_service_id: 2001 # At PE1
# vpws_local_service_id: 2001  # At PE2
# vpws_remote_service_id: 1001 # At PE2

# vpws_local_service_id: 1002  # At PE1 for vlanaware ifl-2
# vpws_remote_service_id: 2002 # At PE1 for vlanaware ifl-2
# vpws_local_service_id: 2002  # At PE2 for vlanaware ifl-2
# vpws_remote_service_id: 1002 # At PE2 for vlanaware ifl-2

Configuration Script

#! /usr/bin/python
"""
    FileName: create_evpn_vpws_vrf.py
    Version: 1.0
    Description: This script will create evpn vpws vrf instances and configure it on the router
    Author: Suneesh Babu
"""
import yaml
from glob import glob
from jinja2 import Template
import ipaddress
from jnpr.junos.utils.config import Config
from jnpr.junos import Device
from jnpr.junos.factory import loadyaml
from jnpr.junos.op import *

def iflrange(ifd_name, start_unit, max):
    """
    This subroutine yields the specified number of l3 ifls for the ifd
    """
    while(max):
        iflname = ifd_name + '.' + str(start_unit)
        yield iflname
        start_unit += 1
        max -= 1

def router_operation(config_filename, data, mode):
    """
        This sub-routine connectes to the router and do the necessary commit operations
    """
    router = Device(host=data['host'], user=data['username'], password=data['password'], port=22)
    router.open()

    cfg = Config(router)
    if mode == 'jinja':
        cfg.load(template_path=config_filename, template_vars=data, format='text', merge=True)
    elif mode == 'setfile':
        cfg.load(path=config_filename, format='set')
    cfg.pdiff()
    cfg.commit()
    router.close()

def jinja_template_input(data):
    """
        This sub-routine yields the variables required for the jinja template
    """
    ifl_unit_list = range(int(data['ifl_start_unit']), int(data['ifl_start_unit']) + int(data['vrf_max']))
    vlan_list = range(int(data['vlan_id_start']), int(data['vlan_id_start']) + int(data['vrf_max']))

    vrf_id_list = range(int(data['vrf_id']), int(data['vrf_id']) + int(data['vrf_max']))
    ifl_name_list = iflrange(data['ifd_name'], data['ifl_start_unit'], int(data['vrf_max']))

    return zip(ifl_unit_list, vlan_list), zip(vrf_id_list, list(ifl_name_list), vlan_list)

def main():
    """
       To Build the desired number of evpn-vpws instances
    """
    print("Step-1: Read the Variables from the Params File")
    with open(glob('evpn_vpws_params.yaml')[0]) as fh:
        data = yaml.safe_load(fh.read())

    print("Step-2: Build the Data Feed for the Jinja Template Input")
    ifl_attributes, evpn_vpws_attributes = jinja_template_input(data)
    data['ifl_variables'] = ifl_attributes
    data['evpn_vpws_variables'] = evpn_vpws_attributes

    print("Step-3: Build the configuration file from Jinja Template")
    with open(glob('evpn_vpws_jinja.j2')[0]) as t_fh:
        t_format = t_fh.read()
    evpn_snippet = Template(t_format)
    # print (evpn_snippet.render(data))

    print("Step-4: Load the config into router and commit it")
    router_operation('evpn_vpws_jinja.j2', data, 'jinja')

if __name__ == '__main__':
    main()

Traffic Generator Configuration

Hosts are simulated as follows:

Figure 2: Host configuration on the traffic generator

CPU Usage during Traffic Flow

The 12 Core ACX7100-32C remains idle at 93% during the traffic flow

Figure 3: CPU Utilization

Data Plane Traffic Verification

As shown below traffic flows at 99.9% of 100G links over 4 CE bound interfaces and no packet drops are seen for a duration of 58 hours.

Figure 4: Traffic on 58+ hours

Conclusion

In this article, we demonstrate the ACX7k (ACX7100-32C, ACX7100-48L, ACX7509) platforms scale for EVPN VPWS use-cases, proving these routers are ready for the Metro deployments and capable of delivering various ethernet business services of Metro. Next TechPost article will be dedicated to L3VPN scale validation.

References

Glossary

  • BGP – Border Gateway Protocol
  • CE – Customer Edge Node
  • DUT – Device Under Test
  • EVPN – Ethernet Virtual Private Network
  • FXC – Flexible Cross Connect
  • KPI – Key Performance Indicators
  • LAN – Local Area Network
  • MPLS – Multi Protocol Label Switching
  • OSPF – Open Shortest Path First
  • P/PE – Provider/Provider Edge Node
  • SP Style – Service Provider Style
  • SR-MPLS – Segment Routing - MPLS
  • VLAN – Virtual LAN
  • VPWS – Virtual Private Wired Service
  • VRF – Virtual Routing and Forwarding

Acknowledgement

Many thanks to Ramdas Machat, Deepak Kumar Tripathi, Vasily Mukhin and Nicolas Fevrier for reviewing the article and providing the feedback.

Feedback

Revision History

Version Author(s) Date Comments
1 Suneesh Babu November 2022 Initial publication


#Validation
#ACXSeries

Permalink