Skip to main content
akileshc
Staff
Staff
May 21, 2020

Technical Tip: Restricting route advertisement to EBGP neighbours using the 'no-export' community string

  • May 21, 2020
  • 0 replies
  • 7563 views
Description


This article describes how to restrict route advertisement only to immediate External BGP (EBGP) neighbours and not to advertise further using the RFC 1997 'no-export' community string.

 

Scope

 

FortiGate, EBGP.

 

Solution

 

Overview:

  • The 'no-export'/'NO_EXPORT' BGP community is a Well-Known Community defined within RFC 1997. When applied to a prefix that is advertised to an eBGP neighbor, it allows that neighbor to receive and install the route, but NOT propagate it to other EBGP peers:

 

Well-known Communities     The following communities have global significance and their    operations shall be implemented in any community-attribute-aware BGP    speaker.        NO_EXPORT (0xFFFFFF01)          All routes received carrying a communities attribute          containing this value MUST NOT be advertised outside a BGP          confederation boundary (a stand-alone autonomous system that          is not part of a confederation should be considered a          confederation itself). [...]

 

  • The Communities path attribute was first supported in BGP version 2 and continues to be supported in all subsequent versions (unless noted otherwise).
  • In the following example configuration, FGT1 uses an outbound route-map to apply the 'no-export' community to all advertised prefixes matching Rule 1 (in this, 172.16.10.0/24). Any prefix not matching this rule will be denied from being advertised by the implicit deny rule.
  • While FGT2 will be able to receive and install this prefix, it will not forward 172.16.10.0/24 towards other EBGP peers, such as FGT3.

 

Topology:

 

191511 BGP Topology.png

 

Configuration required on FGT1:

 

config router route-map

edit 'community-test'

config rule

edit 1

set set-community 'no-export' <--- No matching criteria is set, so all prefixes can match this rule and have the 'no-export' community applied.

next

end

next

end

 

config router bgp

set as 65001
set router-id 1.1.1.1
config neighbor

edit '172.31.133.109'

set soft-reconfiguration enable
set remote-as 65002
set route-map-out 'community-test'
<--- Outbound route-map will apply 'no-export' community attribute to prefixes advertised out to this neighbor (FGT2).

next

end
config network

edit 2

set prefix 172.16.10.0 255.255.255.0

next

end

end

 

Verification:

 

On FGT1, 172.16.10.0/24 is seen being advertised to FGT2 (neighbor 172.31.133.109):

 

FGT1 # get router info bgp summary
BGP router identifier 1.1.1.1, local AS number 65001
BGP table version is 10
1 BGP AS-PATH entries
1 BGP community entries


Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.31.133.109  4      65002    5815    5963        9    0    0 00:03:12        0
Total number of neighbors 1

 

FGT1 # get router info bgp neighbors 172.31.133.109 advertised-routes
BGP table version is 7, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

 

   Network          Next Hop            Metric LocPrf Weight RouteTag Path
*> 172.16.10.0/24  172.31.133.31                 100  32768        0 i <-/->

Total number of prefixes 1

 

On FGT2, 172.16.10.0/24 has been successfully received from FGT1 (neighbor 172.31.133.31):

 

FGT2 # get router info bgp summary
VRF 0 BGP router identifier 2.2.2.2, local AS number 65002
BGP table version is 3
1 BGP AS-PATH entries
0 BGP community entries

 

Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.31.133.31   4      65001    5571    5582        0    0    0 00:04:01        1
172.31.135.173  4      65003    5555    5584        2    0    0 00:04:02        0

Total number of neighbors 2

 

FGT2 # get router info bgp neighbors 172.31.133.31 received-routes
VRF 0 BGP table version is 1, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

 

   Network          Next Hop            Metric LocPrf Weight RouteTag Path
*> 172.16.10.0/24  172.31.133.31                          0        0 65001 i <-/->

 

Total number of prefixes 1

 

On FGT3, the prefix 172.16.10.0/24 cannot be seen in the received-routes output, as FGT2 is not forwarding this FGT1-based prefix since 'no-export' was applied:

 

FGT3 # get router info bgp summary
BGP router identifier 3.3.3.3, local AS number 65003
BGP table version is 1
1 BGP AS-PATH entries
0 BGP community entries

 

Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.31.133.109  4      65002    5646    5626        0    0    0 00:06:13        1

 

Total number of neighbors 1

 

FGT3 # get router info bgp neighbors 172.31.133.109 received-routes<--- No output observed.

 

For comparison, the following would be seen if FGT1 had not applied the 'no-export' community attribute to the prefix:

 

FGT3 # get router info bgp neighbors 172.31.133.109 received-routes
BGP table version is 1, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight RouteTag Path


*> 172.16.10.0/24  172.31.133.31                          0        0 65002 65001 i

 

Total number of prefixes 1

 

Related article:

Technical Tip: Adding BGP community string to route updates and control BGP routes advertisements by community