Will ChatGPT Replace Stack Overflow?
TL&DR: No. You can move on.
NANOG87 summary by John Kristoff prompted me to look at NANOG87 presentations, and one of them discussed ChatGPT and Network Engineering (video). I couldn’t resist the clickbait ;)
Like most using ChatGPT for something articles we’re seeing these days, the presentation is a bit too positive for my taste. After all, it’s all fine and dandy to claim ChatGPT generates working router configurations and related Jinja2 templates if you know what the correct configurations should look like and can confidently say “and this is where it made a mistake” afterwards.
Chapter 1: Azure VM networking – Virtual Filtering Platform and Accelerated Networking
Note! This post is under the technical review
Introduction
Virtual Filtering Platform (VFP) is Microsoft’s cloud-scale software switch operating as a virtual forwarding extension within a Hyper-V basic vSwitch. The forwarding logic of the VFP uses a layered policy model based on policy rules on Match-Action Table (MAT). VFP works on a data plane, while complex control plane operations are handed over to centralized control systems. The VFP includes several layers, including VNET, NAT, ACL, and Metering layers, each with dedicated controllers that program policy rules to the MAT using southbound APIs. The first packet of the inbound/outbound data flow is processed by VFP. The process updates match-action table entries in each layer, which then are copied into the Unified Flow Table (UFT). Subsequent packets are then switched based on the flow-based action in UFT. However, if the Virtual Machine is not using Accelerated Networking (AccelNet), all packets are still forwarded over the software switch, which requires CPU cycles. Accelerated Networking reduces the host’s CPU burden and provides a higher packet rate with a more predictable jitter by switching the packet using hardware NIC yet still relaying to VFP from the traffic policy perspective.
Hyper-V Extensible Virtual Switch
Microsoft’s extensible vSwitch running on Hyper-V operates as a Networking Virtualization Service Provider (NetVSP) for Virtual Machine. VMs, in turn, are Network Virtualization Service Consumers (NetVSP). When a VM starts, it requests the Hyper-V virtualization stack to connect to the vSwitch. The virtualization stack creates a virtual Network Interface (vNIC) for the VM and associates it with the vSwitch. The vNIC is presented to the VM as a physical network adapter. The communication channel between VM and vSwitch uses a synthetic data path Virtual Machine Bus (VMBus), which provides a standardized interface for VMs to access physical resources on the host machine. It helps ensure that virtual machines have consistent performance and can access resources in a secure and isolated manner.
Virtual Filtering Platform - VFP
A Virtual Filtering Platform (VFP) is Microsoft’s cloud-scale virtual switch operating as a virtual forwarding extension within a Hyper-V basic vSwitch. VFP sits in the data path between virtual ports facing the virtual machines and default vPort associated with physical NIC. VFP uses VM’s vPort-specific layers for filtering traffic to and from VM. A layer in the VFP is a Match-Action Table (MAT) containing policy rules programmed by independent, centralized controllers. The packet is processed through the VFP layers if it’s an exception packet, i.e., no Unified Flow entry (UF) in the Unified Flow Table (UFT), or if it’s the first packet of the flow (TCP SYN packet). When a Virtual Machine initiates a new connection, the first packet of the data flow is stored in the Received Queue (RxQ). The Parser component on VFP then takes the L2 (Ethernet), L3 (IP), and L4 (Protocol) header information as metadata, which is then processed through the layer policies in each VFP layer. The VFP layers involved in packet processing depend on the flow destination and the Azure services associated with the source/destination VM.
VNET-to-Internet traffic from with VM using a Public IP
The metering layer measures traffic for billing. It is the first layer for VM’s outgoing traffic and the last layer for incoming traffic, i.e., it processes only the original ingress/egress packets ignoring tunnel headers and other header modifications (Azure does not charge you for overhead bytes caused by the tunnel encapsulation). Next, the ACL layer runs the metadata through the NSG policy statements. If the source/destination IP addresses (L3 header group) and protocol, source/destination ports (L4 header group) match one of the allowing policy rules, the traffic is permitted (action#1: Allow). After ACL layer processing, the routing process intercepts the metadata. Because the destination IP address in the L3 header group matches only with the default route (0.0.0.0/0, next-hop Internet), the metadata is handed over to Server Load Balancing/Network Address Translation (SLB/NAT) layer. In this example, a public IP is associated with VM’s vNIC, so the SLB/NAT layer translates the private source IP to the public IP (action#2: Source NAT). The VNet layer is bypassed if both source and destination IP addresses are from the public IP space. When the metadata is processed by each layer, the results are programmed into the Unified Flow Table (UFT). Each flow is identified with a unique Unified Flow Identifier (UFID) - hash value calculated from the flow-based 5-tuple (source/destination IP, Protocol, Source Port, Destination Port). The UFID is also associated with the actions Allow and Source NAT. The Header Transposition (HT) engine then takes the original packet from the RxQ and modifies its L2/L3/L4 header groups as described in the UFT. It changes the source private IP to public IP (Modify) and moves the packet to TxQ. The subsequent packets of the flow are modified by the HT engine based on the existing UFT entry without running related metadata through the VFP layers (slow-path to fast-path switchover).
Besides the outbound flow entry, the VFP layer processes generate an inbound flow entry for the same connection but with reversed 5-tuple (source/destination addresses and protocol ports in reversed order) and actions (destination NAT instead of source NAT). These outbound and inbound flows are then paired and seen as a connection, enabling the Flow State Tracking process where inactive connections can be deleted from the UFT. For example, the Flow State Machine tracks the TCP RST flags. Let’s say that the destination endpoint sets the TCP RST flags to the L4 header. The TCP state machine notices it and removes the inbound flow together with its paired outbound flow from the UFT. Besides, the TCP state machine tracks the TCP FIN/FIN ACK flags and TIME_WAIT state (after TCP FIN. The connection is kept alive for max. 2 x Max Segment Lifetime to wait if there are delayed/retransmitted packets).
Intra-VNet traffic
The Metering and ACL layers on VFP process inbound/outbound flows for Intra-VNet connections in the same manner as VNet-Internet traffic. When the routing process notices that the destination Direct IP address (Customer Address space) is within the VNet CIDR range, the NAT layer is bypassed. The reason is that Intra-VNet flows use private Direct IP addresses as source and destination addresses. The Host Agent responsible for VNet layer operations, then examines the destination IP address from the L3 header group. Because this is the first packet of the flow, there is no information about the destination DIP-to-physical host mapping (location information) in the cache table. The VNet layer is responsible for providing tunnel headers to Intra-VNet traffic, so the Host Agent requests the location information from the centralized control plane. After getting the reply, it creates a MAT entry where the action part defines tunnel headers (push action). After the metadata is processed, the result is programmed into Unified Flow Table. As a result, the Header Transposition engine takes the original packet from the Received Queue, adds a tunnel header, and moves the packet to Transmit Queue.
Figure 1-1: Azure Host-Based SDN Building Blocks.
Meet Calico at KubeCon EU 2023!
KubeCon EU 2023 is happening from April 18-21 in Amsterdam. We are very excited to announce that Project Calico will be attending, so come meet us at booth #S28—we’ll be there from 10:30 am onwards!
Chat and learn
At the event, you’ll have an opportunity to meet our Project Calico team, collect cool Calico swags, and ask questions in person. Whether you’re an expert Kubernetes user or just getting started, the Project Calico community is here to provide guidance on best practices and help you get the most out of Calico. Here are some of the things you can learn at our booth:
- Simplified networking: Calico provides a simple, easy-to-use networking solution for Kubernetes. With Calico, you can easily set up and manage your network infrastructure without worrying about complex configurations or difficult networking concepts.
- Enhanced security: Security is a top priority for any Kubernetes and container environment, and Calico provides the tools you need to keep your applications safe. With Calico, you can enforce network policies, protect against DDoS attacks, and more.
- Scalability: Whether you’re running a small Kubernetes cluster or a large-scale deployment, Calico can scale to meet your needs.
- Open-source community: Built on open-source technologies, Project Calico Continue reading
What is Day 2 Network Operations and Why Do You Need It?
Now is the time for enterprises to take a deep hard look at how network operations is being executed and start looking into how automation can help.Day Two Cloud 187: The Back End Of Bear Blog With Herman Martinus
Today on Day Two Cloud we talk with developer Herman Martinus about his open-source blogging platform Bear. We talk about how a developer views infrastructure and operations, and how he went about building his platform.
The post Day Two Cloud 187: The Back End Of Bear Blog With Herman Martinus appeared first on Packet Pushers.
Day Two Cloud 187: The Back End Of Bear Blog With Herman Martinus
Today on Day Two Cloud we talk with developer Herman Martinus about his open-source blogging platform Bear. We talk about how a developer views infrastructure and operations, and how he went about building his platform.Hiding Behind MASQUEs
Privacy was a difficult topic for Internet protocols at the outset of the Internet. Things took a very different turn some 10 years ago following the disclosures of mass surveillence programs in the US, when the IETF declared that pervasive monitoring of users consititued at attack and Internet protocols needed to take measures to contain the way in which data was accessed in the network. The latest offerings in the area of improved privacy include Oblivious HTTP and MASQUE. Lets look at these approaches and the way that they attempt to contain the potential leakage of data.New: CD/CD in Networking Resource Page
Over the years I wrote a dozen blog posts describing various aspects of using CI/CD in network automation. These blog posts are now collected in the new CI/CD in Networking page that also includes links to related podcasts, webinars, and sample network automation solutions.
Full Stack Journey 076: Going Deep On Public Key Infrastructure
We all use certificates and certificate authorities every day, so in episode 76 Scott takes a deep dive on Public Key Infrastructure (PKI) with Linda Ikechuwku of Smallstep Labs. We discuss how PKI and certificates work, revocation options, pros and cons of DIY PKI, and more.
The post Full Stack Journey 076: Going Deep On Public Key Infrastructure appeared first on Packet Pushers.
Full Stack Journey 076: Going Deep On Public Key Infrastructure
We all use certificates and certificate authorities every day, so in episode 76 Scott takes a deep dive on Public Key Infrastructure (PKI) with Linda Ikechuwku of Smallstep Labs. We discuss how PKI and certificates work, revocation options, pros and cons of DIY PKI, and more.