Technica Corp validates Anuta NCX for L2 VPN Provisioning

Executive Summary

IT teams face unprecedented challenges to support dynamic interconnectivity and communication requirements on top of a complex and rapidly evolving infrastructure. In recent years, the use of Layer 2 Virtual Private Network (L2VPN) transport has helped significantly in simplifying the visible architectures of customer networks while providing the quality of service that customers need. For the service provider, it permits the reuse of legacy transport to extend its lifespan and simplify ongoing migrations to more modern infrastructure while allowing the ability to efficiently meet customer bandwidth requirements on a shared transport medium.

But with every savings and simplification there comes a cost, and in this case, it’s the addition of complexity and operational overhead of maintaining a diverse communications infrastructure that utilizes complex routing and forwarding protocols across an ever-increasing footprint to assure a secure and efficient service for its customer base. Using typical vendor-provided tools, this creates a non-linear growth in operational overhead. A vendor-agnostic orchestration helps deliver rapid network services for multi-vendor infrastructure.

Anuta NCX platform with it’s layered, YANG model-driven and abstraction approach helps in delivering vendor neutral, extensible and maintainable services for multiple domains such as Branch/CPE, Data Center, Cloud, and Carrier Core networks. The NCX platform enables customers and partners to develop their own Service and Device models for complete customization within few days. Many large enterprises and service providers have deployed NCX to orchestrate their brownfield and greenfield networks.

Significance of L2VPN and Benefits

The significance of L2VPN transport is based upon one simple idea. Throughout the past 40+ years, numerous internetworking designs and transport protocols have come and gone, but Ethernet, despite of its changes and augmentations, has remained as the layer 2 technology of choice. Nearly all external data communications paths terminate to a device that is connected via IP over Ethernet L2 signaling, and even virtualized communications within hosts is designed to mimic this technology due to its extensive dissemination of knowledge and broad multivendor support.

L2VPNs provide the ability to emulate Ethernet, as well as various other layer 2 topologies such as Frame Relay, ATM, TDM, and a multitude of signaling on fixed wireline services. This is typically accomplished by interconnecting Ethernet segments over Metropolitan Ethernet or MPLS backbones.

Due to the advanced policy-based forwarding, QoS, and fast recovery characteristics that MPLS provides, L2VPN over MPLS continues to grow in popularity.The Challenge

Unfortunately, MPLS, with its multiple routing and label-distribution protocols, virtualized routing, and policy-based forwarding options, can become very complicated and time-consuming to support. This is especially true when we look at the various extensions and enhancements that are not always universally supported across hundreds of vendor platforms. Most LAN, Datacenter (DC), and even Service Provider (SP) staff are not highly skilled in supporting the various technologies that MPLS-based L2VPN topologies require. Until recently, MPLS support was left to the carriers to handle, with Ethernet handed off at the LAN or Datacenter demarcation point, but the benefits of L2VPNs and underlying MPLS configurations have become apparent in the DC, into the cloud environments, and even in some LAN configurations.

The manual process

For most of the history of electronic communications, design, implementation, and support staff have used the Command Line Interface (CLI) when available to provision equipment and troubleshoot problems within the network. This requires staffing to have not only knowledge of the protocols and technologies used within the design, but also vendor-specific knowledge of how to configure and monitor each piece of equipment based on its series and model as well as the software version and any changes that occur between each software release. For anybody who has read the design, configuration, and command reference guides, you’ll find that manuals can run into several thousand pages, while others are broken in to as many as 20 different guides of several hundred pages each for a given product, and new guides are written for each feature and software release. The training or self-learning time can sometimes take months, and much of the design and operations staff find that they must spend as much or more of their time learning about products as they do using them.In reality, the commonly used per-device CLI configuration methodology allows for great flexibility, but it is time consuming and error-prone, and it requires many hours of vendor-specific learning by engineers that could be better spent designing and testing new solutions and service offerings. Multi-vendor Networks

In this case, it’s no wonder why many companies or government agencies find it easier to hire or contract subject matter experts (SMEs) from vendors and other support agencies at several hundred dollars per hour to support these devices. But even experts are prone to mistakes, and mistakes cost time and money, and the more boxes that need to be configured for each additional service, the more mistakes will arise. Of course, contracting SMEs also leads to a lack of internal knowledge, vendor lock-in, and even bottlenecks in most systems, as demand for support on various products fluctuates and service and infrastructure deployment and upgrade timelines continue to slip. Time is money for both unrealized revenue gains as well as lost competitiveness.

Multi-vendor Networks and Compliance

Another issue that we find with the current model is that through the CLI, the configuration process is prone to inconsistencies. Engineers who perform these tasks tend to have develop a myriad of methods to speed the process or shortcut the process when needed. This leads to the possible compounding variables within the network. Even if all staffing followed strict policies, those policies change from time-to-time and staffing turnover leads to new problems.

Depending on how the organization’s security model is designed, there is also the issue of tracking changes, documenting and organizing this information, and determining how to analyze any issues or recover from mistakes. Many organizations have suites of applications that are designed to track this information, but it remains costly and doesn’t address the ability to rollback these mistakes once they are discovered or how to integrate products that don’t support these granular feature sets. Organizations that use these products frequently find themselves with untold quantities of data, and now have a big-data issue they need to address to parse, categorize, and analyze this data. On top of this, any application or system used to address these issues also needs to be secured, licensed, and managed.

For governmental organizations, this can get very costly when trying to meet auditing and compliance requirements.

Anuta NCX

Anuta NCX takes a different approach to configuration and management of these devices. NCX uses the YANG/NETCONF modeling framework to abstract multi-vendor physical and virtual infrastructure and it provides self-service portal. The rich YANG model enables Anuta NCX to integrate seamlessly with any platform, device or interface/protocol, delivering a truly open architecture. NCX integrates with the rest of the enterprise software including Assurance, Compliance and Ticketing systems. The RESTful APIs and model-driven templates enables Anuta NCX to integrate with management platforms such as OSS, BSS and Self-Service Portal; and via Southbound Interfaces such as CLI, REST, YANG, NETCONF connects to VNFs, the SDN Controller and VIMs.

Anuta NCX Architecture

Current vendor and device support includes such common names as Cisco, Juniper, F5, Fortinet, HP, and Palo Alto, covering both physical and virtual devices. However, Anuta uses an open YANG model architecture, which allow simple and fast adaption of any vendor or product that supports NETCONF/YANG. For those that don’t, NCX also provides API interfaces to communicate with external devices and systems, as well as support for both CLI and SNMP southbound communications to allow granular control of legacy devices, while still providing the same level of automation and service-oriented deployment activities. The best part is that to the user, there is no visible difference in the operation of the system or actions that need to be performed in order to provision, de-provision, or monitor devices in the network using Anuta NCX.In other words, NCX truly provides a product-agnostic, multi-vendor Network Service Orchestration.

 For example, in a datacenter interconnect model, L2VPNs have become very popular, allowing interconnectivity between layer 2 switches within the datacenter across varying distances, but with the intelligent quality of service and rapid recovery capability of MPLS that allows their systems to achieve their Service Level Agreements (SLAs) as promised to their customer.

The use of transparent bridging over the L2VPN circuit also allows the datacenter managers to determine where they want to either route or bridge between hosting equipment and cloud environments, so that even down to the user level, each customer can determine how to meet their application requirements. However, management of interconnectivity doesn’t end at the customer demarcation point. To get to your cloud, you still need to navigate the datacenter switching infrastructure.

The Anuta NCX platform allows you to create a service model that separates the device provisioning from the service provisioning. Although NCX does have the ability to do device level checks and monitoring so you can see all the information that can be pulled from each device through various methods, through the service model interface, all you see are the menu options you need to provision the interconnect service request and the status of its activity.

NCX uses industry standard YANG implementation. Hence, customers can import IETF standard YANG models to NCX and customize them as per their requirements.Deploying L2VPN Use CaseWith Anuta NCX, we have demonstrated how you can use the same system to provision an L2VPN path across an MPLS connection service, while provisioning endpoint services within the datacenter to get your traffic where it is needed with single service provisioning action. And the best part is that this activity can be easily performed by an operator with little or no knowledge of the underlying protocols, technology, or equipment specifics, just by filling in the required information from a service request ticket into the Anuta NCX service interface.

Menus can be easily customized to provide as simple or as flexible a service as needed, while underneath, NCX can utilize any one of its various device interfaces to perform the provisioning, validation checks, and notification of service activation. NCX also handles any configuration rollback functions if needed, without service interruptions, and adds the ability to save these service requests to be scheduled during maintenance windows or to await service activation approvals from designated personnel.NCX Orchestrates Multi-Vendor L2 VPN

Anuta NCX adopts the IETF standard L2VPN Yang service model for L2VPN service orchestration. In our use-case, two service models were created to simulate typical real-world scenarios where the L2VPN service is provisioned by the service provider, and the endpoint services are provisioned by the enterprise or datacenter manager. However, for end users who utilize fixed wireline services or dedicated circuits, these two services may be easily combined and provisioned as a single step.

In the first step, we create the L2VPN VPLS service by adding values from the service ticket request

The basic configuration steps for the VPLS creation are as follows:

• Set the L2 VPN type and discovery
–Add route distinguisher, Add VPN target ID
–BGP signalling – Add site range
–Add VPLS Endpoint 1
–Add VPLS Endpoint 2
–Add additional VPLS Endpoints

Keeping in mind that this is a service provider template that allows for broad flexibility in the provisioning of L2VPN services, the values to be entered are below (in blue):

– VPN type and discovery:
• Name: PE1-2_VPLS600 (set by internal policy)
• Type: vpls-instance-type (dropdown select)
• Service Type: l2vpn-service (dropdown select)
• Discovery Type: bgp-auto-discovery (dropdown select)
• Signalling Type: bgp-signaling (dropdown select)

– BGP Auto-discovery
• Route Distinguisher: 27600:1 (dropdown select)
• VPN Target

– Rt-Value: target:27600:1 (dropdown select)

– Rt-type: Both (dropdown select)
– BGP Signaling
• Site Range: 10

– PE1 Endpoint
• Name: PE1-2.600 (set by internal policy)
• Device IP: EJ1_90.13_MX (node name or IP address – dropdown select)
• Interface: ge-0/0/2
• Subinterface ID – check
• VLAN-ID: 600
• Route Map: ABL270000-fwd (dropdown select)
• Site ID: 1
• BGP Community: ABL270000-com (dropdown select)
• In-QoS Policy: POLICER-100M (dropdown select)
• AC or PW or Redundancy Group: AC (dropdown select)

– PE2 Endpoint
• Name: PE2-2.600 (set by internal policy)
• Device IP: EJ2_90.14_MX (node name or IP address – dropdown select)
• Interface: ge-0/0/2
• Subinterface ID – check
• VLAN-ID: 600
• Route Map: ABL270000-fwd (dropdown select)
• Site ID: 2
• BGP Community: ABL270000-com (dropdown select)
• In-QoS Policy: POLICER-100M (dropdown select)
• AC or PW or Redundancy Group: AC (dropdown select)

– Additional PE Endpoints for multipoint circuits

Although the menu options above may seem to have a lot of values to enter, this service model was created to handle an array of L2VPN circuit types and can be simplified to fit individual needs. Also note from the menu display below that this allows for various additional services.

The CLI commands that would need to be created to perform these steps on a single PE Endpoint can be seen below as well:

set interfaces ge-0/0/2 vlan-tagging
set interfaces ge-0/0/2 encapsulation vlan-vpls
set interfaces ge-0/0/2 unit 600 encapsulation vlan-vpls
set interfaces ge-0/0/2 unit 600 vlan-id 600
set interfaces ge-0/0/2 unit 600 family vpls policer input POLICER-100M
set policy-options policy-statement ABL270000-fwd term a from community ABL270000-com
set policy-options policy-statement ABL270000-fwd term a then install-nexthop lsp pelocal-to-peremote
set policy-options policy-statement ABL270000-fwd term a then accept
set policy-options community ABL270000-com members target:20760:1
set firewall policer POLICER-100M if-exceeding bandwidth-limit 100m
set firewall policer POLICER-100M if-exceeding burst-size-limit 100k
set firewall policer POLICER-100M then discard
set routing-instances vpls-600 instance-type vpls
set routing-instances vpls-600 interface ge-0/0/2.600
set routing-instances vpls-600 route-distinguisher 10001:1
set routing-instances vpls-600 vrf-target target:10001:1
set routing-instances vpls-600 protocols vpls site-range 10
set routing-instances vpls-600 protocols vpls site vpls-600 site-identifier 1

