Policy Overview

Policies are rules that allow to control and modify the behavior of routing protocols such as BGP, IS-IS, OSPF, and other supported protocols. The policy framework is generic; it serves multiple purposes and applications. Policies are first created using a common policy configuration and then applied by attaching them to an application like a protocol.

The following diagram shows policy configuration options.

policy config

Policy Components

In RtBrick Full Stack, the policy implementation consists of 4 sub-components:

  • Policy Repository

  • Command Processing Module

  • Policy Server, the policy generation and relationship management component

  • Policy Client, the policy enforcement component

policy architecture

Policy Repository

The policy repository contains all tables related to policy and the associated list of match criteria.

Command Processing Module

The command processing module is part of the configuration daemon (confd), and it handles user interaction with the policy module. This is the back-end of the Command Line Interface (CLI) and JSON configuration that supports the policy configurations.

This module maps the user-defined configuration into the back-end policy object, which is used by the execution engine (after verification), and it ensures that the policy can be correctly executed. This module relays the user intent via related BDS tables to the policy server.

Policy Server

The policy server is a server component that manages all policy rules in the various policy tables and also code generation of the policies.

The following are the functionalities of the policy server:

  • Parses the objects in the policy tables and is an execution engine that generates the code to build the policy rules for evaluation, the relationship between various objects, and relays the intent to the evaluation engine.

  • Maintains relationships between various policy constructs such as policy statements, rules, ordinals, and lists.

  • Tracks the attachment points so that when policies are modified, the appropriate clients are notified of the relevant new policies.

  • Flattens the various relationships and generates a notification table that the clients subscribe to obtain notifications based on specific interest groups.

  • Uses dependency table relationships to generate jobs to trigger code generation for various policy components.

  • On code generation, the policy server updates a notification table that maintains the mapping between the policy server and the client interest groups. The notification table is a single point for the dissemination of information so that it can generate notifications for clients depending on their subscriptions for policy of interest.

  • Policy server notification is generated for the policy clients. A notification is received from the notification table with metadata information that notifies the client if this is a new version of the policy or the original version of the policy. The client uses this information to enforce the policy evaluation and to decide on the version of the policy rule that should be used.

Policy Client

The policy client is a shared library component to which a client daemon, like BGP, IS-IS, OSPF, etc., links. This is the component that performs policy enforcement. It performs the following tasks:

  • Links with client daemons like BGP, IS-IS, and OSPF.

  • Contains a listener that gets notifications on the availability of a new policy rule that is generated by the policy server.

  • Evaluates the compiled rule, and if there are any listeners/ interests, then notifies the components within the client daemon.

  • Evaluates any policy configurations on the client daemon and invokes policy processing in response.

Tables and Subscriptions

The table below shows the various tables and their sharing across various policy components.

Confd

global.policy.list.config global.policy.list.entry.config global.policy.match.rules.config global.policy.statement.config global.policy.ordinal.config global.policy.mapping.list global.policy.mapping.rules

Policy Statement is composed of one or more policy terms. Each term has a match action criteria. In the match and action criteria, either a single element or a list of elements are compared, and actions are taken. The actions include accept, deny, flow-control, etc.

policy.server

global.policy.dependency global.<bds_name>.policy.subscription global.<bds_name>.policy.notification

Policy Server subscribes to all the tables from confd and creates tables that track policy-entry and dependency and notifies clients after code generation.

policy.client

global.<bds_name>.policy.shared.object.cache global.<bds_name>.policy.subscription global.<bds_name>.policy.context

Subscribes to code generation notifications application context and maintains cache of subscribed .so

Policy Building Blocks

The figure below shows the building blocks of a policy.

policy building blocks

Statements

A policy is defined by a policy statement. A policy statement is a compound block of policy definition that consists of one or more set of rules called ordinals. A policy statement is exercised in the order defined. The statement name is a globally unique string that is used to identify the policy, and used by the applications.

The following diagram shows policy statement configuration parameters.

policy statement config

Ordinals

A policy ordinal is the smallest block to represent a user policy intent and consists of rules for match and action blocks. The match blocks can either define single independent elements like AS path, IP prefix, IP addresses, community, and so on, or a list of the elements maintained in a different table.

  • An ordinal must be a unique number within the scope of a statement which determines the order of the term execution within a policy statement.

  • If no ordinal exist or configured, and if the policy is used, then all routes or objects will be denied.

  • A match logic is defined per ordinal. In case of multiple match rules, it defines if all rules (and), or any of the rules (or) have to match.

Match Rules

Match rules define criteria to evaluate and select routes or other objects to which the policy is applied. One or more match rules compose a match block.

The following diagram shows policy match rule parameters.

policy match rules config

  • If the match block results in a successful match ("true"), the corresponding action block will executed.

  • If the match block result is unsuccessful ("false"), the action block will not be executed, and the next ordinal will be processed.

  • If there is no match block, the action block will be executed.

In case of multiple match rules, the behaviour depends on the configured match logic:

  • If the match logic is or, the match block result will be succcessful ("true") if any one rule matches. Otherwise, by default it is "false".

  • If the match logic is and, the match block result will be successful ("true") if all rules match. Otherwise it is "false".

A match rule can refer to a single discrete value, or a list. A policy list is configured separately and referenced from the policy statement. In case of a list match, the behaviour is as follows:

  • If any of the list entries matches the configured value, the match block result will be succcessful ("true"). Otherwise it is "false".

  • If the list is defined but empty, the match rule result will be unsuccessful ("false").

Action Rules

Action rules define operations like return-permit or return-deny, or flow control commands like goto-next-ordinal. The action block will be executed if there is a successful match. Otherwise, the next ordinal is processed. The action block can contain one or multiple action rules. In case of multiple action rules, all actions will be applied. The rules are executed in the order of the rule numbers. If there is any termination action, the rules afterwards are not executed anymore.

The action block is optional. The implicit default action is return-deny.

The following diagram shows action rules configuration parameters.

policy action rules config

Lists

A policy list is a list of values that can be referenced by a match rule in a policy statement. If you have a number of values like for example route prefixes, it is more efficient to refer to a policy list instead of creating one match rule per prefix.

Policy lists are configured separately and can thereby be maintained more easily. Besides, policy lists can be referenced by multiple policy statements.

Conditions

Policy conditions are configured separately and can be used as an additional option in policy statements. A policy rule (ordinal) will only be executed if the condition is true. Conditional policies allow to make policy execution depended on certain states of the system, for example:

  • Protocol neighbor states

  • Presence or absence of a specific route and/or path attribute

  • Number of routes in a routing table

One condition is supported per ordinal. A single condition can be attached to multiple policies.

Attachment Points

Policies define a set of rules that can be used for various purposes by various applications. Once policies have been created, they need to be applied to take effect. Attachment points describe the specific applications and processes to which policies can be applied.

The following diagram shows the BGP attachment points.

bgp attachement point hl

RBFS currently supports the following policy attachment points:

  • Instance import/export - Policies attached to an instance at the address family level allow to control which routes will be imported into the instance and exported from the instance by BGP. Such import and export policies are commonly used with BGP L3VPNs.

The following diagram shows the BGP Global Instance attachment points.

bgp attach point global insta

The following diagram shows the BGP Global Instance default attachment points.

bgp global insta default

The following diagram shows the BGP Global Instance non-default attachment points.

bgp global insta nondefault

  • BGP peer group import/export - Policies attached to BGP peer groups allow to define which routes will be advertised to and accepted from BGP peers. You can attach policies to both instances or peer groups to define the import and export behavior. You can also combine both attachment points, for example if some policy rules apply generically to the instance and some other rules specifically to a peer or peer group.

The following diagram shows BGP peer group attachment points.

bgp attach point peer group

The following diagram shows BGP peer group default attachment points.

bgp peer group default

The following diagram shows BGP peer group non-default attachment points.

bgp peer group nondefault

  • BGP redistribution - You can attach policies to BGP redistribution to define which routes will be redistributed into the BGP process. This is useful if you would like to redistribute only a sub-set of a type of routes.

The following diagram shows BGP redistribution attachment points.

bgp attach point redistribution

  • IS-IS redistribution - Policies can be attached to IS-IS redistribution to control which routes will be redistributed into the IS-IS process.

The following diagram shows IS-IS Redistribution attachment point.

isis attach point redistribution

  • OSPFv2 redistribution - Policies can be attached to OSPFv2 redistribution to control which routes will be redistributed into the OSPFv2 process.

The following diagram shows OSPF Redistribution attachment points.

ospf attach point redistribution

  • LDP redistribution - Policies can be attached to the LDP redistribution to control which routes will be redistributed into the LDP process.

The following diagram shows LDP Redistribution attachment points.

ldp attach point redistribution

The following diagram shows LDP peer group attachment points.

ldp attach point peer

  • IGMP group filtering - You can apply policies to IGMP interface profiles. Such policies act as IGMP group filters when receiving IGMP Membership Report messages.

  • IGMP SSM-mapping - Policies are further used to define SSM mapping. SSM mapping policies attached to IGMP interface profiles define how to translate IGMPv2 (*,G) to IGMPv3 (S,G) Reports.

The following diagram shows IGMP attachment points.

igmp attach point

Policy Behaviour

The default behaviour of a policy is deny. This means, if a route or any other object is subject to a policy, by default it will be marked as deny. For example in case of an import policy, it will not be imported. A policy will permit an object, for example import a route, if the route or object successfully matches the match rules, and if there is an action rule with a permit. In addition, further operations like modifying route attributes might be executed.

Policy ordinals are executed in the order of the ordinal numbers.

  • If an ordinal results in a terminating action like permit or deny, the policy processing is completed for the respective object. Subsequent ordinals will not be processed.

  • If an ordinal does not result in a match, the next ordinal is processed.

There might be situations in which a policy configuration is not complete or not valid. In particular, a policy may contain a match or action type not supported by an attachment point. For example, the ipv4-mcast-group type is not supported by BGP or IS-IS. The following list summarizes the behaviour for such invalid scenarios:

  • If a policy is attached but does not exist, all routes or objects will be denied.

  • If a policy contains only statements, or only statements and ordinals, but no match and action block, it will deny all.

  • If a match or action type is not supported by the attachment point, the policy will ignore the unsupported rule and process only the supported rules. For any ignored rule, the default deny is not impacted. The behaviour will be the same as if the unsupported rule does not exist.

Match Type

The Match Type refers to the criteria or conditions used to determine if a particular route or set of routes should be acted upon by the policy. It specifies which attributes of the routes are to be evaluated to see if they meet the policy conditions.

The following diagram shows various match types supported.

match type

Operation Type

The Operation Type refers to the actions applied to the routes that match the specified criteria or match types within the policy. Once a route matches the conditions set by the match types, the operation type dictates what is to be done with the route.

The following diagram shows various operation types supported.

operation type

Attribute Type

The Attribute Type refers to the specific properties of routes that can be matched against or modified within the policy. These attributes are used to define conditions (match types) or actions (operation types) on the routes.

The following diagram shows various attribute types supported.

attribute type

Policy Chaining

Multiservice edge nodes, such as Broadband Network Gateways (BNG) and peering points, manage routes from various sources. The complexity of policy configurations for these routes can be significant. Certain policies, like filtering private IP addresses and removing private Autonomous System (AS) numbers from the AS path, are frequently reused across different router application points. Therefore, implementing modularization and enabling the chaining of these policies improve both maintainability and clarity in policy configurations.

Policy chaining is used to modularize monolithic complex routing policies into multiple smaller policies that are executed in a predefined order and are easier to maintain.

Benefits of using policy chaining:

  • Rule Reusability: Reuse common rules (for example, RFC1918, bogon filtering) across multiple chains, simplifying configuration.

  • Custom Policies: Create customer-specific policies by combining existing rules for different peering scenarios (transit, upstream, public).

  • Easier Rule Updates: Simplify updates to general rules affecting multiple policies.

  • Simplify Troubleshooting: Make troubleshooting easier by breaking down complex configurations into reusable components.

The diagram below shows how a chain of routing policies is evaluated. When Policy Statements 1-3 are chained in configuration, the actual policy evaluation should proceed as shown in the figure below.

policy chaining

  1. The route is first evaluated against the first ordinal in the first routing policy. If it matches, the specified action is taken. If the action is to “return-permit” or “return-deny” the route, that action is taken, and the evaluation of the route ends. If the goto-next-ordinal action is specified, if no action is specified, or if the route does not match, the evaluation continues by processing the second ordinal in the first routing policy in the same manner. If goto-next-policy action is specified, the evaluation continues by processing the first ordinal of the next policy.

  2. If the route does not match an ordinal or matches an ordinal with a goto-next-policy action in the first routing policy, it is evaluated against the first ordinal in the second routing policy.

  3. The evaluation continues until the route matches an ordinal with a ‘return-permit’ or ‘return-deny’ action defined or until there are no more routing policies to evaluate. If there are no more routing policies, then the return-permit or return-deny action specified by the default policy is taken. If there are no more routing policies to evaluate, the default action is return-deny.

Supported Platforms

Not all features are necessarily supported on each hardware platform. Please refer to the RBFS Platform Guide for the features and the sub-features supported or not supported for each platform.