FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
akileshc
Staff
Staff
Article Id 191511
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...