Troubleshooting Tip: Routes learned from one eBGP neighbor not being advertised to another eBGP neighbor

[MJ_FTNT]

Description	This article describes one of the possible reasons why routes learned from one eBGP neighbor will not be advertised to another eBGP neighbor and then the solution to overcome this situation.
Scope	FortiGate.
Solution	Consider the following topology where FortiGate has two eBGP neighbors established. FortiGate has two eBGP neighborship, 10.21.7.58 is the ISP Router and 10.10.3.127 is the Hub Router.   ISP Router is advertising subnet 1.1.1.1/32 to the FortiGate using BGP, which is received by the FortiGate and installs in the routing table: FortiGate-400E # get router info routing-table bgp Routing table for VRF=0 B 1.1.1.1/32 [20/0] via 10.21.7.58 (recursive is directly connected, port1), 03:08:37, [1/0] But the FortiGate is not advertising this prefix to the Hub: FortiGate-400E # get router info bgp neighbors 10.10.3.127 advertised-routes % No prefix for neighbor 10.10.3.127 This is due to the community 'no-export' being attached to the NLRI (prefix 1.1.1.1/32). FortiGate-400E # get router info bgp network 1.1.1.1 VRF 0 BGP routing table entry for 1.1.1.1/32 Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer) Not advertised to any peer Original VRF 0 7000 10.21.7.58 from 10.21.7.58 (10.21.7.58) Origin IGP metric 0, localpref 100, valid, external, best Community: no-export The purpose of the 'no-export' community is to prevent the advertisement of a particular route to eBGP (external BGP) peers. When a route carries the 'no-export' community, it signifies that the route should not be propagated beyond the immediate eBGP neighbors. Solution: There are two possible solutions to this issue: Discuss with the ISP to let them remove the 'no-export' community when advertising the prefixes. Implement a route-map to match the community when the routes are being received from the ISP router and remove that community. Create a community list to match the community 'no-export': config router community-list     edit "no-export"         config rule             edit 1                 set action permit                 set match "no-export"             next         end     next end Create a route-map to remove the community 'no-export' from the routes: config router route-map    edit "Remove-Community"       config rule          edit 1             set set-community-delete "no-export"          next       end    next end Apply the route-map incoming to the BGP neighbor:    config router bgp       config neighbor           edit "10.21.7.58"               set remote-as 7000               set route-map-in "Remove-Community"           next       end      end Verification: On the hub, the prefix 1.1.1.1/32 advertised by the ISP is now seen. Routing table for VRF=0 S* 0.0.0.0/0 [10/0] via 10.21.7.254, port1, [1/0] B 1.1.1.1/32 [20/0] via 10.10.3.199 (recursive is directly connected, port2), 00:00:01, [1/0]