Archive

Category Archives for "Networking"

LISP – OMP – BGP EVPN Interoperability – Part VII: End-to-End Data-Plane Operation

 

Introduction

 

This chapter introduces Data-Plane operation and explains how the data packets from EP3 (IP 172.16.30.3) in Datacenter Fabric are forwarded via SD-WAN to EP1 (IP 172.16.100.10) in Campus Fabric. (1) EndPoint3 sends the ICMP Request packet to its gateway switch Leaf-11. Leaf-11 makes routing decisions based on the VRF NWKT routing table. Before forwarding the packet, Leaf-11 adds a VXLAN header where it uses L3VNI 10077. It also sets the outer IP header where it uses the Border-Leaf-13 tunnel interface’s IP address 192.168.50.13 as a destination. Spine-1 routes the packet to Border-Leaf-13 based on the outer IP address. Border-Leaf-13 notices that the destination IP address of the received IP packet belongs to its’s NVE1 tunnel interface. It removes the outer IP header and based UDP destination port it notices that this is VXLAN encapsulated packet. It knows that L3VNI 10077 belongs to VRF NWKT. It strips off the VXLAN header and routes the packet to vEdge-2. The ingress interface towards DC in vEdge-2 belongs to VPN 10. vEdge-2 consults its routing table. Based on it, vEdge-2 constructs tunnel headers and sends ICMP Request to vEdge-1 via Public-Internet using MPLS Label 1003 as a VPN identifier. Routers in Internet routes packet based on the outer destination IP address. When vEdge-1 receives the packet, it notices that the destination IP address is its’ Public IP address. It first removes the outer IP header. Then it checks the tunnel header. Based on the Label value 1003, it knows that packet belongs to VPN 10. It consults the VPN 10 RIB and routes the packet to Border-PxTR-13. The ingress interface on Border-PxTR-13 belongs to VRF 100_NWKT that belongs to LISP Instance 100. It checks the Instance 100 specific LISP mapping in order to know how it should route the packet. The LISP mapping Database does not contain the information because this is the first packet to destination 172.16.100.10. Border-PxTR-13 sends a LISP Map-Request message to MapSrv-22, which replies with a LISP Map-Reply message, where it describes the RLOC of Edge-xTR-11 that has registered the IP address 172.16.100.10. I have excluded the Map-Request/Reply processes from figure 6-1 to keep the figure simple. Border-Leaf-13 encapsulates the ICMP Request packet with a tunnel header. It sets the Instance-Id 100 on the VXLAN header and adds the outer IP header where it uses the Edge-xTR-11’s IP address 192.168.0.13 as a destination address. Core-1 routes the packet to Edge-xTR-11 based on the outer IP header destination address. Edge-xTR-11 processes the ingress IP packet because the destination IP address belongs to it. Based on the destination UDP port 4789, it knows that the following header is a VXLAN header. Edge-xTR-11 knows that the LISP Instance-Id 100 is bind to BD 100. Because Edge-xTR-11 has an L3 interface in BD 100, it resolves the MAC address for the IP address 172.16.100.10 from the ARP table and the egress interface for the MAC from the MAC address table. EP1 processes the ICMP Request packet and sends the ICMP Reply to EP3.


Figure 6-1:End-to-End Data-Plane Operation.

 

Continue reading

Heavy Networking 592: The VAR Perspective On Networking And Customer Trends

Today on Heavy Networking, we talk with Remington Loose, Solutions Architect at a mid-sized VAR, to get a sense of what technology is in demand; what problems customers are trying to solve; and how cloud, DIY, and other forces affect the competitive landscape. It's a #VARlife episode.

The post Heavy Networking 592: The VAR Perspective On Networking And Customer Trends appeared first on Packet Pushers.

Follow My Leader

I spent the past two weeks enjoying the scenic views at the Philmont Scout Ranch with my son and some of his fellow Scouts BSA troop mates. It was very much the kind of vacation that involved a lot of hiking, mountain climbing, and even some inclement weather. We all completely enjoyed ourselves and I learned a lot about hanging bear bags and taking care of blisters. I also learned a lot about leadership by watching the boys in the crew interact with each other.

Storm Warnings

Leadership styles are nothing new to the people that read my blog. I’ve talked about them at length in the past. One thing I noticed when I was on the trek was how different leadership styles can clash and create friction among teenagers. As adults we tend to gloss over delivery and just accept that people are the way they are. When you’re fourteen or fifteen you haven’t quite taken that lesson to heart yet. That means more pushing against styles that don’t work for you.

We have all worked for or with someone that has a very authoritarian style in the past. The kind of people that say, “Do this right now” Continue reading

Introducing Deploy Hooks for Cloudflare Pages

Introducing Deploy Hooks for Cloudflare Pages
Introducing Deploy Hooks for Cloudflare Pages

With Cloudflare Pages, deploying your Jamstack applications is easier than ever — integrate with GitHub and a simple git push deploys your site within minutes. However, one of the limitations of Pages was that triggering deployments to your site only happens within the confines of committing to GitHub. We started thinking about how users who author content consistently on their site — our bloggers and writers — may not always be editing their copy directly via the code but perhaps through a different service. Headless content management systems (CMSs) are a simple solution to solve this problem, allowing users to store their backend content through an editing interface as a service for an application like Pages.

It made us wonder: what if we could trigger deployments based on updates made in other places rather than just via GitHub? Today, we are proud to announce a new way to connect your Pages application with your headless CMSs and databases: introducing Deploy Hooks for Pages.

What’s a headless CMS?

Headless CMSs such as Contentful, Ghost and Sanity.io allow optimization of content formatting for any type of interface. With tools like these, you can leverage a “decoupled” content management model where all Continue reading

LISP – OMP – BGP EVPN Interoperability – Part VI: LISP Control-Plane – Registering External IP Prefixes

 

Introduction

 

This chapter introduces how Border-PxTR-13 registers the external IP prefix 172.16.30.0/24 received as a BGP update from vEdge-1 to MapSrv-22 using LISP Map-register messages. Chapter 2 explains the LISP RLOC-to-EID mapping process in detail so this chapter just briefly recaps the operation. Figure 5-1 illustrates the overall process. vEdge-1 sends a BGP Update message where it describes the NLRI for prefix 172.16.30.0/24. Border-PxTR-13 first imports the information into the LISP processes. Next, it sends a LISP Map-Register message to MapSrv-22. In addition to IP prefix information, the Map-Register message carries Locator Record information that describes the destination IP address used in the outer IP header (tunnel header) when devices route IP packets towards the advertised subnet.  



Figure 5-1:Overall Control-Plane Operation: OMP to LISP

Continue reading

How to deploy a BGP route generator? | Containerlab | ExaBGP

Hi all!

The blog post is sort of "How to ...?"

Introduction

Some time ago I needed to prepare a lab environment where I should have to simulate a huge amount of BGP updates between routers.  How can we arrange that? The main thing is how to generate a lot of BGP updates? As I see we have two ways:

  • VM with network OS from classic vendors (Cisco, Juniper, Nokia);
  • Linux BGP daemon
Sure, BGP daemons are more scalable and suitable for lab purposes. And a lot of companies use them in production (in most cases as BGP RR). Of course, I knew about different Linux BGP demons but didn't have experience with them. This time I followed the next simple workflow in the tech world - don't know something? Let's Googling! (don't use this way in the production environment - firstly, read tech books, user guides, RFC, etc :) )

This way I've found all that I need:

1) BGP daemon. I decided to use ExaBGP
2) Route generator. It's a simple python script route-smash that uses ExaBGP API.

As a lab environment, I'm using Containerlab. Don't know what more I can add about Containerlab. If you don't Continue reading

Some not-DNS Topics at IETF 111

It may be surprising to the DNSphiles out there but there really are other topics that are discussed at IETF meetings not directly related to the DNS! These are some notes I took on the topic of current activities in some of the active IETF areas that are not DNS topics.

DNS at IETF 111

IETF 111 was held virtually in July 2020. These are some notes I took on the topic of current activities in the area of the Domain Name System and its continuing refinement at IETF 111.

Chip shortage has networking vendors scrambling

High-tech vendors continue to battle supply-chain problems and higher costs brought on by the current semiconductor shortage, according to statements made in the most recent round of earnings calls.As Network World reported in May, COVID-19 triggered an explosion of the global remote workforce, which created extraordinary demand for new tech gear. It also forced the shutdown of processor plants. Restarting those plants and renewing supply chains to their pre-pandemic state will be a lengthy process, industry leaders warn.To read this article in full, please click here

Ransomware recovery: Cloud is the way to go

If you’ve been attacked by ransomware, a fully automated, high-speed disaster recovery is the way to successfully avoid paying the ransom. Recovery is the second step in the two-step process after getting rid of the malware as described here.There are three ways to affect a disaster recovery after a ransomware attack: a traditional recovery, an image-based recovery, or a cloud-based recovery. But the only way for most environments to afford automating a large-scale recovery is to recover in the cloud.How to protect backups from ransomware Traditional disaster recovery A traditional disaster recovery is one where you begin a traditional restore after you have suffered a loss—in this case, after you receive a ransom demand. It is still a traditional restore if you are restoring virtual machine images to a hypervisor platform such as VMware, Hyper-V, or KVM, or a hyperscaler such as AWS, Azure, or GCP. What makes it traditional is that you are waiting until the event happens to begin the restore. (As you will see later in this article, there are ways to restore the data before you need it.)To read this article in full, please click here

Cloudflare Helps K-12s Go Back to School

Cloudflare Helps K-12s Go Back to School
Cloudflare Helps K-12s Go Back to School

While Federal funding programs focus on providing connectivity to students and staff, security is often an afterthought and reallocating funds to protect the network can become a challenge. We are excited to announce our Back to School initiative to further support our mission to provide performance and security with no trade-offs.

From start to finish, education customers will work with our dedicated Public Sector team, well-versed in the specific technical environments and business needs for K-12 districts. Your IT team will have access to 24/7/365 technical support, emergency response and support during under attack situations, and ongoing training to continuously help improve your security posture and business continuity plans.

Attacks Against K-12 Schools On The Rise

Public schools in the United States, especially K-12s, saw a record-breaking increase in cybersecurity attacks. The K-12 Cyber Incident Map cataloged 408 publicly-disclosed school incidents, including a wide range of cyber attacks; from data breaches to ransomware, phishing attacks, and denial-of-service attacks. This is an 18 percent increase over 2019 and continues the upward trend in attacks since the K-12 Cyber Incident Map started tracking incidents in 2016. To support our public education partners, Cloudflare has created a tailored onboarding experience to help education Continue reading

Kubernetes security issues: An examination of major attacks

In a never-ending game of cat and mouse, threat actors are exploiting, controlling and maintaining persistent access in compromised cloud infrastructure. While cloud practitioners are armed with best-in-class knowledge, support, and security practices, it is statistically impossible to have a common security posture for all cloud instances worldwide. Attackers know this, and use it to their advantage. By applying evolved tactics, techniques and procedures (TTPs), attackers are exploiting edge cases. As a result, organizations like Capital One, Jenkins, Docker and many others have experienced high-profile breaches.

TTPs are defined as “patterns of activities or methods associated with a specific threat actor or group of threat actors.” TTPs describe how threat actors (the bad guys) orchestrate, execute, and manage their operations attacks. Analysis of TTPs can benefit security operations by providing a description of how threat actors performed their attacks. Kubernetes is not immune to TTPs. Let’s examine some recent cases within the Kubernetes ecosystem.

 

Case #1: Misconfigured Docker

If you’re an attacker looking for misconfigured Docker instances to exploit, it’s as easy as probing open ports 2375, 2376, 2377, 4243, and 4244 on the internet. Vulnerable instances can also be located using search engines like Continue reading