Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Routing Policies

SUMMARY Juniper Cloud-Native Contrail Networking (CN2) release 23.3 supports routing policies. Routing Policies modify a route's path and attributes dynamically. With release 23.3, the manipulation and filtering of routes is more granular.

Routing Policies Overview

Contrail uses routing policies to control the flow of network traffic between virtual networks (VNs). Routing policies enable you to define how traffic is forwarded, filtered, and controlled based on certain conditions. Routing policies define conditions (source or destination IP address, packet attributes, routing protocols) packets must meet for the policy to apply.

For more information about routing policies, see Routing Policy.

Routing Policy Infrastructure

Routing Policy List Terms

Routing policies contain a set of list terms. List terms are conditions and actions that determine how routing policies handle traffic. Each routing policy can consist of one or more terms. Each terms specifies a set of conditions (match conditions) to be met and the corresponding actions to take if those conditions are fulfilled. A term can be a terminal rule, meaning that upon a match on the specified term, no further terms are evaluated and the route is dropped or accepted, based on the action in that term.

If the term is not a terminal rule, subsequent terms are evaluated for the given route. The following example shows the structure of list terms:

The following example shows the structure of a term's match conditions and actions:

A term cannot contain an any match condition. For example, an empty from cannot be present.

If an any match condition is present, all routes are considered as matching the term. In contrast, the then condition can be empty or the action can be unspecified.

Apply a Routing Policy

A routing policy evaluation has the following key points:

  • If the term of a routing policy consists of multiple match conditions, a route must satisfy all match conditions to apply the action specified in the term.

  • If a term in the policy does not specify a match condition, all routes are evaluated against the match.

  • If a match occurs but the policy does not specify an accept, reject, or next term action, one of the following occurs:

    • The next term, if present, is evaluated.

    • If no other terms are present, the next policy is evaluated.

    • If no other policies are present, the route is accepted. The default routing policy action is “accept”.

  • If a match does not occur with a term in a policy, and subsequent terms in the same policy exist, the next term is evaluated.

  • If a match does not occur with any terms in a policy, and subsequent policies exist, the next policy is evaluated.

  • If a match does not occur by the end of a policy or all policies, the route is accepted.

A routing policy consists of multiple terms. Each term consists of match conditions and actions to apply to matching routes.

Each route is evaluated against the policy as follows:

  1. The route is evaluated against the first term. If it matches, the specified action is taken. If the action is to accept or reject the route, that action is taken and the evaluation of the route ends. If the next term action is specified or if no action is specified, or if the route does not match, the evaluation continues as described above to subsequent terms.

  2. Upon hitting the last non-terminal term of the given routing policy, the route is evaluated against the next policy, if present, in the same manner as described in step 1.

Create a Routing Policy

The following is an exampe virtual network with a routing policy referenced in the routingPolicyReferences field.

Note:

The virtualNetworkProperties.forwardingMode field must be set to l2_l3 or l3. The routing policy feature does not apply to intra-VN connections when the forwarding mode of the VN is L2.

Routing Policies and BGP Extended Communities

Border Gateway Protocol (BGP) extended communities are additional attributes for BGP routes. BGP extended communities provide a method of associating additional information like route target or encapsulation protocol with routes. Creating a routing policy with extended communities makes the policy more granular, enabling you to distribute routes and manage traffic effectively. This makes BGP extended communities ideal for complex, dynamic routes.

CN2 offers extended community support with the import routing policy feature. This feature allows for the use of import routing policy terms to identify extended communities and execute import routing policy actions, such as the addition, adjustment, or removal of these extended communities.

CN2 supports the following extended communities:

  • Route Target

  • Encapsulation

  • Security Group

  • Origin VN

  • MAC Mobility

  • Load Balance

  • Tag

  • Color

For information about these extended communities, see BGP Extended Communities.

Create a Routing Policy With BGP Extended Communities

The following is an example of a routing policy that matches with a BGP extended community. The following example matches for a prefix specified in the termMatchCondition field and attaches the BGP color community (color:0:100) when the prefix is matched.

Note the following fields:

  • term: Represents a defined condition and associated actions to execute if term conditons are met.

  • extcommunity: add:: Specifies an extended community to add to the route.

    community: Contains the extended community string color:0:100.

  • termMatchCondition: Specifies the conditions that must be satisfied for the actions in the term to take effect.

  • asPath, community, localPref: Specifies additional term match conditions to match with the route.

  • prefix: A match condition that specifies that the term will match with routes with the exact prefix 172.100.70.5/32.

The following table provides addition information about the fields of a routing policy.

Table 1: Create a Routing Policy

Field

Guidelines

Name

Enter a name for the routing policy.

Term(s)

Community

Select the community string to match for the routing policy. The community string is represented with accept-own, no-advertise, no-export, no-export-subconfed, no-reoriginate..

Match All

Select the check box to match all the community strings.

Extended Community

Select the extended community string to match for the routing policy.

Match All

Select the check box to match the extended community strings.

Protocol

Select the protocol for the routing policy which is an array of path source or path protocol to match. The protocols are interface, aggregate, bgp, BGPaaS, interface-static, service-chain, service-interface, static, and xmpp. A path is considered as matching this condition if the path protocol is one of protocols in the list.

Prefixes

Select a list of prefixes to match.

Each prefix in the list is represented as prefix and match type, where the prefix match type can be:

  • exact

  • orlonger

  • longer

Example: 10.1.0.0/16 orlonger

A route matches this condition if its prefix matches any of the prefixes in the list.

Then

Actions

Select the actions to be performed on the matching routes. The supported actions and the values are listed in the Table 2.

Policy Actions

Table 2: Policy Actions
Action Value
action

Reject-Reject the route that matches this term. No more terms are evaluated after hitting this term.

Accept-Accept the route that matches this term. No more terms are evaluated after hitting this term.

Next-This is the default action taken upon matching the policy term. The route is updated according to the update specified in the policy action. Next terms present in the routing policy are processed on the route. If there are no more terms in the policy, the next routing policy is processed, if present.

add community

Add a list of community to the existing community.

The community is of type unsigned 32 bit integer:unsigned 32 bit integer.

For example, 64512:55555.

add extended community

Add a list of extended community to the existing community.

 An eight octet string representation of value type:administrator:assigned-number where type is two octets, administrator is four octets, and assigned-number is two octets or it can be a hexadecimal representation of the community like: 0xFFffA101.

as-path

Select different AS paths to control routing decisions

Unsigned 32-bit integer representing the as-path.

For example, 444.

local-preference

Select the local preference to distinguish routes and take further action.

Unsigned 32-bit integer representing local-preference.

For example, 444.

med

Select the MED of the BgpPath.

Unsigned 32-bit integer representing the MED.

For example, 444.

remove community

Remove a list of community (if present) from the existing community.

 The community is of type unsigned 32 bit integer:unsigned 32 bit integer.

remove extended community

Remove a list of extended community (if present) from the existing community.

 An eight octet string representation of value type:administrator:assigned-number where type is two octets, administrator is four octets, and assigned-number is two octets or it can be a hexadecimal representation of the community like: 0xFFffA101.

set community

Set a list of community.

 The community is of type unsigned 32 bit integer:unsigned 32 bit integer.

set extended community

Set a list of extended community.

 An eight octet string representation of value type:administrator:assigned-number where type is two octets, administrator is four octets, and assigned-number is two octets or it can be a hexadecimal representation of the community like: 0xFFffA101.

Related Documentation