Cisco SD-WAN: The Right Tool for Keeping Fleets Moving

When people think of fleets, they often think of a collection of ships cruising across the sea. Modern-day fleets, however, include public transportation, first responders, and service trucks for utilities, ISPs, and equipment or appliance repair. Gone are the days when fleet activities were solely managed by two-way radio voice communication from a dispatcher.  In the last 20 years, fleets have been reinvented to digitally connect over wide area networks (WANs) while on the move and sending and receiving important information in real-time enabling them to operate efficiently and reliably.  Modern fleets share the need for reliable and available communications, security, and visibility.

Communication, Reliability, and Visibility

Whether we are talking about public transportation moving thousands of citizens across the city, first responders racing to the scene of an accident, or service fleets responding to power outages – fleet deployments have a definitive need for secure, reliable network connectivity with high availability that will relay business information in real-time and through the best transport possible in order to maintain operational availability and contain costs.

Consider the impact of a city bus losing connectivity to computer-aided dispatch and missing route updates or a first responder being unable to access the location of an accident scene. These kinds of scenarios emphasize the criticality of that connectivity being both reliable and available. Just like office applications, these fleet solutions require always-on, reliable WAN connectivity to perform their functions while in motion and while they are wirelessly connected.

Security as the Backbone of Fleet Management

Segmentation is critical. Take a city bus for example – several applications are running simultaneously across payment services, predictive maintenance, passenger services, and video analytics. Each requires controlled access so that only the intended persona can access data associated with each service. Using these examples, you’d want only the payment processing company seeing payment information, the maintenance department seeing predictive maintenance data, and security forces seeing video footage. This segmentation enabled by virtual routing and forwarding (VRF) capabilities provides peace of mind for those on the security side while simplifying the day-to-day life for those on the operations side.

Credentialed access to enterprise networks is also important for service fleets that run applications accessing inventory databases, work order management systems, and even payment systems that are hosted in the enterprise core network. Identity-based security policies on Cisco SD-WAN help ensure that access to sensitive information is automated and scalable to keep the right eyes on the right data.

Data encryption is critical for first responders, particularly ambulances, due to the additional consideration of patient information. Privacy is necessary to comply with HIPPA guidelines so stricter measures may need to be taken to ensure the data is secure. Cisco SD-WAN provides peace of mind when it comes to the handling of sensitive information as 2048-bit encryption keys, and underlying traffic encrypted using the AES-256 cipher come standard for devices connected through your routers.

Operational Efficiency – The Brass Ring

While all fleet categories require reliable and available connectivity as well as security, transit systems, and service fleets are also greatly concerned about operational efficiency. The fact is that most public transit systems operate at a loss and are publicly funded, bringing immense pressure to reduce costs. Service fleets, while typically funded by private industry, are ever vigilant about controlling costs and reducing service call count and duration. Both have the need for automation, consolidation, visibility, and managing airtime costs.

Cisco SD-WAN is the Answer

Cisco SD-WAN provides fleet operators with the ability to connect and monitor their fleet vehicles and automate processes while also providing needed visibility, security, and consolidation with the enterprise network.

The ruggedized industrial routers in the Cisco Catalyst IR Series come SD-WAN ready to meet vehicle environmental conditions. These routers provide reliable and available connectivity through multiple means of transport ranging from 5G and LTE to broadband, Wi-Fi, and even satellite. Cisco SD-WAN also offers configurable failovers between transports to ensure continuous communication. The brain of Cisco SD-WAN, vSmart, can automatically route business critical traffic over high bandwidth links and send lower priority traffic over lower cost links, while the vManage dashboard lets you see it all in real-time.

Cisco SD-WAN comes standard with a host of security functions that ensure your fleet vehicles and their applications are protected at the same level as the enterprise. By creating template-based policies, onboarding new devices come with ease and helps bridge together your IT and OT teams as well. The main security benefits of using Cisco SD-WAN for fleet management come from:

◉ End-to-end segmentation that isolates and protects critical information.

◉ Encrypted IPsec tunnels for data privacy.

◉ Identity-based policy management for both enterprise and industrial networks.

◉ Utilizing Cisco Umbrella for protection against internet-based threats.

◉ Security features running directly on the router, including embedded enterprise firewall, IPS, and URL filtering capabilities.

Cisco SD-WAN provides end-to-end visibility for every application and device across the entire SD-WAN fabric. Between the IoT devices powering your fleet, cloud-native applications used in the office, and every device your employees touch – Cisco SD-WAN provides a consolidated console that is guaranteed to simplify your IT operations. Reliability, availability, security, and visibility are all provided to ensure that your enterprise and fleet vehicles are optimized and protected in any scenario.

Source: cisco.com

Continue reading

Perform Web GUI Administration and Configuration with the AXL API

The AXL Philosophy and Purpose

We, as programmers, often look at an API with wild dreams about building dazzling user-facing applications that inspire jaw-dropping amazement. That’s just how we’re built. And the AXL API has the power to let you do that.

One word… DON’T.

AXL is not an API for user-facing applications. It’s an administration and configuration API. You don’t want to push an end-user application built on AXL to 1,000 users. And if you do, you’re going to have a bad time.

Think of AXL as a programmatic way to perform web GUI administration and configuration tasks. For example, in the web GUI, you add an end user this way.

1. Select the User Management menu

2. Select End User

3. Click on +Add New

4. Fill out the form

5. Save.

Now, programming that might seem silly and more work than using the web GUI. But think of it this way. You have a text file with a list of names, email addresses, phone numbers, assigned company phone extension and other personal data of new employees. Now you can write an application that reads the file and creates and configures an end-user account for each of the persons and creates and configures lines and phones entries for them. That’s automating an administration and configuration task in a way that makes your life as an administrator easier.

The Basics

AXL is a SOAP-based API. There’s no REST for the wicked here.

The most often used AXL APIs fall into the following groups:

1. addSomething (e.g., add a phone)

2. getSomething (e.g., get a phone’s info and settings)

3. updateSomething (e.g., change a phone’s info and settings)

4. applySomething (e.g., apply the changes you made for the phone)

5. removeSomething (e.g., remove a phone)

6. listSomething (e.g., list all phones)

There are a few other AXL APIs not in those groups that you’ll need at times, but those are the most frequently used operations.

Getting Started: Preparation

The best way to get familiar with AXL is to use a free, open-source tool called SoapUI. SoapUI makes it easy to experiment with the AXL API. But first, you need to download the files you’ll use with SoapUI.

Log into Call Manager as an administrator. Under the Application menu, select Plugins.

Click the Find button (not shown in this screen shot). The first item is the Cisco AXL Toolkit. Click on Download and save it somewhere.

The saved file should look like this:

Open the zip file to see its contents

Open the schema directory.

Pick the version of Call Manager you are using. In this sample, we’ll pick current.

Copy the three files above to a working directory. I chose C:\SOAP.

Download and install the open-source SoapUI from this page. You’re done with preparation. Now, it’s time to create an AXL project to play with the API.

Set Up a SoapUI AXL Project

Click on the File menu and choose New SOAP Project.

Pick a name for your project. Set the Initial WSDL to point to the AXLAPI.wsdl file you saved to a working directory earlier. Click OK.

In the left column, you should see this (assuming you used the name New AXL Test, otherwise look for the name you chose).

Right click on AXLAPIBinding and select Show Interface Viewer. You should see this Dialog Box.

Click on the Service Endpoints tab and you’ll see where you can enter information for AXLAPI binding.

Type what you see in the Endpoint field, except point to your server where it says YOURSERVER. Assuming it’s safe for your work environment to do, enter your Administrator username and password in the appropriate fields. You can create an Administrator account in Call Manager specifically for use with the AXL API, or you can use your primary Administrator account.

You can close this dialog box now.

Now let’s play with one of the requests. In the left column, find listPhone and click on its plus sign. Then double-click on Request 1. You should see all the XML for this request pop up in a new dialog.

The listPhone request has a few potential hangups that are good to learn how to avoid. Any listSomething request is going to return, well, a list of things. Scroll down to the bottom of the request XML and you’ll see these options. These give you the option to skip a number of results, or define the starting point. We don’t want to mess with those options right now, so select them and delete them.

At the top, look for what I have selected here, select it and delete it. This attribute can be useful, and you don’t always have to delete it, but in this case, you’ll need to remove the ‘sequence=”?”’ for the request to work properly.

There’s one more thing. Get rid of what you see selected in this screen shot. Select it and delete it.

There are way too many values to specify, so let’s chop down the request to look like this. Make sure to put a percent sign in the <name></name> tag. This is a wild card, which means it will list ALL the phones. You want to start simple, so this is a simplified listPhone operation.

Now’s the time to try it out. Click on the green “run” icon in the upper left. You should see the right side of the request change to this:

This is an unfortunate bug in the current version of SoapUI. It should show you the XML response by default, but it instead shows you raw information. Until the app is fixed, you’ll have to click on the upper left XML tab to view the response.

The response might look something like this:

With that, you now have enough basic knowledge to experiment with any of the AXL APIs. Hey now, you’re an all-star, get your game on, go play.

Programming Tip

And if you really want to run with the big boys, here’s a tip for running multiple AXL request sequentially. Every time you make an AXL request, Call Manager launches a Tomcat session. When you make many requests in a row, Call Manager will launch multiple Tomcat sessions, which use up CPU and RAM.

Here’s a way around that. At the bottom of the response, open up the headers and you’ll see a cookie named JSESSIONID and its value.

If you set the JSESSIONID cookie and use the same value for your next AXL request, Call Manager will re-use the Tomcat session instead of launching a new one.

What to Avoid and Common Mistakes

Many requests have a list of optional search parameter tags, commonly <name> and <uuid>. You will usually have to choose one and delete the others.

As logical as it may seem, you can’t perform a getPhone, change some values, and then copy and paste the modified XML into an updatePhone request. getPhone and updatePhone XML tags are not mirror images.

Be careful when using APIs that give you direct access to the Call Manager database, like executeSqlQuery. Complicated joins may be clever, but they can also suck up CPU and memory the size of a spy balloon, and that eats into the performance of every other operation.

Source: cisco.com

Continue reading

Gain Deeper Insights into your Cisco SD-WAN Deployments with NWPI

Imagine that you’ve built a house and invested time, money, and effort into it for a long time. You are happy that the house is completed to your satisfaction on time and that you and your family have moved in as planned. Living in your own home has never been so satisfying and things are going great. After a few months, you find that there is a water leak in your basement and a tense moment with family members to fix it. You are not a plumber, nor a contractor, and you don’t know the internal details of the pipe, the layout of the walls, or how your architect designed the house. What do you do? You need to hire an expert to first identify the source of the leak, and then spend time and money to fix it—and while waiting for the repairs you have to live with the water continuing to leak.

But what if you could have a centralized dashboard where you input the location of the seepage, it gives you all the information on the source of the leak, why and how it was caused, whether there were any issues in the architectural design, construction, etc. and a possible solution on how to fix it? Just like any professional architect helping you locate the root cause and faults, IT organizations can derive tremendous value from identifying network issues in their SD-WAN network before there is any impact on users.

Introducing Network-Wide Path Insights

Network-Wide Path Insights (NWPI) is a tool natively built into Cisco vManage that helps you find the source of the network issues users are facing from time to time while accessing their applications residing on-prem or in the cloud.  NWPI provides greater visibility and deeper insights into your SD-WAN deployment. It helps enterprises and managed service providers (MSPs)  ensure their network is operating optimally at all times.

NWPI provides comprehensive analyses of traffic flows in the network with information on applications accessed by users, classification of business-critical flows, monitoring and reporting of network delays, troubleshooting tips, and graphical deep insights into flow analyses.

Figure 1: Network-Wide Path Insights dashboard

NWPI gives visual representations of how a packet traverses the network, along with the routing policies that were made while the packet ingresses and exits the router device. It provides visibility and insights into the packet, application, flow, and network level with detailed insights such as network jitter, loss, and latency. It can assist your IT teams with performance analysis, network planning, and troubleshooting. For example, NWPI can provide the best path recommendation for an application.  For example, Webex voice traffic is better off taking the internet as a transport route to reach the destination as opposed to taking a private MPLS link route.

NWPI monitoring and analyses can be accomplished by triggering a trace for a given set of IP addresses and site IDs in the NWPI UI screen in vManage as shown below in Figure 2:

Figure 2: NWPI trace creation within Cisco vManage

When a trace is started, NWPI programs the router at each site to start collecting flow insight data with the filters specified. Your NetOps team can monitor the flow for a particular site ID, a particular VPN, or a particular source and destination IP address. To tune and deploy the policy for interested applications and domains, the DNS Domain discovery knob can be turned on to make effective design decisions before deploying newer sites.

During the duration of the trace, NWPI constantly monitors the traffic ingressing and exiting the router device based on the filters specified. The device sends the trace which is collected as metadata to the vManage console at constant intervals. vManage correlates data received from multiple routers and data sources for further analyses and reporting. There is little impact on the routers when a trace is started as all the operations are performed in the hardware. The trace thus collected helps you get deeper insights into flows that are traversing the device or network.

NWPI Integration with Cisco ThousandEyes 

NWPI can integrate with Cisco ThousandEyes (TE) to gain visibility and insight across WAN networks and ISPs geographically separated. The tool can drill down from TE tests to synthetic flows and display a readout of the packets dropped because of any congestion in the network.

Figure 3: Network-Wide Path Insights with Cisco ThousandEyes

In summary, NWPI is an extremely valuable tool built into the vManage GUI to help your IT organization gain deeper insights and more proactively manage your SD-WAN deployment.

Source: cisco.com

Continue reading

Cisco Demonstrates Co-packaged Optics (CPO) System at OFC 2023

THE CASE FOR CO-PACKAGED OPTICS:  LOWER POWER

As network traffic continues to grow due to higher bandwidth applications, such as AI/ML (Artificial Intelligence/Machine Learning), high-resolution video streaming and virtual reality, the strain placed upon data center networks continues to increase.  These insatiable demands for more bandwidth are resulting in higher speed and higher density optics and ASICs.  The aggregate throughput of switch and optics devices is doubling every two to three years, which ultimately results in doubling the speed and increases in power of the host to pluggable optics electrical interface.  Unfortunately, while Moore’s Law continues to allow us to scale our chips and equipment (despite non-trivial technical challenges), its corollary, Dennard Scaling, has been dead for a while.  This means the power required for the new generation of switch and optics semiconductors is higher than the previous one.

For Cisco’s Webscale data center customers, this has many implications.  To continue scaling a typical data center built around a fixed electrical power budget, both compute and networking must keep up with these new bandwidth demands, but within the same power envelope as before or face an expensive upgrade.

In the compute space, the requirement to remain within a fixed power budget has forced changes:

◉ Movement from single core to lower frequency multicore CPUs (central processing units)

◉ Movement away from general purpose CPUs to focused accelerators GPUs (graphics processing units) for applications such as AI/ML inference and training.

In the networking space, data center topology compromises must occur to remain within the required power envelope, and we must reconsider how we design our equipment.

◉ Take a “clean sheet” architectural approach. Cisco’s Silicon One achieves significant power efficiency improvements by rethinking how networking silicon is built.

◉ Use the latest silicon process technology to optimize the design

◉ Innovate thermal design to reduce the power needed to cool the system

◉ Holistically design our silicon, optics, and systems to optimize power consumption and thermal cooling

However, in our continued quest for innovative designs, we needed to continue to innovate. This is where co-packaged optics (CPO) come in.

THE THREE PILLARS OF CO-PACKAGING OPTICS

Pillar #1 – Removal of a Level of DSPs to Save Power

As switch system speeds and densities have increased, so has the percentage of the system power consumed by front panel pluggable optics. At 25G/lane and faster speeds, the necessity of active DSP-based retimers has driven up system power.

One of the key innovations of co-packaged optics is to move the optics close enough to the Switch ASIC die to allow removal of this additional DSP (see Figure 1).

Pillar #2 –The Remote Light Source

In traditional pluggable optics, all sub-components of the optics reside in the pluggable modules. But as optics move closer to the ASIC, the partitioning of the optical components is a critical decision.  Lasers are highly sensitive to high temperature and experience increased failure rates when placed in hotter environments (e.g. adjacent to a very hot switch ASIC).  Moving the lasers away from the high power ASIC to cooler locations within the system chassis results in several improvements:

1. Lasers can be passively cooled to a lower temperature, enabling them to be more efficient in generating optical power / Watt, lowering system power without active components like a TEC (thermo-electric cooler).

2. Lasers can be replaced from the chassis faceplate. Since the lasers are the least reliable components of the optics subsystem, making the light source accessible from the system front panel to allow easy insertion and removal is important to ensuring CPO systems have similar MTBF (mean time between failure) to legacy systems.

3. The industry can standardize on the form factor and design of the remote light source, which allows for multi-vendor sourcing. [Industry standard MSA for ELSFP (External Laser Small Form Factor Pluggable)] Cisco’s demo at OFC is the first system demo to use the industry standard form factor.

Pillar #3 – Production-Proven Silicon Photonics Platform

To place optical components very close to the Switch ASIC silicon die, two orders of magnitude (over 100x) of miniaturization is required over existing pluggable modules.  To do this, many previously separate ICs (TIA, driver, modulator, mux/demux) must be combined together on a single IC.  Cisco’s Silicon Photonics technology enables this.

Figure 2 – 4x OSFP800 vs. Cisco 3.2T CPO module (>100x volume reduction)

In this era of supply chain challenges, it is important to choose a partner with proven, reliable technology. One of Cisco’s advantages in the CPO space is the experience developing, optimizing, and shipping millions of Silicon Photonics-based optical modules.

Figure 3 – Cisco 106.25Gbps/lane Silicon Photonics SISCAP modulator (a) First generation siscap configuration; (b) driving siscap; (c) measured pam4 53gbaud transmit waveform (106.25Gbps) from second generation siscap and driver

CPO SYSTEM BENEFITS SUMMARY

As a result of these innovations, the power required for connecting the Switch ASIC to front panel pluggable optics can be reduced by up to 50%, resulting in a total fixed system power reduction of up to 25-30%.

Figure 4 – 51.2T system power reduction from pluggable to CPO

CISCO’S OFC DEMONSTRATION OF CO-PACKAGED OPTICS (CPO)

At OFC 2023, Cisco is proud to demonstrate these next steps – a side-by-side comparison of the real power reduction between:

◉ Cisco 8111-32EH, a conventional 32-port 2x400G 1RU router fully populated with 2x400G-FR4 pluggable optics modules (64x400G FR4) based on the Cisco Silicon One G100 ASIC

◉ Cisco CPO router populated with a full complement of co-packaged Silicon Photonics-based optical tiles driving 64x400G FR4 also based on the Cisco Silicon One G100 ASIC with CPO substrate

Figure 5- Cisco’s OFC 2023 CPO Demo System (in 128x400G FR4 chassis configuration)

KEY ADVANTAGES

Cisco’s CPO demonstration at OFC 2023 highlights some of the key advantages of Cisco’s technology development.

Integrated Silicon Photonics Mux/Demux for 400G FR4

One of the challenges of co-packaging optics is the requirement to miniaturize the optical components to fit on an ASIC package (over 100x lower volume than a conventional QSFP-DD or OSFP module). This requires optics and packaging innovation.

Any CPO architecture must provide the flexibility to support all data center optics types, including those using parallel single mode fiber, e.g. 4x100G DR4, and CWDM (coarse wave division multiplexing) e.g. 400G FR4.

400G FR4 uses 4 different wavelengths of light on the same fiber, each carrying 100Gbps. This means 4 different wavelengths need to be combined together.  This is often done using an external lens, which takes up significant volume.

Cisco has invented an innovative way to do this mux/demux on the Silicon Photonics IC, which we are demonstrating as part of the OFC demo.

Figure 6 – 400G FR4 module block diagram (highlighting mux/demux)

Multiple modules running at once

Integration of optical tiles on the Switch ASIC package requires innovation in package mechanical design (to ensure mechanical reliability), power delivery (to deliver current to both the switch ASIC and the optical tiles in a small area), and thermal cooling (to remove the higher power density).

Cisco’s demo has a full complement of optical tiles drawing their full power.

Enhanced thermal design to permit conventional air cooling

Another of the challenges of integrating optics with switch ASICs is while total system power decreases, the thermal density in the center of the system grows, because optics move from the front panel to the ASIC package.

Other vendors use liquid cooling to manage this higher thermal density.

Cisco has worked with key partners to develop advanced heat sink technologies, which allow conventional, reliable air cooling to continue to be used instead of forcing customers to change their infrastructure to support liquid cooling before they want to.

CISCO IS THE RIGHT CHOICE FOR OF CO-PACKAGED OPTICS (CPO)

Cisco recognizes the potential benefits of CPO technology and is investing to ensure we are ready for this inevitable transition.

However, CPO poses extremely complex problems that system vendors and network operators must solve before significant deployments can begin.  For example, it must be reliable, serviceable, deployable, offer significant power savings, and be cost-effective.  This is the reason for our demo at OFC.  Cisco expects trial deployments coincident with the 51.2Tb switch cycle followed by larger scale adoption during the 101.2Tb switch cycle.

We believe it’s not a matter of if co-packaged optics will occur, it is a matter of when. Cisco has expertise in systems, ASICs, and optics, which makes it one of the few companies that can successfully implement and deploy co-packaged optics in volume.  We remain dedicated to investing for this inevitable transition, but realistic that it may be still some ways away.

Source: cisco.com

Continue reading

ACI Segmentation and Migrations made easier with Endpoint Security Groups (ESG)

Let’s open with a question: “How are you handling security and segmentation requirements in your Cisco Application Centric Infrastructure (ACI) fabric?”

I expect most answers will relate to constructs of Endpoint Groups (EPGs), contracts and filters.  These concepts are the foundations of ACI. But when it comes to any infrastructure capabilities, designs and customers’ requirements are constantly evolving, often leading to new segmentation challenges. That is why I would like to introduce a relatively recent, powerful option called Endpoint Security Groups (ESGs). Although ESGs were introduced in Cisco ACI a while back (version 5.0(1) released in May 2020), there is still ample opportunity to spread this functionality to a broader audience.

For those who have not explored the topic yet, ESGs offer an alternate way of handling segmentation with the added flexibility of decoupling this from the earlier concepts of forwarding and security associated with Endpoint Groups. This is to say that ESGs handle segmentation separately from the forwarding aspects, allowing more flexibility and possibility with each.

EPG and ESG – Highlights and Differences

The easiest way to manage endpoints with common security requirements is to put them into groups and control communication between them. In ACI, these groups have been traditionally represented by EPGs. Contracts that are attached to EPGs are used for controlling communication and other policies between groups with different postures. Although EPG has been primarily providing network security, it must be married to a single bridge domain. This is because EPGs define both forwarding policy and security segmentation simultaneously. This direct relationship between Bridge Domain (BD) and an EPG prevents the possibility of an EPG to span more than one bridge domain. This design requirement can be alleviated by ESGs. With ESGs, networking (i.e., forwarding policy) happens on the EPG/BD level, and security enforcement is moved to the ESG level.

Operationally, the ESG concept is similar to, and more straightforward than the original EPG approach. Just like EPGs, communication is allowed among any endpoints within the same group, but in the case of ESGs, this is independent of the subnet or BD they are associated with. For communication between different ESGs, we need contracts. That sounds familiar, doesn’t it? ESGs use the same contract constructs we have been using in ACI since inception.

So, what are the benefits of ESGs then? In a nutshell, where EPGs are bound to a single BD, ESGs allow you to define a security policy that spans across multiple BDs. This is to say you can group and apply policy to any number of endpoints across any number of BDs under a given VRF.  At the same time, ESGs decouple the forwarding policy, which allows you to do things like VRF route leaking in a much more simple and more intuitive manner.

ESG. A Simple Use Case Example

To give an example of where ESGs could be useful, consider a brownfield ACI deployment that has been in operation for years. Over time things tend to grow organically. You might find you have created more and more EPG/BD combinations but later realize that many of these EPGs actually share the same security profile. With EPGs, you would be deploying and consuming more contract resources to achieve what you want, plus potentially adding to your management burden with more objects to keep an eye on. With ESGs, you can now simply group all these brownfield EPGs and their endpoints and apply the common security policies only once. What is important is you can do this without changing anything having to do with IP addressing or BD settings they are using to communicate.

So how do I assign an endpoint to an ESG? You do this with a series of matching criteria. In the first release of ESGs, you were limited in the kinds of matching criteria. Starting from ACI 5.2(1), we have expanded matching criteria to provide more flexibility for endpoint classification and ease for the user. Among them: Tag Selectors (based on MAC, IP, VM tag, subnet), whole EPG Selectors, and IP Subnet Selectors. All the details about different selectors can be found here: https://www.cisco.com/c/en/us/td/docs/dcn/aci/apic/6x/security-configuration/cisco-apic-security-configuration-guide-60x/endpoint-security-groups-60x.html.

EPG to ESG Migration Simplified

In case where your infrastructure is diligently segmented with EPGs and contracts that reflect application tiers’ dependencies, ESGs are designed to allow you to migrate your policy with just a little effort.

The first question that most probably comes to your mind is how to achieve that? With the EPG Selector, one of the new methods of classifying endpoints into ESGs, we enable a seamless migration to the new grouping concept by inheriting contracts from the EPG level. This is an easy way to quickly move all your endpoints within one or more EPGs into your new ESGs.

For a better understanding, let’s evaluate the below example. See Figure 1. We have a simple two EPGs setup that we will migrate to ESGs. Currently, the communication between them is achieved with contract Ctr-1.

High-level migration steps are as follows:

1. Migrate EPG 1 to ESG 1

2. Migrate EPG 2 to ESG 2

3. Replace the existing contract with the one applied between newly created ESGs.

Figure-1- Two EPGs with the contract in place

The first step is to create a new ESG 1 where EPG 1 is matched using the EPG Selector. It means that all endpoints that belong to this EPG become part of a newly created ESG all at once. These endpoints still communicate with the other EPG(s) because of an automatic contract inheritance (Note: You cannot configure an explicit contract between ESG and EPG).

This state, depicted in Figure 2, is considered as an intermediate step of a migration, which the APIC reports with F3602 fault until you migrate outstanding EPG(s) and contracts. This fault is a way for us to encourage you to continue with a migration process so that all security configurations are maintained by ESGs. This will keep the configuration and design simple and maintainable. However, you do not have to do it all at once. You can progress according to your project schedule.

Figure 2 – Interim migration step

As a next step, with EPG Selector, you migrate EPG 2 to ESG 2, respectively. Keep in mind that nothing stands in the way of placing other EPGs into the same ESG (even if these EPGs refer to different BDs). Communication between ESGs is still allowed with contract inheritance.

To complete the migration, as a final step, configure a new contract with the same filters as the original one – Ctr-1-1. Assign one ESG as a provider and the second as a consumer, which takes precedence over contract inheritance. Finally, remove the original Ctr-1 contract between EPG 1 and EPG 2. This step is shown in Figure 3.

Figure 3 – Final setup with ESGs and new contract

Easy Migration to ACI

The previous example is mainly applicable when segmentation at the EPG level is already applied according to the application dependencies. However, not everyone may realize that ESG also simplifies brownfield migrations from existing environments to Cisco ACI.

A starting point for many new ACI customers is how EPG designs are implemented.  Typically, the most common choice is to implement such that one subnet is mapped to one BD and one EPG to reflect old VLAN-based segmentation designs (Figure 4). So far, moving from such a state to a more application-oriented approach where an application is broken up into tiers based on function has not been trivial. It has often been associated with the need to transfer some workloads between EPGs, or re-addressing servers/services, which typically leads to disruptions.

Figure 4 – EPG = BD segmentation design

Introducing application-level segmentation in such a deployment model is challenging unless you use ESGs. So how do I make this migration from pure EPG to using ESG? With the new selectors available, you can start very broadly and then, when ready, begin to define additional detail and policy. It is a multi-stage process that still allows endpoints to communicate without disruption as we make the transition gracefully. In general, the steps of this process can be defined as follows:

1. Classify all endpoints into one “catch-all” ESG

2. Define new segmentation groups and seamlessly take out endpoints from “catch-all” ESG to newly created ESGs.

3. Continue until all endpoints are assigned to new security groups.

In the first step (Figure 5), you can enable free communication between EPGs, by classifying all of them using EPG selectors and putting them (temporarily) into one “catch-all” ESG. This is conceptually similar to any “permit-all” solutions you may have used prior to ESGs (e.g. vzAny, Preferred Groups).

Figure 5 – All EPGs are temporarily put into one ESG

In the second step (Figure 6), you can begin to shape and refine your security policy by seamlessly taking out endpoints from the catch-all ESG and putting them into other newly created ESGs that meet your security policy and desired outcome. For that, you can use other endpoint selector methods available – in this example – tag selectors. Keep in mind that there is no need to change any networking constructs related to these endpoints. VLAN binding to interfaces with EPGs remains the same. No need for re-addressing or moving between BDs or EPGs.

Figure 6 – Gradual migration from an existing network to Cisco ACI

As you continue to refine your security policies, you will end up in a state where all of your endpoints are now using the ESG model. As your data center fabric grows, you do not have to spend any time worrying about which EPG or which BD subnet is needed because ESG frees you of that tight coupling. In addition, you will gain detailed visibility into endpoints that are part of an ESG that represent a department (like IT or Sales in the above example) or application suite. This makes management, auditing, and other operational aspects easier.

Intuitive route-leaking

It is well understood that getting Cisco ACI to interconnect two VRFs in the same or different tenants is possible without any external router. However, two additional aspects must be ensured for this type of communication to happen. First is regular routing reachability and the second is security permission.

In this very blog, I stated that ESG decouples forwarding from security policy. This is also clearly visible when you need to configure inter-VRF connectivity. Refer to Figure 7 for high-level, intuitive configuration steps.

Figure 7. Simplified route-leaking configuration. Only one direction is shown for better readability

At the VRF level, configure the subnet to be leaked and its destined VRF to establish routing reachability. A leaked subnet must be equal to or be a subset of a BD subnet. Next attach a contract between the ESGs in different VRFs to allow desired communication to happen. Finally, you can put aside the need to configure subnets under the provider EPG (instead of under the BD only), and make adjustments to define the correct BD scope. These are not required anymore. The end result is a much easier way to set up route leaking with none of the sometimes confusing and cumbersome steps that were necessary using the traditional EPG approach.

Source: cisco.com

Continue reading

Meraki Network Management with ServiceNow Graph Connector

ServiceNow is a popular cloud-based platform that offers a wide range of IT services management solutions. Apart from being a great CRM tool, one of the key features of ServiceNow is its ability to integrate with other applications and systems.

The ServiceNow Graph Connector for Meraki is one such integration that provides a seamless way to monitor your Meraki organizations, networks, and devices. And create workflows to efficiently manage incidents and alerts.

How does Meraki integrate with ServiceNow?

The Service Graph Connector application or in short the SGC application is a native integration between Meraki and ServiceNow.

The application enables you to import your Meraki organizations and thus all its networks and devices into ServiceNow’s CMDB. Once imported, you can start receiving Meraki alerts and generate incidents that can be assigned and tracked. The application works by leveraging the Meraki Dashboard API and Webhooks.

How to set up a Service Graph connector to start receiving Meraki alerts?

First step is to install this application from the ServiceNow store.

Second step, head over to our detailed step-by-step configuration guide to connect your Meraki organizations with the application and start generating incidents.

What’s new in the Service Graph Connector v1.3

Recently the SGC application was updated to support the Tokyo version of ServiceNow.

With this new version update, some new features were included such as:

◉ Simplified and improved setup experience with a step by step configuration guide.

Guided Set Up

◉ New CMDB sync filters based on specific Meraki Organizations.

◉ Support for pre/post scripts in the import job so that users have the ability to adjust the data mappings as necessary.

◉ New administrative and debugging menus to add more troubleshooting.

◉ Enhanced ServiceNow security settings for receiving Meraki webhooks.

◉ Integration Dashboard to get a concise view of CMDB execution status and integration errors.

Integration Dashboard

The SGC application leverages Meraki Webhooks to send alerts to the ServiceNow instance. The built in ‘ServiceNow’ webhook payload template enables you to easily export these alerts in the format that is compatible with ServiceNow.

Built-in ServiceNow Webhook template

The ServiceNow Graph Connector for Meraki is a powerful and efficient tool for managing your Meraki network incidents. Coupled with the Meraki Dashboard platform, this integration helps ensure your network is always running smoothly.

Source: cisco.com

Continue reading

Greater Monitoring and Visibility for your Security Success

Managing network and security needs of a modern enterprise

Today’s digital transformation is fostering the modernization of enterprise networks. It’s very common for an enterprise to mix and match vendors to build its network and security infrastructure just like you would use different sources to build your home entertainment center. With the increasing adoption of different point products, SOC (Security Operations Center) engineers are getting overwhelmed with all the consoles they need to keep track of. They need a way to pool all the information together just like you would use a receiver to connect all the components of your home entertainment center

SIEM (Security Information and Event Management) is the “receiver” used to address this challenge by offering a common console to visualize data. Cisco has collaborated with Splunk, one of the market leaders in the SIEM space, to produce a comprehensive SOC dashboard.

Using Cisco SD-WAN and Splunk to create efficiencies 

Your enterprise solution often has comprehensive logging streams, and your SOC team needs an efficient approach to make sense of all the chaos around them. In addition, it’s becoming increasingly challenging to find and retain security professionals. All this and much more fuel the argument that a SIEM is becoming extremely important in enterprise networks.

Cisco has developed the SD-WAN Splunk application to ensure we are not leaving you ‘high and dry’. The application automatically parses the router’s security logs when they are sent to your Splunk environment and populates the data on a pre-built security dashboard.

How it works

You can locate and download the application on the Splunk marketplace, Splunkbase, using your existing Splunk license. The Cisco SD-WAN and Splunk integration can be achieved in a few simple steps

Figure 1 – Cisco SD-WAN / Splunk Topology

1. Download and install the Cisco SD-WAN Splunk App and App Add-on https://splunkbase.splunk.com/app/6657 Cisco SD-WAN Splunk App

https://splunkbase.splunk.com/app/6656 App Add-on

2. Under the application settings, add the Cisco SD-WAN IP and port number as a source for the log forwarding

On Cisco SD-WAN vManage, add the Splunk Application IP as a destination to forward logs

Figure 2 – Cisco SD-WAN App on Splunkbase

Deliver significant insights out of a mountain of alerts

You’re then able to make use of a comprehensive SOC dashboard to visualize all the threats captured by the SD-WAN router.

This will serve as a one-stop shop to gain a holistic view of the security events in your network. You can navigate through charts and graphs to drill down to device-level details and inspect what packet flows triggered a security event. These events are listed in three main sections.

Figure 3 – Threat Inspection Dashboard

Together, Cisco SD-WAN and Splunk enable you to transform your network and security operations

Enterprises rely on Cisco to build secure and agile networks that can safeguard their users and applications from bad actors and external threats. Just like an amplifier helps your receiver consume all the components of your home entertainment center for the best overall experience, the new Cisco SD-WAN Splunk Application helps enterprises collect vital security analytics and ensure their SOC team is on top of all the security events traversing their network.

Source: cisco.com

Continue reading