Cisco Stealthwatch Launches on DevNet

Find documentation, code examples, and a strong community of fellow API developers eager to help

When it comes to working with a new API or technology, the learning experience provided by the vendor can have a significant impact on the success of their customers. Having worked with dozens of different APIs over the course of my career, I have experienced the highs and lows of implementing a new solution using programmatic interfaces. Some of the toughest times I have had involved products with minimal documentation, no shared code samples, and no active community of API developers with knowledge to poll. On the other hand, some of the best APIs I have worked with have thorough documentation, plenty of examples to get me started, and a strong community of fellow API developers eager to help me on my journey to success.

When it comes to network security, being able to integrate an array of products into your security suite can be crucial to ensuring a security incident is efficiently detected and mitigated before major damage occurs.

Cisco Stealthwatch Enterprise has proven to be a powerhouse for end-to-end visibility

Being able to understand the true nature of each host and its baseline behavior, as well as efficiently responding when hosts deviate from their expected behavior is a critical facet of network security. With capabilities like advanced threat detection, accelerated threat response, malware detection in encrypted traffic, and more, Cisco Stealthwatch Enterprise has proven to be a powerhouse for end-to-end visibility and vital to the success and security of thousands of businesses and enterprises across the globe. As the need for API development continues to grow each day, so does the need for proper resources to enable these developers to be as successful as possible utilizing these programmatic interfaces. With so much important data, telemetry, and analytics inside a single tool, it makes obvious sense to extend those capabilities with an API.

Stealthwatch Enterprise has joined the DevNet community!

Being able to provide our users with a “one-stop-shop” for everything related to Stealthwatch APIs ensures that all of the relevant information essential for success is readily available and easily accessible. With the Stealthwatch Enterprise launch on DevNet, we are rolling out an array of useful tools to help API developers spend less time learning APIs and more time using these APIs.

What resources are planned for Stealthwatch and DevNet?

To begin with, we are joining the rest of the Cisco offerings by hosting the entirety of the Stealthwatch Enterprise REST API documentation on DevNet, including for our new Cognitive Intelligence REST API capabilities launched in version 7.1.0 of Stealthwatch Enterprise. No longer will developers need to jump around between different resources or be forced to search deep inside of user guides and help menus to find the relevant API information they are looking for. Now, they can simply go to the same place they already go to for the rest of their Cisco products to get all of the important information needed to make them successful.

Working code examples help you get started

On top of API documentation, we are also launching a set of Postman collections and Python sample scripts to allow developers a great starting point with their API development. Having working examples of code can be a major advantage when getting started with a new API, so including an array of working examples is an absolute necessity for our users’ success.

But we aren’t just stopping there – aside from the API documentation and sample scripts, we are also launching a Code Exchange for Stealthwatch Enterprise. Now, API experts will be able to share useful scripts and software capabilities that leverage Stealthwatch Enterprise with the rest of the DevNet community.

To round out this new community, we are also launching a new Cisco Forum specifically for API developers to ask and answer questions related to Stealthwatch APIs, serving not only as a way to resolve any issues being faced, but also serve as a rich knowledge base of information from those who already have experience.

This latest launch on DevNet is an incredibly exciting one for us, especially having worked many hours over the past few months to ensure the utmost success for our API users. In the future, we plan to expand the DevNet resources even further to include interactive sandboxes and learning labs for Stealthwatch APIs.

Continue reading

Using Amazon Web Services? Cisco Stealthwatch Cloud has all your security needs covered

Like many consumers of public cloud infrastructure services, organizations that run workloads in Amazon Web Services (AWS) face an array of security challenges that span from traditional threat vectors to the exploitation of more abstract workloads and entry points into the infrastructure.

This week at AWS re:Inforce, a new feature for AWS workload visibility was announced – AWS Virtual Private Cloud (VPC) Traffic Mirroring.  This feature allows for a full 1:1 packet capture of the traffic flowing within and in/out of a customer’s VPC environment.  This allows for vendors to provide visibility into the entire AWS traffic, and the ability to perform network and security analytics.  Cisco Steathwatch Cloud is able to fully leverage VPC Traffic Mirroring for transactional network conversation visibility, threat detection and compliance risk alerting.

Stealthwatch Cloud is actually unique in that we have had this level of traffic visibility and security analytics deep within an AWS infrastructure for a number of years now with our ability to ingest AWS VPC Flow Logs. VPC Flow Logs allow for a parallel level of visibility in AWS without having to deploy any sensors or collectors. This method of infrastructure visibility allows for incredibly easy deployment within many AWS VPCs and accounts at scale in a quick-to-operationalize manner with Stealthwatch Cloud’s SaaS visibility and threat detection solution. In fact, you can deploy Stealthwatch Cloud within your AWS environment in as little as 10 minutes!

Additionally, we are seeing that the majority of customer traffic in, out and within a VPC is encrypted. Stealthwatch Cloud is designed from the ground up to assume that the traffic is encrypted and to model every entity and look for threats leveraging a multitude of data points regardless of payload.

Stealthwatch Cloud takes the AWS visibility and protection capability even deeper by leveraging the AWS API to retrieve a wide array of telemetry from the AWS backend to tell a richer story of what’s actually going on throughout the AWS environment, far beyond just monitoring the network traffic itself. We illuminate API keys, user accounts, CloudTrail audit log events, instance tags, abstract services such as Redshift, RDS, Inspector, ELBs, Lambdas, S3 buckets, Nat Gateways and many other services many of our customers are using beyond just VPCs and EC2 instances.

Here is a screenshot from the customer portal with just a sample of the additional value Stealthwatch Cloud offers AWS customers in addition to our network traffic analytics:

The following screenshot shows how we are able to extend our behavioral anomaly detection and modeling far beyond just EC2 instances and are able to learn “known good” for API keys, user accounts and other entry points into the environment that customers need to be concerned about:

Combine this unique set of rich AWS backend telemetry with the traffic analytics that we can perform with either VPC Flow Logs or VPC Traffic Mirroring, and we are able to ensure that customers are protected regardless of where the threat vector into their AWS deployment may exist – at the VPC ingress/egress, at the AWS web login screen or leveraging API keys.  Cisco is well aware that our customers are using a broad set of services in AWS that stretch from virtual machines to serverless and Kubernetes.  Stealthwatch Cloud is able to provide the visibility, accountability and threat detection across the Kill Chain in any of these environments today.

Continue reading

Cisco 200-105 ICND2 Certification: Exam Profile

o progress in any field, it is essential to be familiar with the fundamentals of it. The CCNA Routing and Switching certification that you achieve from passing the 200-105 exam is one of the most fundamental and foundational certifications in the network technology. If you intend to make a career as a network engineer, this certification is one you require to have before you can move to a higher level certification.

The ICND2 certification is one that makes you familiar with the fundamentals of networking, something that persists relevant even as technologies develop and change over time. After all, any progress in these technologies will rest on the fundamentals, so understanding the basics is crucial for any right network specialist. This certification will teach you to install, monitor, and troubleshoot network infrastructure products, something that were and still are at the center of the Internet.

Obtaining your ICND2 certification means that you own the basic knowledge to operate and oversee networks from all aspects, presenting you as a qualified and desired professional in the field.

ICND2 exam topics emphasis on presenting the skills and knowledge necessary to execute and support a small switched and routed network.

• How to Prepare for Cisco CCNA (200-125) Exam?

The 200-105 Interconnecting Cisco Networking Devices Part 2 (ICND2) is the exam associated with the CCNA Routing and Switching certification. This exam measures an applicant's knowledge and skills in LAN switching technologies, WAN technologies, IPv4 and IPv6 routing technologies, infrastructure services, and infrastructure maintenance.

Prerequisites

The recommended knowledge and skills that an applicant should have to appear for ICND2 certification exam:

• Understand network fundamentals
• Implement local area networks
• Implement Internet connectivity
• Manage network device security
• Implement WAN connectivity
• Implement basic IPv6 connectivity

Theses exam topics outline for the content likely to be covered on the Cisco Interconnecting Cisco Networking Devices Part 2 (ICND2) exam.

ICND2 Exam Topics:

1. LAN Switching Technologies (26%)

1 Configure, verify, and troubleshoot VLANs (normal/extended range) spanning multiple switches

• Access ports (data and voice)
• Default VLAN

2 Configure, verify, and troubleshoot interswitch connectivity

• Add and remove VLANs on a trunk
• DTP and VTP (v1&v2)

3 Configure, verify, and troubleshoot STP protocols

• STP mode (PVST+ and RPVST+)
• STP root bridge selection

4 Configure, verify, and troubleshoot STP-related optional features

• PortFast
• BPDU guard

5 Configure, verify, and troubleshoot (Layer 2/Layer 3) EtherChannel

• Static
• PAGP
• LACP

6 Describe the benefits of switch stacking and chassis aggregation

7 Describe common access layer threat mitigation techniques

• 802.1x
• DHCP snooping
• Nondefault native VLAN

2. Routing Technologies (29%)

1 Configure, verify, and troubleshoot Inter-VLAN routing

• Router on a stick
• SVI

2 Compare and contrast distance vector and link-state routing protocols

3 Compare and contrast interior and exterior routing protocols

4 Configure, verify, and troubleshoot single area and multiarea OSPFv2 for IPv4 (excluding authentication, manual summarization, filtering, redistribution, stub, virtual-link, and LSAs)

5 Configure, verify, and troubleshoot single area and multiarea OSPFv3 for IPv6 (excluding authentication, filtering, manual summarization, redistribution, stub, virtual-link, and LSAs)

6 Configure, verify, and troubleshoot EIGRP for IPv4 (excluding authentication, manual summarization, filtering, redistribution, stub)

7 Configure, verify, and troubleshoot EIGRP for IPv6 (excluding authentication, manual summarization, filtering, redistribution, stub)

3. WAN Technologies (16%)

1 Configure and verify PPP and MLPPP on WAN interfaces using local authentication

2 Configure, verify, and troubleshoot PPPoE client-side interfaces using local authentication

3 Configure, verify, and troubleshoot GRE tunnel connectivity

4 Describe WAN topology options

• Point-to-point
• Hub and spoke
• Full mesh
• Single vs. dual-homed

5 Describe WAN access connectivity options

• MPLS
• MetroEthernet
• Broadband PPPoE
• Internet VPN (DMVPN, site-to-site VPN, client VPN)

6 Configure and verify single-homed branch connectivity using eBGP IPv4 (limited to peering and route advertisement using Network command only)

4. Infrastructure Services (14%)

1 Configure, verify, and troubleshoot basic HSRP

• Priority
• Preemption
• Version

2 Describe the effects of cloud resources on enterprise network architecture

• Traffic path to internal and external cloud services
• Virtual services
• Basic virtual network infrastructure

3) Describe basic QoS conceptsQoS concepts

• Marking
• Device trust
• Prioritization
• Congestion management

4 Configure, verify, and troubleshoot IPv4 and IPv6 access list for traffic filtering

• Standard
• Extended
• Named

5 Verify ACLs using the APIC-EM Path Trace ACL analysis tool

5. Infrastructure Maintenance (15%)

1 Configure and verify device-monitoring protocols

• SNMPv2
• SNMPv3

2 Troubleshoot network connectivity issues using ICMP echo-based IP SLA

3 Use local SPAN to troubleshoot and resolve problems

4 Describe device management using AAA with TACACS+ and RADIUS

5 Describe network programmability in enterprise network architecture

• The function of a controller
• Separation of control plane and data plane
• Northbound and southbound APIs

6 Troubleshoot basic Layer 3 end-to-end connectivity issues

Ever since the Cisco 200-105 ICND2 certification presented, Cisco certifications have been desired by network engineers and organizations all over the world. According to the latest study, Cisco skills are among the most preferred skills in hiring requirements. They are incorporated more frequently than 97 percent of all skills inquired. The requirement for an intimate understanding of network infrastructure and protocols and how they work together has always been important. Now, that need is raising. ICND2 certification qualifies you with the expertise and skills to succeed in networking, even as technologies remain to evolve. The certification qualifies you to how to install, monitor, and troubleshoot the network infrastructure applications that are at the very heart of the Internet of Things.

Continue reading

Extending an Enterprise Network? Start Here.

IoT sensors, cameras and other smart devices are fueling opportunities to extend digitization into entirely new parts of a business. These investments can support business process transformation, enhanced operational efficiency and better, more personalized experiences for customers and employees.

But implementing IoT solutions can be daunting even to veterans of network management. That’s because most IoT sensors and devices are deployed in “uncarpeted” areas that aren’t typically connected to the enterprise network. Those areas can range from company parking lots to warehouses, distribution centers, seaports and airports. And they bring a unique set of challenges:

◈ How can IT ensure that Ethernet switches and access points can stand up to harsh conditions like extreme temperatures or exposure to shock and vibrations?

