Skip to content

Routing Policies Application#
Group/Version routingpolicies.eda.nokia.com/v1
Supported OS Nokia SR Linux: 24.10.*, 25.3.*, 25.7.*, 25.10.*, 26.3.*
Nokia SR OS: 24.10.r4+, 25.3.r2+, 25.7.*, 25.10.*, 26.3.*
Arista EOS: 4.33.2f:beta
Cisco NX-OS: 10.5.2:alpha
Catalog Nokia/catalog/routingpolicies
Source Code coming soon

Routing policies are ordered lists of rules (known as policy statements) that filter and/or modify routes, and can be applied in two directions:

  • An import Policy to accept, reject, or modify routes received from a BGP, IS-IS, or OSPF neighbor.
  • An export Policy to send, block, or modify routes advertised to a BGP, IS-IS, or OSPF neighbor.

In addition, Policies can be used to control which routes are leaked across virtual network instances.

The application provides the following components:

Policy statements#

Every statement, which is one rule of a Policy, has two components: match criteria to determine which routes the rule applies to, and an action determining what to do with routes that match the rule. The following resources are used in the match criteria and/or action of a policy statement:

  • PrefixSets are used exclusively in match criteria, and allow matching based on the subnet of a route.
  • ASPathSets are used exclusively in match criteria, and allow matching based on the AS path of a BGP route.
  • CommunitySets are used in match criteria to allow matching based on the (extended) communities of a BGP route, as well as in actions to add, remove, or replace the route's (extended) communities.
  • TagSets are used in match criteria to allow matching based on the internal tag assigned to a route, as well as in actions to set a route's internal tag.
The difference between tags and communities

Communities are BGP path attributes that can be propagated to peers, subject to policy. In contrast, internal route tags are locally significant metadata attached to routes and are not sent on the wire.

Examples of BGP communities
  • 65500:100 - BGP standard (32-bit) community whose semantics are defined by the operator of AS 65500
  • target:65510:100 - BGP Route Target extended community using AS 65510 and locally assigned value 100
  • origin:65500:1 - BGP Route Origin extended community using AS 65500 and locally assigned value 1

Well-known communities and extended-community types have standardized meanings. Operators define the semantics of other administratively assigned values.

Route tags are vendor-specific and locally significant to the device. While they are not transmitted to neighbors or peers, they can influence which routes are advertised to other peers. For example, an operator may assign a temporary isolation tag to all routes received from one or more BGP peers, and then prevent routes with this tag from being advertised to an external peer.

Examples of route tags
  • 20 - assigned to routes that are to be advertised to an external internet gateway
  • 30 - assigned to routes that are not to be advertised to an external internet gateway
  • 99 - routes that are not (yet) classified as internal or external

Note that there are no hard rules for the numbering of route tags.

Route leaking#

Virtualized networking services are used to isolate traffic, ensuring that there is no connectivity between isolated sets of hosts. For example, virtual Routers may be used to separate a lab network and a production network.

Sometimes, however, exceptions must be made. For example, system administrators may require connectivity to the servers in both the lab and production networks. In this example, routes to the system administrators' VPN subnet must be leaked into both the lab and production routers. In the opposite direction, routes to the compute hosts' management subnets must be leaked into the management network.

Routing policies may be used to control which routes are leaked into and out of virtualized Router services.