Attach BGP Communities to Outgoing BGP Updates

In previous lab exercises, you figured out how to nudge an adjacent network to prefer one of the links with the Multi-Exit Discriminator attribute, and how to push a bit harder with AS path prepending. Sometimes, more than that is needed, and in this lab exercise, you’ll have to deal with a scenario in which a Service Provider routing policy interferes strongly with your intentions.

You have two sites. One is connected to two Service Providers (ISP-1 and ISP-2), and the other has only one uplink (to ISP-2). The link from Site-1 to ISP-1 is significantly faster than the alternate link, and you’d like to use it exclusively. The traffic from Site-2 to Site-1 should therefore flow through ISP-2 and ISP-1 (C2→X2→X1→C1)

In this lab, you’ll try to influence the Service Provider route selection with AS path prepending and use BGP communities to tell them what changes you’d like them to make to their routing policy.

Lab topology

Initial Router Configurations

The routers in your lab use the following BGP AS numbers. Each autonomous system advertises an IPv4 prefix.

Node/ASN Router ID Advertised prefixes
AS65000
c1 10.0.0.1 192.168.42.0/24
AS65001
c2 10.0.0.2 192.168.37.0/24
AS65207
x1 10.0.0.10 172.17.207.0/24
AS65304
x2 10.0.0.11 172.23.4.0/24

Your routers have these BGP neighbors:

Node Router ID /
Neighbor		 Router AS/
Neighbor AS		 Neighbor IPv4
c1 10.0.0.1 65000
x1 65207 10.1.0.2
x2 65304 10.1.0.6
c2 10.0.0.2 65001
x2 65304 10.1.0.14

Start the Lab

Assuming you already set up your lab infrastructure:

Note: netlab will configure IP addressing, BGP, EBGP sessions, and BGP prefix advertisements on your routers. If you’re not using netlab, you must configure your routers manually.

Warning

This lab requires additional configuration on X2. That configuration is currently available only for Arista EOS, Cumulus Linux, and FRR – you have to use one of those devices as the external BGP router(s).

Default Traffic Flow

After starting the lab, log into C2 and examine its BGP table, looking for prefixes advertised by C1. You should get a printout similar to this one (generated on Arista cEOS)1:

c2>show ip bgp | include 192.168.42.0
 * >      192.168.42.0/24        10.1.0.14             0       -          100     0       65304 65000 ?

As you can see, X2 decided to reach AS 65100 over the direct link. Let’s fix that with AS path prepending.

Configure AS Path Prepending

X2 might select the path through X1 as the best path toward Site-1 (AS 65100) if you inject enough copies of your AS number into the BGP updates C1 sends to X2. Following the procedure outlined in the Use AS-Path Prepending to Influence Incoming Traffic Flow exercise, extend the AS path of the prefixes C1 sends to X2. If that doesn’t work, prepend more copies of your AS to the AS path.

Eventually, you’ll figure out that no amount of prepending fixes the problem. X2 stubbornly uses the direct path to Site-1 (X2-C1) even if you prepend many copies of 65000 to the AS path. Here’s the relevant printout from C2:

c2>show ip bgp | include 192.168.42.0
 * >      192.168.42.0/24        10.1.0.14             0       -          100     0       65304 65000 65000 65000 65000 65000 65000 65000 65000 ?

BGP Communities to the Rescue

It’s time to give up and give ISP-2 a call. After enjoying the on-hold music for too long and going through too many escalation steps, you might find someone who understands what you’re trying to do, pointing you to an online document describing how ISP-2 uses BGP communities. That document might contain a description along these lines2:

All customer routes received by ISP-2 are assigned a local preference 200. Customers can alter this local preference using the following BGP communities:

Community Local Pref Effect
65304:102 190 Used for customer backup when multi-homed to ISP-2
65304:101 100 Sets local preference equal to transit routes
65304:100 50 Lowest possible value. Used for backup when multi-homed to multiple providers

It looks like your woes could be fixed by using community 65304:100. Here’s what you have to do:

  • You already created a routing policy on C1 to implement AS path prepending. If you skipped that step, create a new routing policy (often called a route map) on C1. You have already used routing policies in previous lab exercises and should be familiar with them.
  • In the routing policy, set the BGP community to 65304:100
  • Attach the routing policy to outgoing updates C1 sends to X2.
  • If needed, configure BGP community propagation on C1 with a BGP configuration command similar to neighbor address send-community.

Warning

  • Many BGP implementations strip BGP communities from outgoing BGP updates by default. Your routing policy might be perfect, but it will only affect the EBGP updates if you configure BGP community propagation. Even worse, if you use a command like show ip bgp neighbor address advertised-routes prefix, it might not show the BGP community3, leading you to the conclusion that your routing policy might be broken.
  • Applying routing policy parameters to BGP neighbors doesn’t necessarily change the BGP table, as the new routing policy might be evaluated only on new incoming updates. You might have to use a command similar to clear ip bgp * soft to tell your router to resend BGP updates to its neighbors.

Verification

Reexamine the BGP table on C2. If you did everything right, you’d see that X2 changed its mind and now advertises the path through X1 (AS 65207) as the best path:

c2>show ip bgp | include 192.168.42.0
 * >      192.168.42.0/24        10.1.0.14             0       -          100     0       65304 65207 65000 ?

Want to know how the magic works behind the scenes? Log into X2 and inspect its BGP table. This is how you would do it on Cumulus Linux4 (this command also comes in handy if you did something wrong and have to figure out what’s going on):

$ netlab connect x2 vtysh -c 'show ip bgp 192.168.42.0'
Connecting to container clab-a_community-x2, executing vtysh -c "show ip bgp 192.168.42.0"
BGP routing table entry for 192.168.42.0/24
Paths: (2 available, best #2, table default)
  Advertised to non peer-group peers:
  10.1.0.5 x1(10.1.0.9) 10.1.0.13
  65000 65000 65000 65000 65000 65000 65000 65000
    10.1.0.5 from 10.1.0.5 (10.0.0.1)
      Origin incomplete, localpref 50, valid, external, bestpath-from-AS 65000
      Community: 65304:100
      Last update: Sat Nov 11 08:42:42 2023
  65207 65000
    10.1.0.9 from x1(10.1.0.9) (10.0.0.10)
      Origin incomplete, valid, external, bestpath-from-AS 65207, best (Local Pref)
      Last update: Sat Nov 11 08:41:49 2023

Next:

Reference Information

This lab uses the 4-router lab topology. Some links are unused to retain the interface names from that topology.

The following information might help you if you plan to build custom lab infrastructure:

Device Requirements

Lab Wiring

Link Name Origin Device Origin Port Destination Device Destination Port
Primary uplink c1 Ethernet1 x1 swp1
Backup uplink c1 Ethernet2 x2 swp1
Inter-ISP link x1 swp2 x2 swp2
Unused link c2 Ethernet1 x1 swp3
Site 2, uplink 2 c2 Ethernet2 x2 swp3

Lab Addressing

Node/Interface IPv4 Address IPv6 Address Description
c1 10.0.0.1/32 Loopback
Ethernet1 10.1.0.1/30 Primary uplink
Ethernet2 10.1.0.5/30 Backup uplink
c2 10.0.0.2/32 Loopback
Ethernet1 Unused link
Ethernet2 10.1.0.13/30 Site 2 uplink
x1 172.17.207.1/24 Loopback
swp1 10.1.0.2/30 Primary uplink
swp2 10.1.0.9/30 Inter-ISP link
swp3 Unused link
x2 172.23.4.1/24 Loopback
swp1 10.1.0.6/30 Backup uplink
swp2 10.1.0.10/30 Inter-ISP link
swp3 10.1.0.14/30 Site 2 uplink

  1. I’m using the concise printout of the BGP table (show ip bgp) with an output filter to reduce the amount of information you have to sift through. You could also use a command similar to show ip bgp 192.168.42.0 ↩

  2. Based on an actual ISP document ↩

  3. Details are implementation-dependent. I observed this behavior on Arista EOS. ↩

  4. You should also inspect the configuration of X2 to get some hints for one of the upcoming lab exercises. ↩