Worth Reading: Things We Know about Network Queues
Every time someone tries to persuade you to buy (expensive) big-buffer data center switches, take an antidote: the Things we (finally) know about network queues article by Avery Pennarun.
HW023: The Best of WLPC 2024 Phoenix
The Wireless LAN Professionals organization just had its 10th annual conference and who better to break it down than WLPC founder (and Heavy Wireless host) Keith Parsons and friend of the show Ferney Munoz. They review their favorite presentations as well as heartwarming moments. Episode Guest Ferney Munoz | Ekahau and CWNP Certified Wireless Network... Read more »HN726: From Automation to Orchestration for a FinTech Network (Sponsored)
Fiserv is one of the largest payment processors in the world, In 2023 it handled more than 35 billion transactions worth $2.03 trillion US dollars. Its network is critical to the business. The organization knew it needed network automation, but early attempts got some things wrong. On today’s Heavy Networking we talk about how Fiserv... Read more »NaaS 2024: A Look at the Future of Network Services
As NaaS continues to evolve with AI, SDN, and industry-specific solutions, it is poised to shape the future of network services.Akamai to Deploy Advanced AI Across its Global Edge Network
With partner Neural Magic's software, potential user benefits may include lower latency, higher service levels, and faster response times.Public Videos: Routing Protocol Convergence
All Routing Protocol Convergence videos from the How Networks Really Work webinar are now public. Enjoy!
IPB147: The Network Engineering Advantages of IPv6
For years, Johannes Weber has heard network engineers around the world repeat the myth that IPv6 is more of a hassle than IPv4. So he made a list: “Why IPv6 is better than IPv4.” Don’t worry, solving global address exhaustion isn’t on it. In this episode, Johannes goes over his list with precision and passion... Read more »Signed but not secure
Signed but not secure
At the start of the year a very interesting (and some would say inevitable) event happened involving internet routing security, the first case study of a large-scale victim o
Embracing the Digital Wave: How Government is Transforming with Technology
The Technology Modernization Fund (TMF) has invested $800 million in technology initiatives to upgrade and modernize high-priority systems such as cybersecurity, public-facing digital services, and cross-government collaborations.KU051: Getting Under the Hood of Yellowbrick’s K8s Data Warehouse (Sponsored)
In this episode of the Kubernetes Unpacked Podcast, Kristina and Michael catch up with Mark from Yellowbrick to talk about all things underlying architecture. Very rarely do we get a vendor to chat about what’s going on underneath the hood and how a particular application stack/tool is running, so this was an awesome episode! Mark... Read more »Hedge 218: Longer than /24’s
Most providers will only accept a /24 or shorter IPv4 route because routers have always had limited amounts of forwarding table space. In fact, many hardware and software IPv4 forwarding implementations are optimized for a /24 or shorter prefix length. Justin Wilson joins Tom Ammon and Russ White to discuss why the DFZ might need to be expanded to longer prefix lengths, and the tradeoffs involved in doing so.
BGP Labs: Stop the Fat-Finger Incidents
Last time, we discussed the first line of defense against fat finger incidents: limiting the number of BGP prefixes your router accepts from a BGP neighbor. However, you can do much more without deploying customer-specific filters (which might require a customer database) or ROV/RPKI.
You can practice the default filters you should always deploy on EBGP sessions with your customers in the Stop the Propagation of Configuration Errors lab exercise.
BGP Labs: Stop the Fat-Finger Incidents
Last time, we discussed the first line of defense against fat finger incidents: limiting the number of BGP prefixes your router accepts from a BGP neighbor. However, you can do much more without deploying customer-specific filters (which might require a customer database) or ROV/RPKI.
You can practice the default filters you should always deploy on EBGP sessions with your customers in the Stop the Propagation of Configuration Errors lab exercise.
D2C237: Managing Medical IoT Devices on AWS
In this podcast episode, Randy Horton from Orthogonal and Ian Sutcliffe from AWS discuss the complexities of supporting regulated medical devices in the cloud. They explore the challenges of adhering to regulations, the importance of security, and the need for robust frameworks. The conversation highlights the non-prescriptive nature of regulations, encouraging best practices rather than... Read more »Bring Network and Security Teams Together by Asking the Right Questions
Finding the balance point of performance and security that best serves the organization can only be done when both the networking and security teams work together.NAN058: The Story of containerlab with Roman Dodin (Part 2)
Welcome back for Part 2 of Eric’s interview with Roman Dodin, co-creator of containerlab. Roman describes containerlab as a “lab as code” tool that quickly and easily creates virtual networking topologies. With increased automation and containerization in network engineering, the tool’s popularity has exploded. We talk about how folks contribute to containerlab’s development and what... Read more »Nile Bets on AI Networking with Performance Guarantees
Nile offers consumption-based pricing, masks all the legacy complexity of operating a network, and makes use of AI to bring the benefits of the cloud delivery model to the network.How Anycast VTEP Broke My Lab And What I Learned
I’m preparing a massive blog post on vPC in the context of VXLAN/EVPN and while doing so I accidentally broke my lab. What a great learning experience! I thought I would share it with you and how to perform troubleshooting of this scenario.
My topology looks like this:
Before I made any changes, there was full connectivity between these hosts, meaning that both bridging and routing was working. I then changed the loopback1 (NVE source interface) configuration of Leaf-1 and Leaf-2 to add a secondary IP. This was the initial configuration:
! Leaf-1 interface loopback1 description VTEP ip address 203.0.113.1/32 ip router ospf UNDERLAY area 0.0.0.0 ip pim sparse-mode ! Leaf-2 interface loopback1 description VTEP ip address 203.0.113.2/32 ip router ospf UNDERLAY area 0.0.0.0 ip pim sparse-mode
This then changed to:
! Leaf-1 interface loopback1 description VTEP ip address 203.0.113.1/32 ip address 203.0.113.12/32 secondary ip router ospf UNDERLAY area 0.0.0.0 ip pim sparse-mode ! Leaf-2 interface loopback1 description VTEP ip address 203.0.113.2/32 ip address 203.0.113.12/32 secondary ip router ospf UNDERLAY area 0.0.0.0 ip pim Continue reading
FRRouting RIB and FIB
This is how we described the interactions between routing protocol tables, RIB, and FIB in the ancient times:
- Routing protocols compute the best paths to all known prefixes.
- These paths compete for entry in the routing table. The path(s) with the lowest administrative distance win.
- The entries from the routing table are fully evaluated (in particular, their next hops) and entered in the forwarding table.
Let’s use a simple BGP+OSPF network to illustrate what I’m talking about: