Delivering 1 Gbps over DSL with Cisco’s ISR 1000

I still remember the day I first got ADSL at home in 2000. The top speed was only 2 Mbps, but I was purely fascinated by everything I could do at home, especially playing video games. Not before long, ADSL was replaced with VDSL, which changed my use of the internet from playing games to downloading video and music files in bulk, thanks to Napster and Torrent.

Putting memories aside, the general landscape of the internet has completely changed over the last decade. No longer are the days of one desktop serving an entire family, instead each family member has at least one smartphone and possibly a laptop which are used constantly for streaming videos, music and more. Businesses have an immense scale of data to process and share over the internet. What this means is that bandwidth is the key to keeping families happy and businesses running.

DSL innovation has been relentless when it comes to meeting the growing demand for higher bandwidth in the market. The latest form of DSL that has been introduced is G.fast, which is expanding aggressively in the UK and Switzerland. G.fast is a DSL technology that has stretched its frequency spectrum up to 106 MHz with the additional capability to increase up to 212 MHz. Compared to the common VDSL2 deployment with 17 MHz, G.fast at 106MHz is capable of offering throughput up to 1 Gbps. In addition to its high bandwidth, G.fast is a more affordable option compared to fiber, since it is deployed over copper wires.

Today’s internet landscape has also played a major role in propelling local governments and service providers to work hand-in-hand to provide faster internet services to the general public. For example, the EU has launched an initiative to support access to internet connections with 1 Gbps by 2025 for all schools, transport hubs and main providers of public services, as well as digitally intensive enterprises. In order to support this initiative, it is no surprise that G.fast is highly favored by many service providers in Europe. British Telecom and Swisscom are at the forefront in leading their services with G.fast.

G.fast in Detail

G.fast is a DSL technology, but it sets itself apart in a few aspects from its predecessors, such as VDSL. First, the frequency spectrum used in G.fast is far wider compared to most profiles in VDSL2. The latest VDSL2 profile, deployed in Italy and Germany, is only at 35MHz, offering a throughput of 300 Mbps. Early G.fast deployments used a frequency spectrum of 22-106MHz to avoid interference from the range used by VDSL, which resulted in approximately 100 Mbps less throughput compared to using the full spectrum from 2 MHz. To increase the throughput on G.fast, the current frequency spectrum is being evaluated for an extension down to 2 MHz and up to 212 MHz. Particularly, 212MHz promises a peak aggregate throughput of 2 Gbps, which will enable 1Gbps for both downstream and upstream.

Another technical difference that makes G.fast unique is Time Domain Duplex (TDD). ADSL and VDSL have traditionally used Frequency Domain Duplex (FDD), where downstream and upstream had one frequency band for each to communicate. Since the frequency band for each direction of traffic was fixed, it was difficult to dynamically adjust the throughput per direction depending on need.

TDD enables both downstream and upstream to use the same frequency band, which allows G.fast to make throughput adjustments flexibly for both directions. The benefit of using TDD for G.fast is huge for service providers who have more flexibility to design different classes of service offerings on the same link.

G.fast Deployment

DSL, by design, is vulnerable to attenuation occurring on copper wires, which means that throughput varies depending on the distance from the CPE to DSLAM. G.fast is no exception to attenuation. Though it is able to reach 1Gbps in theory, in a very short loop length, it is impossible to maintain such short loop length in an actual deployment. Different studies would show different throughput results over distance, but the throughput range between the distance of 200 to 400 meters falls between 500 Mbps to 200 Mbps. For this reason, current G.fast deployments in the UK and Switzerland are designed for the distance between 200 – 300 meters with a target throughput between 200 Mbps to 500 Mbps. With the introduction of 212 MHz in the future, the serviceable areas with G.fast will be extended with higher levels of throughput.

Cisco’s Solution

Cisco never shied away from accommodating new changes in the market and meeting the most challenging demands from the customers. Cisco’s flagship product family, the Integrated Services Router Series, has evolved ever since its inception to stay competitive and relevant in the market by adding new routers with the latest innovations.

Cisco introduced the ISR 1000 Series routers in late 2017. It was the latest addition to the Integrated Services Routers family. The routers perform at an unmatched level to meet today’s growing demand for high throughput while offering a diverse set of WAN connectivity options including LTE Advanced, VDSL, Ethernet and Fiber.

In July 2018, G.fast was added to the list of supported WAN options on the 8 LAN port ISR 1000 Series routers with the creation of new models: C1112 and C1113. G.fast on the C1112 and C1113 will be supported over both POTS and ISDN to serve a wider list of countries. In addition to G.fast, both models will support ADSL and VDSL, including Profile 35b, to provide customers with flexible DSL deployment options. As early as November 2018, C1112 and C1113 will also be integrated with Cisco SD-WAN.

C1112 and C1113 are the only enterprise-grade routers in the market to provide secure and reliable connection with the ability to provide the high bandwidth required by today’s G.fast deployments. Both routers will not only enable customers to expand their service offerings with G.fast, but help them to protect their investment in the existing infrastructure.

Continue reading

Shining a Light on Shadow IT

But there is another ecosystem of applications and hardware besides IoT devices to manage in the realm of Shadow IT. From the old days of departments buying OTS packaged software for special projects, to today’s BYOD to work, organizations struggle with un-vetted and unauthorized information technology accessing sensitive personal and business data. IT SecOps deploys a wide range of security processes to gain some control over these proliferating endpoints in enterprise networks—often with limited success. The proof of that, unfortunately, is in the growing number of successful malware infections and data breaches that use these unregulated endpoints as gateways to the network crown jewels.

Cisco recognizes that security is foundational to the network itself. When you apply identity and security policies consistently throughout the network fabric, Shadow IT devices and applications become part of the managed ecosystem, and not outliers operating under their own security parameters. So when the Finance department, for example, decides to purchase and use only iPad tablets to access SaaS financial applications, only iPads tagged as part of the “Finance” network have access to the apps. Meanwhile, HR’s Surface tablets are assigned policies to send and receive data from SaaS HR apps, not financial data. These policies enforce network intentions.

Policies are codified network intentions that manage and automatically configure access privileges for devices and their associated applications. By assigning policies at the device level, or groups of devices, the network automatically adapts to changes, such as location, ownership, and signs of infection. Let’s look at how intent-based networking simplifies the management of Shadow IT devices and applications—and everything else.

Detecting and Identifying Shadow IT Devices 

Control of Shadow IT begins with locating and identifying devices and applications as they connect to the network. Cisco Identity Services Engine (ISE) scans the network, cataloging in DNA Center all devices or services operating on the wireless and wired network segments. ISE automatically tags rogue devices with policies that limit their access and connectivity until their legitimacy is verified and appropriate security policies applied. In essence, ISE prevents Shadow IT from accessing sensitive data sources without the knowledge of IT.

Providing Persistent Security with Software-Defined Segmentation

After shadow IT devices are identified and tagged by the ISE and cataloged in DNA Center, the concept of micro-segmentation comes into play with Cisco SD-Access. The goal is to apply policies to devices that follow them around the network—campus, wireless, WAN, mobile—virtually segmenting them according to the defined network intentions. The security for any device is therefore persistent, no matter where the device may roam.

For example, the tablets purchased by the finance department can join the network anywhere in a wireless campus environment, yet are constrained to specific data sources to which they can connect. The policies attached to tablets in a virtual segment can also maintain a higher quality of service with priority for traffic to the SaaS financial applications, versus a lower level of service for streaming video from the internet. Devices that have internet exposure are monitored for malware, with policies that automatically isolate an infected device from the rest of the network. This capability is especially critical with Shadow IT devices which may not have up-to-date security patches.

Cisco provides several technologies to manage virtual software-defined segmentation, all working under the umbrella of DNA Center. Tagging individual or groups of devices to create software-defined segments with security policies is automated with Cisco Trustsec, which works in conjunction with ISE. A department’s Shadow IT devices can be tagged as one group and security policies applied consistently no matter where the device connects to the network. Security tagging plays a critical role in compliance too, by ensuring, for example, that payment card data touches only specific groups of devices. Cisco Stealthwatch is a third component working with ISE and Trustsec that is critical to managing Shadow IT. Once devices are cordoned into software-defined segments, Stealthwatch monitors their health to detect any infections such as zero-day malware or ransomware and quarantines the offending devices and connections.

Managing Shadow IT in the Multi-Cloud

The growing use of public and hybrid clouds are another reason to better manage Shadow IT. Recent IT surveys show that the average organization uses over 1,427 different cloud services. When a department decides to use a file-sharing platform, subscribe to a SaaS CRM application, or run apps on AWS, they are doing so to improve efficiency and ease of use. Doing so, of course, opens up connections between sensitive enterprise data and third-party clouds, the security of which are beyond SecOp’s immediate control. With the capability to apply security and access policies, an intent-based network plays a critical role in controlling data inside and outside the enterprise.

For enterprises that have multi-cloud projects—whether officially condoned or emerging from the shadows—the Cisco DNA Center open cloud management platform provides granular control of how devices connect to cloud resources and defines how data flows among data center, public and private clouds, and SaaS platforms. Assigning traffic segmentation policies for public and private clouds creates end-to-end segregation with device and application-aware topologies that select the best paths to achieve desired SLAs and optimum application experience for both sanctioned and shadow technology.

Take Back Control by Integrating Shadow IT into the Network Ecosystem

Shadow IT projects will continue to take root and proliferate throughout enterprise networks. With the ubiquitous availability of cloud apps, mobile devices, and freemium services, employees will find ways to make their work life more efficient, easier, and indeed fun. Instead of fighting rogue devices and applications, IT can exert control over shadow IT by integrating the devices and services into the network ecosystem. With intent-based networking, IT can automate the application of policies to keep data secure while expanding the choices of devices and applications that employees and departments can use.

Continue reading

Why download the exploit, when you can carry it with you?

For the 2nd year, RSA Conference 2018 APJ created an educational exhibit, sponsored by RSA and Cisco, to monitor the RSA Conference public Wi-Fi network provided by the Marina Bay Sands (MBS). This exhibit was created in the form of the RSA Conference Security Operations Center (SOC). RSA and Cisco provided technology and staffing to monitor the network for threats, but also to educate attendees on the risks of free Wi-Fi.

What is the difference between a SOC and a NOC?

Network Operations Center

The NOC is usually responsible for monitoring and maintaining the overall network infrastructure—its primary function is to ensure uninterrupted network service

Security Operations Center

The SOC is responsible for protecting networks, as well as web sites, applications, databases, servers and data centers and other technologies

RSA and Cisco provided the SOC. The NOC was provided by the MBS.

The mission of the RSAC SOC was to ensure the conference Wi-Fi is not attacked (denial of service, laterally spreading malware, etc.). We did not block malicious DNS traffic, downloads or attachments; as this was a learning and demonstration environment. We make sure that network is protected from attackers. We locate (when we can) and advise users when they are at risk.

What technology is in the RSAC SOC?

MBS provided the RSAC SOC a span of all network traffic from the .RSAConference network, which was passed through the Cisco Next Generation Firewall / ISP and then split the traffic to NetWitness Packets NetWitness Packets and the Cisco Stealthwatch teams.

RSA used NetWitness Packets to collect and investigate all traffic on the Wi-Fi network, from the firewall; to detect deviations from normal behavior and create a probability-weighted risk score for alerts based on these results. NetWitness inspects every network packet session for threat indicators at time of collection and enriches this data with threat intelligence and business context. At the end of the conference, all of this data was wiped from NetWitness.

For suspicious files that might be malicious, NetWitness Packets checks a community AV lookup, some static analysis and its own network intelligence. Then the NetWitness Orchestrator sends the files to Cisco Threat Grid for dynamic malware analysis.

Threat Grid combines advanced sandboxing with threat intelligence into one unified solution to protect organizations from malware. Threat Grid analyzes the behavior of a file against millions of samples and billions of malware artifacts. The SOC team had a global and historical view of the malware, what it’s doing and how large a threat it posed to the RSAC network.

Threat Grid identifies key behavioral indicators of malware and their associated campaigns. The SOC team was able to save time by quickly prioritizing attacks with the biggest potential impact. We used tools like Glovebox, to safely interact with samples and observe malware behavior directly. In addition, we used Cisco Umbrella to have visibility in all DNS activity. We also used the Threat Intelligence of Cisco Visibility and Talos Intelligence.

When the Cisco team found a potential threat, they handed it off to the RSA team for further investigation. In summary, the technology stack was:

◈ Firewall – Cisco Next Generation Firewall with IPS
◈ Full Packet Capture and Investigation – RSA NetWitness Packets
◈ Orchestration – RSA NetWitness Orchestrator, powered by Demisto
◈ Dynamic File Analysis – Cisco Threat Grid
◈ DNS / IP Intelligence – Cisco Umbrella / Cisco Umbrella Investigate
◈ Encrypted Traffic Analytics – Cisco Stealthwatch and Cognitive Threat Analytics
◈ Threat Intelligence – Cisco Visibility

Identifying endpoint vulnerabilities without an agent

Cisco’s Next Generation Firewall was set up as the perimeter Firewall for the wireless connection of the RSA APJ event. All traffic to and from wireless guests went through the Firepower Threat Defense (FTD). FTD not only detected threats, but also discovered what was running on the network endpoints; such as Operating Systems, Ports, Applications and Files.

Discovered Applications

Discovered Files

Geolocation Information

During the conference, several threats were detected, and we were able to see the total Connections and Bytes connecting to known bad IP Addresses.

We were also able to see the Total Intrusion Events detected per Classification.

FTD automatically correlated threat events with the contextual information discovered to identify which IPS events to prioritize for further investigation. This was reflected via Impact Flag 1 events. Data showed that there were 31 events to be prioritized.

Impact Flag 1 events shown below.

Checking the Rule documentation of the BMP overflow IPS event, it shows that it is applicable only for traffic coming from external network to internal network.

And, applicable if the target host has this vulnerability, with cve.mitre.org documentation included.

Checking on the event we confirmed that the event is coming from the Internet going inside the network. IPS Event Details below.

Checking on the host profile, we confirmed the target host had this specific vulnerability.

Vulnerability list of the target host based on the discovered Operating System and Applications.

Why download the exploit, when you can carry it with you?

On the 2nd day of the Conference, the SOC team observed a .DOC file sent to a conference attendee in a plain text email, along with several PDFs. The .DOC file was extracted by NetWitness and had a score of 0 from the RSA Malware Analysis Community lookup, meaning it had never been detected by an AV vendor. The Static Analysis score was 80, making it worth a review, and the Dynamic Analysis/Sandbox score from Threat Grid was 100, meaning confirmed malicious based on behavior. The team went into action to assess the threat.

The .DOC file was assigned a Threat Score of 100 for the Behaviors of launching Powershell and creating an Executable File.

We were able to see the code in the document to create and launch the eng.exe file.

After the creation of the executable, the malware dropped some artifacts on disk that are known to be used by remote access Trojans and opened communication with a domain on the Umbrella block list for Malicious.

We pivoted to Umbrella Investigate to learn more. If we had AMP for Endpoints deployed on the endpoints in the network, we would have instantly been able to see affected endpoints and remediate.

In Umbrella Investigate, we learned more about the domain, including the global requests for the campaign.

Most affected computers from the United States.

We found the hosted IP address 5[.]79[.]72[.]163 (link to the Investigate report) and then went into Cisco Visibility to access the global Cisco threat intelligence and to see if there were more associated IPs.

With this intelligence, we were able to go to the Firewall and NetWitness teams and check if there was any outbound communication to those three IP addresses. There were none, indicated the person who received the email did not open it on a vulnerable endpoint at the conference.

Everything an attacker needs for spear phishing lures

Threat Grid currently supports the following file types for analysis:

For RSAC SOC, the NetWitness team focused on submitting the following file types, with the distribution in parenthesis:

◈ .PDF (93%)

◈ .EXE (4%)

◈ .DLL (2%)

◈ .DOC/X (<1%)

◈ .XLS/X (<1%)

We saw many invoices, billing statements and confidential business proposals as attachments to emails sent with unsecure protocols, such as POP3 and HTTP. Each could be used by an attacker, sniffing the public network; to craft a custom spear phishing lure, as they had legitimate business and financial information; such as the email addresses of the sender/receiver, account information, billing address and the types of products/services the email recipient expected to receive.

Cryptomining

At Black Hat Asia 2018 in March, we saw a massive increase in cryptocurrency mining. Also, with the Black Hat training courses, there were 20 times as many domains of concern for roughly the same amount of DNS requests, around 5 million for each of the conferences in Singapore.

There was much less Cryptomining at RSAC; however, several common sites were active:

◈ widgetsbitcoin[.]com (links to the Umbrella Investigate report)

◈ api.hitbtc[.]com

◈ ws022.coinhive[.]com

◈ coinhive[.]com

◈ cdn.mngepvra[.]com

◈ authedmine[.]com

◈ coin-hive[.]com

◈ coinone.co[.]kr

When we saw the cryptocurrency mining activity based on Umbrella DNS request, Stealthwatch provided the visibility into endpoint without an agent/connector. Below is the dashboard of Cognitive Cloud Analytics (CTA). Together with Cisco Stealthwatch Enterprise, CTA is part of Cisco Encrypted Traffic Analytics. This solution can detect malware hiding in encrypted traffic without decrypting the data.

Upon investigate into “High Risk” and “Confirmed” event. There were three endpoints identified to have cryptocurrency mining activity at the time of investigation.

Below is the snapshot of the endpoint activities related to cryptocurrency mining.

Together with Umbrella, we could identify endpoint with initial cryptocurrency mining DNS request and detail HTTPS request to the server with Stealthwatch Enterprise and CTA.

Continue reading

Open vRAN Update: NETCONF/YANG Comes to 5G RAN!

One of the key principles of the Open vRAN ecosystem that Cisco and its ecosystem partners announced earlier this year, is to establish open, standard interfaces and management for vRAN. Recently the xRAN Forum has defined the use of IETF’s NETCONF/YANG standard for programmatically configuring and managing its lower layer split RAN architecture.

We are proud to have taken a lead role, working closely with top tier operators and other vendors (including ecosystem partner Mavenir), in helping the xRAN Forum define the use of NETCONF/YANG by the 5G Radio Unit. We are excited about this for many reasons. Not only will the use of native YANG models ensure the easiest route to full multi-vendor interoperability in the future disaggregated RAN, but it should also ease the integration of the management for the lower layer split deployment into existing systems.

Let’s break down what this means. YANG (RFC 7950) is a modelling language that is used by xRAN to model the configuration and operational state of its 5G Radio Unit, together with defining remote procedure calls (RPCs) for supporting tasks like software management, and notifications for indicating xRAN defined alarms. Because YANG defines syntax, relationships and constraints between the data, it enables operators of xRAN’s lower layer split to validate configuration data against the model before committing the configuration of the xRAN Radio Units.

The use of augmented IETF standard YANG models, together with xRAN specific models, lays the foundation for cross-domain orchestration of the RAN with other domains that have already adopted NETCONF/YANG. Recognizing that xRAN Radio Unit suppliers need to be able to support vendor differentiation, the YANG models are extensible, allowing them to be augmented to support enhanced vendor-specific functionality, while simultaneously ensuring baseline multi-vendor interoperability of the standardized functionality defined by xRAN.

With the results of xRAN’s work now public, all Open vRAN Ecosystem members have endorsed these early deliverables as an important first step towards the evolution of a truly open and virtualised RAN.

Continue reading

5 Reasons Cloud UC and BroadSoft Are Top of Mind

There, my Cisco colleague Andy Johnston and I shared an overview of the cloud unified communications market to a standing-room‑only audience. We described how the combined strength of the Cisco and BroadSoft calling portfolios are helping you accelerate transitioning to cloud.

I’d like to highlight five key reasons why I think our overview resonated so well.

1. Customer cloud UC perceptions have changed

We recently conducted a survey with over 1,000 IT decision makers from seven countries. In it, we learned that cloud UC is a key priority of their digital transformation strategies. 74% of respondents said they will choose a cloud provider in the next 24 months.

2. SMBs need native mobile

Mobile working has many benefits. Many small businesses are ditching their on-premises solution and going mobile first for both cost and efficiency reasons. One of our portfolio’s most unique and innovative differentiators is our ability to deeply integrate communications within the core mobile network. This allows our mobile carrier partners like Verizon, Vodafone, Telstra, Deutsche Telekom, and Rogers to deliver a fixed-mobile converged experience that helps SMBs become more agile and productive, and appear bigger and stronger.

3. Mid-market needs enterprise-grade features without cost and complexity

Mid-market organizations need enterprise-grade features and a way to seamlessly and reliably network their PBX and cloud applications. This includes:

◈ a common network dialing plan

◈ a consistent collaboration experience across locations

◈ centralized and local administration capabilities

In addition, they need simplicity, on-demand scalability, global scale, and reliable communications for remote and mobile employees.

4. Flexible and smooth transition to cloud

Transitioning to the cloud will take some time for mid-sized and large enterprises that have large investments they simply cannot replace overnight. A 2017 study by global research firm Nemertes suggests that more than 70% of enterprises are still running TDM to at least half of their endpoints. You need solutions that both maximize the life of in-place investments and allow you to network with cloud solutions via SIP trunking for new locations, expansions, branch offices, contact centers, and mobile workers.

5. Cloud UC offers a better total cost of ownership

Cloud is a natural and more economical solution for new sites, site expansions, and smaller branch offices. In our survey:

◈ 68% of respondents believe their current on-premises systems are too expensive to maintain

◈ 70% believe cloud will reduce their IT staff efforts

◈ 69% say their current systems don’t have the advanced features they need

For many, cloud contact centers will offer more capabilities, on-demand flexibility, and superior multisite and remote-agent support. In fact, 88% of premises-based contact center users are considering moving to CCaaS, with 68% in active evaluation.

The Transition Zone

For all these reasons, we’ve developed a thoughtful technology plan that provides a smooth network transition from on-prem to cloud. A hybrid model that ensures user adoption helps you realize value more quickly and move at a pace that makes sense for your organization.

Flexible and affordable migration strategies with hybrid configuration support allow you to implement a cap-and-grow strategy. You maintain your in-place investments until they reach the end of their natural life-cycle, then transition to cloud when the time is right.

The Cisco Collaboration Flex Plan decouples the purchasing and deployment so that you can choose on-premises, hosted, or cloud options. You can move your organization, specific users, specific sites, or individual applications when it suits you in a flexible, phased approach that addresses all your needs.

This level of flexibility is available today. As you look to make your cloud transition, consider a vendor that can provide a complete solution that looks not only at your PBX requirements, but addresses your mobility and voice conferencing needs as well.

Cisco and BroadSoft are in a prime position to help you make the transition and migrate while leveraging your existing investments.

Continue reading

Top 7 Multicloud Initiatives – Delivering on the Multicloud Promise

According to IDC, by 2021, enterprises’ spending on cloud services and cloud-enabling hardware, software, and services will more than double to over $530 billion, leveraging a diversifying cloud environment that is 20% at the edge, more than 15% specialized (non-x86) compute, and more than 90% Multicloud. A high majority of enterprise IT organizations out there want to adopt multicloud now. It is thrilling to see enterprises around the world undertaking the key initiatives necessary to transform and stay ahead of the game in a multicloud era. Let’s examine what it takes to deliver the promise behind these initiatives.

Multicloud Journey – Before the “How”, Consider the “Why” and “What”

Embracing a multicloud world is important to increasing the pace of innovation for every company today. But it can be daunting to even large IT organizations to embark upon the multicloud journey due to seemingly never-ending complexity, fragmented solutions that got implemented over time, and no consistency or data control. IDC found that about 89% of enterprises today do not have an actionable and optimized plan for cloud. Faced with CIO directives and urgent timelines, IT teams today are under extreme pressure to claim progress in adopting multicloud. Before getting into the “how” or even a POC, enterprise IT oranizations should consider the “why” and the “what” for their selected initiatives.

The “why” is about aligning the selected initiatives to needed business outcomes. For example, is IT management looking for cost reduction, agility, much-needed application technology enhancements, or on-demand and efficient scaling of IT, a competitive differentiator, or expanding the business?

The “what” is about capturing your multicloud requirements, prioritizing them, identifying dependencies, and scoping what you want to accomplish and by when. This involves coming up with distinct but connected initiatives that can be phased or accomplished in a complementary fashion.

Cisco’s multicloud approach and Multicloud Portfolio helps enterprise IT teams that are trying to take on a multicloud journey to determine the “why” and “what” and produce definitive multicloud requirements and an actionable plan.

Here are key multicloud initiatives that enterprises around the world are considering. All these initiatives may not apply to every enterprise, and, in general, an enterprise may require additional initiatives based on their cloud adoption maturity and specific application needs.

1. Connect DC/Campus, CoLo, and Cloud

When enterprise IT organizations decide to a public cloud as part of their IT technology mix, this initiative becomes important. It involves connecting data centers or campuses directly to the cloud or via a colocation option. Secure connectivity to a public cloud includes considering having a CoLo in between DCs and the cloud for various reasons like backup, data sovereignty, and a high-speed connection to cloud infrastructure on the backend.

2. Connect Branches Direct-to-Cloud

When enterprise IT organizations with branches decide to have significant numbers of applications migrate to a public cloud or subscribe to SaaS offers, the branch’s connectivity direct to the cloud becomes important in delivering the best application user experience. Also, with the increased needs of edge computing and local analytics, it is paramount to have better and direct connectivity to the cloud applications from the edge. It essentially involves connecting branches directly to the public cloud application environments (including SaaS applications) using SD-WAN solutions with the high-speed Internet service providers locally available to each branch, as well as DNS security.

3. Build and Manage a Hybrid Cloud

Modernization has been a key driver for IT organizations, with various projects supporting it, including the adoption of a public cloud in the IT mix and transforming the consumption of IT on-premises into a cloud-like experience. According to a recent IDC survey, 87% of enterprises that are using the cloud are taking steps towards creating and managing a hybrid cloud. A hybrid cloud is essentially an application infrastructure configuration that has both an on-premises private cloud and a public cloud for deploying applications in a hybrid model. An example is when the data tier is running on-premises with the web and app tier running on the public cloud.

4. Migrate and Manage Applications to Public Cloud

This is the most common initiative that enterprise IT management is asking their IT engineering and LOB engineering teams to tackle, and it has the potential to be the riskiest journey that IT can take. Many enterprises migrated applications to a public cloud and then brought them back on-premises due to various reasons they did not anticipate. This initiative requires careful selection with dependency analysis, meticulous planning, and end-to-end management of the applications to be migrated to a public cloud.

5. Manage Cloud-Native Applications in Public Clouds

With the onset of mature container technology and proliferation of cloud services, enterprise IT organizations and LOBs are driving the creation of new cloud-native applications or re-platforming existing applications to not only run the application better with scale at every microservice that is part of the application but to leverage cloud-native services that the application can use, such as auto-scaling of underlying Kubernetes on-prem as well as on the public cloud, serverless and cloud-agnostic application environments, and much more. Traditionally such capabilities required multiple management tools, but now auto-scaling is an attractive way to run the applications. This initiative requires bringing together networking, security, analytics and management for the cloud-native apps to span both on-premises and public cloud.

6. Burst Applications Into Public Cloud

Enterprise IT organizations are familiar with this strategy of extending on-premise capacity (aka bursting) for certain applications from the data center or private cloud to a public cloud infrastructure on-demand for application runtime needs. A good example of this can be found with retailers that have on premise ecommerce processing applications, but due to seasonal demands, that application footprint and sale is not enough to manage the ecommerce demand. This initiative also is becoming common among the emerging artificial intelligence (AI) applications that burst into the designated public cloud compute infrastructure, especially for analyzing the “hot” data at the edge along and expanding compute-crunching needs.

7. Optimize SaaS Application Connectivity and Security

Along with public cloud infrastructure adoption, software-as-a-service (SaaS) offers the enterprise a tremendous opportunity to realize an application’s business benefits by “renting” the application use vs. stretching to handle the management responsibilities of running it, updating it, etc. themselves.

Over the last 5+ years, SaaS delivery models for applications have demonstrated their ease of use, breadth, and affordability of packaged applications in a fraction of the time and for a fraction of the cost of traditional models. But SaaS also changes the role of IT. Enterprise IT organizations can no longer guarantee that SaaS providers will meet IT’s compliance standards or use any leverage to negotiate better terms and conditions. Also, IT can do little to ensure the performance of SaaS offers from various enterprise offices, which rely on local Internet service providers – and the unpredictable internet access networks—who can impact the consistency of SaaS delivery, even in regions with highly developed Internet infrastructure. This initiative uses SD-WAN capability to optimize the network path and keep it optimized.

Below is an example of how Cisco’s multicloud approach addresses the “how” in order to deliver on the promise of multicloud when it comes to an organization’s initiative to migrate applications to a public cloud.

By offering a simplified approach to answering “how,” our multicloud approach helps organizations understand the capabilities needed for their chosen initiatives in order to easily and confidently select the foundational products needed for the design and implementation stages of their multicloud initiatives.

Continue reading

Render your first network configuration template using Python and Jinja2

We all know how painful it is to enter the same text in to the CLI, to program the same network VLANs, over, and over, and over and over, and over…. We also know a better way that exists, with network programmability, but this solution could be a few years out before your company adopts the newest network programmability standards.  What are you to do???

Using Python and Jinja2 to automate network configuration templates is a really useful way to simplify repetitive network tasks, that as engineers, we often face on a daily basis. In using this alternative method to automate our tasks we can remove the common error mistakes experienced in the copying/pasting of commands into the CLI (command line interface). If you are new to network automation, this is a fantastic way to get started with network programmability.

Firstly, let’s cover the basic concepts we will run over here.

◈ What are CLI Templates? CLI templates are a set of re-usable device configuration commands with the ability to parameterize select elements of the configuration as well as add control logic statements. This template is used to generate a device deployable configuration by replacing the parameterized elements (variables) with actual values and evaluating the control logic statements.
◈ What is Jinja2? Jinja2 is one of the most used template engines for Python. It is inspired by Django’s templating system but extends it with an expressive language that gives template authors a more powerful set of tools.

Prerequisites: 

Jinja2 works with Python 2.6.x, 2.7.x and >= 3.3. If you are using Python 3.2 you can use an older release of Jinja2 (2.6) as support for Python 3.2 was dropped in Jinja2 version 2.7. To install this use pip.

pip install jinja2

Now we have Jinja2 installed let us take a quick look at this with a simple “Hello World” example with Python. To start with, create a Jinja2 file with “Hello World” inside (I am saving this into the same directory I am going to write my python code in). A quick way to create this file is with echo.

echo "Hello World" > ~/automation_fun/hello_world.j2

Now let us create our python code. We import Environment and FileSystemLoader, which allows us to use external files with the template. Feel free to create your python code in the way you feel is best for you. You can use the python interpreter or an IDE such as PyCharm.

from jinja2 import Environment, FileSystemLoader

#This line uses the current directory
file_loader = FileSystemLoader('.')

env = Environment(loader=file_loader)
template = env.get_template('hello_world.j2')
output = template.render()
#Print the output
print(output)

Use the following command to run your python program.

STUACLAR-M-R6EU:automation_fun stuaclar$ python hello_template.py
Hello World

Congratulations, your first template was a success!

Next, we will look at variables with Jinja2.

Variables With Jinja2

Template variables are defined by the context dictionary passed to the template. You can change and update the variables in templates provided they are passed in by the application. What attributes a variable has depends heavily on the application providing that variable. If a variable or attribute does not exist, you will get back an undefined value.

In this example, we will build a new BGP neighbor with a new peer. Let’s start by creating another Jinja2 file, this time using variables.  The outer double-curly braces are not part of the variable, what is inside will be what is printed out.

router bgp {{local_asn}}
 neighbor {{bgp_neighbor}} remote-as {{remote_asn}}
!
 address-family ipv4
  neighbor {{bgp_neighbor}} activate
exit-address-family

This python code will look similar to what we used before, however, we are passing three variables

from jinja2 import Environment, FileSystemLoader
#This line uses the current directory
file_loader = FileSystemLoader('.')
# Load the enviroment
env = Environment(loader=file_loader)
template = env.get_template('bgp_template.j2')
#Add the varibles
output = template.render(local_asn='1111', bgp_neighbor='192.168.1.1', remote_asn='2222')
#Print the output
print(output)

This will then print this output, notice that as we have repetitive syntax (the neighbor IP address), the variable is used again.

STUACLAR-M-R6EU:automation_fun stuaclar$ python bgp_builder.py
router bgp 1111
 neighbor 192.168.1.1 remote-as 2222
!
 address-family ipv4
  neighbor 192.168.1.1 activate
exit-address-family

If we have some syntax that will appear multiple times throughout our configuration, we can use for loops to remove redundant syntax.

For Loops with Jinja2

The for loop allows us to iterate over a sequence, in this case, ‘vlan’. Here we use one curly brace and a percent symbol. Also, we are using some whitespace control with the minus sign on the first and last line.  By adding a minus sign to the start or end of a block the whitespaces before or after that block will be removed. (You can try this and see the output difference once the Python code has been built). The last line tells Jinja2 that the template loop is finished, and to move on with the template.

Create another Jinja2 file with the following.

{% for vlan in vlans -%} 
    {{vlan}}
{% endfor -%}

In the python code, we add a list of vlans.

from jinja2 import Environment, FileSystemLoader

#This line uses the current directory
file_loader = FileSystemLoader('.')
# Load the enviroment
env = Environment(loader=file_loader)
template = env.get_template('vlan.j2')
vlans = ['vlan10', 'vlan20', 'vlan30']
output = template.render(vlans=vlans)
#Print the output
print(output)

Now we can run with python code and see our result.

STUACLAR-M-R6EU:automation_fun stuaclar$ python vlan_builder.py
vlan10
vlan20
vlan30

All of the code for these examples can be found on my GitHub https://github.com/bigevilbeard/jinja2-template

Continue reading