Matching BGP extended community route targets in route maps 7.2.4
|
This information is also available in the FortiOS 7.2 Administration Guide: |
BGP extended community route targets can be matched in route maps. This can be applied in a scenario where the BGP route reflector receives routes from many VRFs, and instead of reflecting all routes from all VRFs, users only want to reflect routes based on a specific extended community route target.
To configure the extended community list:
config router extcommunity-list
edit <name>
set type {standard | expanded}
config rule
edit <id>
set action {deny | permit}
set type {rt | soo}
set match <extended_community_specifications>
set regexp <ordered_list_of_attributes>
next
end
next
end
|
type {standard | expanded} |
Set the extended community list type (standard or expanded). |
|
action {deny | permit} |
Deny or permit route-based operations based on the route's extended community attribute. |
|
type {rt | soo} |
Set the extended community type:
|
|
match <extended_community_specifications> |
Set the extended community specifications for matching a reserved extended community (community number in AA:NN format; use quotation marks complex expressions, |
|
regexp <ordered_list_of_attributes> |
Set the ordered list of extended community attributes as a regular expression. |
To configure the BGP extended community list in the route map:
config router route-map
edit <name>
config rule
edit <id>
set match-extcommunity <list>
set match-extcommunity-exact {enable | disable}
next
end
next
end
|
match-extcommunity <list> |
Set the BGP extended community list to match to. |
|
match-extcommunity-exact {enable | disable} |
Enable/disable exact matching of extended communities. |
Example
In this example, multiple companies (or departments of a company) share the same hub and spoke VPN infrastructure. Company A and company B each have two branches in two different locations. The goal is for company A’s branches (A-1 and A-2) to be able to communicate only with each other over VPN but not with company B’s branches. Likewise, company B’s branches (B-1 and B-2) can only communicate with each other over VPN but not with company A’s. This is accomplished by placing each branch VLAN into their respective VRFs (VRF1 and VRF2), and encapsulating the VRF information within the VPN tunnel. The hub forms BGP peering with its neighbors, spoke 1 and spoke 2, over each IPsec overlay. The hub’s BGP route reflector reflects the routes to the corresponding VRFs, allowing each spoke to form ADVPN shortcuts with the other spoke for each VRF.
However, in this scenario, we want A-1 and A-2 to use an ADVPN shortcut, but we do not want B-1 and B-2 to use ADVPN. A route map is configured on the hub to match the desired extended community route target number where only this route target is permitted, and others are denied. This allows the hub’s BGP route reflector to only reflect routes associated with VRF1, allowing the spokes to form an ADVPN shortcut for VRF1. Routes associated with VRF2 are not reflected, and each spoke must route traffic through the hub to reach VRF2 on the other spoke.
Configure the topology by following the instructions of Example 1 in SD-WAN segmentation over a single overlay. Note that when checking the spoke 1 routes in example 1, there is a VRF2 route:
Spoke 1 # get router info routing-table bgp
…
Routing table for VRF=2
B V 33.1.1.0/24 [200/0] via 10.10.100.3 [2] (recursive via vd2-1 tunnel 11.1.1.11), 00:00:20, [1/0]
[200/0] via 10.10.200.3 [2] (recursive via vd2-2 tunnel 11.1.2.11), 00:00:20, [1/0]
The following procedure applies a route map on the hub’s BGP configurations to limit route reflection to only routes matching the external community target of 1:1. This external community target corresponds to BGP paths for VRF1 learned from spoke 1 and spoke 2. The external community target of 2:1 corresponds to BGP paths for VRF2. By not explicitly permitting this target (2:1) in the community list and denying everything other than the permitted target (1:1) in the route map, the VRF2 BGP paths are essentially omitted from being reflected to the spokes.
To configure BGP filtering for an extended community route target on the hub:
-
Identify the external community target of VRF1 to be permitted:
# get router info bgp network 33.1.1.0/24 VRF 0 BGP routing table entry for 33.1.1.0/24 Paths: (2 available, best #2, table Default-IP-Routing-Table) Advertised to non peer-group peers: 11.1.1.1 Advertised to peer-groups: gr1 gr2 … VRF 1 BGP routing table entry for 33.1.1.0/24 Paths: (2 available, best #2, table Default-IP-Routing-Table) Not advertised to any peer Original VRF 0 external duplicated Local, (Received from a RR-client) 0.0.0.0 from 10.10.100.3 (3.3.3.3) Origin IGP metric 0, localpref 100, valid, internal, best Extended Community: RT:1:1 Receive Path ID: 1 Advertised Path ID: 1 Last update: Wed Aug 17 10:31:02 2022 Original VRF 0 external duplicated Local, (Received from a RR-client) 0.0.0.0 from 10.10.200.3 (3.3.3.3) Origin IGP metric 0, localpref 100, valid, internal, best Extended Community: RT:1:1 Receive Path ID: 1 Advertised Path ID: 2 Last update: Wed Aug 17 10:31:02 2022 VRF 2 BGP routing table entry for 33.1.1.0/24 Paths: (2 available, best #2, table Default-IP-Routing-Table) Not advertised to any peer Original VRF 0 external duplicated Local, (Received from a RR-client) 0.0.0.0 from 10.10.100.3 (3.3.3.3) Origin IGP metric 0, localpref 100, valid, internal, best Extended Community: RT:2:1 Receive Path ID: 1 Advertised Path ID: 1 Last update: Wed Aug 17 10:31:02 2022 Original VRF 0 external duplicated Local, (Received from a RR-client) 0.0.0.0 from 10.10.200.3 (3.3.3.3) Origin IGP metric 0, localpref 100, valid, internal, best Extended Community: RT:2:1 Receive Path ID: 1 Advertised Path ID: 2 Last update: Wed Aug 17 10:31:02 2022 -
Configure the extended community list:
config router extcommunity-list edit "extcomm1" config rule edit 1 set action permit set match "1:1" set type rt next end next end -
Apply the extended community list to the route map:
config router route-map edit "rmp11" config rule edit 1 set match-extcommunity "extcomm1" next edit 2 set action deny next end next end -
Update the related BGP neighbor group settings:
config router bgp config neighbor-group edit "gr1" set route-map-out-vpnv4 "rmp11" next edit "gr2" set route-map-out-vpnv4 "rmp11" next end end -
Refresh the routes:
# execute router clear bgp all vpnv4 unicast out
-
Check the spoke 1 routes. Since the extended community route target is applied, the VFR2 route does not appear in the BGP routing table:
# get router info routing-table bgp Routing table for VRF=0 B* 0.0.0.0/0 [200/0] via 10.10.100.254 (recursive via vd2-1 tunnel 11.1.1.11), 03:47:50, [1/0] [200/0] via 10.10.200.254 (recursive via vd2-2 tunnel 11.1.2.11), 03:47:50, [1/0] B 1.1.1.1/32 [200/0] via 11.1.1.1 [2] (recursive via 12.1.1.1, vd2-vlan12), 03:47:50, [1/0] B 1.222.222.222/32 [200/0] via 11.1.1.1 [2] (recursive via 12.1.1.1, vd2-vlan12), 03:47:50, [1/0] B 11.11.11.11/32 [200/0] via 10.10.100.254 (recursive via vd2-1 tunnel 11.1.1.11), 03:47:50, [1/0] [200/0] via 10.10.200.254 (recursive via vd2-2 tunnel 11.1.2.11), 03:47:50, [1/0] B 33.1.1.0/24 [200/0] via 10.10.100.254 [2] (recursive via vd2-1 tunnel 11.1.1.11), 03:47:21, [1/0] [200/0] via 10.10.200.254 [2] (recursive via vd2-2 tunnel 11.1.2.11), 03:47:21, [1/0] Routing table for VRF=1 B V 11.11.22.11/32 [200/0] via 10.10.100.254 (recursive via vd2-1 tunnel 11.1.1.11), 03:47:50, [1/0] [200/0] via 10.10.200.254 (recursive via vd2-2 tunnel 11.1.2.11), 03:47:50, [1/0] B V 33.1.1.0/24 [200/0] via 10.10.100.3 [2] (recursive via vd2-1 tunnel 11.1.1.11), 03:47:21, [1/0] [200/0] via 10.10.200.3 [2] (recursive via vd2-2 tunnel 11.1.2.11), 03:47:21, [1/0] B V 100.1.1.0/24 [200/0] via 10.10.100.254 (recursive via vd2-1 tunnel 11.1.1.11), 03:47:50, [1/0] [200/0] via 10.10.200.254 (recursive via vd2-2 tunnel 11.1.2.11), 03:47:50, [1/0]