Enterprise Networking in 2020: 5 Trends to Watch in Wireless, SD-WAN, More

Networking isn’t what it used to be. A few years ago, the epicenter of networking began to move. It shifted from company-owned datacenters, out to the cloud. For users, the focus of networking moved from computers connected with wires, to mobile devices connected over the air. These fundamental shifts, in where business processes run and how they’re accessed, is changing how we connect our locations together, how we think about security, the economics of networking, and what we ask of the people who take care of them.

So it is going to be an exciting year. Here’s how:

Wireless: It’s Wi-Fi, It’s 5G. It’s Both.

In 2020, Wi-Fi 6 will enter the enterprise, through the employee door and through enterprise access point refreshes. 5G will also appear, although in 2020, it will be mostly for consumers.

The latest smartphones from Apple, Samsung, and other manufacturers are Wi-Fi 6 enabled, and Wi-Fi 6 access points are currently shipping to businesses and consumers. 5G phones are not yet in wide circulation, although that will begin to change in 2020. We project that through 2020 more people will be using Wi-Fi 6 than 5G.

2020 will also see the beginning of a big improvement in how people use Wi-Fi networks. The growth of the OpenRoaming project will make joining participating Wi-Fi networks as easy as using a cell phone in a new town: Users won’t have to think about it.

While “5G” service will roll out in 2020 (some is already switched on today), almost none of it will be the ultra-high speed connectivity that we have been promised or that we will see in future years. With 5G unable to deliver on that promise initially, we will see a lot of high-speed wireless traffic offloaded to Wi-Fi networks.

2020 will also see the adoption of new frequency bands, including the beginning of the rollout of “millimeter wave” (24Ghz to 100Ghz) spectrum for ultra-fast, but short-range 5G; and of CBRS, at about 3.5Ghz, which may lead to the creation of new private networks that use LTE and 5G technology, especially for IoT applications. We will also see continued progress in opening up the 6 GHz range for unlicensed Wi-Fi usage in the United States and the rest of world.

Eventually, having even more pervasive, high-speed, secure wireless connectivity will open up new kinds of business opportunities in all industries, from healthcare to transportation. In combination with the improved performance of both Wi-Fi 6 and (eventually) 5G, we are in for a large – and long-lived – period of innovation in access networking.

The Network as Intelligent Sensor

Businesses have started to use their networks for more than data transmission. Now they’re being used to sense their environments as well. This is going to have big impacts on business – not just for network operators, but directly to the bottom line as well.

With software that is able to profile and classify the devices, end points, and applications (even when they are sending fully encrypted data), the network will be able to place the devices into virtual networks automatically, enable the correct rule set to protect those devices, and eventually identify security issues extremely quickly. Ultimately, systems will be able to remediate issues on their own, or at least file their own help desk tickets. This becomes increasingly important as networks grow increasingly complex.

Wireless networking equipment can also collect data on how people and things move through and use physical spaces – for example, IoT devices in a business; or medical devices in a hospital. That data can directly help facility owners optimize their physical spaces, for productivity, ease of navigation, or even to improve retail sales. These are capabilities that have been rolling out in 2019, but as business execs become aware of the power of this location data, the use of this technology will begin to snowball.

SD-WAN Plans Solidify in 2020

The workplace is becoming virtual, not physical. Businesses now hire talent wherever it is, and these dispersed employees are connecting to increasing numbers of cloud services. This dispersal of connectivity – the growth of multicloud networking – will force many businesses to re-tool their networks in favor of SD-WAN technology. IDC research shows that almost 95% of the enterprises they surveyed expect to be using SD-WAN within 24 months.

Meanwhile the large cloud service providers, like Amazon, Microsoft, and Google are connecting to networking companies (like Cisco), to forge deep partnership links between networking stacks and services.

When it comes to their own WAN solutions, each enterprise is different. Some enterprises, looking for security solutions that align with compliance regulations, need on-premise security. Smaller businesses often want their security solutions in the cloud. Many businesses will need hybrid solutions that combine elements of traditional on-premise control for compliance, with cloud-based solutions for flexibility and agility. Security, and workloads, have to be installed where they meet the needs of the business.

This is going to lead to a growth in business for managed service providers (MSPs), many more of which will begin to offer SD-WAN as a service. We expect MSPs to grow at about double the rate of the SD-WAN market itself, in line with IDC’s predictions. We also expect that MSPs will begin to hyper-specialize, by industry and network size.

Multidomain Needs Spur Controller-Based Integration

The intent based networking model that enterprises began adopting in 2019 is making network management more straightforward by absorbing the complexities of the network. However, networking systems are made up of multiple networks themselves (for example, campus networks and WANs), as well as domains of technology that are traditionally managed in their own domains (for example, security). For better management, agility, and especially for security, these multiple domains need to work together. Each domain’s controller needs to work in a coordinated manner to enable automation, analytics and security across the various domains.

Increasing network complexity fuels adoption of multidomain technologies.

The next generation of controller-first architectures for network fabrics allow the unified management of loosely-coupled systems using APIs and defined data structures for inter-device and inter-domain communication. With the way networks are changing, there is no other solution to keep ahead of system growth and complexity.

From Network Engineer to Network Programmer

The standard way that network operators work – provisioning network equipment using command-line interfaces like CLI – is nearing the end of the line. Today, intent-based networking lets us tell the network what we want it to do, and leave the individual device configuration to the larger system itself. We can also now program our updates, rollouts, and changes using centralized networking controllers, again not working directly with devices or their own unique interfaces. But new networks run by APIs require programming skills to manage. Code is the resource behind the creation of new business solutions.

If maximizing the value of these controllers means getting up to speed with programming them, there’s a big opportunity for the people who get ahead of this trend. But it will not be an easy change. Retraining yourself (or your team) is expensive, and not everyone will adapt to the new order. For those that do, the benefits are big. Network operators will be closer to the businesses they work for, able to better help businesses achieve their digital transformations. The speed and agility they gain thanks to having a programmable network, plus telemetry and analytics, opens up vast new opportunities.

It remains critical for individuals to validate their proficiency with new infrastructure and network engineering concepts. With training, network operators will be able to stay closer to the businesses they work for, providing value beyond maintenance and support. Networks in 2020 will become even more central to how businesses function. As always, CEOs will direct resources into infrastructure projects that directly generate revenue.       

2020 Will be Transformative

Together, new capabilities will make networks into even more important business assets, and companies will leverage them in ways that we have not imagined.

We just finished surveying over 2,000 network executives and operators on the future of networking.

Continue reading

Why Upgrade to MDS 9700

MDS 9500 family has supported customers for more than a decade helping them  through FC speed transitions from 1G, 2G, 4G, 8G and 8G advanced without forklift upgrades. But as we look in the future the MDS 9700 makes more sense for a lot of data center designs.  Top four reasons for customers to upgrade are

1. End of Support Milestones
2. Storage Consolidation
3. Improved Capabilities
4. Foundation for Future Growth

So lets look at each in some detail.

1. End of Support Milestones

MDS 4G parts are going End of Support on Feb 28th 2015. Impacted part numbers are DS-X9112, DS-X9124, DS-X9148. You can use the MDS 9500 Advance 8G Cards or MDS 9700 based design. Few advantages MDS 9700 offers over any other existing options are

a. Investment Protection – For any new Data Center design based on MDS 9700 will have much longer life than MDS 9500 product family. This will avoid EOL concerns or upgrades in near future. Thus any MDS 9700 based design will provide strong investment protection and will also ensure that the architecture is relevant for evolving data center needs for more than a decade.

b. EOL Planning – With MDS 9700 based design you control when you need to add any additional blades but with MDS 9500, you will have to either fill up the chassis within 6 months (End of life announcement to End of Sales) or leave the slots empty forever after End of Sale date.

c. Simplify Design – MDS 9700 will allow single skew, S/W version, consistent design across the whole fabric which will simplify the management. MDS 9700 massive performance allows for consolidation and thus reducing footprint and management burden.

d. Rich Feature Set – Finally as we will see later MDS provides host of features and capabilities above and beyond MDS 9500 and that enhancement list will continue to grow.

2. Storage Consolidation

MDS 9700 provides unprecedented consolidation compared to the existing solutions in the industry. As an example with MDS 9710 customers can use the 16G Line Rate ports to support massively virtualized workload and consolidate the server install base. Secondly with 9148S as Top of Rack switch and MDS 9700 at Core, you can design massively scalable networks supporting consistent latency and 16G throughput independent of the number of links and traffic profile and will allow customers to Scale Up or Scale Out much more easily than legacy based designs or any other architecture in the industry.

Moreover as shown in figure above for customers with MDS 9500 based designs MDS 9710 offers higher number of line rate ports in smaller footprint and much more economical way to design SANs. It also enables consolidation with higher performance as well as much higher availability.

3. Improved Capabilities

MDS 9700 design provides more enhanced capabilities above and beyond MDS 9500 and many more capabilities will be added in future. Some examples that are top of mind are detailed below

Availability: MDS 9700 based design improves the reliability due to enhancements on many fronts as well as simplifying the overall architecture and management.

◉ MDS 9710 introduced host of features to improve reliability like industry’s first N+1 Fabric redundancy, smaller failure domains and hardware based slow drain detection and recovery.

◉ Its well understood that reliability of any network comes from proper design, regular maintenance and support. It is imperative that Data Center is on the recommended releases and supported hardware. As an example data center outage where there are unsupported hardware or software version failure are exponentially more catastrophic as the time to fix those issues means new procurement and live insertion with no change management window. Cost of an outage in an Data Center is extremely high so it is important to keep the fabric upgraded and on the latest release with all supported components. Thus for new designs it makes sense that it is based on the latest MDS 9700 directors, as an example, rather than MDS 9513 Gen-2 line cards because they will fall of the support on Feb 28, 2015. Also a lot of times having different versions of the hardware and different software versions add complexity to the maintenance and upkeep and thus has a direct impact on the availability of the network as well as operational complexity.

Throughput:

With massive amounts of virtualization the user impact is much higher for any downtime or even performance degradation. Similarly with the data center consolidation and higher speeds available in the edge to core connectivity more and more host edge ports are connected through the same core switches and thus higher number of apps are dependent on consistent end to end performance to provide reliable user experience. MDS 9700 provides industries highest performance with 24Tbps switching capability. The Director class switch is based on Crossbar architecture with Central Arbitration and Virtual Output Queuing which ensures consistent line rate 16G throughput independent of the traffic profile with all 384 ports operating at 16G speeds and without using crutches like local switching (muck akin to emulating independent fixed fabric switches within a director), oversubscription (can cause intermittent performance issues) or bandwidth allocation.

Latency:

MDS Directors are store and forward switches this is needed as it makes sure that corrupted frames are not traversing everywhere in the network and end devices don’t waste precious CPU cycles dealing with corrupted traffic. This additional latency hit is OK as it protects end devices and preserves integrity of the whole fabric. Since all the ports are line rate and customers don’t have to use local switching. This again adds a small latency but results in flexible scalable design which is resilient and doesn’t breakdown in future. These 2 basic design requirements result in a latency number that is slightly higher but results in scalable design and guarantees predictable performance in any traffic profile and provides much higher fabric resiliency .

Consistent Latency: For MDS directors latency is same for the 16G flow to when there are 384 16G flows going through the system. Crossbar based switch design, Central arbitration and Virtual Output Queuing guarantees that. Having a variable latency which goes from few us to a high number is extremely dangerous. So first thing you need to make sure is that director could provide consistent and predictable latency.

End to End latency: Performance of any application or solution is dependent on end to end latency. Just focusing on SAN fabric alone is myopic as major portion of the latency is contributed by end devices. As an example spinning targets latency is of the order of ms. In this design few us is orders of magnitude less and hence not even observable. With SSD the latency is of the order of 100 to 200 us. Assuming 150 us the contribution of SAN fabric for edge core is still less than 10%. Majority (90%) of the latency is end devices and saving couple of us in SAN Fabric will hardly impact the overall application performance but the architectural advantage of CRC based error drops and scalable fabric design will make provided reliable operations and scalable design.

Scalability:

For larger Enterprises scalability has been a challenge due to massive amount of host virtualization. As more and more VMs are logging into the fabric the requirement from the fabric to support higher flogins, Zones. Domains is increasing. MDS 9700 has industries highest scalability numbers as its powered by supervisor that has 4 times the memory and compute capability of the predecessor. This translates to support for higher scalability and at the same time provides room for future growth.

4. Foundation for Future Growth:

MDS 9700 provides a strong foundation to meet the performance and scalability needs for the Data Center requirements but the massive switching capability and compute and memory will cover your needs for more than a decade.

◉ It will allow you to go to 32G FC speeds without forklift upgrade or changing Fabric Cards (rather you will need 3 more of the same Fabric card to get line rate throughput through all the 384 ports on MDS 9710 (and 192 on MDS 9706).

◉ MDS 9700 allow customers to deploy 10G FCoE solution today and upgrade without forklift upgrade again to 40G FCoE.

◉ MDS 9700 is again unique such that customers can mix and match FC and FCoE line cards any way they want without any limitations or constraints.

Most importantly customers don’t have to make FC vs FCoE decision. Whether you want to continue with FC and have plans for 32G FC or beyond or if you are looking to converge two networks into single network tomorrow or few years down the road MDS 9700 will provide consistent capabilities in both architectures.

In summary SAN Directors are critical element of any Data Center. Going back in time the basic reason for having a separate SAN was to provide unprecedented performance, reliability and high availability. Data Center design architecture has to keep up with the requirements of new generation of application, virtualization of even the highest performance apps like databases, new design requirements introduced by solutions like VDI, ever increasing Solid State drive usage, and device proliferation. At the same time when networks are getting increasingly complex the basic necessity is to simplify the configuration, provisioning, resource management and upkeep. These are exact design paradigms that MDS 9700 is designed to solve more elegantly than any existing solution.

Continue reading

Stealthwatch Enterprise and Cisco Threat Response: Bringing machine-scale analysis to human-scale understanding

From zero-day malware to cryptojacking, from man-in-the-middle attacks to spear phishing, from ransomware to distributed denial of service attacks (DDoS) attempts – businesses of all sizes and industries are the constant target of these attacks. It’s perfectly normal to find this barrage of threats overwhelming – and then there’s constant pivot between multiple security solutions required to detect, investigate and remediate.

Now imagine a world where disparate solutions do not exist. A world where there is no need to manually correlate information from various sources to build a complete picture of each potential threat. Where two clicks are all it takes to get situational awareness of the threat impact and potential scope of compromise, and the context needed to formulate an adequate response strategy.

Two clicks and done, you say?

What if you could get insights into everything going on across the network, and you could quickly baseline your environment’s normal behavior, no matter what your organization’s size or type? And what if this knowledge could also be correlated with alerts across your endpoints, firewall, web, etc. to make it easier to identify something suspicious and kick it off your network? With Cisco Threat Response, you can now convert this vision into reality. It is a key pillar of Cisco’s integrated security platform and is designed to give you the contextual awareness you need so you can see, investigate, and act on threats fast. Our obsession with connecting the dots within your network has already made Threat Response the Incident Response workbench of choice for SOCs across the world.

Get Answers, Not Alerts

An investigation can involve dozens or even hundreds of discrete data elements, multiple sources of threat intelligence and an armor of security products providing telemetry. Before Cisco Threat Response, each observable had to be investigated against each threat intel source and each network and security products individually and manually, which takes even seasoned experts a long time to do. With Threat Response, they can either simply paste all of those observables into Cisco Threat Response and it does the work for them. It brings all of that knowledge back from intel sources and security products, displaying results in seconds. From there, SOC teams can take action immediately or continue their investigation with the tools provided.

Cross-platform visibility and response powered by analytics

We all know that security analytics has become something of a buzzword, but it continues to gain positive momentum and sustain relevance. Cisco’s network security analytics solution, Cisco Stealthwatch Enterprise integration with Threat Response brings the power of each to the other.

How does this work?

Stealthwatch provides agentless enterprise-wide visibility, across on-premises, as well as in all public cloud environments. Using the power of behavioral modeling, multilayered machine learning, and global threat intelligence, Stealthwatch Enterprise produces alarms on critical threats by monitoring both north-south and east-west traffic. Stealthwatch sends those alarms directly to Cisco Threat Response’s Incident Manager feature, allowing users to see those alarms alongside prioritized security alerts from other products such as Firepower devices. This communication is handled via a secure intermediary cloud service called Cisco Security Service Exchange (SSE). No internal data is bulk uploaded to the cloud; sightings and the associated metadata are sent only in response to specific queries. In this way, investigations on all IP addresses are enriched with Stealthwatch insight, regardless of the catalyst for the investigation, all delivered in seconds and in an easy to read graphical format that helps you both intuitively understand what happened and respond quickly and effectively across your entire portfolio. These incidents can then be investigated with additional context from your other threat response-enabled technologies, all in one console, with one click. This lowers the time required to perform triage and response to these alarms.

Figure1- Ability to pivot and drill-down into the Stealthwatch Management Console or choose to investigate a directly in Threat Response

Figure 2-Enrichment of Stealthwatch alarms with context from other security technologies. Block suspicious files, domains, and more–without having to log in to another product first.

The Stealthwatch -Threat Response integration bring together a number of unique differentiators for the SOC workflow. Our Cisco Security customers are able to:

◉ Streamline Investigation Workflow

◉ Enhance Collaboration with Case Book

The  casebook browser plug in allows a Stealthwatch users to leverage all the power of their configured threat response modules, right from the Stealthwatch interface via built-in pivot menus. For example, you can use it to pull IP addresses or domains from Stealthwatch interface where there’s an observable and the casebook feature of Threat response will allow you to kick off an investigation directly from your browser.

◉ Accelerate Response with Incident Reporting to Threat Response

Stealthwatch automatically shares critical and major Alarms with Cisco Threat Response as Incidents which are then further enriched. You are able to tie independent product data and events together to uncover threats by investigating multiple observables across multiple data sets and products. The integration gives you the power to investigate with automated enrichment and respond with confidence directly from the Threat Response interface using products such as AMP for endpoint and Umbrella.

◉ Access the Power of Analytics ( for existing Threat Response users)

With the integration, Threat Response users can now investigate entity security events sent over from Stealthwatch in cases where the potential host can be the source or target of an event. This provides granular visibility on internal network activity for suspected hosts under investigation.

Simplify to Amplify

Threat Response is designed to get you more from your Cisco Security investments by automating integrations directly out of the box. It’s also designed to dramatically cut the time and effort needed to detect, investigate, and remediate – making your SOC operations more efficient and effective.

More than 6,700 customers today are reducing the time it takes to both investigate and respond to threats across multiple security technologies with Cisco Threat Response. And it’s included as part of the Cisco Security product licenses and take under 10 minutes to get up and running in your SOC. There’s nothing more to buy.

Overwhelmed to Empowered

At every RSA conference, 600 security vendors vie for the CISO’s mindshare with no shortage of vendors offering point solutions that offer miracles for your SOC.The reality is that most organizations already have an abundance of point products designed to address specific challenges, but most of these products can’t be easily integrated to fulfill a larger and more effective security strategy. Isn’t it time for the security industry to do better? At Cisco, we think it is. We’re building a platform that redefines security powered by integrations. At the heart of our platform approach is a simple idea: security solutions should be designed to act as a team. We invite you to come with us on this journey that simplifies your experience and reduces complexity, paves the path for an integrated and open platform that strengthens operations, stays out of the way, and gives your team time back.

Continue reading

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