Video: Intro to Real Life Network Automation
Urs Baumann invited me to have a guest lecture in his network automation course, and so I had the privilege of being in lovely Rapperswil last week, talking about the basics of real-life network automation.
Urs published the video recording of the presentation on YouTube; hope you’ll like it, and if you don’t get too annoyed by the overly pushy ads, watch the other videos from his infrastructure-as-code course.
Video: Intro to Real Life Network Automation
Urs Baumann invited me to have a guest lecture in his network automation course, and so I had the privilege of being in lovely Rapperswil last week, talking about the basics of real-life network automation.
Urs published the video recording of the presentation on YouTube; hope you’ll like it, and if you don’t get too annoyed by the overly pushy ads, watch the other videos from his infrastructure-as-code course.
KU050: CI/CD for Platform Engineering
CI/CD is not a villain. GitOps is not some kind of Kubernetes way of sneaking around it. In fact, GitOps falls under the CI/CD umbrella. Marcus Noble joins the show today to talk about how he uses a Kubernetes-native, open-source CI/CD framework called Tekton to test Kubernetes cluster creation, configuration, and deletion based on changes... Read more »History of SDN in Google’s datacentre
I recently read a very interesting post on LinkedIn in which Urs Hölzle, one of the original Google network engineers, celebrated twenty years of Google network innovation. He provided links to the recent paper from Google describing how Google developed its datacentre network and how it has evolved since then. The paper describes how Google applied the Clos network topology in its datacentres and the early implementations of software-defined-networking that controlled data flows across the network.
One point that was really interesting, which came up in the comments to the article, is that Google implemented the original network routing code in Python.
Mr. Hölzle also linked to an independant research report that came out at the time. It provided the initial view of what Google was developing and is interesting to read almost 20 years after it was written.
The post History of SDN in Google’s datacentre appeared first on Open-Source Routing and Network Simulation.
Hedge 217: Doug Madory and BGP Security Incidents
We hear a lot about BGP security incidents–but what is really going on? How often do these happen, and how much damage do they do? Doug Madory, who monitors these things for Kentik, joins Russ White and Tom Ammon to talk about BGP security in the wild.
Data Center Fabric Designs: Size Matters
The “should we use the same vendor for fabric spines and leaves?” discussion triggered the expected counterexamples. Here’s one:
I actually have worked with a few orgs that mix vendors at both spine and leaf layer. Can’t take names but they run fairly large streaming services. To me it seems like a play to avoid vendor lock-in, drive price points down and be in front of supply chain issues.
As always, one has to keep two things in mind:
Data Center Fabric Designs: Size Matters
The “should we use the same vendor for fabric spines and leaves?” discussion triggered the expected counterexamples. Here’s one:
I actually have worked with a few orgs that mix vendors at both spine and leaf layer. Can’t take names but they run fairly large streaming services. To me it seems like a play to avoid vendor lock-in, drive price points down and be in front of supply chain issues.
As always, one has to keep two things in mind:
NAN057: Nile Incorporates Network Automation from the Ground Up (Sponsored)
What if you could eliminate the burdens of networking without losing your control and visibility of the network? That’s the idea behind Nile. With Nile co-managing the network, you don’t have to spend all your time chasing down tickets, running patches, and dealing with CLI syntax. Instead you get to focus on higher level tasks... Read more »BGP AS Numbers for a Private MPLS/VPN Backbone
One of my readers was building a private MPLS/VPN backbone and wondered whether they should use their public AS number or a private AS number for the backbone. Usually, it doesn’t matter; the deciding point was the way they want to connect to the public Internet:
We also plan to peer with multiple external ISPs to advertise our public IP space not directly from our PE routers but from dedicated Internet Routers, adding a firewall between our PEs and external Internet routers.
They could either run BGP between the PE routers, firewall, and WAN routers (see BGP as High-Availability Protocol for more details) or run BGP across a bump-in-the-wire firewall:
BGP AS Numbers for a Private MPLS/VPN Backbone
One of my readers was building a private MPLS/VPN backbone and wondered whether they should use their public AS number or a private AS number for the backbone. Usually, it doesn’t matter; the deciding point was the way they want to connect to the public Internet:
We also plan to peer with multiple external ISPs to advertise our public IP space not directly from our PE routers but from dedicated Internet Routers, adding a firewall between our PEs and external Internet routers.
They could either run BGP between the PE routers, firewall, and WAN routers (see BGP as High-Availability Protocol for more details) or run BGP across a bump-in-the-wire firewall:
Adding IPv6-only to DNS and Truncation in UDP
We repeat the measurements of the behaviour of the DNS when processing truncated UDP responses, but this time we've constrained the measurement so that only IPv6-capable DNS resolvers are being measured. Does this make the results better or worse?Adding IPv6-only to DNS and Truncation in UDP
We repeat the measurements of the behaviour of the DNS when processing truncated UDP responses, but this time we've constrained the measurement so that only IPv6-capable DNS resolvers are being measured. Does this make the results better or worse?PP005: Red, Blue, Purple: Choosing the Right Teams for Security Testing and Defense
According to Bryson Bort, you can build higher metaphorical fences, electrify them, and have sharks with laser beams prowling the moat, but attackers are still going to get through the security perimeter. That’s why the priority of any IT team should be to identify anomalies and anticipate attack logic. To do this, organizations need to... Read more »How to Mitigate Shadow AI Security Risks by Implementing the Right Policies
Security has become even more paramount in every organization with growing popularity in AI created by a new phenomenon of ‘Shadow AI’ applications that need to be vetted against security policies.Adding TS’s IP Address to MAC-VRF (L2RIB) and IP-VRF (L3RIB)
In the previous chapter, we discussed how a VTEP learns the local TS's MAC address and the process through which the MAC address is programmed into BGP tables. An example VTEP device was configured with a Layer 2 VLAN and an EVPN Instance without deploying a VRF Context or VLAN routing interface. This chapter introduces, at a theoretical level, how the VTEP device, besides the TS's MAC address, learns the TS's IP address information after we have configured the VRF Context and routing interface for our example VLAN.
Figure 1-3: MAC-VRF Tenant System’s IP Address Propagation.
I have divided Figure 1-3 into three sections. The section on the top left, Integrated Routing and Bridging - IRB illustrates the components required for intra-tenant routing and their interdependencies. By configuring a Virtual Routing and Forwarding Context (VRF Context), we create a closed routing environment with a per-tenant IP-VRF L3 Routing Information Base (L3RIB). Within the VRF Context, we define the Layer 3 Virtual Network Identifier (L3VNI) along with the Route Distinguisher (RD) and Route Target (RT) values. The RD of the VRF Context enables the use of overlapping IP addresses across different tenants. Based on the RT value of the VRF Context, Continue reading
10 Steps to Choosing the Best SD-WAN Provider for Your Company
When evaluating SD-WAN providers, proceed with caution.OSPF Summarization and Split Areas
In the Do We Still Need OSPF Areas and Summarization? I wrote this somewhat cryptic remark:
The routers advertising a summarized prefix should be connected by a path going exclusively through the part of the network with more specific prefixes. GRE tunnel also satisfies that criteria; the proof is left as an exercise for the reader.
One of my readers asked for a lengthier explanation, so here we go. Imagine a network with two areas doing inter-area summarization on /24 boundary:
OSPF Summarization and Split Areas
In the Do We Still Need OSPF Areas and Summarization? I wrote this somewhat cryptic remark:
The routers advertising a summarized prefix should be connected by a path going exclusively through the part of the network with more specific prefixes. GRE tunnel also satisfies that criteria; the proof is left as an exercise for the reader.
One of my readers asked for a lengthier explanation, so here we go. Imagine a network with two areas doing inter-area summarization on /24 boundary: