The first BGP labs are online. They cover the basic stuff (one has to start with the basics, right?):

• 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.

The first set of BGP labs covered the basics, the next four will help you master simple routing policy tools (BGP weights, AS-path filters, prefix filters) using real-life examples:

• 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.

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.

I would strongly recommend to run labs with netlab, but if you like extra work, feel free to use any system you like including physical hardware.

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 checksums¹.

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.

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.

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

Note: if you want to keep things simple, run BGP labs with netlab (other options).

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.

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.

A quick update BGP Labs project status update: now that netlab release 1.6.4 is out I could remove the dependency on using Cumulus Linux as the external BGP router.

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.

Last time we built a network with two adjacent BGP routers. Now let’s see what happens when we add a core router between them:

A while ago we used BGP weights to select the best link out of an autonomous system. In this lab we’ll use BGP local preference to implement a consistent network-wide routing policy:

In the previous labs, we used BGP weights and Local Preference to select the best link out of an autonomous system and thus change the outgoing traffic flow.

Most edge (end-customer) networks face a different problem – they want to influence the incoming traffic flow, and one of the tools they can use is BGP Multi-Exit Discriminator (MED).

In the previous lab, you learned how to use BGP Multi-Exit Discriminator (MED) to influence incoming traffic flow. Unfortunately, MED works only with parallel links to the same network. In a typical Redundant Internet Connectivity scenario, you want to have links to two ISPs, so you need a bigger hammer: AS Path Prepending.

It’s hard to influence the behavior of someone with strong opinions (just ask any parent with a screaming toddler), and trying to persuade an upstream ISP not to send the traffic over a backup link is no exception – sometimes even AS path prepending is not a strong enough argument.

An easy solution to this problem was proposed in 1990s – what if we could attach some extra attributes (called communities just to confuse everyone) to BGP updates and use them to tell adjacent autonomous systems to lower their BGP local preference? You can practice doing that in the Attach BGP Communities to Outgoing BGP Updates lab exercise.

In the previous BGP labs, we built a network with two adjacent BGP routers and a larger transit network using IBGP. Now let’s make our transit network scalable with BGP route reflectors, this time using a slightly larger network: