BGP No-Export Community

Contents

Intro

The BGP No-Export community is a “well-known” community that instructs BGP routers to advertise prefixes to iBGP neighbors only.

Topology

The last octet is the router number unless specified otherwise. Example: R1's G0/2 is 10.10.13.1/24. Don't forget to download the EVE-NG topology file for this tutorial below.

Initial Configs

Configuration Steps

1. Configure Basic BGP

I’ll start by getting all of the BGP peerings up using their respective AS numbers and R4’s Lo4 and Lo44 prefix advertised into BGP.

R1:

router bgp 1
 neighbor 10.10.12.2 remote-as 23

R2:

router bgp 23
 neighbor 10.10.12.1 remote-as 1
 neighbor 10.10.23.3 remote-as 23

R3:

router bgp 23
 neighbor 10.10.34.4 remote-as 4
 neighbor 10.10.23.2 remote-as 23
 neighbor 10.10.23.2 next-hop-self

R4:

router bgp 4
 neighbor 10.10.34.3 remote-as 23
 network 4.4.4.4 mask 255.255.255.255
 network 44.44.44.44 mask 255.255.255.255

Use the show ip bgp summary command on all routers to see if the peerings are up and how many prefixes are being received. 

R1:

R1#show ip bgp summary | begin Neighbor
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.12.2      4           23      10      10        3    0    0 00:06:02        2

R1’s peering with R2 is up and two prefixes are being received.

R2:

R2#show ip bgp summary | begin Neighbor
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.12.1      4            1      10      10        3    0    0 00:06:02        0
10.10.23.3      4           23      11       9        3    0    0 00:06:01        2

R2’s peerings with R1 and R3 are up. Two prefixes are being received from R3.

R3:

R3#show ip bgp summary | begin Neighbor
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.23.2      4           23       9      11        3    0    0 00:06:01        0
10.10.34.4      4            4      10       9        3    0    0 00:06:20        2

R3’s peerings with R2 and R4 are up. R3 is currently receiving 2 prefixes from R4.

R4:

R4#show ip bgp summary | begin Neighbor
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.34.3      4           23       9      10        3    0    0 00:06:20        0

Lastly you can see R4’s peering with R3 is up. 

At this point you can see the peerings are up and prefixes are being received but we don’t know exactly what the prefixes are. Sure we can assume but it’s better to verify it yourself to be 100 percent sure. I’ll use the show ip bgp command for this. 

R1#show ip bgp | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>   4.4.4.4/32       10.10.12.2                             0 23 4 i
 *>   44.44.44.44/32   10.10.12.2                             0 23 4 i

R2#show ip bgp | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>i  4.4.4.4/32       10.10.23.3               0    100      0 4 i
 *>i  44.44.44.44/32   10.10.23.3               0    100      0 4 i
R3#show ip bgp | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>   4.4.4.4/32       10.10.34.4               0             0 4 i
 *>   44.44.44.44/32   10.10.34.4               0             0 4 i

This confirms that the two loopback prefixes on R4 are being advertised into BGP and received by all BGP routes in the network. Now I’ll configure the BGP No-Export community on R4 so that it sends the prefixes to R3 with the No-Export community attached. The result of this should be that R3 sends the prefixes to its iBGP neighbor R2, but R2 won’t advertise to its eBGP peer R1.  

2. Enable the sending of communities.

In Cisco IOS, BGP communities are not sent by default. You need to enable it on a per-neighbor.

R4:

router bgp 4
 neighbor 10.10.34.3 send-community

3. Attach the No-Export community to R4's prefixes.

Next I’ll tell R4 what prefixes the community should be attached to. To do this I’ll use a route-map.

R4:

route-map R4-NO-EXPORT permit 10
set community no-export

R4 is sending multiple prefixes to R3. If I wanted to apply this community to one prefix and not the other I can match the networks in a prefix-list or ACL and reference it in this route-map. Since I’m not matching anything, I’m setting the No-Export community to all prefixes. 

The route-map is created but it won’t take effect until I apply it to a neighbor.

R4:

router bgp 4
 neighbor 10.10.34.3 route-map R4-NO-EXPORT out

The route-map is applied towards the neighbor R3 in the outbound direction. This means the No-Export community is applied to all prefixes R4 sends outbound to R3. Another way to implement the No-Export community is I could’ve applied this in the inbound direction on R3 instead. R3 should have received R4’s prefixes with the No-Export community set, let’s confirm this by looking at R3’s BGP table.

If the policy takes a while to kick in, do a clear ip bgp * soft on R4 to speed things up. 
R3#show ip bgp 4.4.4.4
BGP routing table entry for 4.4.4.4/32, version 6
Paths: (1 available, best #1, table default, not advertised to EBGP peer)
  Advertised to update-groups:
     3         
  Refresh Epoch 2
  4
    10.10.34.4 from 10.10.34.4 (44.44.44.44)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: no-export
      rx pathid: 0, tx pathid: 0x0

R3#show ip bgp 44.44.44.44
BGP routing table entry for 44.44.44.44/32, version 7
Paths: (1 available, best #1, table default, not advertised to EBGP peer)
  Advertised to update-groups:
     3         
  Refresh Epoch 2
  4
    10.10.34.4 from 10.10.34.4 (44.44.44.44)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: no-export
      rx pathid: 0, tx pathid: 0x0

In the above output you can see that R3 received 4.4.4.4/32 and 44.44.44.44/32 prefix with the No-Export community applied. Here’s how the prefixes on R3 looked before I applied the community configuration. 

R3#show ip bgp 4.4.4.4    
BGP routing table entry for 4.4.4.4/32, version 8
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     3         
  Refresh Epoch 2
  4
    10.10.34.4 from 10.10.34.4 (44.44.44.44)
      Origin IGP, metric 0, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

R3#show ip bgp 44.44.44.44
BGP routing table entry for 44.44.44.44/32, version 9
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     3         
  Refresh Epoch 2
  4
    10.10.34.4 from 10.10.34.4 (44.44.44.44)
      Origin IGP, metric 0, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

R3 should be advertising these prefixes with the No-Export community applied to its iBGP neighbor R2. I’ll check R2’s BGP to be sure.

R2#show ip bgp 4.4.4.4
BGP routing table entry for 4.4.4.4/32, version 10
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1         
  Refresh Epoch 1
  4
    10.10.23.3 from 10.10.23.3 (10.10.34.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

R2#show ip bgp 44.44.44.44
BGP routing table entry for 44.44.44.44/32, version 11
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1         
  Refresh Epoch 1
  4
    10.10.23.3 from 10.10.23.3 (10.10.34.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

In the above output it looks like R2 is receiving the prefixes from R3 but no communities are applied. This is because I only enabled the sending of communites from R4 to R3. If I expect R3 to send communities to R2 then I need to configure R3 to do so. 

R3:

router bgp 23
neighbor 10.10.23.2 send-community

Now I’ll check R2’s BGP table again.

R2#show ip bgp 4.4.4.4    
BGP routing table entry for 4.4.4.4/32, version 12
Paths: (1 available, best #1, table default, not advertised to EBGP peer)
  Not advertised to any peer
  Refresh Epoch 1
  4
    10.10.23.3 from 10.10.23.3 (10.10.34.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: no-export
      rx pathid: 0, tx pathid: 0x0

R2#show ip bgp 44.44.44.44
BGP routing table entry for 44.44.44.44/32, version 13
Paths: (1 available, best #1, table default, not advertised to EBGP peer)
  Not advertised to any peer
  Refresh Epoch 1
  4
    10.10.23.3 from 10.10.23.3 (10.10.34.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: no-export
      rx pathid: 0, tx pathid: 0x0

The above output shows that R2 is receiving the prefixes from its iBGP neighbor R3 and the No-Export community is successfully applied. You can see it says “not advertised to EBGP peer” that’s exactly what the No-Export community is designed to do. Let’s confirm this by looking at the BGP table of R1 to make sure those prefixes aren’t there. 

R1#sh ip bgp 4.4.4.4
% Network not in table

R1#sh ip bgp 44.44.44.44 
% Network not in table

Perfect, the prefixes that have the No-Export community applied stayed within AS23 and were never sent to R1.

Checking the BGP table on R1 is a valid verification step but what if you don’t have access to that router. You need to know how to verify it on both ends espcially if your going for the CCIE lab. I can use the show ip bgp neighbors advertised routes command from R2 to see exactly what its sending to R1. 

R2#show ip bgp neighbors 10.10.12.1 advertised-routes 

Total number of prefixes 0

The show ip bgp neighbors advertised-routes command shows me that R2 is sending no prefixes to R1. This is the No-Export community doing its job of not sending prefixes to eBGP peers. 

Take a look at the BGP UPDATE message in Wireshark. This is what R4 sent to R3 when the No-Export community was applied. Notice under the Path Attribute it says Communities: NO_EXPORT.

Wireshark capture screenshot displaying BGP NO_EXPORT community attribute in packet details.

EVE-NG Lab File

Images used in lab: VIOS-ADVENTERPRISEK9-M), Version 15.9(3)M2

Here’s the EVE-NG Topology file if you want to import it into your own EVE-NG lab and practice. Please note this is the topology file not the Cisco images, we don’t provide those. 

Download

Full Configs

Here are the full configs from all routers if you want to try it out yourself.

Got questions?

Any questions or comments feel free to send me an email at rafael@networkengineerpro.com and I’ll get back to you when I can.