Although it may not seem like a lot of provisioning needed to perform the actions contained within the menu, we all know that the number of options and variables is many times in the thousands, and that in a CLI world, each of these configuration variations should be tested in a test or development network to validate functionality for each software revision prior to deployment into a production network.

Network engineers also need to create rollback, modification, and de-provisioning procedures for removing or recovering from each of these services. The real power of Anuta NCX provisioning is understood when you consider that the manuals that you need to read in order to provision this service on just one provider edge device via the usual CLI process consist of 7,538 pages (JUNOS 16.1 on an MX-series router):

  • Juniper MX L2VPN and VPLS Feature Guide: 1,662 pages
  • Juniper MX Ethernet Interface Guide: 1,986 pages
  • Juniper MX Interface Fundamentals: ` 2,312 pages
  • Juniper MX Routing, Firewall, Traffic Policers Guide 1,578 pages

This does not include command reference guides that may be needed to provide additional reference to command options and parameters. Of course, Cisco and vendor devices provide the same level of effort when you are using carrier class equipment that is flexible enough to support multiple service levels over various transport modes.

Now you can have your network engineers working in the lab or in a test environment developing new services and not in the production network provisioning the services. In this way, engineering labor can be leveraged and multiplied hundreds of times.

The Attached screenshots highlights the information discussed above.Full L2 VPN Service Model

VPLS Endpoint Sub-Menu

Full L2 Edge Menu Hierarchical Structure

In the second step, we create the L2 Endpoint service by adding values from the customer’s service ticket request, but in this instance, one device was a legacy switch that didn’t support NETCONF and we didn’t want to use vendor APIs, since CLI configuration was relatively easy. The other device was configured using NETCONF.

The basic configuration steps for the L2 Edge creation are as follows:

• Create a service name for the data path
– Select the first device to configure
• Select the desired interface
• Select interface switching mode
• Select the desired VLAN or VLANs to apply

• Select any additional interfaces and options
– Select the second device to configure 
• Select the desired interface
• Select interface switching mode
• Select the desired VLAN or VLANs to apply

• Select any additional interfaces and options
– Select any additional endpoints or data path devices for multipoint switching services.

In this instance, we assumed that the datacenter or enterprise manager would have strict policies on interconnect requirements, so we only exposed the basic parameters that would need to be set by an operator. All other options were set automatically without operator input the values to be entered are below (in blue):

• Service-Name: L2vpls600-edge
– Device 1 Name: 3750_EC9004i (dropdown select)

• Interface-Name: FastEthernet4/0/47 (dropdown select)
– Interface Mode: Trunk (dropdown select)
– VLAN ID: 600 (dropdown select)

• Interface-Name: FastEthernet4/0/3 (dropdown select)
– Interface Mode: Access (dropdown select)
– VLAN ID: 600 (dropdown select)

• Interface-Name: FastEthernet4/0/4 (dropdown select)
– Interface Mode: Access (dropdown select)
– VLAN ID: 600 (dropdown select)
– Device 2 Name: EX4300_EJ9003i (dropdown select)

• Interface-Name: ge-0/0/47 (dropdown select)
– Interface Mode: Trunk (dropdown select)
– VLAN ID: 600 (dropdown select)

• Interface-Name: ge-0/0/0 (dropdown select)
– Interface Mode: Access (dropdown select)
– VLAN ID: 600 (dropdown select)

Additional devices, interfaces, options, etc may be added to each of these services as needed just using the “Actions” dropdown selector

Once again, there are hundreds, if not thousands of options that are available on these interfaces just for switching services, but the Anuta NCX service model interface leaves these policy-based decisions (such as BPUD handling, Spanning tree modes and registration, Filters and forwarding policies, etc) to the service definitions instead of forcing the operator to provision these manually.

From a development viewpoint Anuta NCX uses the YANG model w