BGP Session Security: Be Very Skeptical
A while ago I explained how Generalized TTL Security Mechanism could be used to prevent denial-of-service attacks on routers running EBGP. Considering the results published in Analyzing the Security of BGP Message Parsing presentation from DEFCON 31 I started wondering how well GTSM implementations work.
TL&DR summary:
Worth Reading: Flow Distribution Across ECMP Paths
Dip Singh wrote another interesting article describing how ECMP load balancing implementations work behind the scenes. Absolutely worth reading.
Worth Reading: Flow Distribution Across ECMP Paths
Dip Singh wrote another interesting article describing how ECMP load balancing implementations work behind the scenes. Absolutely worth reading.
Worth Reading: Single-Port LAGs
Lindsay Hill described an excellent idea: all ports on your switches routers should be in link aggregation groups even when you have a single port in a group. That approach allows you to:
- Upgrade the link speed without changing any layer-3 configuration
- Do link maintenance without causing a routing protocol flap
It also proves RFC 1925 rule 6a, but then I guess we’re already used to that ;)
Worth Reading: Single-Port LAGs
Lindsay Hill described an excellent idea: all ports on your switches routers should be in link aggregation groups even when you have a single port in a group. That approach allows you to:
- Upgrade the link speed without changing any layer-3 configuration
- Do link maintenance without causing a routing protocol flap
It also proves RFC 1925 rule 6a, but then I guess we’re already used to that ;)
How GitHub Saved My Day
I always tell networking engineers who aspire to be more than VLAN-munging CLI jockeys to get fluent with Git. I should also be telling them that while doing local version control is the right thing to do, you should always have backups (in this case, a remote repository).
I’m eating my own dog food1 – I’m using a half dozen Git repositories in ipSpace.net production2. If they break, my blog stops working, and I cannot publish new documents3.
Now for a fun fact: Git is not transactionally consistent.
How GitHub Saved My Day
I always tell networking engineers who aspire to be more than VLAN-munging CLI jockeys to get fluent with Git. I should also be telling them that while doing local version control is the right thing to do, you should always have backups (in this case, a remote repository).
I’m eating my own dog food1 – I’m using a half dozen Git repositories in ipSpace.net production2. If they break, my blog stops working, and I cannot publish new documents3.
Now for a fun fact: Git is not transactionally consistent.
BGP Labs: Use BFD to Speed Up Convergence
In the next BGP labs exercise you can practice tweaking BGP timers and using BFD to speed up BGP convergence.
I would strongly recommend using netlab to run BGP labs, but if you insist you can use any system you like including physical hardware.
BGP Labs: Use BFD to Speed Up Convergence
In the next BGP labs exercise, you can practice tweaking BGP timers and using BFD to speed up BGP convergence.
Why Do We Need Source IP Addresses in IP Headers?
After discussing names, addresses and routes, and the various addresses we might need in a networking stack, we’re ready to tackle an interesting comment made by a Twitter user as a reply to my Why Is Source Address Validation Still a Problem? blog post:
Maybe the question we should be asking is why there is a source address in the packet header at all.
Most consumers of network services expect a two-way communication – you send some stuff to another node providing an interesting service, and you usually expect to get some stuff back. So far so good. Now for the fun part: how does the server know where to send the stuff back to? There are two possible answers1:
Why Do We Need Source IP Addresses in IP Headers?
After discussing names, addresses and routes, and the various addresses we might need in a networking stack, we’re ready to tackle an interesting comment made by a Twitter user as a reply to my Why Is Source Address Validation Still a Problem? blog post:
Maybe the question we should be asking is why there is a source address in the packet header at all.
Most consumers of network services expect a two-way communication – you send some stuff to another node providing an interesting service, and you usually expect to get some stuff back. So far so good. Now for the fun part: how does the server know where to send the stuff back to? There are two possible answers1:
Does EVPN/VXLAN over SD-WAN Make Sense?
It looks like we might be seeing VXLAN-over-SDWAN deployments in the wild. Here’s the “why that makes sense” argument I received from a participant of the ipSpace.net Design Clinic in which I wasn’t exactly enthusiastic about the idea.
Also, the EVPN-over-WAN idea is not hypothetical since EVPN+VXLAN is now the easiest way to build L3VPN with data center switches that don’t support MPLS LDP. Folks with no interest in EVPN’s L2 features are still using it for L3VPN.
Let’s unravel this scenario a bit:
Does EVPN/VXLAN over SD-WAN Make Sense?
It looks like we might be seeing VXLAN-over-SDWAN deployments in the wild. Here’s the “why that makes sense” argument I received from a participant of the ipSpace.net Design Clinic in which I wasn’t exactly enthusiastic about the idea.
Also, the EVPN-over-WAN idea is not hypothetical since EVPN+VXLAN is now the easiest way to build L3VPN with data center switches that don’t support MPLS LDP. Folks with no interest in EVPN’s L2 features are still using it for L3VPN.
Let’s unravel this scenario a bit:
Repost: L2 Is Bad
Roman Pomazanov documented his thoughts on the beauties of large layer-2 domains in a LinkedIn article and allowed me to repost it on ipSpace.net blog to ensure it doesn’t disappear
First of all: “L2 is a single failure domain”, a problem at one point can easily spread to the entire datacenter.
Repost: L2 Is Bad
Roman Pomazanov documented his thoughts on the beauties of large layer-2 domains in a LinkedIn article and allowed me to repost it on ipSpace.net blog to ensure it doesn’t disappear
First of all: “L2 is a single failure domain”, a problem at one point can easily spread to the entire datacenter.
BGP Labs: Protect EBGP Sessions
I published another BGP labs exercise a few days ago. You can use it to practice EBGP session protection, including Generalized TTL Security Mechanism (GTSM) and TCP MD5 checksums1.
I would strongly recommend to run BGP labs with netlab, but if you like extra work, feel free to use any system you like including physical hardware.
-
I would love to add TCP-AO to the mix, but it’s not yet supported by the Linux kernel, and so cannot be used in Cumulus Linux or FRR containers. ↩︎
BGP Labs: Protect EBGP Sessions
I published another BGP labs exercise a few days ago. You can use it to practice EBGP session protection, including Generalized TTL Security Mechanism (GTSM) and TCP MD5 checksums1.
-
I would love to add TCP-AO to the mix, but it’s not yet supported by the Linux kernel, and so cannot be used in Cumulus Linux or FRR containers. ↩︎
Addresses in a Networking Stack
After discussing names, addresses and routes, it’s time for the next question: what kinds of addresses do we need to make things work?
End-users (clients) are usually interested in a single thing: they want to reach the service they want to use. They don’t care about nodes, links, or anything else.
End-users might want to use friendly service names, but we already know we need addresses to make things work. We need application level service identifiers – something that identifies the services that the clients want to reach.
Addresses in a Networking Stack
After discussing names, addresses and routes, it’s time for the next question: what kinds of addresses do we need to make things work?
End-users (clients) are usually interested in a single thing: they want to reach the service they want to use. They don’t care about nodes, links, or anything else.
End-users might want to use friendly service names, but we already know we need addresses to make things work. We need application level service identifiers – something that identifies the services that the clients want to reach.
Names, Addresses and Routes
It always helps to figure out the challenges of a problem you’re planning to solve, and to have a well-defined terminology. This blog post will mention a few challenges we might encounter while addressing various layers of the networking stack, from data-link layer and all the way up to the application layer, and introduce the concepts of names, addresses and routes.
According to Martin Fowler, one of the best quotes I found on the topic originally came from Phil Karlton: