All Tunnels Lead to GENEVE

As a global citizen, I’m sure you came here to read about Genève (French) or Geneva (English), the city situated in the western part of Switzerland. It’s a city or region famous for many reasons including the presence of a Cisco R&D Center in the heart of the Swiss Federal Institute of Technology in Lausanne (EPFL). While this is an exciting success story, the GENEVE I want to tell you about is a different one.

GENEVE stands for “Generic Network Virtualization Encapsulation” and is an Internet Engineering Task Force (IETF) standards track RFC. GENEVE is a Network Virtualization technology, also known as an Overlay Tunnel protocol. Before diving into the details of GENEVE, and why you should care, let’s recap the history of Network Virtualization protocols with a short primer.

Network Virtualization Primer

Over the course of years, many different tunnel protocols came into existence. One of the earlier ones was Generic Routing Encapsulation (GRE), which became a handy method of abstracting routed networks from the physical topology. While GRE is still a great tool, it lacks two main characteristics that hinder its versatility:

1. The ability to signal the difference of the tunneled traffic, or original traffic, to the outside—the Overlay Entropy—and allow the transport network to hash it across all available links.

2. The ability to provide a Layer-2 Gateway, since GRE was only able to encapsulate IP traffic. Options to encapsulate other protocols, like MPLS, were added later, but the ability to bridge never became an attribute of GRE itself.

With the limited extensibility of GRE, the network industry became more creative as new use-cases were developed. One approach was to use Ethernet over MPLS over GRE (EoMPLSoGRE) to achieve the Layer-2 Gateway use case. Cisco called it Overlay Tunnel Virtualization (OTV). Other vendors referred to it as Next-Generation GRE or NVGRE. While OTV was successful, NVGRE had limited adoption, mainly because it came late to Network Virtualization and at the same time as the next generation protocol, Virtual Extensible LAN (VXLAN), was already making inroads.

A Network Virtualization Tunnel Protocol

VXLAN is currently the de-facto standard for Network Virtualization Overlays. Based on the Internet Protocol (IP), VXLAN also has an UDP header and hence belongs to the IP/UDP-based encapsulations or tunnel protocols. Other members of this family are OTV, LISP, GPE, GUE, and GENEVE, among others. The importance lays in the similarities and their close relation/origin within the Internet Engineering Task Force’s (IETF) Network Virtualization Overlays (NVO3) working group.

Network Virtualization in the IETF

The NVO3 working group is chartered to develop a set of protocols that enables network virtualization for environments that assume IP-based underlays—the transport network. A NVO3 protocol will provide Layer-2 and/or Layer-3 overlay services for virtual networks. Additionally, the protocol will enable Multi-Tenancy, Workload Mobility, and address related issues with Security and Management.

Today, VXLAN acts as the de-facto standard of a NVO3 encapsulation with RFC7348 ratified in 2014. VXLAN was submitted as an informational IETF draft and then become an informational RFC. Even with its “informational” nature, its versatility and wide adoption in Merchant and Custom Silicon made it a big success. Today, we can’t think of Network Virtualization without VXLAN. When VXLAN paired up with BGP EVPN, a powerhouse was created that became RFC8365—a Network Virtualization Overlay Solution using Ethernet VPN (EVPN) that is an IETF RFC in standards track.

Why Do We Need GENEVE if We Already Have What We Need?

When we look to the specifics of VXLAN, it was invented as a MAC-in-IP encapsulation over IP/UDP transport, which means we always have a MAC-header within the tunneled or encapsulated packets. While this is desirable for bridging cases, with routing it becomes unnecessary and could be optimized in favor of better payload byte usage. Also, with the inclusion of an inner MAC-header, signaling of MAC to IP bindings becomes necessary, which needs either information exchanged in the control-plane or, much worse, flood-based learning.

Compare and Contrast VXLAN to GENEVE Encapsulation Format

Fast forward to 2020, GENEVE has been selected as the upcoming “standard” tunnel protocol. While the flexibility and extensibility for GENEVE incorporates the GRE, VXLAN, and GPE use-cases, new use-cases are being created on a daily basis. This is one of the most compelling but also most complex areas for GENEVE. GENEVE has a flexible option header format, which defines the length, the fields, and content depending on the instruction set given from the encapsulating node (Tunnel Endpoint, TEP). While some of the fields are simple and static, like bridging or routing, the fields and format used for telemetry or security are highly variable for hop-by-hop independence.

While GENEVE is now an RFC, GBP (Group Based Policy), INT (In-band Network Telemetry) and other option headers are not yet finalized. However, the use-case coverage is about equal to what VXLAN is able to do today. Use cases like bridging and routing for Unicast/Multicast traffic, either in IPv4 or IPv6 or Multi-Tenancy, have been available for VXLAN (with BGP EVPN) for almost a decade. With GENEVE, all of these use-cases are accessible with yet another encapsulation method.

GENEVE Variable Extension Header

With the highly variable but presently limited number of standardized and published Option Classes in GENEVE, the intended interoperability is still pending. Nevertheless, GENEVE in its extensibility as a framework and forward-looking technology has great potential. The parity of today’s existing use cases for VXLAN EVPN will need to be accommodated. This is how the IETF prepared BGP EVPN from its inception and more recently published the EVPN draft for GENEVE.

Cisco Silicon Designed with Foresight, Ready for the Future

While Network Virtualization is already mainstream, the encapsulating node or TEP (Tunnel Endpoint) can be at various locations. While a tunnel protocol was often focused on a Software Forwarder that runs on a simplified x86 instruction set, mainstream adoption is often driven by the presence of Software as well as Hardware forwarder, the latter built into the switch’s ASIC (Merchant or Custom Silicon). Even though integrated hybrid overlays are still in their infancy, the use of Hardware (the Network Overlay) and Software (the Host Overlay) in parallel are widespread, either in isolation or as ships in the night. Often it is simpler to upgrade the Software forwarder on a x86 server and benefit from a new encapsulation format. While this is generally true, the participating TEPs require consistency for connections needed with the outside world and updating the encapsulation to such gateways is not a simple matter.

In the past, rigid Router or Switch silicon prevented fast adoption and evolution of Network Overlay technology. Today, modern ASIC silicon is more versatile and can adapt to new use cases as operations constantly change to meet new business challenges. Cisco is thinking and planning ahead to provide Data Center networks with very high performance, versatility, as well as investment protection. Flexibility for network virtualization and versatility of encapsulation was one of the cornerstones for the design of the Cisco Nexus 9000 Switches and Cloud Scale ASICs.

We designed the Cisco Cloud Scale ASICs to incorporate important capabilities, such as supporting current encapsulations like GRE, MPLS/SR and VXLAN, while ensuring hardware capability for VXLAN-GPE and, last but not least, GENEVE. With this in mind, organizations that have invested in the Cisco Nexus 9000 EX/FX/FX2/FX3/GX Switching platforms are just a software upgrade away from being able to take advantage of GENEVE.

Cisco Nexus 9000 Switch Family

While GENEVE provides encapsulation, BGP EVPN is the control-plane. As use-cases are generally driven by the control-plane, they evolve as the control-plane evolves, thus driving the encapsulation. Tenant Routed Multicast, Multi-Site (DCI) or Cloud Connectivity are use cases that are driven by the control-plane and hence ready with VXLAN and closer to being ready for GENEVE.

To ensure seamless integration into Cisco ACI, a gateway capability becomes the crucial base functionality. Beyond just enabling a new encapsulation with an existing switch, the Cisco Nexus 9000 acts as a gateway to bridge and route from VXLAN to GENEVE, GENEVE to GENEVE, GENEVE to MPLS/SR, or other permutations to facilitate integration, migration, and extension use cases.

Leading the Way to GENEVE

Cisco Nexus 9000 with a Cloud Scale ASIC (EX/FX/FX2/FX3/GX and later) has extensive hardware capabilities to support legacy, current, and future Network Virtualization technologies. With this investment protection, Customers can use ACI and VXLAN EVPN today while being assured to leverage future encapsulations like GENEVE with the same Nexus 9000 hardware investment. Cisco thought leadership in Switching Silicon, Data Center networking and Network Virtualization leads the way to GENEVE (available in early 2021).

If you are looking to make your way to Geneve or GENEVE, Cisco makes investments in both for the past, present, and future of networking.

Continue reading

Bring your personal devices to the enterprise network with Cisco User Defined Network

Are your users overloading your network with their devices? It’s no wonder. With streaming services, video game systems, virtual assistants, wireless speakers, and other devices it’s a struggle to meet demands of your network users.

Add chatty protocols such as mDNS and UPnP among others—and it just adds to the damage it can do to your enterprise network. 

The Cisco User Defined Network (UDN) solution is your savior as it helps you meet the growing demand of proliferation of wireless devices.

How does it work? It all begins on a shared network; for example you could have students in a dorm or seniors living in senior living facilities or developers and testers looking to emulate home environment. There’s a lot of devices jockeying for space on the network and not only that, these devices aren’t private. Anyone can see them, and a lot of time, anyone can access them. With Cisco UDN users get their own private partition on the network.  

Now your users can bring their home devices to the enterprise network and control their devices like they do at home. Users will now only see their personal devices on the network even when they are connected to a shared enterprise network. Not only that—and here’s the really cool thing—they can invite other users to their UDN and even share services between their personal devices and their friend’s devices while in their UDN defined partition.  

And it couldn’t be easier. All users have to do is download a new mobile app from Cisco (available for free in the Apple App and Google Play stores). This app allows them to control their UDN-defined partition, you can allow and deny access to your devices with a touch of a button. But get this, users can pre-register their personal devices before they bring them in enterprise network. That means user devices are ready to be used the minute they walk on campus. None of our competitors can say the same thing. The only thing that you have to do is enable the Cisco UDN solution from Cisco DNA Center and it works! 

Now that we told you what Cisco User Defined Network is all about, I’m sure your next question is, “How does it make my job easier and what about the network?” We’ve got you covered, check this out:  

◉ Privacy – Currently, when users connect to an enterprise network, they see all of the devices on the network—not just their own devices. With Cisco UDN, they get the peace of mind that only they can see their personal devices which they have registered through mobile app. And the flip side is no one can see their devices (see below).  

◉ Control – Currently when users authenticate to the shared network, anybody could take control of their devices because they see those devices in the network. With Cisco UDN, malicious users cannot see other devices on network, so they cannot take control of your users’ personal devices.

◉ Manage home device proliferation – You can only say no so many times to your network users to bring their home devices to the network. You know the reasons why not, but they’re not going to listen to you. To add to this frustration, this holiday season there’s a new launch of Xbox Series X, and PlayStation 5. Good luck getting anyone to keep these at home, so these devices on your network are only going to increase in numbers.

◉ Sharing – With Cisco UDN, network users can now share devices and services with each other like they used to do at home with their family and friends. So, whether it’s playing multiplayer on your game consoles, printing on a wireless printer, playing music on your roommates’ new wireless speaker or dropping files to your friend, Cisco UDN makes it just an invitation away. 

So, how does it make all of this possible? When users register their devices through the Cisco UDN mobile app, it creates a personal network for each user like a partition. Only the devices which are present in the partition can recognize each other. Users will not be able to see other devices present on the shared network. So, now they cannot start streaming to other device accidently or share something unless they absolutely want to. If they now wish to share devices with other users, they can invite those users and their selected devices to their UDN and start sharing with them. Cisco UDN gives control to invitee as well as invited user on when they want to join or leave the UDN. 

Figure 1: User Defined Networks in a shared network

Cisco User Defined Network not just helps your network users but also takes into consideration needs for an IT Admin as well in the following ways –

◉ Prevents flooding – By containing multicast traffic such as Bonjour, UPnP, and others inside their UDN partition, it prevents flooding of such packets to entire network as the traffic is now contained within a particular UDN. 

◉ Easy registration of devices – Cisco UDN provides multiple options to register the devices through mobile app via camera scanning, image scanning and other flexibilities to register from anywhere on-prem and off-prem. This gives IT admins peace of mind as they don’t have to handle registration requests when everybody tries to deploy their devices to the network.  

◉ Enablement on location of choice – Cisco UDN provides the option to be enabled only in one part of the network and need not be enabled on entire campus such as in a residential building only or only on specific SSIDs. 

◉ Provide service to subset of users – Through the integration with Active Directory, you can provide the Cisco UDN service to a subset of users and not need to enable to everyone on the network. Basically, you get to choose who can use the UDN solution. For example – you may want to enable only for students living in a dorm and not for all students.  

With Cisco User Defined Network, now you can think about allowing your users to bring any device they want to the enterprise network without having to worry about flooding or privacy. Your users can enjoy a premium home–like user experience even when they are connected to enterprise network. 

Continue reading

Watch How Riedel Networks Ensures World Events Win

Today everyone wants more and more from their network: more control, more visibility, and more security. And that’s exactly what Riedel Networks intends to give its customers, including the Olympic Games and Formula 1 as well as TV broadcasters and global enterprises.

With customers migrating data and applications, the communications networks provider decided to expand its product offerings to include a managed SD-WAN (software-defined networking in a wide area network) offering. 

Riedel Networks services some of the largest and most connected events around the world.

But with today’s security threats coming from vectors including remote workers, the additional of SD-WAN requires security gateways, both central and remote customer locations. The company needed an SD-WAN security solution for the edge.

Riedel has relied on Cisco technology since it started out connecting the headquarters of Formula 1 teams with race circuits. So, it was only natural that it turned to Cisco.

Cisco SD-WAN Security ensures every single packet on its journey to the cloud and back is kept secure without hindering performance. The Cisco technology provides everything from a broad range of connectivity options – including satellite connections and 5G mobile networks – to advanced SD-WAN routing and a full security suite.

And the vManage software controller means Riedel can manage everything centrally, over a single dashboard. With the right security controls in the right place based on policy, traffic, and location, customers have greater resiliency, no matter where they are – which is vital for businesses reliant on their networks for transferring pictures and sound as well as data.

Riedel Networks delivers customers a managed digital service including SD-WAN and SD-WAN Security for the latest in cloud networking.

The company plans to adopt Cisco’s new Catalyst 8000 Edge Platforms, which will allow Riedel Networks to deliver a secure, connected multicloud across the Cisco SD-WAN edge. Ultimately, bandwidth above one gigabyte per second means Riedel can include headquarters and data center sites in the SD-WAN.

Continue reading

Study Guide: Cisco 200-901 DevNet Associate Certification

Cisco DEVASC Exam Description:

This exam tests a candidate's knowledge of software development and design including understanding and using APIs, Cisco platforms and development, application development and security, and infrastructure and automation. The course, Developing Applications and Automating Workflows using Cisco Core Platforms, helps candidates to prepare for this exam.

Cisco 200-901 Exam Overview:

• Exam Name:- Developing Applications and Automating Workflows using Cisco Core Platforms
• Exam Number:- 200-901 DEVASC
• Exam Price:- $300 USD
• Duration:- 120 minutes
• Number of Questions:- 90-110
• Passing Score:- Variable (750-850 / 1000 Approx.)
• Recommended Training:- Developing Applications and Automating Workflows using Cisco Core Platforms (DEVASC)
• Exam Registration:- PEARSON VUE
• Sample Questions:- Cisco 200-901 Sample Questions
• Practice Exam:- Cisco Certified DevNet Associate Practice Test

Related Articles:-

• Complete Guide to Understanding Cisco DEVASC 200-901 Exam
• 200-901 DEVASC: Explore the Cisco Exam and Career Benefits
• Acing the Cisco DevNet 200-901 Exam: Top Tactics and Other Insights
• Cisco DevNet Associate 200-901 Certification: Start your DevNet Journey Today!

Continue reading

Cisco NX-OS VXLAN Innovations Part 2: Seamless Integration of EVPN(TRM) with MVPN

In today’s world, multicast senders and receivers are not limited to a single network. They can be spread across enterprise and data center locations. Multicast can be generated or consumed anywhere and can be present in various security contexts – be it a tenant of VXLAN EVPN -based data center or within a traditional IP multicast network.  

Applications expect transparency to the underlying transport architecture while security compliance demand segmentation.  Networks should enable seamless and secure connectivity without compromising security or performance. The Border Device interconnected multicast network domains are the focus of this innovation. Both the seamless integration of VXLAN EVPN with TRM (Tenant Routed Multicast) and MVPN (Multicast VPN); two flavors of the same kind. 

The Two-Node Approach

An integration in which each node acts as a border to their domain requires a two-node approach. This incurs both CapEx costs and operations burden for customers to manage two devices. The complexity is multiplied if the integration needs to happen between traditional multicast networks, VXLAN EVPN (multicast network), and MVPN networks.  

To keep OpEx and CapEx costs to a minimum, we need a simpler, single-node approach.  

We followed a step–by–step approach to provide a solution addressing all these challenges. 

◉ Cisco innovated Tenant Routed Multicast (TRM) as a first–shipped solution delivering Layer-3 multicast overlay forwarding in VXLAN EVPN networks with an Anycast Designated router (DR) for End-Points. 

◉ Cisco introduced Multicast VPN (Draft Rosen PIM/GRE) support on Cisco Nexus 3600-R and 9500-R as a steppingstone.   

◉ Cisco NX-OS 9.3(5) release delivered seamless integration between EVPN(TRM) and MVPN (Draft Rosen). Since these edge devices have functions for both TRM as well as MVPN, they act as seamless hand-off nodes for forwarding multicast between VXLAN EVPN networks and MVPN network. 

Tenant Routed Multicast 

Cisco Tenant Routed Multicast (TRM) efficiently delivers overlay Layer-3 multicast traffic in a multi-tenant VXLAN BGP EVPN data center network. Cisco TRM is based on standards-based, next-gen multicast VPN control plane (ngMVPN) as described in IETF RFC 6513 and RFC 6514 plus the extensions posted as part of IETF “draft–bess–evpn–mvpn-seamless-interop“. In VXLAN EVPN fabric, every Edge-Device act as a Distributed IP Anycast Gateway for unicast traffic as well as a Designated Router (DR) for multicast. On top of achieving scalable unicast and multicast routing, multicast forwarding is optimized by leveraging IGMP snooping on every edge-device by sending traffic only to the interested receivers. 

TRM leverages Multicast Distribution Trees (MDT) in the underlying transport network and incurs multi-tenancy with VXLAN encapsulation. A default MDT is built per-VRF and individual multicast group addresses in the overlay is mapped to respective underlay multicast groups for efficient replication and transport. TRM can leverage the same multicast infrastructure as VXLAN BUM (Broadcast, Unknown Unicast, and Multicast) traffic. Even by leveraging the same infrastructure, Rendezvous-Point (RP), the Multicast groups for BUM, and MDT are separated. The combination of TRM and Ingress Replication is also supported.  In the overlay, TRM operates as fully distributed Overlay Rendezvous-Point (RP), with seamless RP presence on every edge-device. The whole TRM–enabled VXLAN EVPN fabric acts as a single Multicast Router.   

In multicast networks, multicast sources, receivers, and Rendezvous-point (RP) reside within the fabric, across sites, inside Campus locations or over the WAN network. TRM allows seamless integration with existing multicast networks regardless of whether the sources, receivers and RP are located. TRM allows tenant-aware external connectivity using Layer-3 physical or sub-interfaces.    

TRM Multi-Site – DCI with Multicast 

Multi-site architecture

Data and application growth compelled customers to look for scale-out data center architectures as one large fabric per location brought challenges in operation and fault isolation. To improve fault and operational domains, customers started building smaller compartments of fabrics with Multi-Pod and Multi-Fabric architectures. These fabrics are interconnected with the Data Center Interconnect (DCI) technologies. The complexity of interconnecting these various compartments prevented from the rollout of such concepts with the introduction of Layer–2 and Layer–3 extensions. With a single overlay domain (end-to-end encapsulation), Multi-Pod introduced challenges with scale, fate sharing, and operational restrictions. Although Multi-Fabric provided improvements over Multi-Pod by isolating both the control and the data plane, it introduced additional challenges and operational complexity with confused mixing of different DCI technologies to extend and interconnect the overlay domains.  

TRM Multi-site

For unicast traffic, VXLAN EVPN Multi-Site architecture was introduced to address the above concerns. It allows the interconnection of multiple distinct VXLAN BGP EVPN fabrics or overlay domains, new approaches to fabric scaling, compartmentalization, and DCI. At the DCI, Border Gateways (BGW) were introduced to retain the network control points for overlay network traffic. Organizations also have a control point to steer and enforce network extension within and beyond a single data center. 

 Further, the Multi-Site architecture was extended with TRM in NX-OS 9.3(1) for seamless communication between sources and receivers spread across multiple EVPN VXLAN networks. This enables them to leverage similar benefits as that of the VXLAN EVPN Multi-site architecture.   

Tenant Routed Multicast to MVPN  

Multicast VPN (Draft Rosen – PIM/GRE)

MVPN (PIM/GRE) Draft-Rosen IETF draft “draft-rosen-vpn-mcast-10“ is an extension of BGP/MPLS IPVPN[RFC4364] and, specifies the necessary protocols and procedures for support of IPv4 Multicast. Like unicast IP VPN, MVPN allows enterprises to transparently interconnect its private network across the provider backbone without any change in enterprise network connectivity and administration for streaming multicast data. 

The NX-OS 9.3(3) release introduced MVPN (PIM/GRE) support on Cisco Nexus 9000 (R-Series) and Nexus3000 Series switches (R-Series). 

Seamless integration between EVPN (TRM) and MVPN (Draft Rosen) 

Brand new in Cisco NX-OS 9.3(5), we introduced the seamless integration between TRM capable edge-devices with Multicast VPN networks. The functionality of VXLAN VTEP and MVPN PE is brought together on the Nexus 9500-R Series and Nexus 3600-R Series. In Border PE (a combination of VXLAN Border and MPLS PE), a border device plays a VTEP role in VXLAN EVPN(TRM) network and a PE role in the MVPN network. The gateway node enables packets to be handed off between a VXLAN network (TRM or TRM Multi-Site) and an MVPN network. It acts as a central node that performs necessary packet forwarding, encapsulation, and decapsulation to send multicast traffic to the respective receivers.  The rendezvous point (RP) for the customer (overlay) network can be in any of the three networks:  VXLAN, MVPN, or IP multicast. 

Customers reap the benefits of lower OpEx and CapEx costs with a single-node approach at the border for hand-off functionality.   

Customers achieve the benefits of standards-based data center fabric deployments using VXLAN EVPN technology – scalability, performance, agility, workload mobility, and security. As data cross multiple domains or boundaries, it becomes critical for customers to achieve similar benefits without increasing costs and operational complexity. Customers are looking for a simple, flexible, manageable approach to data center operations and Cisco’s single-box solution (both VXLAN EVPN(TRM) and MVPN function on the same device) offers operational flexibility to customers.

Continue reading

Cisco NX-OS VXLAN Innovations Part 1: Inter-VNI Communication Using Downstream VNI

In this blog, we’ll look closely at VXLAN EVPN Downstream VNI for intra-site and inter-site (Inter-VNI communication using Downstream VNI).

Segmentation is one of the basic needs for Multi-Tenancy. There are many different ways to segment,  be it with VLANs in Ethernet or VRFs in IP Routing use-cases. With Virtual Extensible LAN (VXLAN), segmentation becomes more scalable with over 16 million assignable identifiers called VNI (Virtual Network Identifier). Traditionally, VXLAN segments are assigned in a symmetrical fashion, which means it must be the same to allow communication. While this symmetric assignment is generally fine, there are use cases that could benefit from a more flexible assignment and the communication across VNIs. For example, Acquisition and Mergers or  Shared Services offerings.

During Acquisition and Mergers, it is pertinent to achieve a fast and seamless integration both for the business and the IT infrastructure. In the specific case of the IT infrastructure, we are aiming to integrate without any renumbering. This broken down to VXLAN, we want to provide inter-VNI communication.

