While preparing the Internet Routing Security webinar, I stumbled upon RFC 7908, containing an excellent taxonomy of BGP route leaks. I never checked whether it covers every possible scenario1, but I found it a handy resource when organizing my thoughts.
Let’s walk through the various leak types the authors identified using the following sample topology:
Stefano Sasso added two new Junos platforms in netlab release 1.5.4:
There are also the usual bug fixes, and we moved the documentation to netlab.tools.
Stefano Sasso added two new Junos platforms in netlab release 1.5.4:
There are also the usual bug fixes, and we moved the documentation to netlab.tools.
Large language models (LLM) – ChatGPT and friends – are one of those technologies with a crazy learning curve. They look simple and friendly (resulting in plenty of useless demoware) but become devilishly hard to work with once you try to squeeze consistent value out of them.
Most people don’t want to talk about the hard stuff (sexy demoware results in more page views), but there’s an occasional exception, for example All the Hard Stuff Nobody Talks About when Building Products with LLMs describing all the gotchas Honeycomb engineers discovered when creating a LLM-based user interface.
Large language models (LLM) – ChatGPT and friends – are one of those technologies with a crazy learning curve. They look simple and friendly (resulting in plenty of useless demoware) but become devilishly hard to work with once you try to squeeze consistent value out of them.
Most people don’t want to talk about the hard stuff (sexy demoware results in more page views), but there’s an occasional exception, for example All the Hard Stuff Nobody Talks About when Building Products with LLMs describing all the gotchas Honeycomb engineers discovered when creating a LLM-based user interface.
Security researches found another ICMP redirect SNAFU: a malicious wireless client can send redirects on behalf of the access point redirecting another client’s traffic to itself.
I’m pretty sure the same trick works on any layer-2 technology; the sad part of this particular story is that the spoofed ICMP packet traverses the access point, which could figure out what’s going on and drop the packet. Unfortunately, most of the access points the researchers tested were unable to do that due to limitations in the NPUs (a fancier word for SmartNIC) they were using.
Security researches found another ICMP redirect SNAFU: a malicious wireless client can send redirects on behalf of the access point redirecting another client’s traffic to itself.
I’m pretty sure the same trick works on any layer-2 technology; the sad part of this particular story is that the spoofed ICMP packet traverses the access point, which could figure out what’s going on and drop the packet. Unfortunately, most of the access points the researchers tested were unable to do that due to limitations in the NPUs (a fancier word for SmartNIC) they were using.
After discussing the backend and CPE architecture in a typical SD-WAN solution in the SD-WAN Overview webinar, Pradosh Mohapatra mentioned a few SD-WAN security aspects, focusing on typical attack vectors and the usual mitigations.
After discussing the backend and CPE architecture in a typical SD-WAN solution in the SD-WAN Overview webinar, Pradosh Mohapatra mentioned a few SD-WAN security aspects, focusing on typical attack vectors and the usual mitigations.
Got this question from a networking engineer attending the Building Next-Generation Data Center online course:
Has anyone an advice on LACP fast rate? When and why should you use it instead of normal LACP?
Apart from forming link aggregation groups, you can use LACP to detect link- and node failures (more details). However:
Got this question from a networking engineer attending the Building Next-Generation Data Center online course:
Has anyone an advice on LACP fast rate? When and why should you use it instead of normal LACP?
Apart from forming link aggregation groups, you can use LACP to detect link- and node failures (more details). However:
Distributed systems are complicated. Add networking to the mix, and you get traumatic challenges like the CAP theorem and Byzantine fault tolerance. Most of those challenges are unknown to engineers who have to suffer through the vendor marketing presentations, making it hard to determine whether the latest shiny gizmo works outside of PowerPoint.
I started collecting articles describing distributed-system gotchas years ago, wrote numerous blog posts on the topic in the heydays of the SDN Will Save the World lemming run, and organized them into the Distributed Systems Resources page.
Distributed systems are complicated. Add networking to the mix, and you get traumatic challenges like the CAP theorem and Byzantine fault tolerance. Most of those challenges are unknown to engineers who have to suffer through the vendor marketing presentations, making it hard to determine whether the latest shiny gizmo works outside of PowerPoint.
I started collecting articles describing distributed-system gotchas years ago, wrote numerous blog posts on the topic in the heydays of the SDN Will Save the World lemming run, and organized them into the Distributed Systems Resources page.
EIGRP routing updates have always contained the next hop field (similar to BGP updates), which was unused until Cisco IOS release 12.3 when the no ip next-hop-self eigrp AS-number interface configuration command was implemented.
EIGRP does not set the next hop field by default. An EIGRP router receiving a routing update thus assumes that the next hop of the received routes is the sending router. This behavior usually works well, but prevents site-to-site shortcuts to be established in DMVPN networks, and results in suboptimal routing in some route redistribution scenarios.
EIGRP routing updates have always contained the next hop field (similar to BGP updates), which was unused until Cisco IOS release 12.3 when the no ip next-hop-self eigrp AS-number interface configuration command was implemented.
EIGRP does not set the next hop field by default. An EIGRP router receiving a routing update thus assumes that the next hop of the received routes is the sending router. This behavior usually works well, but prevents site-to-site shortcuts to be established in DMVPN networks, and results in suboptimal routing in some route redistribution scenarios.
One of the most common causes of Internet routing leaks is an undereducated end-customer configuring EBGP sessions with two (or more) upstream ISPs.
Without basic-level BGP knowledge or further guidance from the service providers, the customer network engineer1 might start a BGP routing process and configure two EBGP sessions, similar to the following industry-standard CLI2 configuration:
One of the most common causes of Internet routing leaks is an undereducated end-customer configuring EBGP sessions with two (or more) upstream ISPs.
Without basic-level BGP knowledge or further guidance from the service providers, the customer network engineer1 might start a BGP routing process and configure two EBGP sessions, similar to the following industry-standard CLI2 configuration:
Brandon Hitzel published a detailed document describing various Internet WAN edge designs. Definitely worth reading and bookmarking.
Brandon Hitzel published a detailed document describing various Internet WAN edge designs. Definitely worth reading and bookmarking.
Another phenomenal detective story published on Cloudflare blog: Unbounded memory usage by TCP for receive buffers, and how we fixed it.
TL&DR: Moving TCP window every time you acknowledge a segment doesn’t work well with scaled window sizes.
The interesting takeaways: