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

Enabling Integration via Webex Teams – All Together Now

Enabling Integration via Webex Teams and Cisco DNA, SD-Wan, Intersight, Thousand Eyes via Cloud API Gateway

I was really excited to have a unique opportunity to put together a team of my fellow engineers to work on a Collaboration hacking contest within Cisco. This annual event is usually in-person for a day or two in San Jose, making it out of reach for my nomadic desert comrades located in Arizona. This year, however, remote is the new normal. This unique situation made it possible for my ragtag band of misfits to participate in events regardless of our geography. So we embarked on a mission to enable webhook integration for Webex teams, so that our products can send notifications into Teams, just as they can into email.

A cloud native yet cloud agnostic solution

In order to do this we decided to make sure this wasn’t only able to support diverse products, but also, diverse clouds. A cloud native, yet cloud agnostic solution based upon serverless infrastructure supporting standard webhooks and HTTPS Post messages. We decided on Google Cloud platform and Amazon Web Services for our multi cloud endeavor.

The initial idea was actually for a separate use case – I have esp8266 modules integrated with Teams for the use case of being notified when my garage door is opened/closed, my bearded dragon’s cage is hot, etc. As these scale in number, if I ever were to change my security bot token or room ID, I would have to go re-flash all of my IoT Sensors to match. So, it creates an operational problem for leveraging Teams as a IoT device receiver or third party integrator.

Enable cloud as an API gateway

The idea was to enable cloud as an API gateway to accept requests, do advanced security checks, and decouple the Webex Teams security and context information from what is flashed onto the sensors to better manage the lifecycle. But extending this to webbooks was a natural evolution that seemed to have the most immediate impact to customers. When Demo’ing some of our cloud technologies (Intersight, Meraki), customers saw that notifications can go to webhook or email, and naturally inquired about their Webex Teams integration.

By enabling the webhook capability, we immediately added support for all of our product sets that support webhooks to integrate with Webex Teams. And do so without requiring any change on either the product, or Webex Teams. We did want to have native “handlers” in the code to handle differences in webhook formatting between different products. For our project we created handlers for Cisco DNA Center and Meraki. We had started work on Thousand Eyes but didn’t have the lab instance able to send webhooks at the time we finished the project. The amount of effort to create and modify a handler is as simple as 20 minutes worth of effort ensuring that the JSON fields that you care about, are included in what is sent to Teams.

The code is available on Github

Of note, while the code should have been very consistent between solutions, there is a difference in how Google integrates their API with their cloud functions compared to AWS. The API gateway on GCP has been out for a while, but right now integration of the API gateway on Google for cloud functions is in Beta and does require a bit more lift to setup. I expect this will normalize as it is brought to market. I also want to caveat that by noting I was seeking a functional product, closer integration with GCP teams probably would have helped with how I managed some error handling in Cloud Functions to make it integrate with API GW.

Continue reading

Retail network segmentation landscape

For as long as I can remember, retailers have recognized the importance of segmentation. The perils of mixing transactional data with other types of network traffic are significant. Yet, many retailers have found that a lack of attention in this area results in the compromise of transactional or Personally Identifiable Information (PII).

The challenge becomes exponentially more complex as the use of technology expands:

The long-predicted explosion of Internet of Things (IoT) devices is finally here. As many businesses respond to unpredictable business circumstances, it has become increasingly important that they have near real-time operational data on their stores and distribution centers. What is the current occupancy of my store? Are my chillers, freezers and hot tables working properly? Where are my associates and customers? What is my current inventory-on-hand (and what’s on the inbound truck, and when will it be here)? These questions can all be answered using IoT sensors. It is worth noting though that IoT sensors are either limited, or single-function devices, and therefore are not always able to defend themselves. If left unprotected, these devices can present a tempting attack surface for threat actors.

Point of Sale may not always be a static location. We are seeing more retailers shun the traditional fixed point of sale and adopt mobile devices. In some cases the POS may still be at a lane or cash wrap, but it may also be used for line busting, curbside pickup, home delivery, and for omni-channel returns. These additional use cases shift the emphasis from dedicated payment terminals that communicate directly with a payment processor, to multifunction devices sitting on the wireless network.

Guest wireless is now table stakes – customers expect to be able to send and receive text and email, access their shopping lists, or showroom their impending purchase to ensure they are getting the best price. A robust wireless network will not only be an expectation going forward, but a necessity to support associate efficiency and customer needs. With the advent of 5G networks, any communication that happens in the store via a mobile device needs to happen over the store wireless network, because 5G signals are unlikely to penetrate the structure of the building. Voice and data will cease when customers enter the store, unless the device can seamlessly roam onto the store network. That network will need the resilience and capacity to handle that traffic. Customers who cannot continue their conversations or access their data while in the store are likely to “vote with their feet” and shop elsewhere. In much the same way as guests now judge hotels by how fast and reliable the internet service is in their rooms, connectivity will be paramount for consumers and guests alike.

The inextricable move to the cloud has accelerated recently for multiple reasons – a need to

◉ reduce the physical IT footprint in the store

◉ stand up and configure new or pop-up stores quickly

◉ capitalize on the elastic capacity that cloud processing provides for busy periods

◉ leverage Software as a Service offerings for business systems such as supply chain and customer relationship management.

This shift to public, private and hybrid cloud can present new complexities and create a reliance on external parties, resulting in limited visibility and management to the retailer.

Many systems that are considered non-essential to the core retail mission (such as mechanical maintenance and physical security) are increasingly being outsourced. These moves result in third-party managed (or unmanaged) devices and sensors residing on the store or distribution center network.

These changes in the day-to-day operations of retailers can significantly increase the attack surface, and consequently the risk profile, for the retailer if not appropriately mitigated. The key is having a well-planned and executed segmentation and access control policy to ensure that devices and users can only access the systems and data appropriate for their role. Traditionally, this has been a somewhat manual process, which may be perfectly feasible for smaller organizations, but much more complex for larger retailers.

Continue reading