I had the Italian version of the book since the days I was running SDN workshops with Tiziano in Rome, and it’s really nice to see they finally decided to address a wider market.
Also, you know what would go well with that book? Free open-source BGP configuration labs of course 😉
You can use any device that is supported by bgp.session and bgp.policy plugins as the external BGP router. You could use Arista EOS, Aruba AOS-CX, Cisco IOSv, Cisco IOS-XE, Cumulus Linux or FRR as external BGP routers with netlab release 1.6.4, and I’m positive Jeroen van Bemmel will add Nokia SR Linux to that list.
If you’re not ready for a netlab upgrade, you can keep using Cumulus Linux as external BGP routers (I’ll explain the behind-the-scenes magic in another blog post, I’m at the Deep Conference this week).
For more details read the updated BGP Labs Software Installation and Lab Setup guide.
I’ll be talking about Internet routing security at the Deep conference in a few days, and just in case you won’t be able to make it1 ;) here’s the first bit of my talk: a very brief history of BGP route leaks2.
After going through the BGP basics, it’s time to build a network that has more than one BGP router in it, starting with the simplest possible topology: a site with two WAN edge routers.
TL&DR: Violating the Betteridge’s Law of Headlines, the answer is “Yes, but the devil is in the details.”
It all started with the following observation by Minh Ha left as a comment to my previous BGP session security blog post:
I’d think it’d be obvious for BGP routers to only accept incoming sessions from configured BGP neighbors, right? Because BGP is the most critical infrastructure, the backbone of the Internet, why would you want your router to accept incoming session from anyone but KNOWN sources?
Following my “opinions are good, facts are better” mantra, I decided to run a few tests before opinionating1.
A few days after I published the EBGP session protection lab, Jeroen van Bemmel submitted a pull request that added TCP-AO support to netlab. Now that the release 1.6.3 is out, I could use it to build the Protect BGP Sessions with TCP Authentication Option (TCP-AO) lab exercise.
In the BGP Route Aggregation lab you can practice:
- OSPF-to-BGP route redistribution
- BGP route aggregation
- Suppression of more-specific prefixes in the BGP table
- Prefix-based filtering of outbound BGP updates
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.
In the next BGP labs exercise you can practice tweaking BGP timers and using BFD to speed up BGP convergence.
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. ↩︎
In the next BGP labs exercise you’ll build the customer part of an MPLS/VPN solution. You’ll use bidirectional OSPF-to-BGP route redistribution to connect two sites running OSPF over a Service Provider MPLS backbone.
Talking about BGP routing policy mechanisms is nice, but it’s even better to see how real Internet Service Providers use those tools to implement real-life BGP routing policy.
Getting that information is incredibly hard as everyone considers their setup a secret sauce. Fortunately, there are a few exceptions; Pim van Pelt described the BGP Routing Policy of IPng Networks in great details. The article is even more interesting as he’s using Bird2 configuration language that looks almost like a programming language (as compared to the ancient route-maps used by vendors focused on “industry-standard” CLI).
- Use BGP weights to prefer one of the upstream providers
- Prevent route leaking between upstream providers with an AS-path filter
- Filter prefixes advertised by your autonomous system with a prefix list
- Minimize the size of your BGP table with inbound filters
The labs are best used with netlab (it supports BGP on almost 20 different devices), but you could use any system you like (including GNS3 and CML/VIRL). If you’re stubborn enough it’s possible to make them work with the physical gear, but don’t ask me for help. For more details, read the Installation and Setup documentation.
- Configuring an EBGP session
- Connecting to multiple upstream ISPs
- Advertise your prefixes
- Configure BGP for IPv6
The labs are supposed to be run on virtual devices, but if you’re stubborn enough it’s possible to make them work with the physical gear. In theory, you could use any system you like to set up the virtual lab (including GNS3 and CML/VIRL), but your life will be way easier if you use netlab – it supports BGP on almost 20 different devices. For more details, read the Installation and Setup documentation.
Approximately 30 years ago I managed to persuade the powers-that-be within Cisco’s European training organization that they needed a deep-dive BGP course, resulting in a 3 (later 5) day Advanced BGP Configuration and Troubleshooting (ABCT) course1. I was delivering that course for close to a decade, and gradually built a decent story explaining the reasoning and use cases behind most of (then available) BGP features, from simple EBGP sessions to BGP route reflectors and communities2.
Now imagine having more than a dozen hands-on labs that go with the “BGP from rookie to hero” story available for any platform of your choice3. I plan to make that work (eventually) as an open-source project that you’ll be able to download and run free-of-charge.