Choosing the Best Overlay Routing Architecture for EVPN

A Comparative Analysis of Architectures and Their Trade-offs

Organizations have many options when implementing an Ethernet Virtual Private Network (EVPN). Choice of network design with respect to overlay routing may be influenced by a combination of factors, including scalability, multi-tenancy, segmentation, and operational simplicity. Understanding the key differences among various overlay routing architectures makes it possible to evaluate and choose an implementation that offers a best fit for an organization.

Read More: 200-901: Developing Applications and Automating Workflows using Cisco Core Platforms (DEVASC)

This blog post compares the trade-offs across different overlay Anycast routing architectures in the context of overlay networks deployed using EVPN Integrated Routing and Bridging. It covers Centralized Routing, Distributed Asymmetric Routing, and Distributed Symmetric Routing. Note that this discussion is independent of data plane encapsulation and applies equally to IP and MPLS tunnel data paths.

Overlay Networks

Overlay networks have become ubiquitous across enterprise, data center, and service provider network architectures. They enable deployment of a simple non-blocking IP routed infrastructure with the flexibility to deploy multi-tenant unicast and multicast services on top. Overlay endpoints or workloads may be placed or moved anywhere across a non-blocking fabric, independent of overlay addressing and subnet assignments. A flexible and scalable IP Clos fabric provides reachability across edge and border devices. A VPN tunnel mesh across edge and border devices provides overlay connectivity between  connected endpoints (see Figure 1).

Figure 1: VPN overlay with simple non-blocking routing infrastructure.

There may be additional factors, including security and traffic engineering policies, to consider when deploying an overlay across different use cases. Reachability, however, is the least common denominator across all overlay use cases. For flexible workload placement and mobility that is independent of addressing and subnetting constraints, a multi-tenant overlay network must provide reachability across:

◉ Tenant endpoints within an IP subnet,

◉ Tenant endpoints in different IP subnets.

As intra-subnet overlay connectivity is enabled via layer 2 VPN bridging services deployed across fabric edge and optionally border devices, multiple options exist for overlay routed connectivity between endpoints in different subnets. The following will detail and compare trade-offs across three overlay Anycast routing architectures:

1. Centralized Routing

2. Distributed Asymmetric Routing

3. Distributed Symmetric Routing

1 – Centralized Anycast Routing Architecture

A centralized routing model connects endpoints to layer-2 EVPN gateways (GW) that provide VPN bridging. This enables intra-subnet flows across the overlay while all routing to endpoints in different subnets, within and outside the fabric, is centralized via designated Integrated Routing and Bridging (IRB) L2+L3 GWs.

First-hop routing for each overlay subnet is deployed using a subnet Anycast GW that is hosted on one or more designated IRB GW nodes. A key attribute defining this overlay routing architecture is that first-hop routing function for an overlay subnet is decoupled from the EVPN L2-GW edge that provides intra-subnet bridging service for that subnet. This decoupling results in first-hop routing for overlay endpoints across the fabric being “centralized” on designated IRB nodes. Note that the Anycast GW for each subnet is still distributed across these “centralized” IRB GW nodes.

It is common to deploy first-hop Anycast routing for all overlay subnets in a fabric on the same set of IRB nodes. While not necessarily required, this is often done for operational simplicity and optimal routing. It is also common for this first-hop routing function to be hosted on border nodes that also act as interconnect GWs to external L2 or L2/L3 domains. Optionally, these IRB nodes may also function as edge nodes and connect to local overlay endpoints, resulting in the model shown in Figure 2.

Figure 2: EVPN Centralized Routing Deployment Model

Control Plane Operation

A centralized approach essentially uses an EVPN overlay as a layer-2 VPN overlay, with the inclusion of the host IP along with the host MAC being optional in EVPN host route advertisements (see Figure 3). The host route is advertised by the egress L2 GW with layer 2 attributes that, on the ingress L2 GW and on the centralized IRB GW, result in:

◉ Import of the host MAC to the MAC VRF in the control plane.

◉ Host MAC reachability via layer-2 VPN encapsulation and tunnel to the egress GW.

Figure 3: Control plane operation with centralized routing.

In addition, IRB GW nodes also install layer-3 adjacencies to the remote host IP.  Host IP to MAC bindings for this purpose may be learnt on the IRB GW via:

◉ Advertising L2 GW learning the host IP by snooping and including the host IP in the EVPN host route advertisement.

◉ OR in data plane via ARP and ND packets received from the host.

Note that reachability to a remote layer-3 host adjacency is still resolved by host MAC reachability via a layer-2 VPN tunnel to the egress GW. In addition, IRB gateways may also proactively advertise the Anycast GW MAC/IP in the EVPN control plane for the purpose of avoiding duplicate ARP responses from redundant Anycast GWs. On the L2 GW, this results in L2 reachability to Anycast GW MACs in the MAC VRF, and local ARP suppression for Anycast GW IP ARP requests from hosts.

Data Plane Operation

For data plane operation (see Figure 4), intra-subnet flow destined to a remote host is bridged on the ingress L2 GW via a tunnel to the egress L2 GW, with the layer 2 VPN encapsulation advertised by the egress L2 GW. On the egress L2 GW, this layer 2 VPN encapsulation maps to a MAC VRF, where the packet is again bridged to the local host.

Inter-subnet flow destined to Anycast GW MAC is bridged on the ingress L2 GW to one of the centralized IRB GW via tunnel to the IRB GW with layer 2 VPN encapsulation advertised by the IRB GW. Packets are then routed on the IRB GW via layer-3 adjacency to the destination host IP. This results in the packet being encapsulated with the host MAC rewrite that resolves via tunnel to the egress L2 GW and layer 2 VPN encapsulation advertised by the egress L2 GW. On the egress GW, this layer 2 VPN encapsulation maps to the MAC VRF, where the packet is again bridged to the local host.

Figure 4: Data plane operation, showing intra-subnet flow and inter-subnet flow with centralized routing

Control Plane Scalability – Limited by “all subnets on centralized GWs”

Control plane scalability is limited by the fact that each IRB node that is part of the centralized Anycast GW cluster is required to program:

◉ Layer-3 (SVI) interfaces for ALL overlay subnets for which it is a first-hop GW.

◉ Layer-3 adjacencies to ALL overlay endpoints in these subnets.

◉ MAC VRFs for ALL overlay subnets for which it is a first-hop GW.

◉ MAC routes for ALL overlay endpoints in these subnets.

◉ IP host routes for ALL overlay endpoints across the fabric.

◉ Overlay tunnels to ALL edge nodes.

A simple deployment centralizes all overlay subnets on the same set of IRB nodes. In this case, the fabric wide scale of overlay subnets and endpoints is limited by the IRB device’s individual layer 3 interface, layer adjacency, and MAC route scale. Note that in this model, redundant nodes that are part of the same Anycast GW cluster do not contribute to overall fabric scale, since the same forwarding state needs to be replicated across all Anycast GW nodes.

Control Plane Scalability – At the cost of optimal routing

Alternatively, first-hop routing service for different subnets may be load-shared across multiple centralized Anycast GW clusters to reduce the scale on each IRB node.

Figure 5: First-hop routing for subnets hosted on different IRB nodes.

Figure 5 shows first-hop routing for two subnets hosted on the first two IRB nodes with routing for two other subnets hosted on the other two IRB nodes. However, this may result in a sub-optimal data path with an extra routing hop as shown in Figure 6. It also compromises the operational simplicity of being able to manage routing for all overlay subnets on the same IRB nodes.

Figure 6: This approach may introduce an extra routing hop, resulting in a sub-optimal data path that also compromises the operational simplicity of being able to manage routing for all overlay subnets on the same IRB nodes.

Sub-optimal Data Path – Local inter-subnet flows

The sub-optimal nature of inter-subnet routing in this approach applies to local inter-subnet flows that must always be bridged on the ingress L2 GW to the centralized IRB GW, only to be routed back to the ingress L2 GW. This results in a ‘traffic trombone effect’ (see Figure 7).

Figure 7: The ‘traffic trombone’ effect occurs when local inter-subnet flows that must always be bridged on the ingress L2 GW to the centralized IRB GW are routed back to the ingress L2 GW.

Operational Simplicity

Despite these sub-optimal scaling and data path properties, this approach is still a good trade-off in certain use cases for operational reasons:

◉ This approach provides operational simplicity of provisioning and managing first-hop routing and associated routing policies for all overlay subnets on designated nodes. As an example, for use cases where an overlay subnet is stretched across campus and DC domains, this approach allows you to manage inter-subnet and external routing policies for the subnet at a central point.

◉ Forwarding semantics, being similar to traditional IRB, are simple to understand, deploy, and operate.

◉ EVPN centralized routing design, in principle, aligns with legacy access/distribution layer-2 network design, where routing functionality is centralized and decoupled from layer-2 only access devices. An EVPN layer 2 overlay can be thought of as replacing a traditional layer-2 access network, with EVPN-IRB functionality on centralized distribution nodes being the traditional L2/L3 boundary. It is hence a conceptually easier transition from such legacy architectures.

Centralized Anycast GW Redundancy – just FYI

The Centralized Anycast GW approach across redundant IRB GWs introduces additional complexity that an operator should be aware of:

◉ If L2 GWs only advertise host MAC routes in the EVPN control plane, host layer-3 adjacencies are learnt on the Anycast GW via ARP and ND. Since adjacencies could be learnt on any of the redundant GWs, Anycast GWs must implement additional mechanisms to sync layer-3 host adjacencies across them. Alternatively, L2 GWs must implement MAC-IP learning via snooping and advertise the host MAC and IP via the EVPN control plane for Anycast GW nodes to learn host layer-3 adjacencies via EVPN.

◉ ARP requests for an Anycast GW IP from a host is flooded across the overlay and hence results in multiple ARP responses from redundant GWs. To avoid this, Anycast GWs must advertise the GW MAC-IP bindings upfront via the EVPN and L2 GWs must implement local ARP suppression. In the case of a VXLAN fabric, Anycast VTEP may also be used across redundant GWs to avoid multiple ARP responses.

2 – Distributed Asymmetric Routing Architecture

The distributed asymmetric approach is a variation of the centralized Anycast routing approach, with the layer 2/3 routing boundary pushed to fabric leaf nodes (see Figure 8). In this approach, first-hop Anycast GW functionality for an overlay subnet is deployed across ALL leaf nodes that now operate as IRB GWs (as opposed to being L2 GWs).

Figure 8: A Distributed Asymmetric Routing Architecture pushes the layer 2/3 routing boundary to fabric leaf nodes.

Control Plane Operation

Much like the centralized IRB approach, this approach also uses the EVPN overlay as a layer-2 VPN overlay. A slight difference is that the host IP is now required in the EVPN host route advertisement, along with the host MAC. Similar to centralized IRB operation, the host route is advertised by the egress GW with layer 2 attributes that, on the ingress GW, results in:

◉ Import of the host MAC to the MAC VRF in control plane.

◉ Host MAC reachability via layer-2 VPN encapsulation and tunnel to the egress GW.

IRB-capable nodes also install layer-3 adjacencies to the remote host IP with IP to MAC binding learnt via host routes. Reachability for remote layer-3 host adjacency is still resolved by host MAC reachability via a layer-2 VPN tunnel to the egress GW.

Data Plane Operation

While this approach enables EVPN routing and bridging functions to be co-located on EVPN leaf nodes, it has the same forwarding semantics as a centralized Anycast GW. The overlay routing function on the leaf IRB GW routes packets directly to the host’s layer-3 adjacency. “Asymmetric” in this context refers to the fact that this results in inter-subnet flows being “routed and bridged” on the ingress IRB GW and “bridged” on the egress IRB GW (Figure 9).

Figure 9: This approach is asymmetric in that inter-subnet flows are “routed and bridged” on the ingress IRB GW, and “bridged” on the egress IRB GW.

Control Plane Scalability – Limited by “all subnets everywhere”

Control plane scalability is even more severely limited by the fact that each IRB leaf node is now required to program:

◉ Layer-3 (SVI) interfaces for ALL overlay subnets in the IP VRF, even if it does not have locally attached hosts in that subnet.

◉ Layer-3 adjacencies for ALL overlay endpoints in these subnets, even if it does not have locally attached hosts in that subnet.

◉ MAC VRFs for ALL overlay subnets in the IP VRF, even if it does not have locally attached hosts in that subnet.

◉ MAC routes for ALL overlay endpoints in these subnets, even if it does not have locally attached hosts in that subnet.

◉ IP host routes for ALL overlay endpoints across the fabric in an IP VRF.

As a result, fabric wide scale of overlay subnets and endpoints is limited by each leaf device’s layer 3 interface, layer adjacency scale, and MAC route scale. Adding more GW devices to the Anycast GW cluster does not mitigate this limitation, as ALL leaf nodes host routing interfaces, layer-3 adjacencies, and MAC routes for ALL subnets and endpoints across the IP VRF.

Optimal Data Path – Local routing

In contrast to centralized IRB, local inter-subnet flows are always routed locally on the ingress GW, while inter-subnet flows across the fabric are always routed directly to the remote host (see Figure 10).

Figure 10: Local inter-subnet flows are always routed locally on the ingress GW. Inter-subnet flows across the fabric are always routed directly to the remote host.

Operational Simplicity – Traditional IRB forwarding

◉ Much like the centralized IRB approach, this approach also uses the EVPN overlay as a layer-2 overlay (akin to a traditional switching fabric). It treats remote IP endpoints as directly connected layer-3 adjacencies. Forwarding semantics, being similar to traditional IRB, are still simple to understand, deploy, and operate.

◉ Pushing the first-hop routing function to EVPN leaf GWs is a shift from traditional centralized routing designs. When migrating a legacy switching design, network designers must view EVPN fabric roles for network devices, independent from traditional access / distribution switching roles.

3 – Distributed Symmetric Routing Architecture

Much like the distributed asymmetric routing architecture, the distributed symmetric approach deploys the first hop Anycast GW function for an overlay subnet across ALL leaf nodes that operate as IRB GWs. However, for better scalability, symmetric IRB forwarding semantics and control plane operation are much different from that of asymmetric or centralized IRB that use EVPN to build a layer-2 VPN overlay. Instead of routing functionality being achieved via traditional IRB over the layer-2 overlay, the symmetric IRB approach uses EVPN as a single control plane to build:

◉ A layer-2 VPN overlay to enable intra-subnet bridging.

◉ A layer-3 VPN overlay to enable inter-subnet routing.

This additional layer-3 VPN overlay is the key differentiating attribute of a symmetric IRB architecture. It allows restriction of subnet provisioning on edge devices to locally attached subnets. This results in better scaling properties.

Figure 11: The additional layer-3 VPN overlay in a symmetric IRB architecture allows restriction of subnet provisioning on edge devices to locally attached subnets for better scaling properties.

Control Plane Operation

To build an additional layer-3 VPN overlay for inter-subnet routing, EVPN MAC+IP host routes are advertised with additional layer-3 VPN attributes to enable:

◉ Layer-3 VPN import to IP VRF in the control plane.

◉ Layer-3 VPN encapsulation in the data plane.

In summary, a single host route in the control plane is used to signal a layer-3 VPN host route to be installed in the IP VRF and a layer-2 VPN MAC route to be installed in MAC VRF, with the corresponding L3VPN and L2VPN encapsulations.

Data Plane Operation

◉ Intra-subnet bridging – Much like as is the case with the asymmetric and centralized approaches, bridging across the layer-2 VPN overlay is accomplished via layer-2 VPN encapsulation (L2 MPLS label or L2 VNI) that maps to the local MAC VRF. Bridged forwarding plane is identical across all three routing architectures.

◉ Inter-subnet routing – Inter-subnet flows are routed on the source (ingress) GW to the destination (egress) GW next-hop via a tunnel to the egress GW with L3VPN encapsulation. This L3VPN encapsulation is terminated and identifies the IP VRF at the egress GW, where the packet is again routed in the IP VRF to a locally connected endpoint. This routing data path is similar to traditional L3VPN, with the EVPN GWs acting as L3VPN PE devices.

Figure 12: Inter-subnet flows are routed on the source (ingress) GW to the destination (egress) GW next-hop via a tunnel to the egress GW with L3VPN encapsulation.

Control Plane Scalability – No more “all subnets everywhere”

A separate layer-3 VPN overlay allows inter-subnet host reachability on the source GW to be recursively resolved via a L3VPN tunnel to a destination GW next-hop. This differs from the asymmetric and centralized approaches where the source GW relies on layer-3 adjacencies to all remote hosts and their host MAC reachability via layer-2 VPN tunnels to achieve inter-subnet routing. As a result:

◉ The ingress GW no longer needs to be provisioned with routing interface (SVI) for ALL overlay subnets in an IP VRF. It only needs to be provisioned with the SVI interface for locally attached subnets.

◉ The ingress GW no longer has layer-3 adjacencies to ALL overlay endpoints in an IP VRF. It only has host routes for all end points via a tunnel to the destination GW next hop.

◉ The ingress GW no longer has MAC-VRFs for all overlay subnets in an IP VRF. It only has MAC-VRFs for locally attached subnets.

◉ The ingress GW no longer has MAC routes to ALL overlay endpoints in an IP VRF. It only has MAC routes for locally attached subnets.

◉ Ingress GW still has host routes to all endpoints in an IP VRF, unless a subnet is restricted to strictly one GW (or a multi-homing GW complex). In this case, it is possible for routing to be based on the subnet route alone.

Optimal Data Path

As in asymmetric IRB, local inter-subnet flows are always routed locally on the ingress GW, while inter-subnet flows across the fabric are always routed directly to the egress GW.

Extra TTL Decrement

Note that with this approach, an inter-subnet flow across two endpoints attached to the fabric goes via two routing hops instead of the usual single routing hop, as in traditional LANs connected via a router, or in the case of centralized and asymmetric IRB. This is not to say that the routing data path is sub-optimal. Rather, it is just an operational side effect of the packet being routed (instead of bridged) at the destination GW.

Operational Overhead – Separate L2VPN and L3VPN overlays

As opposed to centralized and asymmetric IRB architectures, the symmetric approach does result in separate layer-2 VPN and layer-3 VPN overlays to operate and manage. Together with the shift from traditional centralized routing to distributed routing across the fabric edge, this may result in a higher learning curve.

Source: cisco.com

Continue reading

Monitoring your indoor IoT environment – Cisco DNA Spaces IoT Services

IoT Services Overview

Cisco DNA Spaces is the world’s most powerful location platform that uses existing Wi-Fi infrastructure to give actionable insights and drive business outcomes. Cisco DNA Spaces IoT services has been transforming how businesses measure and interact with their environment at scale. Cisco IoT services has brought hardware, software, and services together to digitize spatial data into actionable intelligence. Businesses are planning occupancy monitoring, air quality testing, contact tracing, and in-room presence use cases with Cisco DNA Spaces to prepare workspaces for a post-pandemic reopening. Enabling all these use cases require seamlessly consuming a ton of data and working with a plethora of devices. So how does an enterprise monitor the health of their IoT environment in an ocean of devices broadcasting data continuously? Enter, Cisco IoT Services Device Monitoring.

IoT Services Components

The key components of the solution are comprised of Cisco DNA Spaces IoT Services, Cisco Catalyst 9800 Series Wireless Controllers, Cisco Access Points, and our IoT Partner Ecosystem. The specific roles of each piece of the solution are described below:

All components in the IoT Services architecture communicate with their peers over a data channel to forward measurements and a control channel to pass actionable information. For example, in the network architecture below, Access Points communicate with the Connector over a gRPC data plane while it communicates with the Controller over a CAPWAP control plane.

Data Volume

The vastly scalable data plane enables DNA Spaces  IoT services to ingest and process humongous volumes of data. Partner device broadcasts are either time-driven or event-driven. Beacons, for example, can broadcast advertisements at an astonishingly high frequency while some telemetry devices can be triggered only when certain conditions are fulfilled. As a result, the per-device transmission rate varies widely from every 100ms to once in several days. On average IoT services process, more than 300 million messages per day, and data volume is increasing every day as more and more devices are being scanned.

Read More: 350-901: Developing Applications Using Cisco Core Platforms and APIs (DEVCOR)

Needle in a haystack

Analyzing the millions of packets consumed by IoT Gateways, DNA Spaces IoT Services Device monitoring identifies and predicts possible issues in the network’s IoT Infrastructure.

Device Monitoring

Network snapshot

IoT Services provides a snapshot to quickly identify if any Gateway is down in the environment. It also identifies the total number of transmitting IoT devices and how many devices are active currently. This quickly provides customers with an idea of how cluttered the BLE environment in the enterprise may be.

Battery monitoring

Unmonitored devices running out of battery is one of the primary causes of IoT network failures. It adversely affects almost all IoT use cases such as wayfinding, sensor telemetry. Devices advertising with high frequency or transmission power are particularly susceptible to battery drainage. Device monitoring provides a concise view of identifying devices that have critical or low battery life. It also provides information to locate the devices on a map so that network administrators can easily find the device and change its battery.

Active devices

The active devices count provides the number of devices the gateways have scanned in the last 5 mins. If there are too many active devices, it may indicate unmitigated rogue transmissions on the network. On the other hand, if there are too few active devices, it may indicate malfunctioning devices or data channel setup issues.

We are integrating more and more metrics to provide powerful insights into your IoT Network through device monitoring. In combination with network policies, device monitoring can truly transform IoT network management.

Source: cisco.com

Continue reading

Wireless Security Solutions Overview

Enterprise network is undergoing digitization through multiple technological transitions that include explosion of connected and IoT devices in the network and the movement of applications and services to the cloud. Of the 29.3 billion networking devices that are forecasted to be seen in the network by 2023, 50% are expected to be IoT devices. Cloud based applications and services are expected to be accessed from multiple sites and locations, both on and off of the Enterprise network. These new trends and network transitions have not only increased the threat surface but also has advanced the sophistication of the attacks. Securing and protecting the Enterprise infrastructure has become top of the mind for network administrators and customers. With the advances and ratifications in the Wi-Fi standard, wireless has become the de facto standard of access technology in the Enterprise network. However, due to the inherent nature of the wireless networks, it becomes even more important to detect and protect not only the network infrastructure and users, but also to secure the air.

Wireless Security Solutions

At Cisco, all solutions are built with end-to-end security in mind. In this blog, we discuss some of the security initiatives and solutions that play a role in securing the Enterprise wireless networks. These components form various pieces of the security puzzle addressing over the air security, infrastructure security and provide end-to-end visibility.

Securing the Air using Rogue Management and aWIPS Solution

Rogue management and Advanced Wireless Intrusion Prevention System (aWIPS) is a wireless intrusion, threat detection and mitigation mechanism that secures the air. Rogue management solution provides protection against AP impersonation, AP Mac spoofing, Honeypot and Rogue on wire. Auto/manual containment enables the attacks to be contained before the actual damage happens. Rogue and aWIPS together provides security against denial-of-service attacks, management frame attacks and tools-based attacks to name a few.

Rogue Management and aWIPS Solution

Rogue Management and aWIPS solution architecture comprises of:

◉ Access points: Monitors the air and detects threats using advanced configurable signature-based techniques

◉ Wireless controller: Configures the access points; receives aWIPS alarms and rogue information from the AP; does rogue classification and sends consolidated report to the Cisco DNA Center

◉ Cisco DNA Center: Provides simple and intuitive dashboard for configuration and customization of aWIPS and rogue rules. Cisco DNA Center also monitors, aggregates and consolidates events and alarms in a single pane of glass

In conjunction with Cisco DNA Center, users can customize the Rogue detection and management and also fine-tune aWIPS signatures and thresholds based on individual network needs. To meet compliance requirements and also for post-analysis of the attacks happening in the network, per-signature forensic packet capture knob is provided through Cisco DNA center. DNA Center aggregates, correlates and summarizes the attacks across the managed network on the unified Rogue management and aWIPS dashboard.

Device profiling with Endpoint-Analytics

As we embark the new wave of digital transformation, more and more devices (including IoT devices) are being added to the network. A malicious user in the network is just required to find a single vulnerable entry point in the network to breach and exploit the entire network. Once that is done, the threats can spread throughout the network from device to device in a matter of seconds. Such vulnerabilities in the network mandates granular network segmentation thereby preventing the lateral spread of threats. The first step towards achieving granular network segmentation is to identify and profile the devices and endpoints that are present in the network so that segmentation and other policies can then be enforced on these groups of devices. 

Cisco AI Endpoint Analytics is the next-generation endpoint visibility solution. It gathers context from the network and enables the visibility of the endpoints to the administrator through “behavioral-based device classification”. Following techniques are used to achieve that:

◉ Deep packet inspection (DPI): uses enhanced NBAR technology to inspect and understand the applications and the protocols the endpoints are sending over the network to gather deeper context on the endpoint

◉ Machine Learning (ML): constructs for intuitive grouping of the endpoints which have common attributes 

◉ Integration with Cisco and third-party products for additional context

Cisco AI Endpoint Analytics

Cisco’s DPI based profiling capabilities is supported in Catalyst 9800 series Wireless Controller platforms. The controller does deep packet inspection and generates telemetry data to the DNA Center to perform analytics. This enables the users to group the endpoints for segmentation and policy enforcement.

Insight into Encrypted Traffic using Encrypted Traffic Analytics 

The rapid rise in the encrypted traffic is changing the security landscape. A significant number of services and applications are using encryption as the primary method for securing information. As a result, malware detection using traditional flow monitoring techniques will no longer be feasible. Traditional way of inspecting the flows with decryption, analysis and re-encryption is not always feasible and also compromises on data integrity and privacy. Encrypted Traffic Analytics (ETA) provides insight into the encrypted traffic without decryption using passive monitoring. This insight enables us to identify and detect malware present in encrypted network connections. 

Cisco Secure Network Analytics

Encrypted traffic analytics (ETA) extracts four data elements: Initial data packet (IDP), sequence of packet lengths and times, byte distribution and TLS-specific features. These four data elements are embedded as vendor-specific data elements in enhanced Netflow records and are sent to Cisco Secure network analytics engine for further analysis. Secure network analytics analyzes these new data elements by applying machine learning algorithms and statistical modeling techniques to pinpoint malicious patterns in the encrypted traffic and help identify threats.

Cisco Catalyst 9800 Wireless Controllers support exporting of the enhanced Netflow records to security network analytics engine for further analytics and threat detection.

Securing the Network using Umbrella 

Cisco Umbrella is a cloud delivered network security service that uses DNS queries to determine if traffic to a particular domain should be allowed, dropped or needs to be inspected further. Cisco Umbrella uses DNS to stop threats across all protocols and ports. It stops malware and attackers (in real time) if infected machines connect to the network. Cisco Umbrella uses evolving big data and data mining methods to proactively predict attacks and does category-based filtering. 

Cisco Umbrella Solution with Catalyst 9800

Cisco 9800 Wireless Controllers and Cisco Embedded Wireless Controllers (EWC) support Umbrella network security service. WLC intercepts the DNS requests from the clients and redirects the queries to the Cisco Umbrella server in the cloud, along with the identity. The Umbrella service resolves the query and enforces category-based filtering rules on a per-identity basis. Policies can be enabled on individual SSIDs with separate policy for each SSID.

Umbrella can be enabled using DNA center dashboard and can be actively monitored using simplistic statistics dashboard. Umbrella enables customers to block threats at DNS layer and secures endpoints and users.

Nano Segmentation with User-Defined Network

Wireless being a shared network, there is no easy way for an end-user to communicate only with his devices or deterministically discover and limit access to only the devices that belong to them. This results in security concerns where in, a user knowingly or unknowingly may take control of devices that belong to other users.

Cisco User Defined Network

Cisco’s User Defined Network (UDN), enables simple, secure and remote on-boarding of wireless clients on to the shared network environment to give a personal network-like experience. UDN allows an end-user to create their own personal network, consisting of only their devices thereby enabling End-User driven network segmentation. This will help in limiting service discovery scope, realize traffic segmentation and enforcing of access control policies at a group level. This creation of nano-segments in a shared media provides a closed group. In addition, UDN’s ability to invite other trusted users into their personal network gives them the ability to collaborate and share their devices with select set of friends. 

Cisco’s UDN solution is supported on Catalyst 9800 controllers in centrally switched mode. Wireless controller along with the APs enables the containment of link-local multicast and broadcast traffic and optionally unicast traffic. This solution works with both Cisco and 3rd party switching infrastructure and for both IPv4 and IPv6 traffic. The SSID on which UDN profile can be enabled should have either MAC-filtering enabled or should be an 802.1x SSID.

Security is the first line of defense for protecting users, devices and data from malicious actors. The wireless security solutions discussed above detect and protect the users, devices, applications and data. It addition, it enables traffic segmentation along with end-to-end user and application visibility and network analytics.

Source: cisco.com

Continue reading

Make Your Career Bright with Cisco 350-801 CLCOR Certification Exam

Cisco CLCOR Exam Description:

This Cisco CCNP Collaboration exam tests a candidate's knowledge of implementing core collaboration technologies including infrastructure and design, protocols, codecs, and endpoints, Cisco IOS XE gateway and media resources, Call Control, QoS, and collaboration applications. The course, Implementing Cisco Collaboration Core Technologies, helps candidates to prepare for this exam.

Cisco 350-801 Exam Overview:

• Exam Name- Implementing Cisco Collaboration Core Technologies
• Exam Number- 350-801 CLCOR
• Exam Price- $400 USD
• Duration- 120 minutes
• Number of Questions- 90-110
• Passing Score- Variable (750-850 / 1000 Approx.)
• Recommended Training- Implementing Cisco Collaboration Core Technologies (CLCOR)
• Exam Registration- PEARSON VUE
• Sample Questions- Cisco 350-801 Sample Questions
• Practice Exam- Cisco Certified Network Professional Collaboration Practice Test

Related Articles:-

• Which is the Simplest Way to Pass Your Cisco 350-801 CLCOR Exam
• Your Journey to Being CCNP Collaboration 350-801 Certified Made Easier
• Know the Study Secret to Ace Cisco 350-801 CLCOR Exam

Continue reading

What Do Network Operators Need for Profitable Growth?

For the past 30 years, service providers have built networks using technology that was limited in terms of speed, cost, and performance. Historically, optical and routing platforms evolved independently, forcing operators to build networks using separate architectures and on different timelines. This resulted in a solution that drives up complexity and Total Cost of Ownership (TCO).

Current multi-layer networks made up of Dense Wavelength Division Multiplexing (DWDM), Reconfigurable Optical Add-Drop Multiplexers (ROADMs), transponders, and routers suffer from current generational technology constraints and head-spinning complexity. Additionally, operators face a highly competitive pricing environment with flat Average Revenue Per User (ARPU) but enormous increases in usage. This requires re-evaluating network architecture to support massive scale in an economically and operationally viable way to improve TCO.

Here are a few factors that contribute to high network TCO:

◉ Redundant resiliency in each network layer leading to poor resource utilization

◉ Siloed infrastructure relying on large volumes of line cards for traffic handoff between layers

◉ High complexity due to multiple switching points, control, and management planes

◉ Layered architecture requiring manual service stitching across network domains that presents challenges to end-to-end cross-loop automation needed for remediation and shorter lead times

But now we live in a different world, and we have technology that can address these problems and more. We envision a network that is simpler and much more cost-effective, where optical and IP networks can operate as one. Rather than having two different networks that need to be deployed and maintained with disparate operational support tools, we’re moving toward greater IP and optical integration within the network.

Advances in technology enabling a fully integrated routing and optical layer

Service provider business profitability runs through best-in-class network processing and coherent optical technology advancements, enabling higher network capacities with lower power and space requirements. These, coupled with software providing robust automation and telemetry, will simplify the network and lead to greater utilization and monetization. Applications like Multi-access Edge Computing (MEC) that require every operator office to become a data center continue to increase the importance of delivering higher capacities.

We’ve made great strides in technology advancements across switching, Network Processing Unit (NPU) silicon, and digital coherent optics. Last year we introduced Cisco Silicon One, an exciting new switching and routing silicon used in the Cisco 8000 Series of devices that can also be purchased as merchant silicon.

Cisco Silicon One allows us to build switches and routers that can scale to 100s of Terabits. It also means the scalability is optimized for 400G and 800G coherent optics.

Figure 1. The basics of Cisco Routed Optical Networking

What can Cisco Routed Optical Networking do for you?

The technology advancements I mentioned now enable a new network architecture for operators that we call Cisco Routed Optical Networking. We designed this solution to help service providers scale their networks more effectively to meet future traffic demands. This new architecture will lead to simplification and drive higher scale and lower TCO for IP services.

It features the integration of 400G coherent transponder functions into routing devices, meaning convergence of IP routing and coherent DWDM by leveraging the advancement of silicon photonics. You can now realize 400G coherent transport in a compact Quad Small Form-factor Pluggable-Double Density (QSFP-DD) on high-scale routing platforms. This enables service line cards that aren’t compromised in routing port density or capacity relative to their gray optical counterparts.

Other features include:

◉ Massive network simplification and higher fiber utilization by leveraging hop-by-hop IP core architecture that avoids the complexity of contentionless ROADMs and reduces compromise in fiber resource utilization to maximize network monetization

◉ Removes barriers to automated network infrastructure via closed-loop automation framework across a single converged IP and optical infrastructure for service path computation, activation, orchestration, remediation, and optimization

◉ Assimilation of private line/Optical Transport Network (OTN) services and photonic switching into a single converged IP/Multi-Protocol Label Switching (MPLS) network layer with single forwarding and control plane that leverages segment routing for sub-50ms service resiliency

Figure 2. Traditional architecture vs. integrated optics with hop-by-hop digital ROADM

 

Cisco Routed Optical Networking can provide up to 40 percent savings on TCO versus current layered network architectures. It’s also a lower TCO solution for IP aggregation for mobile backhaul applications based on coherent DWDM interface integration into IP aggregation devices. This can help service providers realize cost savings of up to 40 percent in Capital Expenditure (CapEx) and 60 percent in Operating Expenditure (OpEx).

ROADM-enabled “optical bypass” was introduced around 2005 to mitigate the cost of scaling router platforms, but this new NPU silicon, along with 400G-plus digital coherent interfaces, has changed the economics. Operators can now adopt architectures that remove their higher cost and complex ROADM-based photonic layer in favor of simplified hop-by-hop designs. However, if some network operators still prefer to maintain a ROADM-based photonic layer, they may now connect that layer directly into the router, thus eliminating the pervasive need for a discrete optical network switch or transponder layer.

Overall, these technology advancements enable new architecture and design options for operators that simplify the network and provide cost-effective ways to route traffic to intended destinations. These optimized architectures can then be built with modern software such as our IOS XR7 operating system and Crosswork automation solutions, which simplify network operation and accelerate monetization by leveraging robust APIs, model-driven provisioning, and streaming telemetry.

Our investment and strategy alignment

We’ve positioned ourselves as industry leaders in technology advancements that enable network operators to find future profitability and success. We’ll continue to lead the way through key investments and a clear strategy.

Our development of Cisco Silicon One, IOS XR7, and CrossWork are but a few examples. In March 2021 we completed the purchase of Acacia, a component supplier and manufacturer of high-speed optical networking technology. Since 2010 we’ve spent $6 billion in acquisitions and inorganic investment across optical/coherent and switching/routing silicon.

Service providers realize that the bulk of services now consuming their network capacity result in traffic increases but flat ARPU, which is not commensurate with the cost of building network infrastructure that scales to support growth at an exponential rate. There’s a need to leverage automation, Software-Defined Networking (SDN), telemetry, and machine learning to lower OpEx. Our investment and strategy, more than other suppliers, is directly aligned with enabling service provider profitability and market share growth.

Source: cisco.com

Continue reading

Cisco introduces Dynamic Ingress Rate Limiting – A Real Solution for SAN Congestion

I’m sure we all agree Information Technology (IT) and acronyms are strongly tied together since the beginning. Considering the amount of Three Letter Acronyms (TLAs) we can build is limited and now exhausted, it comes with no surprise that FLAs are the new trend. You already understood that FLA means Four Letter Acronym, right? But maybe you don’t know that the ancient Romans loved four letter acronyms and created some famous ones: S.P.Q.R. and I.N.R.I.. As a technology innovator, Cisco is also a big contributor to new acronyms and I’m pleased to share with you the latest one I heard: DIRL. Pronounce it the way you like.

Please welcome DIRL

DIRL stands for Dynamic Ingress Rate Limiting. It represents a nice and powerful new capability coming with the recently posted NX-OS 8.5(1) release for MDS 9000 Fibre Channel switches. DIRL adds to the long list of features that fall in the bucket of SAN congestion avoidance and slow drain mitigation. Over the years, a number of solutions have been proposed and implemented to counteract those negative occurrences on top of Fibre Channel networks. No single solution is perfect, otherwise there would be no need for a second one. In reality every solution is best to tackle a specific situation and offer a better compromise, but maybe suboptimal in other situations. Having options to chose from is a good thing.

DIRL represents the newest and shining arrow in the quiver of the professional MDS 9000 storage network administrator. It complements existing technologies like Virtual Output Queues (VOQs), Congestion Drop, No credit drop, slow device congestion isolation (quarantine) and recovery, portguard and shutdown of guilty devices. Most of the existing mitigation mechanisms are quite severe and because of that they are not widely implemented. DIRL is a great new addition to the list of possible mitigation techniques because it makes sure only the bad device is impacted without removing it from the network. The rest of devices sharing the same network are not impacted in any way and will enjoy a happy life. With DIRL, data rate is measured and incremental, such that the level of ingress rate limiting is matched to the device continuing to cause congestion. Getting guidance from experts on what mitigation technique to use remains a best practice of course, but DIRL seems best for long lasting slow drain and overutilization conditions, localizing impact to a single end device.

The main idea behind DIRL

DIRL would deserve a very detailed explanation and I’m not sure you would keep reading. So I will just drive attention to the main concept which is quite simple actually and can be considered the proverbial egg of Columbus. Congestion in a fabric manifests when there is more data to deliver to a device than the device itself is able to absorb. This can happen under two specific circumstances: the slow drain condition and the solicited microburst condition (a.k.a. overutilization). In the SCSI/NVMe protocols, data does not move without being requested to move. Devices solicit the data they will receive via SCSI/NVMe Read commands (for hosts) or XFR_RDYs frames (for targets). So by reducing the number of data solicitation commands and frames, that will in turn reduce the amount of data being transmitted back to that device. This reduction will be enough to reduce or even eliminate the congestion. This is the basic idea behind DIRL. Simple, right?

The real implementation is a clever combination of hardware and software features. It makes use of the static ingress rate limiting capability that is available for years on MDS 9000 ASICs and combines that with the enhanced version of Port Monitor feature for detecting when specific counters (Tx-datarate, Tx-datarate-burst and TxWait) reach some upper or lower threshold. Add a smart algorithm on top, part of the Fabric Performance Monitor (FPM), and you get a dynamic approach for ingress rate limiting (DIRL).

DIRL is an innovative slow drain and overutilization mitigation mechanism that is both minimally disruptive to the end device and non-impactful to other devices in the SAN. DIRL solution is about reducing those inbound SCSI Read commands (coming from hosts) or XFR_RDY frames (coming from targets) so that solicited egress data from the switch is in turn reduced. This brings the data being solicited by any specific device more in line with its capability to receive the data. This in turn would eliminate the congestion that occurs in the SAN due to these devices. With DIRL, MDS 9000 switches can now rate limit an interface from about 0.01% to 100% of its maximum utilization and periodically adjust the interface rate dynamically up or down, based on detected congestion conditions. Too cool to be true? Well, there is more. Despite being unique and quite powerful, the feature is provided at no extra cost on Cisco MDS 9000 gear. No license is needed.

Why DIRL is so great

By default, when enabled, DIRL will only work on hosts. Having it operate on targets is also allowed, but considering that most congestion problems are on hosts/initiators and the fact a single target port has a possible impact on multiple hosts, this needs to be explicitly configured by the administrator. With DIRL, no Fibre Channel frames are dropped and no change is needed on hosts nor targets. It is compatible with hosts and targets of any vendor and any generation. It’s agentless. It is a fabric-centric approach. It is all controlled and governed by the embedded intelligence of MDS 9000 devices. Customers may chose to enable DIRL on single switch deployments or large fabrics. Even in multiswitch deployments or large fabrics DIRL can deployed on only a single switch if desired (for example for evaluation). Clearly DIRL operates in the lower layers of the Fibre Channel stack and this makes it suitable for operation with both SCSI and NVMe protocols.

DIRL makes dynamic changes to the ingress rate of frames for specific ports and it operates on two different time scales. It is reasonably fast (seconds) to reduce the rate with 50% steps and it is slower (minutes) to increase it with 25% steps. The timers, thresholds and steps have been carefully selected and optimized based on real networks where it was initially tested and trialed with support by Cisco engineering team. But they are also configurable to meet different user requirements.

The detailed timeline of operation for DIRL

To explain the behavior, let’s consider an MDS 9000 port connected to a host. The host mostly sends SCSI Read Commands and gets data back, potentially in big quantities. On the MDS 9000 port, that would be reflected as a low ingress throughput and a high egress throughput. For this example, let’s say that Port Monitor has its TxWait counter configured with the two thresholds as follows:

Rising-threshold – 30% – This is the upper threshold and defines where the MDS 9000 takes action to decrease the ingress rate.

Falling-threshold – 10% – This is the lower threshold and defines where the MDS 9000 gradually recovers the port by increasing the ingress rate.

The stasis area sits between these two thresholds, where DIRL is not making any change and leaves the current ingress rate limit as-is.

The crossing of TxWait rising-threshold indicates the host is slow to release R_RDY primitives and frames are waiting in the MDS 9000 output buffers longer than usual. This implies the host is becoming unable to handle the full data flow directed to it.

The timeline of events in the diagram is like this:

T0: normal operation

T1: TxWait threshold crossed, start action to reduce ingress rate by 50%

T1+1 sec: ingress rate reduced by 50%, egress rate also reduced by some amount, TxWait counter still above threshold

T1+2 sec: ingress rate reduced by another 50%, egress rate also reduced by some amount, TxWait counter now down to zero, congestion eliminated

T5: Port has had no congestion indications for the recovery interval. Ingress rate increased by 10%, egress rate increases as well by some amount, TxWait still zero

T5 + 1 min: Port to have no congestion indications for the recovery interval. Ingress rate increased by another 10%, egress rate increases as well by some amount, TxWait still zero

T5 + 2 min: Port to have no congestion indications for the recovery interval. Ingress rate increased by another 10%, egress rate increases as well by some amount, TxWait jumps to 8% but still below falling-threshold.

T5 + 3 min: ingress rate increased by another 10%, egress rate increases as well by some amount, TxWait jumps to 20%. This puts TxWait between the two thresholds. At this point recovery stops and the current ingress rate limit is maintained.

T5 + 4 min: ingress rate was not changed, egress rate experienced a minor change, but TxWait jumped above upper threshold, congestion is back again and remediation action would start again.

Source: cisco.com

Continue reading