When I published the Bidirectional Route Redistribution lab exercise, some readers were quick to point out that you’ll probably have to reuse the same AS number across multiple sites in a real-life MPLS/VPN deployment. That’s what you can practice in today’s lab exercise – an MPLS/VPN service provider allocated the same BGP AS number to all your sites and expects you to deal with the aftermath.
When I published the Bidirectional Route Redistribution lab exercise, some readers were quick to point out that you’ll probably have to reuse the same AS number across multiple sites in a real-life MPLS/VPN deployment. That’s what you can practice in today’s lab exercise – an MPLS/VPN service provider allocated the same BGP AS number to all your sites and expects you to deal with the aftermath.
One of the roles of Cloudflare's Observability Platform team is managing the operation, improvement, and maintenance of our internal logging pipelines. These pipelines are used to ship debugging logs from every service across Cloudflare’s infrastructure into a centralised location, allowing our engineers to operate and debug their services in near real time. In this post, we’re going to go over what that looks like, how we achieve high availability, and how we meet our Service Level Objectives (SLOs) while shipping close to a million log lines per second.
Logging itself is a simple concept. Virtually every programmer has written a Hello, World! program at some point. Printing something to the console like that is logging, whether intentional or not.
Logging pipelines have been around since the beginning of computing itself. Starting with putting string lines in a file, or simply in memory, our industry quickly outgrew the concept of each machine in the network having its own logs. To centralise logging, and to provide scaling beyond a single machine, we invented protocols such as the BSD Syslog Protocol to provide a method for individual machines to send logs over the network to a collector, providing a single pane of glass Continue reading
In the last post Advertising IPs In EVPN Route Type 2, I described how to get IPs advertised in EVPN route type 2, but why do we need it? There are three main scenarios where having the MAC/IP mapping is useful:
In this post I will cover the first use case and the topology below will be used:
When two hosts in the same subnet want to send Ethernet frames to each other, they will ARP to discover the MAC address of the other host. This is no different in a VXLAN/EVPN network. The ARP frame, which is broadcast, will have to be flooded to other VTEPs either using multicast in the underlay or by ingress replication. Because the frame is broadcast, it will have to go to all the VTEPs that have that VNI. The scenario with ingress replication is shown below:
In this scenario, SERVER-1 is sending an ARP request to get the MAC address of SERVER-4. As all leafs are participating in the L2 VNI, LEAF-1 will perform ingress replication and send it to all leafs. However, sending the ARP request to LEAF-2 and LEAF-3 is not needed Continue reading
This LinkedIn snippet just came in from the someone is not exactly right on the Internet department:
Unlike IGP protocols, BGP is not dependent on a single type of metric to choose the best path.
EIGRP is an immediate counterexample that brought the above quote to my attention, but it’s worth exploring the topic in more detail.
This LinkedIn snippet just came in from the someone is not exactly right on the Internet department:
Unlike IGP protocols, BGP is not dependent on a single type of metric to choose the best path.
EIGRP is an immediate counterexample that brought the above quote to my attention, but it’s worth exploring the topic in more detail.
Much like a previous talk of mine at Chaos Computer Congress this blog post is a direct write-up of a talk, if you prefer to consume this kind
https://codingpackets.com/blog/aws-advanced-networking-speciality
Investment in supercomputing and related HPC technologies is not just a sign of how much we are willing to bet on the future with someone else’s money, but how much we believe in it ourselves, and more importantly, how much we believe in the core idea that we can predict and therefore shape the future of the world. …
The post The Future We Simulate Is The One We Create first appeared on The Next Platform.
The Future We Simulate Is The One We Create was written by Timothy Prickett Morgan at The Next Platform.
We talk with network architects and engineers at NewYork-Presbyterian Hospital about their automation strategy for mission-critical networks that support patient care. We explore the automation progress they've made, long-term goals, technical and cultural challenges, what they'd like to see from vendors, and more.
The post HN715: Prescribing The Right Dose Of Automation For A Hospital Network appeared first on Packet Pushers.
Welcome to Technology Short Take #172, the first Technology Short Take of 2024! This one is really short, which I’m assuming reflects a lack of blogging activity over the 2023 holiday season. Nevertheless, I have managed to scrape together a few links to share with readers. As usual, I hope you find something useful. Enjoy!
One of the delightful side effects of leaving the paid content business is that I no longer have to try to persuade anyone that my content is any good. That includes the “this video is now public” announcements – instead of elaborate introductions, I’ll just publish a short blog post with the links.
As of today, these videos (along with dozens of previously-released videos) from the Routing Protocols section of the How Networks Really Work webinar are no longer behind a login wall:
