Received non-VPN-aware FlowSpec routes are validated following the procedures described in RFC 5575 and draft-ietf-idr-bgp-flowspec-oid-03, Revised Validation Procedure for BGP Flow Specifications. Configure the validate-dest-prefix command in a routing instance to enable validation checks based on the destination prefix. By default, this check is not performed. When the command is enabled, BGP determines whether a non-VPN-aware FlowSpec route is valid or invalid based on the following logic:
If the FlowSpec route was originated in the same Autonomous System (AS) as the receiving BGP router, it is automatically valid.
If rule 1 does not apply, the FlowSpec route was originated in an external AS, and it does not contain a destination prefix subcomponent, it is considered valid.
If rule 1 does not apply, the FlowSpec route was originated in an external AS, and it does contain a destination prefix subcomponent, it is considered valid if all of the following are true:
The neighbor AS (last non-confed AS in the AS_PATH) of the FlowSpec route matches the neighbor AS of the unicast IP route that is the best match of the destination prefix. The best match unicast IP route must be a BGP route (that is, not static, IGP, or other routes).
The neighbor AS of the FlowSpec route matches the neighbor AS of all unicast IP routes that are longer matches of the destination prefix. All longer match unicast IP routes must be BGP routes (that is, not static, IGP, or other routes).
Non-VPN-aware FlowSpec routes that are received with a redirect-to-IPv4 extended community action are also subject to an additional set of validation checks. If the validate-redirect-ip command is enabled in the receiving BGP instance, a non-VPN-aware FlowSpec route is considered invalid, if it is deemed to have originated in a different AS than the IP route that resolves the redirection IPv4 address. The originating AS of a FlowSpec route is determined from its AS paths.
A FlowSpec route that is determined to be invalid by any of the validation rules described earlier is retained in the BGP RIB, but not used for traffic filtering and not propagated to other BGP speakers.