Junos routing policy allows us to allow, deny, or manipulate the routes when they are imported from a routing protocol to the routing table or exported from the routing table to a routing protocol.
This section discusses the concept of routing policy. In the next section, we configure a real routing policy in SRX devices.
Junos routing policy Fundamental
Why do we need Routing Policy?
Why do we need Routing Policy?
Sometimes want to filter a route when it is learned or when is advertised resulting in filtering in the communication. However, the filtering is done at the control plane, which has less overhead compared to filtering traffic at the data plane, where each packet must be inspected.
Sometimes we want to change the path to reach to a specific destination. This can be done by filtering the route from or to undesired path or neighbor, or we can change the route attributes like metric and next-hop to change the path.
If no policy is configured or a receive route or advertising route does not match any policy in the device, the route is behaving as defined in the default routing policy.
default Routing Policy
What is default routing policy?
Honestly, we have not learned a lot about dynamic routing protocols in this course, and probably these concepts does not make sense to remember but not bad to hear them at least once.
By default, all routes received from OSPF, IS-IS and BGP routing protocols are accepted and installed in the routing table. Routes received from RIP routing protocol are accepted only if the neighbor, from which the routes are received, is explicitly configured.
By default all active BGP routes in the routing table are advertised to every BGP neighbor. In OSPF and ISIS, there are not routes, which are advertised instead LSA or LSP (in OSPF and ISIS in order), which show the state of the links, are advertised.
And by default no routes from routing table is advertised to any RIP neighbor.
Routing Policy Building Block
How Routing Policy Works?
Each route policy has a set of rules, or “terms” in Junos terminology. For each term there is a “from” command that matches the routes and a “then” command that is the action to be taken on matching routes.
The terms are processed in order, and if a route matches a term, then the action is taken.
The most common way to match a route is by prefix. There are two tools, “route-filter” and “prefix-list”, by which we can match the routes by matching the prefix. We will shortly explain these two tools and the differences. But you can also match routes from a specific routing protocol, route attributes or next-hop address.
The most common actions are to permit, deny, or change the attribute of the matching routes. If a route matches a term with these actions, the process ends. But if the action is “next term” or “next policy”, then the route continues to be processed by next rule or next policy.
Junos prefix-list versus route-filter
With both prefix-list and route-filter you can match routes based on both prefix and also subnet mask.
There are two differences between them:
First,, prefix-list can be reused in multiple terms or policies. But route-filter cannot be re-used
Second, with prefix-list, there is less flexibility to match the subnet mask. you can match the subnet 192.168.1.0/24 with the mask /24 “exactly” or bigger (orlonger) but you cannot match the subnet mask with for example, less than /30 or between /28 and /30.
But with route filter there are more operators. “exact”, “orlonger”, “longer”, “upto”, and “prefix-list-range” operators give us the ability to match the subnet mask exactly, greater than or equal to a specific length, less than or equal to a specific length, and the Subnet mask length between two values.
Junos Route Policy Example
To better understand the Junos Route Policy, here there is an example.
In the left side, there is policy. In the right side the policy is applied to OSPF as export policy. That means when the routes are exported from routing table to the OSPF routing protocol, then this policy will be applied.
The policy tells that the connected routes related to interface ge-0/0/0 and also static routes matching exactly 172.18.1.0/24 and 172.18.2.0/24 and also any RIP routes in the routing tables are allowed to be exported to OSPF routing protocol. All other routes are rejected by default policy.
In the next section we will implement a real routing policy scenario in SRX devices.