Using RT Constraint routes

In general (ignoring IBGP-to-IBGP rules, Add-Path, Best-external, and so on), the best VPN route for every prefix/NLRI in the RIB is sent to every peer supporting the VPN address family, but export policies may be used to prevent some prefix/NLRI from being advertised to specific peers. These export policies may be configured statically or created dynamically based on use of ORF or RT constraint with a peer. ORF and RT Constraint are mutually exclusive on a session.

When RT Constraint is configured on a session that also supports VPN address families using route targets (that is: vpn-ipv4, vpn-ipv6, l2-vpn, mvpn-ipv4, mvpn-ipv6, mcast-vpn-ipv4 or evpn), the advertisement of the VPN routes is affected as follows:

1. When the session comes up, the advertisement of the VPN routes is delayed for a short while to allow RTC routes to be received from the peer.

2. After the initial delay, the received RTC routes are analyzed and acted upon. If S1 is the set of routes previously advertised to the peer and S2 is the set of routes that should be advertised based on the most recent received RTC routes then:

   • Set of routes in S1 but not in S2 should be withdrawn immediately (subject to MRAI).

   • Set of routes in S2 but not in S1 should be advertised immediately (subject to MRAI).

If a default RTC route is received from a peer P1, the VPN routes that are advertised to P1 is the set that meets all of the following requirements:

• The set is eligible for advertisement to P1 per BGP route advertisement rules.

• The set has not been rejected by manually configured export policies.

• The set has not been advertised to the peer.

In this context, a default RTC route is any of the following:

• a route with NLRI length = zero

• a route with NLRI value = origin AS and NLRI length = 32

• a route with NLRI value = {origin AS+0x0002 | origin AS+0x0102 | origin AS+0x0202} and NLRI length = 48

  • If an RTC route for prefix A (origin-AS = A1, RT = A2/n, n > 48) is received from an IBGP peer I1 in autonomous system A1, the VPN routes that are advertised to I1 is the set that meets all of the following requirements:

    1. The set is eligible for advertisement to I1 per BGP route advertisement rules.

    2. The set has not been rejected by manually configured export policies.

    3. The set carries at least one route target extended community with value A2 in the n most significant bits.

    4. The set has not been advertised to the peer.

    Note: This applies whether I1 advertised the best route for A or not.

  • If the best RTC route for a prefix A (origin-AS = A1, RT = A2/n, n > 48) is received from an IBGP peer I1 in autonomous system B, the VPN routes that are advertised to I1 is the set that meets all of the following requirements:

    1. The set is eligible for advertisement to I1 per BGP route advertisement rules.

    2. The set has not been rejected by manually configured export policies.

    3. The set carries at least one route target extended community with value A2 in the n most significant bits.

    4. The set has not been advertised to the peer.

    Note: This applies only if I1 advertised the best route for A.

  • If the best RTC route for a prefix A (origin-AS = A1, RT = A2/n, n > 48) is received from an EBGP peer E1, the VPN routes that are advertised to E1 is the set that meets all of the following requirements:

    1. The set is eligible for advertisement to E1 per BGP route advertisement rules.

    2. The set has not been rejected by manually configured export policies.

    3. The set carries at least one route target extended community with value A2 in the n most significant bits.

    4. The set has not been advertised to the peer.

    Note: This applies only if E1 advertised the best route for A.