In the case of Shared Services, many deployed segments are required to reach a common service like DNS, Active Directory or similar. These shared, or extranet, services are often front-ended with a firewall which avoids the need for inter-VNI communication. Nevertheless, there are cases where specific needs dictate transparent access to this extranet service and inter-VNI communication becomes critical.

There are different methods where inter-VNI communication is used. The most common cases with attached terminology are called VRF Route Leaking. In VRF Route Leaking, the goal is to bring an IP route from one VRF and transport or leak it, into a different VRF. Different needs are present in translation cases. For example,  when you want to represent a segment with a different identifier than what was assigned (think VLAN translation).

Downstream VNI assignment for VXLAN EVPN addresses inter-VNI communication needs, be it for communication between VRFs, or is it for use-cases of translating VNIs between Sites.

Use Case Scenarios

Downstream VNI for shared services provides the functionality to selectively leak routes between VRFs. By adjusting the configuration of the VRF Route-Targets (RT), you have the option to import IP prefixes into a different VRF. Downstream VNI assignment allows the egress VTEP (Downstream) to dictate the VNI used by the ingress VTEP (Upstream). This is to reach the network advertised by the egress VTEP, which would otherwise honor the configured VNI. Downstream VNI complements and completes the need for asymmetric VNI assignment and simplifies the communication between different VRF with different VNIs. For example, the Extranet/Shared Services scenario where a service (DNS Server) sitting in service VRF needs to share the services to all the hosts (servers in different VRFs). The Shared service VRF needs to a) import the multiple VRFs into its local VRF as well as should be b) able to support the disparate value of downstream VNI.

Similar as in the shared services use-case, Downstream VNI provides a method of Translating or Normalizing VNI assignments in a VXLAN EVPN Multi-Site deployment. Where traditionally the same VNIs have to be assigned across all the Sites, with Downstream VNI we can allow inter VNI communication on the Border Gateway (BGW). By aligning the Route-Target configuration between the BGW, Sites with different VNIs will be able to communicate. Exactly as explained for the prior use-case, the egress VTEP (Downstream) dictates the VNI to be used by the ingress VTEP (Upstream) For example, Normalization/Asymmetric VNI deployment scenario, when we are adding new Sites in VXLAN EVPN Multi-Site, on new Border Gateway (BGW), it may be desirable to use and stitch completely disparate values of VNIs.

Benefits

Seamless Integration and Flexible Deployments. With Downstream VNI we have the opportunity for more seamless integration of disjoint networks with the same intent. As a result, a much more agile and time-saving approach is available. For use-cases where Extranet/Shared Service scenario exists, a more flexible deployment option exists with Downstream VNI.

How it works

1. Upon receiving a route update on the ingress VTEP (Upstream), the route is being installed with the advertised VNI from the egress VTEP (Downstream). In short, the prefix is installed with the Downstream VNI.

2. As a result, the egress VTEP dictates the VNI used by the ingress VTEP to reach the respective network advertisement done by egress VTEP. This way, the ingress VTEP uses the right VNI to reach the prefix advertised by the egress VTEP when forwarding data to this peer.

3. The process of Downstream VNI is achieved by the egress VTEP (Downstream) publishing the VNI via BGP control-plane protocol to other receiving VTEPs, which will use this downstream assigned VNI for the encapsulation instruction to send data to the egress VTEP. Data traffic will always be sent with the Downstream VNI assigned to a prefix and will override the otherwise honored configured VNI.

4. The egress VTEP dictates the VNI to be used by ingress VTEP by performing the downstream VNI assignment via the BGP EVPN control-plane protocol.

In the above example, the VTEPs have disparate VNIs i.e. 50001 and 50002. If VLAN 20 with VRF-B needs to communicate to VLAN10 of VRF-A, the VTEP-1 (L3VNI 50001) will act as a Downstream VTEP and dictate VTEP-4 to use VNI 50001 to encapsulate the packets to reach VLAN 10 and vice-versa.

What’s Next?

Stay tuned for our next blogs which cover features and benefits for VXLAN EVPN based data center fabrics such as Loop detection and mitigation in VXLAN EVPN fabrics, deliver packets in secured fashion across VXLAN EVPN sites using CloudSec and seamless integration of multicast packet (TRM) with MVPN (Draft-Rosen).

Continue reading

Bolstering Cyber Resilience in the Financial Services Industry: Part Two

As you read in part one of this blog, Cybersecurity threats have never been greater. It is imperative that your financial services organization is prepared to detect and combat even the most sophisticated cyber-attacks. Cybersecurity month brought this issue top of mind for so many in the financial services world, and now it is time to put the information into action.

Last week we starting discussing the five-point strategy to bolster cyber resilience. We walked through the first two points: Secure by Design and Zero Trust. Now let’s jump into the final three elements of this strategy.

#3) Third Party Cyber Risk Assessment

As financial services firms continue to strengthen their cyber resilience, cyber threat actors have been working hard to identify vulnerabilities both internal and external to the firm to gain access to financial data. Most financial services firms have a large ecosystem of partners (customer service, software development, equipment providers, media and internet marketing, etc.) external to the firm, who augment the firm’s products and services with their own and/or play a critical role in developing, deploying, or maintaining the firm’s products and services. These ecosystem partners are all connected to the firms network, have access to critical financial data, and are expected to comply with the firm’s risk and compliance policies. Our research has identified that “70% of Financial Third-Party Vendors have Unacceptable Compliance to Regulations” and “do not have a focus on Insider Threats and Patching”.

Cisco’s Third-Party Security Assessment Program provides financial services firms with proactive services to validate security posture within the firm’s third-party vendors and provides direction for improvement of systems, processes to each vendor, including relevant training and certification support.

#4) Security Awareness Training (Employee Training)

It’s become evident that, often, the weakest link in many cybersecurity defenses are people. In fact, according to the 2019 Gartner Magic Quadrant for Security Awareness Computer-Based Training, “People influence security more than technology or policy and cybercriminals know how to exploit human behaviors.”

So, while technology continues to evolve, the human element will always be the most unpredictable variable to secure. In order to fortify against people-enabled losses, financial services firms are turning to security awareness and training programs. Recent events have highlighted an increased need for security awareness, as the transition to a remote workforce has unveiled new, targeted threats that require employees to detect on their own.

Cisco Security Awareness is designed to help promote and apply effective cybersecurity common sense by modifying end-user behavior. Using engaging and relevant computer-based content with various simulated attack methods, this cloud-delivered product provides comprehensive simulation, training, and reporting so employee process can be continually monitored and tracked; an important part of compliance standards such as HIPAA and GDPR.

#5) Cyber Insurance

Financial services firms are at huge financial risk when a data breach occurs. To protect themselves from such an eventuality and in light of the emerging advancement in data theft and manipulation threats, it is imperative that they protect themselves with cyber insurance. Aside from providing financial cover, these cyber insurance providers also provide their customers with advanced notification of threats. Cisco is part of an industry-first offering partnering with Apple, Aon, and Allianz to bring together the key pieces needed to manage cyber risk: security technology, secure devices, cybersecurity domain expertise, and enhanced cyber insurance (select markets only).

Now What?

It is evident that there has never been a more pressing time to evaluate your cybersecurity strategy. Once you walk through the five-points above, here is one final checklist to ensure you are maximizing your cybersecurity strategy.

For a financial services firm to have a robust cyber resilient strategy:

1. The cybersecurity practices of their third party partners as well as their own have to be regularly reviewed, audited and continuously enhanced.

2. There must be a security-first mindset from the CEO down to every employee and partner in the organization.

3. Employee awareness and training sessions on cyber hygiene best practices must be held regularly to prevent exploitable vulnerabilities and help minimize the impact of any data breach.

4. Firms must collaborate with the financial services industry participants to share learnings, best practices, and develop industry wide cyber resilience strategies

Take these tips and the (above) five point cyber resilience strategy to ensure that you are doing everything you can to secure your financial services organization.

Continue reading