Cisco and IBM: Solving Customer Challenges through the Power of Partnerships

Complexity is one of the top challenges our customers face today. CISOs not only want to enable their teams to detect and respond to threats faster, they want to simplify workflows and streamline operations at the same time. In our annual CISO surveys, we’ve been seeing a trend toward vendor consolidation, which tells us CISOs are looking for ways to make their solutions simpler.

Vendors typically work in siloes to solve these kinds of challenges. But at Cisco, we believe we can achieve more through collaboration. That’s why we’ve been working in partnership with IBM Security to provide joint customers an in-depth, end-to-end defense strategy while simplifying their vendor relationships.

The average organization juggles 45 different security vendors. Leveraging the breadth of Cisco and IBM’s security portfolios allows our customers to drastically reduce that number of vendors while still using best-in-class products. The reduction in vendor surface creates more than just technical efficiencies. By consolidating vendor relationships, customers can maximize their buying power through vehicles like Enterprise Agreements, as well as simplify contract management and support cases.

Leveraging Cisco and IBM strengths

At Cisco, we believe we have excellent technologies to help customers prevent threats to their businesses, and with products like Cisco Threat Response, we even speed up various elements of the technical response. With IBM, we have focused our initial integrations on QRadar and Resilient product lines to help customers further prioritize threats and better assist with their response both at a technical and business level.

Let’s say you had an insider attack. The Cisco/IBM integrated solutions enable faster investigations of suspicious behaviors that could compromise credentials or systems. For example:

◉ Cisco Stealthwatch looks for behavioral indicators of compromise in activity traversing the network, including encrypted traffic without the need to decrypt the data. IBM QRadar builds on that detection, as well as other Cisco solutions like Firepower Threat Defense, to correlate events from network traffic and logs to help security teams quickly prioritize threats.

◉ Cisco Identity Services Engine helps you associate malicious activity with specific user credentials, and you can quarantine the user and lock down network access right from QRadar.

Responding to the attack is not just about gathering the information. You also need to understand how the business responds to the threat — is this something that needs public release of information, do you need to involve law enforcement, will this result in employee termination, and so on. To help operationalize incident response, you can use investigation results from all the integrated solutions to create a report in Resilient.

Innovative solutions to address customer needs

Many of the Cisco/IBM collaborative solutions are unique for the industry, and they’re based on lessons Cisco and IBM have learned from our extensive customer bases and our threat intelligence teams, Cisco Talos and IBM X-Force.

To make breach response more efficient, earlier this year we integrated Cisco Advanced Malware Protection (AMP) for Endpoints with QRadar and IBM Resilient SOAR. These integrations enable security teams to do things like:

◉ Receive AMP for Endpoints telemetry directly in QRadar for a consolidated view of events across endpoints and ability to search, analyze, and correlate them.

◉ Pull AMP for Endpoints data into Resilient to investigate events, automatically bring the results into an incident, and get more details on detected threats, then quarantine detected malicious files.

Since threats evolve quickly, defenses can’t rely on one mechanism alone. We work together in various other ways to help you detect unknown threats like ransomware or speed up response time. For instance:

◉ Resilient customers can submit suspicious malware samples to Cisco Threat Grid to get detonated, with the hashes sent back to Resilient. This can stop malware or ransomware before it ever reaches the end user.

◉ IBM Resilient users can query Cisco Umbrella for a list of blocked domains, save them to a data table, and delete or add new ones — preventing end users from accessing risky internet connections.

We’re listening to your feedback

Because we’re invested in the results that this collaboration can produce for our customers, we’re continuously expanding and improving our integrated solutions based on your feedback. The latest examples are enhancements made to the Firepower Threat Defense and QRadar SIEM integration, which accelerate threat investigation and remediation by correlating events across network, applications, and users.

Our customers wanted to dig deeper than the top-level summaries previously available. We listened — and the new, enhanced Firepower app that we’re releasing provides a higher level of detail in the integrated dashboard.

With Firepower Threat Defense and QRadar, you can answer questions like:

◉ Which hosts in my network are potentially compromised?

◉ Which hosts are known to be compromised?

◉ What malware is most often observed in my network?

◉ Which hosts have sent the most malware?

This is just one of the new enhancements and expansions we’ve been making as part of our alliance, and more are on the roadmap. By reducing complexities, increasing visibility, and improving threat defenses, our collaboration is improving outcomes in areas that are top of mind for our customers.

Continue reading

Unpacking IoT, a series: The complexity challenge and what you can do about it

In this post, I cover the final of the top three challenges: complexity. For an IoT initiative to be successful, the deployment and management of connected devices must be made simplified.

The typical solution to address scalability is automation. Automation certainly helps expedite and scale out an IoT deployment, but it’s not enough. If you cut and paste, and deploy text-based device configurations, that will help speed up configuration, but it won’t simplify deployments. A network administrator still has to come up with an appropriate network configuration to meet the business needs, perform extensive testing and validation of these configurations on a platform-by-platform and software-image by software-image basis, and finally templatize these configurations to support device-specific variables (like device names, discrete interface IP addresses, location details, etc.). So, how do we make this entire process easier beyond just automation?

To simplify IoT deployments, Cisco has made a paradigm shift in terms of how we empower network operators to program network devices. This new approach is called intent-based networking. To realize the impact of this new way of thinking, you need to understand that there are essentially two main ways to “program”— that is, to provide a set of instructions. One way is called the imperative model and the other is called the declarative model. Any programmable thing — whether it’s a computer or a person being given instructions — can be programmed using one of these models. The best way to explain the difference between the two models is to use a simple analogy.

Imagine you’re taking a taxicab to the airport. One way you can ensure you get to your destination is by providing the driver explicit turn-by-turn directions: turn left at the first signal, go down three blocks, turn right on Main Street, etc. You break everything down into discrete, very easy to follow directions, but they’re very complex. This approach illustrates the imperative model of programming, where every instruction needs to be provided in detail. Additionally, it should be noted that the imperative approach may even be sub-optimal and inflexible. For example, what if a particular street was closed for repairs and you didn’t know how to detour around the affected area?

An alternative approach, the declarative model, is to leverage the knowledge of the taxi driver and simply declare your intent: take me to the airport. You don’t need to explain how to get there or which route to take. You just express your intent — the business result that you want to achieve — and then rely on the driver to deliver on that intent. This is the paradigm shift we made at Cisco and what intent-based networking is all about.

Intent-based networking for IoT

Cisco DNA Center is the equivalent of that cab driver who knows how to get you from point A to point B without detailed instructions. We’ve embedded 30 years of networking knowledge into our solutions, enabling network operators to express their intent at the business level. For example, in the case of network security policies, a network operator can indicate these devices can talk to those devices. These people can access thoseapplications. That’s business-level intent. There’s no need to specify all the rules of how that intent is delivered, which technology is utilized, what kind of access policy is applied, where it’s deployed, etc. The network operator allows the machine to translate that and then to scale that configuration using automation to the programmable physical and virtual network infrastructures.

But that’s not all. We close the loop by soliciting telemetry data from the infrastructure to confirm that indeed the stated intent was delivered. The system compares the data from the network with what was declared by the operator to make sure that the business intent is being delivered. Either it is, and you have confirmation and data to that effect. Or, it’s not and that’s very important to know because then you can launch a troubleshooting workflow to investigate the root cause and take remedial action.

Intent-based networking is not new. We’ve been doing it within our data center with our application-centric infrastructure for quite a few years now, and more recently in the past five years we’ve been doing it in our enterprise networking. The expression of that is Cisco DNA Center.

What’s important now is that we’ve extended intent-based networking capabilities to the IoT edge. All IoT switches, routers, and wireless access points that run Cisco IOS XE can be managed by the same pane of glass you use to manage the rest of your network via DNA Center. Furthermore, you can extend the enterprise network to your IoT edge — wherever that happens to be: your parking lots, warehouses, distribution centers, manufacturing facilities, airports, seaports, utilities, power grids, etc. All of these places can be extended to using the same toolset.

The result: one intent-based network architecture for a consistent end-to-end experience and one set of security policies. IoT deployment is simplified, but it’s also scalable and secure.

Continue reading

Optics: Fundamental to Build the Internet for the Future

The internet. Who knew what an impact it would have on our world? Two decades ago, the phrase “being connected” in the way we think of it today barely existed. Now, not only are our computers connected to the internet, but new inhabitants including phones, clothes, cars, homes – the list goes on – are connected. And more is coming, faster. In fact, in 2022, more internet traffic will be created than in the entire 30+ years since the internet started. [Source – Cisco VNI report]

At Cisco, when we think about those numbers, we think about what they mean to our customers and how we can help them navigate the internet of the future. The higher speeds required of the new internet won’t be achievable if the optics connecting the routers and switches can’t keep pace with the silicon that drives them. Therefore, as internet traffic and speeds continue to increase, optics has a critical role in driving architectural transitions.

Today, there are two distinct worlds where optics plays a role:

◉ Inside the data center, where fiber is plentiful and distances are short (<10km). Every router or switch port has its own dedicated fiber. If a new switch or router is added, additional fiber is added to terminate the new ports. We use pluggable “direct detect” technology for this.

◉ Outside the data center, where fiber is scarce and distances are long (>80km). Challenges in transmitting high bit-rate signals over long distances require Dense Wavelength Division Multiplexing (DWDM) coherent transmission technology.
There are trends, both inside and outside the data center, that are taking place.

Trends Inside the Data Center

The growth in within data center traffic accelerates the need for next-generation networking equipment to support higher port densities and faster bit rates. This in turn drives the requirements for large scale deployment of high-speed optics to connect the various layers of the networking equipment. As router/switch port speeds have increased, the cost/bit has steadily decreased from advances in silicon (ASICs). However, while the cost/bit for pluggable optics has also decreased, it has not come down quite as fast as the router/switch port cost.

The result is that as the bit rate increases, pluggable optics represent a larger fraction of the total hardware cost. For example, at 10G, optics represented about 10% of the total hardware cost of a data center network. As we progress to 400G and beyond, that equation flips, and optics will represent more than half of the total hardware cost. In order to break this imbalance between optics cost curves and silicon cost curves, Cisco is investing in technologies like silicon photonics, via the Luxtera and Lightwire acquisitions.

Trends Outside the Data Center – in the DCI, Metro, Long Haul and Subsea Distances

The primary challenges for cloud and service providers in Data Center Interconnect (DCI), Metro, Long Haul and Subsea networks are to:

◉ Increase the capacity on the “existing” fiber infrastructure

◉ Drive down the cost per bit

◉ Automate to lower opex and eliminate human error

The key trend that we see in this segment is a migration from chassis-based solutions to pluggables.

Functions that were traditionally delivered in separate chassis-based transponder solutions will now be available in a pluggable form factor. This has potentially significant benefits for network operators in terms of operational simplicity. The key tipping point for this transition is that the pluggable coherent optics impose no density penalty for the router/switches. Over time, with continued improvements in silicon and optics, we have no reason to believe this won’t extend to cover a wider range of applications.

Our customers increasingly want to consume technology in different ways – some want to consume fully integrated systems (for coherent applications in metro/long haul as an example). As this technology becomes available in pluggable form with things like 400G ZR/ZR+, customers will consider architectural shifts relying on pluggables. These transitions are on the horizon, and Cisco is investing to make sure we have the right technologies to support our diverse customer needs – both for those who continue to deploy chassis-based solutions, as well as those who migrate to pluggables to collapse layers and reduce operations complexity.

And, finally, we want to increase our relevance for customers purchasing pluggables today for short reach applications – even for non-Cisco hosts.  We are confident that we bring unique value to our customers who want to procure optics and can provide them with confidence that Cisco optics will work in any third-party host.

With the ownership of silicon and optics, Cisco is poised like no other in the industry to offer our customers solutions in the form they want to consume – whether that means discrete components or fully integrated solutions – for the new internet.

Continue reading

ACI + UCS: Two ships finally meet

Simplicity has become the new mantra within IT, especially within the datacenter. An abstracted intent driven policy model is the foundation to achieving simplicity. Cisco pioneered this concept back in 2009 with the release of UCS, introducing a radical shift in how compute services are delivered. The desired compute need can be described in an abstracted policy model and automatically orchestrated across a unified compute fabric (compute/peripherals/storage/network).

ACI brought a similar intent driven model to the datacenter networking fabric. Users can model their ideal network topology in a very simplistic user interface and that policy is delivered across a very sophisticated VXLAN host-based routed fabric. ACI automates complex tasks like creating VRFs consistently across a fabric, setting up anycast gateways on all leafs, configuring the underlay and overlay routed networks to support a VXLAN topology, extending networking and security policies across physical sites or into the cloud, and much more.

And now the problem

One very common and popular use case for ACI is managing network segments for workloads to consume, especially for hypervisor based workloads. In the past, the process of properly plumbing a network segment all the way down to the virtual switch required coordination across multiple teams. Network operators needed to ensure the VLAN was properly defined upstream, routing was configured for that network, and the VLAN was trunked across all switches where needed. The hypervisor operators would then need to ensure the same VLAN id was configured properly within the virtual switch across all hypervisor hosts where needed. If any of the hypervisor hosts lived in a blade enclosure where vendor specific networking elements were used then the server operating team would also need to ensure the VLAN was configured properly through the blade switching fabric.

With all of these potential touch points, the theoretically simple task of extending a new networking segment to virtual workloads could be very error prone and susceptible to lengthy delivery times…….but there’s a much simpler way…..ACI to the rescue!! With ACI, the delivery of this network segment can be fully delivered to the virtual switch with multi-tenant segmentation included. This takes care of the physical and virtual networks however server enclosure switching would still need to be configured properly by the server operations team. While UCS provides a programmable compute fabric which makes creating these VLAN segments simple and consistent, operationally ACI and UCS were ships in the night completely operated by different teams thus requiring a coordinated effort.

Better Together FTW

With the 4.1.1 and above release of ACI these two ships have joined forces to completely remove the operational overhead!! For the remainder of this post we will look at how VMM integration is configured inside of ACI, how we had to separately configure UCS in the past, and how this new ACI+UCS integration makes the task simpler.

VMM integration with ACI

Integrating ACI with a VMM (virtual machine manager) domain such as vCenter is very easy to do using the ACI UI. Please watch the video below for a detailed walkthrough.

Testing Connectivity: First Attempt

At this point ACI has helped automate the delivery of multiple multi-tenant network segments (EPGs) throughout the physical and virtual networks. Now let’s attach some linux test VMs to these new networks and verify connectivity.

Centos VM 1

Centos VM 2

From within the vCenter web console for demo-centos-1 we can check if an IP address was properly allocated via DHCP.

It appears that our test vm did NOT properly receive an IP allocation from the DHCP server. What went wrong?

ACI has handled configuring the network segment through the physical and virtual fabric but what about server networking within the UCS compute fabric? Let’s investigate.

As shown above, one of the dynamic VLAN IDs (1005) was checked out of the pool created in ACI and assigned to the distributed port group our test VM is using. However, inside of UCS Manager the VLAN list for the vNIC template of the ESX host is blank. This would definitely explain why reachability is broken.

Now let’s add VLAN 1005 to the UCSM VLAN definitions as well as to the vNIC template and re-test.

The test vm now successfully negotiates a DHCP address and is able to ping its default gateway. Rinse and repeat this process for the second EPG.

In the past, you could minimize this operational overhead by pre-populating all of the VLANs from the dynamic VLAN pool in ACI into UCSM. The drawback to this approach is you are creating unnecessary overhead (STP logical ports) for network segments that may not be in use.

A Better Approach

With the release of ACI version 4.1.1 and above, a new capability has been added called Cisco ACI with Cisco UCSM integration. Today, this integration is specifically for VMM domains deployed on an FI-based UCS compute fabric. The following pre-requisites are required for this new integration to work:

◉ Cisco Application Policy Infrastructure Controller (APIC) Release 4.1(1) or later

◉ Cisco UCS and Cisco UCSM properly installed and configured in your data center

◉ Cisco UCSM 3.2 or later

◉ UCSM vNIC templates that are configured as Updating Template type

◉ Creation of a VMware VMM domain or a Microsoft System Center Virtual Machine Manager (SCVMM) domain (vCenter example is shown in the first part of this blog)

◉ Installation of the Cisco External Switch app.

Setting up the Integration

1. Ensure you’ve met the pre-requisites listed above

2. Install the External Switch ACI app and configure the UCSM Integration

3. Create a new EPG

Now that the integration setup is complete let’s create a new EPG and see how things have changed operationally. Back in the ACI user interface we can repeat the procedure from Step 3 in the VMM Integration with ACI section to create a third EPG.

Now we can verify that the new port group was created on the ACI managed VDS.

As shown in the screen capture above, ACI assigned VLAN 1004 from the dynamic pool to the newly created port group mapped to our EPG. This is where the wheels fell off previously because the VLAN was not yet defined within the UCS fabric. We can now go back into UCSM to verify.

In the screen captures above we can see that VLAN 1004 was correctly added to our VLAN Group managed by the ACI+UCS integration and was also added to our VNIC templates for the ESX hosts. Now we can assign another test VM to this newly created port group and test connectivity.

Our test VM was successfully assigned a DHCP address and is able to ping our first test vm in the 172.17.0/24 subnet.  Mission accomplished!!!

But what about cleanup???

The ACI+UCS integration connects the dots between ACI and UCS for creating new EPGs within our VMM Domain but what about teardown?  Simple enough to test, let’s delete the EPG we created in the last section.

Validating in vCenter

Validating in UCSM

From the screen captures above we can see that the port group was properly removed from the VDS in vCenter AND the VLAN was also removed from the VLAN group and VNIC templates in UCSM.

Final Thoughts

If simplicity is the ultimate goal then the ACI+UCS integration helps get you that much closer to the finish line.  Together these two solutions provide intent driven policy models that simplify how network and compute services are delivered within your datacenter anywhere environments.

Continue reading

The Power of Multi-Domain Integration for Your Network

End-user expectations for digital experiences have never been higher. Cisco is meeting the demand to have an unplugged and uninterrupted experience with its multi-domain integration across the data center, campus, and branch.

But what does this mean in practicality? Application access must be secure regardless of location. Everything must be connected. And the connection must always be on. These expectations are driving the digital transformation happening all around us today.

Today’s workforce is mobile, unplugged, and expects a high-quality application experience, The office is wherever you are, whether it be in the office, at home, or at a café. Such connected mobility is critical, but how well you’re able to interact with your applications is perhaps even more critical for productivity.

For businesses, the need for user segmentation is growing, while also ensuring a completely secure environment. Businesses must provide what users have come to expect when it comes to infrastructure availability, flexibility, and performance. Every organization needs to deliver this unplugged and uninterrupted experience. Business outcomes are driven by connected devices that must be always-on. Network downtime means missed opportunities and the halt of growth.

Finding the right balance

The challenge of balancing these requirements for an unparalleled digital experience falls on the shoulders of IT. When considering how varying the types of needs in different campus environments are today, you can understand the need for multi-domain integration that brings together network visibility, access, and always-on security:

◉ Medical campuses, with life-saving devices connected and relying on the network.

◉ Facilities management, with a vast array of IoT that includes HVAC, security imaging, and lighting control systems.

◉ Retail operations, with internet-connected robotic systems fulfilling orders and restocking returns.

Marriott’s 2018 data breach is the perfect example of the delicate balance between user experience and security that IT must manage. While the focus was on users and the ease of its reservation-booking experience, the hotel chain was unaware that a security breach in the reservation database had taken place over a four-year period, which involved over 380 million guest records and cost the organization more than $120 million to mitigate.

On the one hand, IT is tasked with providing the best digital experience for users and the organization. But at the same time, an equal importance must be placed on compliance requirements and mitigating business risk.

Multi-domain integration for your network

In response to this need, Cisco introduced Intent-Based Networking (IBN) in 2017, which delivers a secure, end-to-end digital experience, with its intuitive, self-optimizing, always-secure network that takes the guesswork out of network management through the power of multi-domain integration.

For the campus, Cisco has delivered the IBN vision through SD-Access. For the branch, it’s SD-WAN. And our Application Centric Infrastructure (ACI) encompasses both the data center and cloud. Multi-domain integration enables these three components to complete our IBN vision, which is a solution only Cisco can provide.

Enhancing your business outcomes, multi-domain provides the expected user interactions with all applications across these interconnected domains, while simultaneously driving down costs, complexity, and risk.

Users and devices can log on from anywhere, while applications can also reside anywhere. Whether you’re using cellular, wireless, or a wired connection from any campus, branch, or remote location, the end-user is provided a seamless, secure experience regardless the means of connection.

The support of built-in security

Built-in security is a key component to reducing the attack surface and mitigating risk, while continuing to provide a fully connected, uninterrupted service. And there are three fundamental pieces of the end-to-end security that multi-domain integration provides.

The first is continuous network visibility. Traditional perimeter-based security, or even a standalone endpoint security solution, isn’t able to address the network communications flow between users, applications, and devices.

