Routing in Azure Subnets

Introduction

Subnets, aka Virtual Local Area Networks (VLANs) in traditional networking, are Layer-2 broadcast domains that enable attached workloads to communicate without crossing a Layer-3 boundary, the subnet Gateway. Hosts sharing the same subnet resolve each other’s MAC-IP address binding using Address Resolution Protocol, which relays on Broadcast messages. That is why we often use the Failure domain definition with subnets. We can spread subnets between physical devices over Layer-2 links using VLAN tagging, defined in the IEEE 802.1Q standard. Besides, tunnel encapsulation solutions supporting tenant/context identifier enables us to extend subnets over Layer-3 infrastructure. Virtual eXtensible LAN (VXLAN) using VXLAN Network Identifier (VNI) and Network Virtualization using Generic Route Encapsulation (NVGRE) using Tenant Network ID (TNI) are examples of Network Virtualization Over Layer 3 (NVO) solutions. If you have to spread the subnet over MPLS enabled network, you can choose to implement Virtual Private LAN (VPLS) Service or Virtual Private Wire Service (VPWS), among the other solutions.  

In Azure, the concept of a subnet is different. You can think about it as a logical domain within a Virtual Network (VNet), where attached VMs share the same IP address space and use the same shared routing policies. Broadcast and Multicast traffic is not natively supported in Azure VNet. However, you can use a cloudSwXtch VM image from swXtch.io to build a Multicast-enabled overlay network within VNet. 

Default Routing in Virtual Network

This section demonstrates how the routing between subnets within the same Virtual Network (VNet) works by default. Figure 2-1 illustrates our example Azure VNet setup where we have deployed two subnets. The interface eth0 of vm-west and interface eth1 of vm-nva-fw are attached to subnet snet-west (10.0.0.0/24), while interface eth2 of vm-nva-fw and interface eth0 of vm-west is connected to subnet snet-east (10.0.1.0/24). All three VMs use the VNet default routing policy, which routes Intra-VNet data flows directly between the source and destination endpoint, regardless of which subnets they are connected to. Besides, the Network Security Groups (NSGs) associated with vNICs share the same default security policies, which allow inbound and outbound Intra-VNet data flows, InBound flows from the Load Balancer, and OutBound Internet connections. 

Now let’s look at what happens when vm-west (DIP: 10.0.0.4) pings vm-west (DIP: 10.0.1.4), recapping the operation of VFP. Note that Accelerated Networking (AccelNet) is enabled in neither VMs.

  1. The VM vm-west sends an ICMP Request message to vm-east. The packet arrives at the Virtual Filtering Platform (VFP) for processing. Since this is the first packet of the flow, the Flow Identifier and associated Actions are not in the Unified Flow Table (UFT). The Parser component extracts the 5-tuple header information (source IP, source port, destination IP, destination port, and transport protocol) as metadata from the original packet. The metadata is then processed in each VFP layer to generate a flow-based entry in the UFT.
  2. The destination IP address matches the Network Security Group's (NSG) default outbound rule, which allows Intra-VNet flows. Then the metadata is passed on to the routing process. Since we haven't yet deployed subnet-specific route tables, the result of the next-hop route lookup is 3.3.3.3, the Provider Address (PA) of Host-C.
  3. Intra-VNet connections use private IP addresses (DIP-Direct IP), and the VFP process bypasses the NAT layer. The VNet layer, responsible for encapsulation/decapsulation, constructs tunnel headers (IP/UDP/VXLAN). It creates the outer IP address with the source IP 1.1.1.1 (Host-A) and destination IP 3.3.3.3 (Host-C), resolved by the Routing layer. Besides, it adds Virtual Network Identifier (VNI) into the VXLAN header.
  4. After each layer has processed the metadata, the result is encoded to Unified Flow Table (UFT) with Flow-Id with push action (Encapsulation). 
  5. The Header Transposition engine (HT) modifies the original packet based on the UFT actions. It adds tunnel headers leaving all original header information intact. Finally, the modified packet is transmitted to the upstream switch. The subsequent packets are forwarded based on the UFT.
  6. The Azure switching infra forwards the packet based on the destination IP address on the outer IP header (tunnel header).
  7. The VFP on Host-C processes the ingress ICMP Request message in the same manner as VFP in Host-A but in reversed order starting with decapsulation in the VNet layer.

Figure 2-1: Example Topology Diagram.
Continue reading

Introducing Rollbacks for Workers Deployments

Introducing Rollbacks for Workers Deployments
Introducing Rollbacks for Workers Deployments

In November, 2022, we introduced deployments for Workers. Deployments are created as you make changes to a Worker. Each one is unique. These let you track changes to your Workers over time, seeing who made the changes, and where they came from.

Introducing Rollbacks for Workers Deployments

When we made the announcement, we also said our intention was to build more functionality on top of deployments.

Today, we’re proud to release rollbacks for deployments.

Rollbacks

As nice as it would be to know that every deployment is perfect, it’s not always possible - for various reasons. Rollbacks provide a quick way to deploy past versions of a Worker - providing another layer of confidence when developing and deploying with Workers.

Via the dashboard

In the dashboard, you can navigate to the Deployments tab. For each deployment that’s not the most recent, you should see a new icon on the far right of the deployment. Hovering over that icon will display the option to rollback to the specified deployment.

Introducing Rollbacks for Workers Deployments

Clicking on that will bring up a confirmation dialog, where you can enter a reason for rollback. This provides another mechanism of record-keeping and helps give more context for why the rollback was necessary.

Introducing Rollbacks for Workers Deployments

Once you enter Continue reading

mTLS client certificate revocation vulnerability with TLS Session Resumption

mTLS client certificate revocation vulnerability with TLS Session Resumption
mTLS client certificate revocation vulnerability with TLS Session Resumption

On December 16, 2022, Cloudflare discovered a bug where, in limited circumstances, some users with revoked certificates may not have been blocked by Cloudflare firewall settings. Specifically, Cloudflare’s Firewall Rules solution did not block some users with revoked certificates from resuming a session via mutual transport layer security (mTLS), even if the customer had configured Firewall Rules to do so. This bug has been mitigated, and we have no evidence of this being exploited. We notified any customers that may have been impacted in an abundance of caution, so they can check their own logs to determine if an mTLS protected resource was accessed by entities holding a revoked certificate.

What happened?

One of Cloudflare Firewall Rules’ features, introduced in March 2021, lets customers revoke or block a client certificate, preventing it from being used to authenticate and establish a session. For example, a customer may use Firewall Rules to protect a service by requiring clients to provide a client certificate through the mTLS authentication protocol. Customers could also revoke or disable a client certificate, after which it would no longer be able to be used to authenticate a party initiating an encrypted session via mTLS.

When Cloudflare receives Continue reading

DHCP Relaying in EVPN VRFs

After figuring out how DHCP relaying works and testing it with VRFs and in VXLAN segments, it seems like a no-brainer to make it work with EVPN.

TL&DR: It works, at least when using Arista vEOS as the relay and Cisco CSR 1000v as the DHCP server.

Lab Topology

We’ll keep using the exact same “physical” topology we used in the VXLAN DHCP relaying lab, add EVPN and BGP to the control-plane cocktail, and put the VXLAN segment into a VRF. We’ll use CSR 1000v as the DHCP server because Cisco IOSv doesn’t support some of the DHCP option-82 sub-options we need.

Read more …

DHCP Relaying in EVPN VRFs

After figuring out how DHCP relaying works and testing it with VRFs and in VXLAN segments, it seems like a no-brainer to make it work with EVPN.

TL&DR: It works, at least when using Arista vEOS as the relay and Cisco CSR 1000v as the DHCP server.

Lab Topology

We’ll keep using the exact same “physical” topology we used in the VXLAN DHCP relaying lab, add EVPN and BGP to the control-plane cocktail, and put the VXLAN segment into a VRF. We’ll use CSR 1000v as the DHCP server because Cisco IOSv doesn’t support some of the DHCP option-82 sub-options we need.

Read more …

New Juniper Rack Mount Kit

Juniper has a new enhanced four-post rack mount kit “JNP-4PST-RMK-1U-E” for their 1RU datacenter devices. It works with devices like the QFX5120 and PTX10001-36MR. It is much improved over the legacy rack mount kit. It are not as good as some competitors, but it is backwards compatible. It makes switch installation quicker and safer.

Background: Current 4-post rail kit

Juniper has used the same 4-post kit for their 1RU datacenter switches and routers for many years. The same kit works on QFX5100, QFX5110 and QFX5120-48Y switches. The MX204 uses a slight variation, but is almost identical. Oddly, the QFX5120-32C uses something completely different. Devices are secured to the front and rear posts. 2-post mounting is unwise for modern deep devices with heavy PSUs. You can still get away with 2-post mounting for lighter, shallower access switches. Modern servers and deep switches/routers need 4-post mounting, or some sort of shelf.

The current kit “EX-4PST-RMK” has 2 parts per side:

Legacy rail kit

One piece screws in to each side of the switch. Note that there are 8 holes per side, but Juniper supplies a total of 12 very small screws. As you can imagine, installing 12 very small screws per switch is no fun Continue reading

Controversial Reads 040123


Last year, around the Thanksgiving holiday, Ohio businessman Michael Larkin received a request for video from his Amazon Ring security system from Hamilton city police.


Once upon a time there live a tribe who lived on the plains. They were an adventurous tribe, constantly wanting to explore. At night they would see the moon drift lazily overhead, and became curious.


If I’ve written in this space before about “convenience of the employer” rules a lot of late, it’s because they are so pernicious. These rules essentially require taxpayers who switch from working in-person in one state to working remotely in another to continue paying income taxes to the state they used to work in, not the one they currently work in.


A federal judge yesterday ruled that Google intentionally destroyed evidence and must be sanctioned, rejecting the company’s argument that it didn’t need to automatically preserve internal chats involving employees subject to a legal hold.


From a national security perspective, banning TikTok seems to be a reasonable step in protecting U.S. citizens. After all, TikTok is merely a video sharing app that is widely used by children; thus, its ability to harm us far outweighs its utility.


And so Continue reading

Weekend Reads 033123

Late posting due to a conference this weekend …


The rapid rise in IT power density, however, now means that plausible design assumptions regarding future power density and environmental conditions are starting to depart from these standard, narrow ranges.


Globalization is over, at least for the chip industry, and this will mean higher chip prices, according to semiconductor contract manufacturer giant TSMC.


Are your online customers being lured away? Learn why retailers must prevent audience hijacking tactics to keep shoppers focused and not distracted by unwanted or malicious in-browser interruptions.


I surveyed the status of RPKI ROA registration for IXPs operating in the Asia Pacific region and several IXPs in the European region on 17 February 2023. My first impression is that both regions lack a sense of unity, with RPKI ROA registration being inconsistent.


Active DNS measurement is fundamental to understanding and improving the DNS ecosystem. However, the absence of an extensible, high-performance and easy-to-use DNS toolkit has limited both the reproducibility and coverage of DNS research.


A group monitored as REF2924 by Elastic Security Labs is wielding novel data-stealing malware — an HTTP listener written in C# dubbed Naplistener by the researchers — in attacks against victims operating Continue reading

Ask JJX: Lynyrd Skynyrd Answers “Who Should Create an Org’s BYOD Policy?”

After LastPass's latest breach through a personal laptop, most boards, CIOs, and CISOs are taking the opportunity to reevaluate their Bring Your Own Device (BYOD) policies.

Here's how, why, and a lesson learned from Lynyrd Skynyrd. 

The post Ask JJX: Lynyrd Skynyrd Answers “Who Should Create an Org’s BYOD Policy?” appeared first on Packet Pushers.

Demo Bytes: Managing Your SD-WAN Deployment Lifecycle With LiveAction’s LiveNX (Sponsored) – Video

Sponsor LiveAction demonstrates how its LiveNX product can be used to deploy, monitor and repair multi-vendor SD-WANs. Our guest is Ron Groulx, Senior Systems Sales Engineer at LiveNX. LiveNX can manage and monitor your SD-WAN lifecycle from day zero (baselining your network performance) to day one (building policies to optimize performance) to day two (deployment […]

The post Demo Bytes: Managing Your SD-WAN Deployment Lifecycle With LiveAction’s LiveNX (Sponsored) – Video appeared first on Packet Pushers.

Heavy Networking 672: Overcoming Your Imposter Syndrome

Lots of folks suffer from impostor syndrome. Tech is complex--how could you know what you’re doing? And yet, many of us are responsible for incredibly complex IT systems. Fake it ‘til you make it, right? To handle the cognitive dissonance of impostor syndrome, we overcompensate. In doing so, we pay a personal price. Today's Heavy Networking guest is Matt Vitale. He's here to share what he's learned about coping with and overcoming imposter syndrome.

Heavy Networking 672: Overcoming Your Imposter Syndrome

Lots of folks suffer from impostor syndrome. Tech is complex--how could you know what you’re doing? And yet, many of us are responsible for incredibly complex IT systems. Fake it ‘til you make it, right? To handle the cognitive dissonance of impostor syndrome, we overcompensate. In doing so, we pay a personal price. Today's Heavy Networking guest is Matt Vitale. He's here to share what he's learned about coping with and overcoming imposter syndrome.

The post Heavy Networking 672: Overcoming Your Imposter Syndrome appeared first on Packet Pushers.

Creating a Talos Linux Cluster on Azure with Pulumi

A little over a month ago I published a post on creating a Talos Linux cluster on AWS with Pulumi. Talos Linux is a re-thinking of your typical Linux distribution, custom-built for running Kubernetes. Talos Linux has no SSH access, no shell, and no console; instead, everything is managed via a gRPC API. This post is something of a “companion post” to the earlier AWS post; in this post, I’ll show you how to create a Talos Linux cluster on Azure with Pulumi.

The program I’ll share with you in this post is written in Go, but the process outlined in this post and the accompanying code is equally applicable in other languages supported by Pulumi. (TypeScript is a popular choice for lots of folks.) The code is available in this GitHub repository. It’s based on this documentation from Sidero Labs, and I also found this blog post to be helpful as well.

The Pulumi program follows this overall flow:

  1. First, the program creates the base infrastructure objects that are required—a resource group, a virtual network, some subnets, and a network security group.
  2. Next, it creates a load balancer, gets a public IP address for the load Continue reading
1 … 273 274 275 276 277 … 3,791