◈ As IoT devices dramatically expand the attack surface, what does it take to keep the network secure?

◈ What’s the best way to position IT to manage IoT solutions as the number of devices grows exponentially in the months and years to come?

With the recent launch of the Extended Enterprise Cisco Validated Design (CVD) at Cisco Live, IT teams now have a proven playbook for the design, implementation and management of five Extended Enterprise use cases – Parking Lots, Warehouses, Distribution Centers, Ports and Airports.

The Extended Enterprise CVD includes in-depth design and implementation guides for Cisco’s IoT Networking Portfolio – empowering IT teams to reduce risk and accelerate speed of implementation. Although the Extended Enterprise CVD provides step-by-step guidance on taking the enterprise network to the IoT Edge, its value goes far beyond how-to instructions. Cisco engineers have tested and validated what works, proving that systems will scale and perform as intended.

As companies work to take the enterprise network to the IoT Edge, the Extended Enterprise CVD empowers IT teams with three key advantages:

1. Simplicity. Manage and monitor the enterprise network – from the office to the parking lot and beyond – through Cisco DNA Center. This “single pane of glass” provides full visibility and control. It also supports automation and analytics that simplify routine maintenance, as well as troubleshooting and guided remediation.

2. Security. Cisco’s Intent-based networking doesn’t just streamline security policy creation and application in traditional “carpeted” areas; it also automates network security in parking lots, warehouses and other rugged environments. It makes it fast and easy to ensure that IoT devices don’t become weak links in an organization’s security posture.

3. Scalability. There’s no end in sight when it comes to the growth and expansion of IoT devices. Businesses need a sustainable and scalable approach to deploying devices beyond an initial set of sensors or cameras. As device quantities grow to the thousands or tens of thousands, implementation must be simple enough to be completed quickly and reliably by virtually any technician.

Continue reading

pyATS & Genie – Beneath the Surface

Today, we’ll take you behind the scenes and inspect the iceberg below the surface: how the framework and its libraries are built, and how you can take advantage of its APIs in Python.

Network Automation & Testing

pyATS | Genie was initially developed as the next-generation test infrastructure for Cisco Engineering. But wait – are we not talking about networking automation and NetDevOps?

We are. Upon closely inspecting and comparing test and network automation, we can identify a high degree of behavior overlap: they both programmatically drive network devices, only to different expectations. Whereas tests have passing criteria, network automation is built around business logic that acts and reacts on input conditions.

In other words – they share the same network automation libraries.

For the past 20 years, Cisco has invested in automated testing. With pyATS | Genie released externally through DevNet, it allows everyone to make use of the great libraries and scripts that have been created as part of this ongoing engineering effort. So, while our engineers rigorously test the next platform/release, you may leverage the same libraries for your own network automation needs.

So, do I use pyATS or Genie?

In short, you use both. They are like two sides of the same NetDevOps coin.

pyATS is the foundation of this ecosystem. As a powerful and highly-pluggable Python test framework, it is designed to provide maximum flexibility to developers, and standardizes the boilerplate requirements:

◈ define topologies and device/interconnects

◈ programmatically interact with various devices

◈ write, execute and report on test scripts

On the other hand, Genie is pyATS’s library and development-kit that focuses on building reusable network automation libraries and testcases. Built on top of pyATS, Genie features:

◈ parsers: converting/formatting command output into Pythonic data structures

◈ models: OS/platform agnostic Python classes that represents feature/protocol configuration state and operational status

◈ triggers & verifications: reusable pool of data-driven testcases

Together, pyATS | Genie provides you with all the tools & libraries necessary for network automation. By picking and choosing the right APIs and testcases, all you have to do is:

1. build your own business logic that makes use of the libraries

2. integrate it into the rest of your automation system, be it Jenkins, Ansible, ROBOT Framework or the likes.

“What do you call a pyATS developer that leverages Genie? A pyATS Genius.”

Parsers & Models

So far, you have seen that you can use Genie and parse CLI commands in shell, eg:

bash$ genie parse “show interfaces” --testbed-file testbed.yaml

Behind the scenes, this invokes Genie’s parsing capability:

1. connects to the testbed device

2. performs a search for the most-appropriate parser to use, based on input CLI and the connected device’s OS and platform information

3. invoke the parser to process the output

4. return the parsed Python dictionary (displayed as JSON in Genie CLI).

Parsers are the lowest library layer in Genie. Each parser is responsible for:

1. issuing the right command on device, collecting output

2. convert/scrape/format the output, based on context, into a schema-controlled dictionary output.

The use of a schema with each parser ensures that each parser is self-describing, self-documenting, and self-testing.

The 1000+ parsers currently featured in Genie give you the basic ability to view, compare and analyze your device’s operational states in straight-up Python dictionary format. As awesome as that sounds, they do come with a few caveats:

◈ each parser processes only one command, and narrowly represents only a slice of the overall operational state of a feature/protocol.

◈ commands between different OS and platforms often differ, and as such, building business logic around parsers does not scale if you have a variety of devices in your network.

This is where models come in.

Genie models are the next-layer-up above parsers: YANG-inspired Python classes that implements a whole feature/protocol agnostically. They’re called YANG-inspired because the development team studies the YANG models of various platforms and crafted their own. Why? Because YANG is a machine-to-machine descriptor, and NETCONF XML comes with its own angle bracket tax…

Built to be human-friendly and engineered to works across different platforms and OSes, Genie models enables users to interact with network devices/protocols in a holistic, high-level and Pythonic fashion.

Take interface for example. To build the interface operational state model, our resident CCIE engineer, @tahigash3 studied YANG interface models across a variety of platforms, and came up with one top-level structure. With it, when you invoke Genie to learn “interface”, eg:

bash$ genie learn interface --testbed-file testbed.yaml

or if you are using Python directly:

The engine automatically issues the following commands for each reference platform.

IOS-XE IOS-XR NXOS

show interfaces

show vrf detail

show ip interface

show ipv6 interface

show interface switchport

show etherchannel summary

show interfaces [intf]

accounting

IOS-XR

show interfaces detail

show vlan interface

show vrf all detail

show ipv4 vrf all interface

show ipv6 vrf all interface

show bundle

show interfaces [intf]

accounting

NXOS

show interface

show vrf all interface

show ip interface vrf all

show ipv6 interface vrf all

show interface switchport

show routing ipv6 vrf all

show routing vrf all

These command outputs are then parsed, using Genie parsers, and reconstructed together into the new data structure that represents the entire operational state of this device’s interfaces:

In addition, each operational model is accompanied by a list of keys that are naturally “less interesting.”  When a diff is performed – the list ensures things like “uptime” and “keep-alive-sent” (e.g., data that is ever changing/incrementing and of minimal value) do no pollute the output, and that you can focus on just the things that matter.

Besides operational status, this design around high-level, holistic model approach applies to device configuration as well: Genie conf models enable users to configure and unconfigure network devices just by setting Python object attributes. The rest is handled for you automatically.

Because these models remain structurally consistent across different OS/platforms, automation built around Genie models are portable across your network: write them once and use them across different topologies and device types.

Can it get even better? Of course! Genie’s opens source library implementations are not limited to just Cisco devices. Whilst the team here is focused on building support for Cisco platforms (duh!), it is 100% possible to support 3rd party vendors and even competitor platforms through library extensions and plugins.

Sky’s the limit

With pyATS | Genie, you have free rein over your network automation. By harnessing the power of parsers and models, you can build true data-driven, portable and agnostic network automation that scales along with your network.

Continue reading

Secure, Interoperable Asset and Entitlement Management Platform Built on Smart Accounts

How can I get full visibility into all IT assets that I own and use?

How can I control and centralize access to my IT assets and entitlements?

How do I manage my IT assets and associated entitlements in a cost-effective way?

I already have an ITAM solution to manage all my procured assets from multiple vendors, can I integrate with Cisco for the investments we have made with Cisco?

How do I automate license deployments and management from our environment with Cisco’s cloud-based licensing platform?

These are questions that I hear from IT managers and administrators every day. That’s why I am happy to tell you about our secure interoperable asset and entitlement management platform —My Cisco Entitlements (MCE). Based on the principle of transparency, standards and security, My Cisco Entitlements provides a convenient platform for customers and partners to manage all their post-sales Cisco IT assets and entitlements.

Smart Accounts – The Foundation of MCE

Smart Accounts and ISO Compliant Application Programming Interfaces (APIs) provides the foundation for MCE. Cisco Smart Accounts were initially created as a time-saving way for customers to organize, use, and manage their Smart Licenses and associated entitlements. MCE extends the concept of Smart Accounts to manage all of Cisco licenses, devices, services, and subscriptions. For Cisco, this is the first time we connect the services and licensing worlds. It brings together license deployment information such as serial numbers with service product identifiers.

Benefits of MCE—Full Visibility, Centralized User Access, and Actionable Insights

When MCE connects services and licensing together, it provides benefits such as full visibility to all assets and entitlements, centralized user access management, and simplified install base reconciliation. Smart Account admins can control access on who views and manages assets.

The MCE dashboard summarizes the health of your products and services. It identifies risk areas such as upcoming Contract Expiration and Last Date of Support (LDoS) dates. For a specific insight, you drill down and view details. Then you can export and act based on this information.

By providing multiple interconnected views, MCE simplifies install base discovery and reconciliation. The “Devices” view captures all of the service coverage and related telemetry data. In addition, users can view all of the licenses deployed on that device enabling them to initiate device-led operations such as license rehosts.

We’ve normalized a “License” feature-based view across classic, smart and cloud licenses. No matter how you purchased the license – individual or bundled in an Enterprise Agreement – you will see it in one inventory.  You have the ability to see the service coverage or subscription, as well as all of the devices where that license has been deployed.

The “Service and Subscriptions” view captures all of your technical support contracts and software subscriptions in one inventory. You can also view links to the licenses or devices covered in any contract. Using various views and functionalities like global search, users can quickly search across device, licenses, services, and subscriptions to find all related data for their search term.

Automation and Scale with APIs

While we’ve built these experiences for online access, we recognize that automation of the tasks required to keep your records in sync with Cisco needs to scale. Customers and partners are increasingly adopting IT Asset Management Systems to automate tasks in maintaining compliance across vendors.  These tools manage entitlements from Enterprise Agreements, purchases, and other records to automatically determine and optimize assets and entitlement positions against discovered hardware and software.

To execute these tasks in a cost-effective way, MCE will allow all operations available online to be executed with ISO standards-based APIs.  Using the same secure Smart Account, customers and partners will be able to maintain their investments in multi-vendor IT Asset Management solutions without the redundant and manual operations to keep them in sync.

MCE allows integration of all online functionalities to be executed with ISO standards-based APIs. MCE also provides service automation platforms for license generation, consumption, and reporting. In the future, we will offer MACDs (Move Add Change Delete) for service SLA management. Integration for Partner Support Services (PSS) to route cases to partners will also be available.

Cisco offers a number of Smart Account and Smart Licensing related APIs including Smart Account Search, Create and Delete, Validation of User Access, License Consumption, Usage, Alerts and Management, and Device Management.

MCE will offer APIs for:

◈ IEC/ISO 19770 Compliant XML for software, hardware and agreements

◈ Smart Account structure and user access management

◈ Asset Management (MACDs)

◈ Direct transaction processing such as Download SW, Case Open, License, SaaS Consumption Management

MCE delivers on our vision for secure, interoperable Asset and Entitlement Management with customers and partners. I look forward to sharing more in the future as we continue to evolve our capabilities.

Continue reading

Equinix Segment Routing-powered network delivers increased value to its customers

Segment Routing 101

Segment Routing (SR) is a flexible and scalable way of performing source routing. The source chooses a path and encodes it in the packet header as an ordered list of segments.

Each segment is identified by the segment ID (SID) consisting of a flat 32-bit integer as illustrated in figure-1 below:

◈ Use case#1: single SID – 16050 – on R1 head-end to reach out to R5 as a loose path
◈ Use case#2 illustrates mix of loose and strict path to reach out to R5. The label stack on R1 can be interpreted to take shortest loose path to R4 (16040) and take strict path to R5

Figure-1: Segment routing source routing and inherent ECMP capabilities

Segment routing eliminates the need to maintain per-application and per-flow state in the network. Instead, it decodes the forwarding instructions provided in the packet header and forwards the packet accordingly.

Segment routing supports both MPLS (Multiprotocol Label Switching) and IPv6 data plane. It natively integrates with MPLS multi service capabilities, including Layer 2 & Layer 3 VPN (L3VPN), Virtual Private Wire Service (VPWS), Virtual Private LAN Service (VPLS), and Ethernet VPN (EVPN).

Why is Equinix adopting Segment Routing?

Segment routing offers stateless service policies which simplify network and provides fine-grained control over applications for guaranteeing stringent SLAs to meet customer mission critical application requirements. It provides native tools built into the technology DNA for simplified service creation which enhances end-user experience. Faster response time via automated service creation can be delivered with the additional ability to custom fit transport to application needs which is critically important for new evolving technology adoption. It also provides built-in network resiliency with tens of millisecond convergence across any network topology.

Moreover, Segment Routing utilizes the network bandwidth more effectively than traditional MPLS networks and offers lower latency.

In summary, Segment Routing drives the next level of network simplification – at the control and data plane level – enabling operators to implement complex use cases without the need to implement and operate complex traffic engineering techniques such as MPLS RSVP TE. It significantly contributes to reducing both CapEx and OpEx.

What are the benefits for Equinix customers?

The future of networking is moving towards “Intent based networking”. Segment Routing is a foundational building block to make network infrastructures intent ready as a SDN controller can translate application intent into a Segment Routing stateless service policy that can be dynamically instantiated to carve out a virtually isolated path based on specific application requirements.

As the world’s global data center interconnection leader, Equinix is constantly innovating on behalf of its customers to help them grow their businesses. At the core of the Equinix interconnection value proposition is a global network infrastructure that offers multiple network services to both Service Providers and Enterprises alike. To offer new and differentiated value-added services and to provide a second-to-none customer experience, Equinix is implementing Segment Routing in their next-generation network infrastructure

Use case 1 – Offering legacy TDM services over a packet switching network Infrastructure

This use case includes migration of TDM services or offering new low-cost TDM services over a packet-based network.  From an end-user perspective, there should not be any differences between traditional and packet-based TDM services. User should be able to subscribe to protected and unprotected services as currently being offered with traditional TDM services.

Segment routing technology with TI-LFA support brings inherent link and node protection with 50ms convergence without a need to enable complex protocols. Segment routing being packet optimized will utilize equal cost path towards the destination without any additional operational overheads and stateless service policies will minimize control plane states with complete control in  operators hands on how to define the service.

Service requirement and design decisions:

Figure 2: Traditional TDM service migration over IP transport network

Implementing TDM services over a packet-based transport network with segment routing stateless traffic-engineered service policy eliminates the need to deploy complex state full RSVP-TE control plane which requires more CPU and memory resources to maintain per service policy soft states (hop by hop path and reservation messages) on every networking device along the path. It is also hard to debug complete OSI stack from layer 1 to layer 7 in production network compared to layer 1 to 3 stack in segment routing implementation.

Use case 2 – Offering Application SLA based Path selection

5G roll-out will drive significant investment in the network infrastructure to support new requirements such as network slicing – specific slices include encrypted, low latency and high bandwidth slices. It will allow Service Providers to offer new, differentiated services and create new revenue streams.

The network infrastructure should be able to offer such complex services without the need to implement complex technologies to ease day to day operational overhead.

Flexible Algorithm makes Segment routing traffic engineering even more agile. On top of current TE capabilities – stateless service policies, on-demand policy generation and automated steering -Flexible Algorithm enables multiple optimizations of the same physical network infrastructure along various dimensions called slices –  for instance, slice 1 can be optimized for encrypted, slice-2 can be optimized for low-latency and slice 3 can be optimized for high bandwidth along with disjoint paths via two distinct planes using anycast capabilities. Application to slice mappings can be done using stateless service policies.

Service requirements and Design decisions:

Figure-3: Network slicing and service policy steering traffic to network slice

Figure 3 compares network slicing across legacy MPLS traffic engineered and emerging segment routing technology. Two obvious differences clearly stand out:

■ Segment routing being packet optimized compared to RSVP-TE being circuit optimized, will inherently use ECMP path without the need to create separate policies for every possible ECMP path along the way to destination – which makes provisioning tool development and troubleshooting more simple resulting into OpEx savings.

■ Better use of bandwidth across the network with simple configuration can help reduce CapEx for the price/bps on expensive network equipment.

The inherent difference between the two technologies is provisioning simplicity and optimal use of network resources which in turn simplifies network operations, topology, and visibility and troubleshooting with reduced CAPEX and OPEX.

Segment Routing is here to stay as upcoming 5G services will drive the need for low latency, highly-resilient, and bandwidth hungry differentiated services over a single physical infrastructure to meet application SLAs. To speed up 5G services’ adoption, Service Providers need to carefully choose technologies that can enable customers to provision differentiated services in real time and at scale. Segment Routing is undoubtedly one of these technologies.

Continue reading