Next is Zero Trust. Bad actors are becoming more sophisticated in avoiding detection. Logical end-to-end segmentation—where we contextually group all endpoints, users, devices, and applications—enables the network to isolate only those assets and resources where access is authorized at any given time.

Finally, constant protection is the final piece of our security puzzle. The network transformation afforded by multi-domain integrated architecture means your entire infrastructure becomes dynamic. To provide total security, Cisco embeds hundreds of thousands of control points with every network device—from the campus across the branch, and into the data center and cloud.

Multi-domain integration brings all the pieces of the IBN puzzle together. And Cisco invites you to unlock the potential of your network and take the next step in your organization’s digital transformation.

Watch for a future blog that dives deeper into the multi-domain integration story and how it works for your network.

Continue reading

ONE Silicon, ONE Experience, MULTIPLE Roles

Wherever you are, you likely have devices containing a semiconductor chip around you – computers, phones, television sets, printers, cars, trains, airplanes, and more. It’s almost hard to believe that this tiny electronic component unleashed the same magnitude of change as the Industrial Revolution by making the computer revolution and the digital age a reality. And these semiconductor chips are everywhere; today, there are more chips in existence than people on earth.

As a critical building block of networking devices, silicon chipset design primarily addressed routing use cases, and chipsets were optimized for programmability, deep buffering, and scale. When enterprises and cloud providers needed higher bandwidth, silicon designs emerged optimized explicitly for high-bandwidth and low power consumption. They met an immediate need, but at the expense of programmability, buffering, and scale.

Different silicon chipset requirements pushed the industry down a trajectory of two separate markets – the switching and routing markets – each of them defined by unique architectures, systems, and software. Despite several attempts to converge these into a single architecture, they have remained separate. Until today, switching silicon has always been faster than routing silicon.

While the industry searched for a convergence point, it grappled with the slowdown of “laws” that governed the development of silicon chipsets. For decades, the economics of silicon have been guided by 1) Moore’s Law – the number of transistors on a single silicon chip would double every two years and 2) Dennard Scaling’s Law – as transistor dimensions shrank, each transistor would operate faster and use less power. These two laws drove the golden age of silicon chipsets, but they are showing signs of weakness. As a result, silicon designs – for both routing and switching – have diverged as companies tried to overcome the limitations of Moore’s and Dennard’s Laws in their own way.

As innovators, and despite the mounting challenges, we never stopped dreaming of a single chipset architecture that could serve the needs of routing and switching. Could we build one architecture to solve multiple market needs, form factors, roles within the system, and that could scale, as needed? And could we do it all without making any compromises?

If we could build it, it would mean a fundamental shift in the industry.

Today, I’m thrilled to announce Cisco Silicon One™- a ground-breaking, new silicon architecture that has achieved these lofty goals.

For the first time, not only are we elevating routing silicon’s performance to the same level as switching silicon’s performance – both from a bandwidth and power efficiency perspective – but we are also paving the way to faster performance gains in the near future.

Cisco Silicon One is the first architecture that serves several different market segments – service provider and web-scale. And with future product lines built on a consistent silicon architecture, customers can enjoy ONE experience across the entire network, across all network functions and covering all form factors. With Cisco Silicon One, customers can significantly reduce OpEx – as network engineers save time on testing functionality, qualifying new hardware, and deploying new services with greater consistency and faster time-to-market.

Cisco Silicon One Q100, the first generation of this architecture, is twice the network capacity of all other high-scale routing ASICs. It is the first routing silicon to break through the 10Tbps benchmark for network bandwidth, without compromising carrier-class capabilities, e.g., feature richness, large queue set, deep buffers, large NPU tables, and advanced programmability.

It also demonstrates many architectural advantages. It can support a fixed switch or router with 10.8T worth of network ports up to large non-blocking distributed routers with Petabit scales. All of them with non-blocking performance, deep buffering with rich QoS, and programmable forwarding.

Another important innovation of the Cisco Silicon One Q100 is its unprecedented versatility. Up until now, networking vendors were using different and specific silicon chipsets for standalone processors, line card processors, and fabric elements.

But with the Cisco Silicon One Q100, all of these roles, including standalone network processor (optional deep buffers), traditional line card network processor (optional deep buffers), oversubscribed line card network processor (optional deep buffers), and fabric element in a distributed router can be met by a single chipset. All accomplished with a common and unified P4 programmable forwarding code and SDK.

And networks built with Cisco Silicon One Q100 will deliver greater consistency in features, services, and telemetry across multiple network locations because it unifies and streamlines operations by eliminating parity problems, upgrades, and other issues associated to different silicon.

The innovations in Cisco Silicon One represent years of investment and are vital for the future of the Internet. Legacy designs that rely simply on CMOS densities will suffer from the slowdowns inherent in Moore’s Law. With Cisco Silicon One, Cisco opens up a fast lane to future innovation that will outpace traditional methods while development cycles for silicon iterations will be dramatically shorter.

Continue reading

Drag and drop your way to network segmentation

I can understand if you dread configuring network segmentation. Not only is it hard to configure the many different switches and routers, creating VLANs, using ACLs to create lists of permit or deny IP addresses, it is also easy to make mistakes and risk shutting down parts of the network. And with users and devices moving around, you must continuously modify these configurations. Is it any surprise that many of today’s networks are not optimally segmented?

In this blog we discuss how Cisco Digital Network Architecture (Cisco DNA) makes it easy to segment your campus and branch networks. This blog is the second in a series focusing on aspects of intent-based networking, the first being on controller-led architecture.

Before digging into the solution, let’s understand why you may want to segment your network in the first place.

◉ Enhanced security: Isolate and filter network traffic to limit communications between users and devices

◉ Better access control: Allow users and devices to access only authorized resources

◉ Improved monitoring: Log events, monitor connection attempts, and detect suspicious behavior

◉ Faster containment: Minimize the scope of a network breach

Group-based access control

Recognizing that segmenting the network is a security must-have, we set about making it easy to do in Cisco DNA – the access network for campus and branch. Those of you who have experienced the Cisco DNA Center – the controller for a Cisco DNA based network – know that it provides a highly intuitive and easy to use graphical interface to manage the network and is the ideal platform to define segmentation. For those who haven’t, we encourage them to attend one of our monthly demo sessions where we explain what Cisco DNA can do for you.

Cisco DNA Center allows you to easily manage security policies through policy-based abstractions called scalable groups.  Scalable groups are used to represent connected users and devices based upon attributes, like role, function, location, etc. rather than IP addresses. These groups then form the basis of security policies, centrally managed on Cisco DNA Center and enforced across the network fabric.

Cisco DNA Center enables simplified management of access control between the different groups, and dynamically configures the access control policy in the fabric consisting of switches, routers, and wireless network devices that make up the fabric.

As people and things connect to the network using either a wired or wireless interface, Cisco DNA identifies them and automatically assigns them to their rightful group and places them in the appropriate segment. We call the creation of these Virtual Networks (VN), macro-segmenting.

The two levels of network segmentation

But what about the communications between members within a VN? We need to control that too for a deeper level of security. We call this micro-segmenting. So, while macro-segmenting isolates traffic between VNs, micro-segmenting controls communications between different groups or members of the same group within the VN.

For example, you might define two VNs – an ‘Employee’ VN with management, HR, security staff, and financial analysts, and an ‘IoT’ VN with security cameras, door locks, and digital signage. With SD-Access macro-segmentation you can ensure that a compromised camera will not let the attacker access HR resources. While with micro-segmentation, you can prevent lateral spread of malware between say HR and security staff or between two financial analysts.

Cisco DNA Center makes it easy to micro-segment the network. The Access Control Application within Cisco DNA Center works with Cisco Identity Services Engine (ISE) to let you define contracts. Contracts are statements that permit or deny specific types of interactions. For example, if you are concerned about malware attacks that spread using well-known TCP ports of 22, 80, and 443, you can simply create a contract that would disallow such communications between members of the same group.

Once you define the contracts, you use a simple matrix within Cisco DNA Center and activate them between source and destination groups. This matrix visually describes policies that the Cisco DNA Center consistently applies and enforces through the network fabric.

Segmentation that extends from access to apps

Just like Cisco DNA Center segments the access network and creates groups of users, Cisco ACI segments data center and cloud networks and creates groups of applications. Cisco’s multidomain architecture lets these networking domains exchange and map these groups. Now, thanks to this integrated segmentation, users can only run applications they are authorized for. For example, only accounting staff may access point-of-sale systems in keeping with PCI regulations.

Continue reading