Policy Framework Overview

Routing Policy and Firewall Filters

The policy framework is composed of the following policies:

• Routing policy—Allows you to control the routing information between the routing protocols and the routing tables and between the routing tables and the forwarding table. All routing protocols use the Junos OS routing tables to store the routes that they learn and to determine which routes they should advertise in their protocol packets. Routing policy allows you to control which routes the routing protocols store in and retrieve from the routing table.

• Firewall filter policy—Allows you to control packets transiting the router to a network destination and packets destined for and sent by the router.

  Note:

  The term firewall filter policy is used here to emphasize that a firewall filter is a policy and shares some fundamental similarities with a routing policy. However, when referring to a firewall filter policy in the rest of this manual, the term firewall filter is used.

Reasons to Create a Routing Policy

The following are typical circumstances under which you might want to preempt the default routing policies in the routing policy framework by creating your own routing policies:

• You do not want a protocol to import all routes into the routing table. If the routing table does not learn about certain routes, they can never be used to forward packets and they can never be redistributed into other routing protocols.

• You do not want a routing protocol to export all the active routes it learns.

• You want a routing protocol to announce active routes learned from another routing protocol, which is sometimes called route redistribution.

• You want to manipulate route characteristics, such as the preference value, AS path, or community. You can manipulate the route characteristics to control which route is selected as the active route to reach a destination. In general, the active route is also advertised to a router’s neighbors.

• You want to change the default BGP route flap-damping parameters.

• You want to perform per-packet load balancing.

• You want to enable class of service (CoS).

Router Flows Affected by Policies

The Junos OS policies affect the following router flows:

• Flow of routing information between the routing protocols and the routing tables and between the routing tables and the forwarding table. The Routing Engine handles this flow. Routing information is the information about routes learned by the routing protocols from a router’s neighbors. This information is stored in routing tables and is subsequently advertised by the routing protocols to the router’s neighbors. Routing policies allow you to control the flow of this information.

• Flow of data packets in and out of the router’s physical interfaces. The Packet Forwarding Engine handles this flow. Data packets are chunks of data that transit the router as they are being forwarded from a source to a destination. When a router receives a data packet on an interface, it determines where to forward the packet by looking in the forwarding table for the best route to a destination. The router then forwards the data packet toward its destination through the appropriate interface. Firewall filters allow you to control the flow of these data packets.

• Flow of local packets from the router’s physical interfaces and to the Routing Engine. The Routing Engine handles this flow. Local packets are chunks of data that are destined for or sent by the router. Local packets usually contain routing protocol data, data for IP services such as Telnet or SSH, and data for administrative protocols such as the Internet Control Message Protocol (ICMP). When the Routing Engine receives a local packet, it forwards the packet to the appropriate process or to the kernel, which are both part of the Routing Engine, or to the Packet Forwarding Engine. Firewall filters allow you to control the flow of these local packets.

  Note:

  In the rest of this chapter, the term packets refers to both data and local packets unless explicitly stated otherwise.

Figure 1 illustrates the flows through the router. Although the flows are very different from each other, they are also interdependent. Routing policies determine which routes are placed in the forwarding table. The forwarding table, in turn, has an integral role in determining the appropriate physical interface through which to forward a packet.

Figure 1: Flows of Routing Information and Packets

You can configure routing policies to control which routes the routing protocols place in the routing tables and to control which routes the routing protocols advertise from the routing tables (see Figure 2). The routing protocols advertise active routes only from the routing tables. (An active route is a route that is chosen from all routes in the routing table to reach a destination.)

You can also use routing policies to do the following:

• Change specific route characteristics, which allow you to control which route is selected as the active route to reach a destination. In general, the active route is also advertised to a router’s neighbors.

• Change to the default BGP route flap-damping values.

• Perform per-packet load balancing.

• Enable class of service (CoS).

Figure 2: Routing Policies to Control Routing Information Flow

You can configure firewall filters to control the following aspects of packet flow (see Figure 3):

• Which data packets are accepted on and transmitted from the physical interfaces. To control the flow of data packets, you apply firewall filters to the physical interfaces.

• Which local packets are transmitted from the physical interfaces and to the Routing Engine. To control local packets, you apply firewall filters on the loopback interface, which is the interface to the Routing Engine.

Firewall filters provide a means of protecting your router from excessive traffic transiting the router to a network destination or destined for the Routing Engine. Firewall filters that control local packets can also protect your router from external incidents such as denial-of-service attacks.

Figure 3: Firewall Filters to Control Packet Flow

Control Points

All policies provide two points at which you can control routing information or packets through the router (see Figure 4). These control points allow you to control the following:

• Routing information before and after it is placed in the routing table.

• Data packets before and after a forwarding table lookup.

• Local packets before and after they are received by the Routing Engine. (Figure 4 appears to depict only one control point but because of the bidirectional flow of the local packets, two control points actually exist.)

Figure 4: Policy Control Points

Because there are two control points, you can configure policies that control the routing information or data packets before and after their interaction with their respective tables, and policies that control local packets before and after their interaction with the Routing Engine. Import routing policies control the routing information that is placed in the routing tables, whereas export routing policies control the routing information that is advertised from the routing tables. Input firewall filters control packets that are received on a router interface, whereas output firewall filters control packets that are transmitted from a router interface.

Policy Components

All policies are composed of the following components that you configure:

• Match conditions—Criteria against which a route or packets are compared. You can configure one or more criteria. If all criteria match, one or more actions are applied.

• Actions—What happens if all criteria match. You can configure one or more actions.

• Terms—Named structures in which match conditions and actions are defined. You can define one or more terms.

The policy framework software evaluates each incoming and outgoing route or packet against the match conditions in a term. If the criteria in the match conditions are met, the defined action is taken.

In general, the policy framework software compares the route or packet against the match conditions in the first term in the policy, then goes on to the next term, and so on. Therefore, the order in which you arrange terms in a policy is relevant.

The order of match conditions within a term is not relevant because a route or packet must match all match conditions in a term for an action to be taken.