Fortinet black logo

New Features

Matching BGP extended community route targets in route maps 7.2.4

Copy Link
Copy Doc ID 77966226-6996-11ec-bdf2-fa163e15d75b:454380
Download PDF

Matching BGP extended community route targets in route maps 7.2.4

Note

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:

  • rt: route target
  • soo: site of origin

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, "123:234 345:456").

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:
  1. 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
  2. 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
  3. 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
  4. 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
  5. Refresh the routes:

    # execute router clear bgp all vpnv4 unicast out
  6. 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]

Matching BGP extended community route targets in route maps 7.2.4

Note

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:

  • rt: route target
  • soo: site of origin

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, "123:234 345:456").

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:
  1. 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
  2. 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
  3. 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
  4. 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
  5. Refresh the routes:

    # execute router clear bgp all vpnv4 unicast out
  6. 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]