Archive

Category Archives for "Networking"

Heavy Networking 579: How Arrcus Enables Network-as-a-Service For 5G Edge/Access Networks (Sponsored)

Today on Heavy Networking, we talk with sponsor Arrcus about its support for segment routing and the impact it will have on the wider network market, particularly for 5G networks. Our guests from Arrcus are Keyur Patel, CTO and Co-Founder; and Murali Gandluru, Vice President, Product Management.

The post Heavy Networking 579: How Arrcus Enables Network-as-a-Service For 5G Edge/Access Networks (Sponsored) appeared first on Packet Pushers.

Cloud Networking As A Service Case Study With Koch – Packet Pushers LiveStream With Alkira (Video 3)

Koch Business Solutions provides IT services for businesses within Koch Industries. The company implemented a cloud-first modernization plan several years ago. At the time, the organization built transport hubs to get huge datasets and workloads into the cloud, but realized it was still coupled to a data center approach. The Packet Pushers’ Drew Conry-Murray speaks […]

The post Cloud Networking As A Service Case Study With Koch – Packet Pushers LiveStream With Alkira (Video 3) appeared first on Packet Pushers.

Cisco SD-WAN



Table of Contents

Chapter 1: Setting Up On-Prem Controllers 1

    Introduction 1

    Configuring IOS-XE Certification Server 2

    Enabling HTTP Server and NTP 2

    Certificate Server Configuration 2

    vManage Configuration 4

    System Information 6

    VPN Configuration 6

    Certification enrollment 8

    vBond Initial Configuration 15

    System Information 17

    VPN Configuration 18

    Certification enrollment 19

    vSmart Initial Configuration 25

    System Information 26

    VPN Configuration 26

    Certification enrollment 27

    Control Connection Verification 33

Continue reading

CDN-Cache-Control: Precision Control for your CDN(s)

CDN-Cache-Control: Precision Control for your CDN(s)
CDN-Cache-Control: Precision Control for your CDN(s)

Today we are thrilled to announce our support of a new set of HTTP response headers that provide surgical control over our CDN’s caching decisions. CDN-Cache-Control allows customers to directly control how our CDN behaves without affecting the behavior of downstream or upstream caches.

You might be thinking that this sounds a lot like the Cache-Control header we all know and love. And it’s very similar! CDN-Cache-Control has exactly the same directives as the Cache-Control header. The problem CDN-Cache-Control sets out to solve is that with Cache-Control, some directives are targeted at specific classes of caches (like s-maxage for shared caches), while other directives are not targeted at controlling any specific classes of intermediary caches (think stale-while-revalidate). As these non-specific directives are returned to downstream caches, they’re often not applied uniformly. This problem is amplified as the number of intermediary caches grows between an origin and the client.

For example, a website may deploy a caching layer on the origin server itself, there might be a cache on the origin’s network, the site might use one or more CDNs to cache content distributed throughout the Internet, and the visitor’s browser might cache content as well. As the response returns Continue reading

Video: We Still Need Networking in Public Clouds

Whenever someone starts mansplaining that you we need no networking when we move the workloads into a public cloud, please walk away – he has just proved how clueless he is.

He might be a tiny bit correct when talking about software-as-a-service (after all, it’s just someone else’s web site), but when it comes to complex infrastructure virtual networks, there’s plenty of networking involved, from packet filters and subnets to NAT, load balancers, firewalls, BGP and IPsec.

For more details, watch the We Still Need Networking in Public Clouds video (part of Introduction to Cloud Computing webinar).

You need Free ipSpace.net Subscription to watch the video

Video: We Still Need Networking in Public Clouds

Whenever someone starts mansplaining that we need no networking when we move the workloads into a public cloud, please walk away – he has just proved how clueless he is.

He might be a tiny bit correct when talking about software-as-a-service (after all, it’s just someone else’s web site), but when it comes to complex infrastructure virtual networks, there’s plenty of networking involved, from packet filters and subnets to NAT, load balancers, firewalls, BGP and IPsec.

For more details, watch the We Still Need Networking in Public Clouds video (part of Introduction to Cloud Computing webinar).

You need Free ipSpace.net Subscription to watch the video

Internet by the people, for the people – a view from the Digital Empowerment Foundation

a man standing in front of a wall holding a mobile phone

The Digital Empowerment Foundation believes building community networks is something everyone can do. And people are doing it. Internet connectivity may be important for our global society, but in rural India it’s a luxury not many villages have access to. Osama Manzar, the founder of the Digital Empowerment Foundation, has spent the last decades trying […]

The post Internet by the people, for the people – a view from the Digital Empowerment Foundation appeared first on Internet Society.

Upbound Universal Crossplane Wants to Replace Infrastructure as Code

Crossplane, has created what it says is the first enterprise distribution of Crossplane called Bassam Tabbara, Upbound founder and CEO, in an interview. Crossplane “becomes your universal control plane that you could use, using the same style that the Kubernetes community pioneered, to manage essentially all the infrastructure that an enterprise touches from a single control plane.” UXP, then, is an open source, vendor-supported, enterprise-grade distribution of Crossplane that also adds on a layer of 24/7 support, priority bug fixes, and consultation with a subscription. UXP is available free for individual users and by subscription for larger deployments, and is a drop-in replacement for Crossplane that installs with a single command. Tabbara noted that UXP is “vendor-supported, not community-supported,” in that Upbound will “help enterprises deploy it, support it, and give them a number of features that makes it easier for them to deploy and manage it in their environment.” As a long-term supported project, UXP also lags behind Crossplane upstream to ensure reliability, and Upbound describes UXP  as “designed to help enterprises adopt a universal control plane, moving beyond infrastructure as code,” in a press statement. In the case of UXP, Crossplane is further extended with its integration with both Upbound Cloud and Upbound Registry, both of which became generally available at the same time as the release of UXP. Upbound Cloud provides teams with visibility into their UXP instances and the infrastructure being managed, giving them a place to see what is running where, and by who it was provisioned. Upbound Registry then provides a place to both publicly and privately share Crossplane Configurations, and for providers to share managed resources. “With UXB, with Upbound Cloud and Upbound Registry, we believe we have a set of products now that can actually take this approach of using control planes in the enterprise and turn it into essentially a new way of managing infrastructure,” Tabbara said. “We see this with existing customers today, maybe even replacing a lot of what they do today with tools like Terraform and infrastructure-as-code approaches and going more towards a control plane approach, or even gitOps on top of a control plane.” The big difference Tabbara sees in all of this is that, by taking the API-driven approach rather than relying on templates, as with infrastructure as code, Crossplane and UXP can deliver a more scalable experience to managing infrastructure across large and varied environments. He explained that part of the appeal of Crossplane lies in the fact that teams can use the same Kubernetes-based tools and approaches that they are already using to deploy software to provision and manage infrastructure. Sponsor Note LaunchDarkly is a feature management platform that empowers all teams to safely deliver and control software through feature flags. By separating code deployments from feature releases, LaunchDarkly enables you to deploy faster, reduce risk, and iterate continuously. “If you are using Helm, or kustomize, or if you’re using literally any of the tools that people are deploying and love and use today with Kubernetes, as a container orchestrator, those tools work exactly in the same way,” said Tabbara. “When you’re using Kubernetes plus Crossplane to manage the rest of the cloud infrastructure and deployments across clouds and hybrid clouds, those tools work exactly in the same way. They are using Crossplane APIs that are extensions of Kubernetes extensions of the Kubernetes control plane.” Following the most recent KubeCon+CloudNativeCon, there were some

Linux as a network operating system


NVIDIA Linux Switch enables any standard Linux distribution to be used as the operating system on the NVIDIA Spectrum™ switches. Unlike network operating systems that are Linux based, where you are limited to a specific version of Linux and control of the hardware is restricted to vendor specific software modules, Linux Switch allows you to install an unmodified version of your favorite Linux distribution along with familiar Linux monitoring and orchestration tools. 

The key to giving Linux control of the switch hardware is the switchdev module - a standard part of recent Linux kernels. Linux switchdev is an in-kernel driver model for switch devices which offload the forwarding (data) plane from the kernel. Integrating switch ASIC drivers in the Linux kernel makes switch ports appear as additional Linux network interfaces that can be configured and managed using standard Linux tools.

The mlxsw wiki provides instructions for installing Linux using ONIE or PXE boot on Mellanox switch hardware, for example, on NVIDIA® Spectrum®-3 based SN4000 series switches, providing 1G - 400G port speeds to handle scale-out data center applications.

Major benefits of using standard Linux as the switch operating system include:

Data Center Threats: Turning Remote Access into Money

Data centers are an appealing target for cybercriminals. Even though they may be more difficult to compromise than the home computer of a kid playing Fortnite or the laptop of a sales representative connecting to a random wireless network, they can bring very large rewards: databases with millions of records containing financial and personal information, substantial computational resources that can be used to mine cryptocurrencies, and access to key assets that can be held for ransom.

In this blog post, we analyze the main pathways that cybercriminals leverage to gain access to data centers, how they take advantage of that access, and what security administrators can do to reduce and manage the associated risks.

Getting into the Data Center

The obvious first goal of an attacker is to gain access to the targeted data center. This can be achieved in several ways — including social engineering [1], physical access [2], and occasionally by deer [3]— but anecdotal evidence suggests that the two main avenues are remote exploitation (also known as remote-to-local attacks [4]), and stolen credentials [5].

Remote-to-local Attacks

In a remote-to-local attack, an attacker targets a remotely accessible service provided by one of the workloads running in the data Continue reading

Improving your monitoring setup by integrating Cloudflare’s analytics data into Prometheus and Grafana

Improving your monitoring setup by integrating Cloudflare’s analytics data into Prometheus and Grafana

The following is a guest post by Martin Hauskrecht, DevOps Engineer at Labyrinth Labs.

Improving your monitoring setup by integrating Cloudflare’s analytics data into Prometheus and Grafana

Here at Labyrinth Labs, we put great emphasis on monitoring. Having a working monitoring setup is a critical part of the work we do for our clients.

Cloudflare's Analytics dashboard provides a lot of useful information for debugging and analytics purposes for our customer Pixel Federation. However, it doesn’t automatically integrate with existing monitoring tools such as Grafana and Prometheus, which our DevOps engineers use every day to monitor our infrastructure.

Cloudflare provides a Logs API, but the amount of logs we’d need to analyze is so vast, it would be simply inefficient and too pricey to do so. Luckily, Cloudflare already does the hard work of aggregating our thousands of events per second and exposes them in an easy-to-use API.

Having Cloudflare’s data from our zones integrated with other systems’ metrics would give us a better understanding of our systems and the ability to correlate metrics and create more useful alerts, making our Day-2 operations (e.g. debugging incidents or analyzing the usage of our systems) more efficient.

Since our monitoring stack is primarily based on Prometheus and Grafana, we decided to implement our own Continue reading

Automation: Dealing with Vendor-Specific Configuration Keywords

One of the students in our Building Network Automation Solutions online course asked an interesting question:

I’m building an IPsec multi-vendor automation solution and am now facing the challenge of vendor-specific parameter names. For example, to select the AES-128 algorithm, Juniper uses ‌aes-128-cbc, Arista aes128, and Checkpoint AES-128.

I guess I need a kind of Rosetta stone to convert the IKE/IPSEC parameters from a standard parameter to a vendor-specific one. Should I do that directly in the Jinja2 template, or in the Ansible playbook calling the template?

Both options are awkward. It would be best to have a lookup table mapping parameter values from the data model into vendor-specific keywords, for example:

Automation: Dealing with Vendor-Specific Configuration Keywords

One of the students in our Building Network Automation Solutions online course asked an interesting question:

I’m building an IPsec multi-vendor automation solution and am now facing the challenge of vendor-specific parameter names. For example, to select the AES-128 algorithm, Juniper uses ‌aes-128-cbc, Arista aes128, and Checkpoint AES-128.

I guess I need a kind of Rosetta stone to convert the IKE/IPSEC parameters from a standard parameter to a vendor-specific one. Should I do that directly in the Jinja2 template, or in the Ansible playbook calling the template?

Both options are awkward. It would be best to have a lookup table mapping parameter values from the data model into vendor-specific keywords, for example: