Routing Policy basic concept

 Composing a Routing Policy

The application of a routing policy is always performed from the perspective of the routing table. Routes being placed into the routing table are said to be “inbound.” 

Routes being extracted from the routing table are said to be “outbound.”

Policy Processing

Each policy contains three possible results:

• accept
• reject
• next policy

A basic routing policy hierarchical concept

policy-options {

     policy-statement policy-name  {

          from {
               match-conditions;
          }

          then {
               actions;
          }
     }
}


              Policy Segmentation

A multiterm policy looks similar to the following:

policy-options {

     policy-statement policy-name {
    
          term term-name {
               from {
                    match-conditions;
               }
               then {
                    actions;
               }
          }

          term term-name {
               from {
                    match-conditions;
               }
               then {
                    actions;
               }
          }
     }
}


              Match Conditions ( from and to )

          from

The protocol match condition is another widely used match criterion. This criterion essentially
means, “How did the route get placed into the routing table?”

policy-options {

     policy-statement bgp-import {

               term coming-from-ISPA {

                    from neighbor 2.2.2.2;
                    then reject;
          }
     }
}

          to


policy-options {

     policy-statement isis-export {

          term sending-to-neighborA {
               to level 2;
               then accept;
          }
     }
}

              Defining Multiple Criteria

policy-options {

     policy-statement bgp-import {

          term coming-from-neighborA {
               from {
                    neighbor 1.1.1.1;
                    metric 10;
               }
               then accept;
          }

          term deny-other-neighborA {
               from neighbor 1.1.1.1;
               then reject;
          }
      }
 }


              Route Filters

Syntax

route-filter prefix/prefix-length match-type actions;

The prefix and prefix-length variables are simply the reference point on the radix tree where you would like to start finding a route. One of six possible match type keywords describes the additional routes on the radix tree that will match the route filter. If any optional actions are defined, they will be processed immediately, allowing the policy to skip actions configured using the then statement.

           match-types

exact  The exact match type will locate only the route at the specified point in the tree.

route-filter 192.168.0.0/16 exact;

orlonger The orlonger match type will also match the route specified in the route filter. In addition, it will match all routes more specific than the specified route. This more specific match will continue until the bottom of the radix tree (the 32nd level) is reached. This match type is similar to a greater- than-or-equals-to operation in mathematics.

The following route filter matches the 192.168.0.0 /16 route and all routes below it in the radix tree:

route-filter 192.168.0.0/16 orlonger;

longer The longer match type is similar to the orlonger match type. The difference between them is that longer will only match routes that are more specific than the specified route. This match type is analogous to the mathematical greater-than operation.
The following route filter matches only the routes below the 192.168.0.0 /16 route in the radix tree starting with 192.168.0.0 /17 and 192.168.128.0 /17:

route-filter 192.168.0.0/16 longer;

upto The upto match type provides the router with a starting prefix and an ending prefix length. The match type locates the route specified in the route filter and starts to match all routes more specific than the specified route. The route matching stops when it reaches the level in the radix tree configured in the route filter. This behavior mimics the orlonger function except now we’re specifying a bottom boundary in the tree lookup instead of letting it continue to the 32nd level of the tree.
The following route filter matches the 192.168.0.0 /16 route. It then starts matching all of the more specific routes until it reaches the 18th level of the tree and matches those routes. In this way, upto is an inclusive match type. If we look back at Figure 4.9, we’ll see that this route filter locates seven total routes.

route-filter 192.168.0.0/16 upto /18;

prefix-length-range Much like the relationship between orlonger and longer, the prefix-length-range and the upto match types are very similar. Recall that upto allows you to configure a bottom boundary in the radix tree lookup. prefix-length-range also provides this capability but adds to it the ability to specify a starting boundary in the radix tree as well. It is important to remember that all routes located by this match type will still share the same more significant bits as configured in the prefix/prefix-length portion of the route filter.
The following route filter starts looking for routes at the 192.168.0.0 /16 level of the radix tree. It starts to match routes at the 17th level of the tree and stops matching routes at the 18th level. Like upto, this is also an inclusive match type. Using Figure 4.9 as a reference again, we’ll see that this route filter locates six total routes.

route-filter 192.168.0.0/16 prefix-length-range /17-/18;

through The through match type is very different from the others we’ve talked about. The configuration for this match type requires you to specify both a starting route and an ending route. The route filter matches both of these routes exactly and then further locates only the routes on the radix tree that connect the two.
The following route filter matches the 192.168.0.0 /16 and 192.168.128.0 /19 routes. It also matches the 192.168.128.0 /17 and 192.168.128.0 /18 routes because they are the routes between the start and end points. A quick look back at Figure 4.9 can verify this.

route-filter 192.168.0.0/16 through 192.168.128.0/19;

             Multiple Route Filters

policy-options {
      policy-statement bgp-export {
            term coming-from-neighborA {
                  from {
                        route-filter 192.168.0.0/16 orlonger;
                        route-filter 192.168.0.0/24 exact;
                  }
                  then accept;
            }
       }
}


            Route Filters and Other Match Criteria

               Absence of Match Criteria

policy-options {
          policy-statement ibgp-export {
                    term accept-all-routes {
                              then accept;
                    }
          }
}

When no match criteria are used, every active route in the routing table will match the policy. In other words, the absence of match criteria means that all routes match. All routes then take the configured actions of the policy term. In the case of this particular policy, all routes would be accepted by the policy.
Finding routes in the routing table is only the first step in using a routing policy. After they are located, we must then decide what to actually do with them. This is the job of a policy action.



            Actions

Flow Control

policy-options {
     policy-statement bgp-import {
        term coming-from-neighborA {
            from {
            neighbor 1.1.1.1;
            metric 10;
            }
            then next policy;
        }
        term deny-other-neighborA {
            from neighbor 1.1.1.1;
            then reject;
        }
    }
}
Routes arriving from the BGP neighbor of 1.1.1.1 that also have a MED of 10 will match the first policy term of coming-from-neighborA. The configured action of next policy directs the candidate routes to the next policy in the policy chain without any other immediate actions taken. All other routes from neighbor 1.1.1.1 match the second policy term of denyother-neighborA and are immediately rejected. This policy allows us to selectively avoid the daisy-chain processing for a portion of the received routes.

Action Modifiers

Before a candidate route is accepted or rejected by a terminating action, you can modify the attributes of the route.

policy-options {
      policy-statement bgp-import {
            term coming-from-neighborA {
                  from {
                        protocol bgp;
                        neighbor 1.1.1.1;
                  }
                  then {
                        metric 20;
                        accept;
                  }
            }
      }
}

All BGP routes received from the neighbor address of 1.1.1.1 have the MED attribute set to 20 and are installed into the routing table via the accept action.

Default Policy

            Border Gateway Protocol (BGP)

Import Policy (All Peers) A BGP router will accept all non-looped BGP routes received from another BGP router.
Export Policy (External Peers) A BGP router will advertise all active BGP routes in inet.0 to all configured external BGP peers.
Export Policy (Internal Peers) A BGP router will advertise all active BGP routes in inet.0 to all internal peers if the routes were originally received from an external peer.



            Routing Information Protocol (RIP)

The default import and export policies for the JUNOS software implementation of RIP do not follow a “normal” operation of a distance-vector protocol. The default import policy is to accept all routes advertised to the local router via RIP. The default export policy for RIP is to not advertise any routes to any neighbors. One main reason for this seemingly odd behavior is that a Juniper Networks router is designed to run in the core of the Internet and RIP is not well suited for that use. However, many customer implementations need to receive RIP routes in their networks from server farms or remote access servers. These routes would then be advertised to the rest of the network using a different routing protocol. The JUNOS software defaults for RIP support this functionality.


            Open Shortest Path First (OSPF)

OSPF is a link-state routing protocol that mandates that each router in an OSPF area maintain an identical link-state database. Filtering out and rejecting incoming routing information could break this mandate, so import policies are not permitted. This means that there is no default import policy for OSPF.
The default export policy for OSPF is to reject all routes. While this sounds very similar to the default RIP export operation, things are actually quite different. OSPF advertises routing information in a format called a link-state advertisement (LSA). These LSAs contain the local router’s networks and are generated by the protocol based on the current router configuration for OSPF and not on the routing table. In addition, these LSAs are flooded by the protocol on all operational OSPF interfaces. In this manner, all routers in the network receive a copy of each router’s information without ever consulting the routing table.


            Intermediate System to Intermediate System (IS-IS)

Like OSPF, IS-IS is a link-state routing protocol. It also must maintain an identical link-state database on all routers in an IS-IS level. This once again means that import policies are not permitted and that there is no default import policy for IS-IS.
Route advertisements are also very similar to OSPF in that information is flooded throughout the network using an update packet called a link-state PDU (LSP). These LSPs are flooded throughout the network to all IS-IS routers using operational IS-IS interfaces. The difference with IS-IS, however, is how the local router populates its own LSP. In OSPF, this was accomplished via the router’s configuration. For IS-IS, this information is actually retrieved from the routing table. To accommodate this difference, the default export policy for IS-IS is to export all direct routes configured for IS-IS.