Route-policy in JUNOS

  • Route Policy similar to the function of route-map in IOS. Used to override and alter the selections made by routing protocols.
  • Inbound/import route-policy: policy by which received routes from the neighbor are installed into routing table.
  • Outbound/export route-policy: Policy by which routes from routing table are advertised to neighbors.
  • Policy Chain:
    • Routes are acted upon by set of policies. Three actions are possible;
      • accept
      • reject
      • next policy
    • If a route matches an accept/reject policy, further check on next policies will not be done. Finally, if a route is not matched by any of the configured policies, ‘default-policy’ will be applied.
  • Basic routing policy will look like; (policy)
policy-statement test1 {
from {
protocol bgp;
external;
}
then accept;
}
  • Each policy can have many ‘term’ . Each term will be executed in seqencial manner. Two advantages;
    • A single policy with multiple match conditions and actions can be implemented.
    • In case, if we need to add another condition, it can be easily done by a new ‘term’.
  • A route-policy with term will look like;
policy-statement test1 {
term test11 {
from {
match-condition1
}
then action1;
}
term test12 {
from {
match-condition2
}
then {
action2;
}
}
}
Match conditions;

  • ‘from’ and ‘to’;

  • ‘protocol’ condition is most used option. Eg: ‘protocol bgp’ to match routes from/to bgp protocol.

Defining multiple criteria;
  • When multiple statements are included in ‘from’ or ‘to’, logical AND operation will be performed.

Route-filters

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

· match-type can be any of the following 4 options;

o exact

§ to match the prefix = exactly.

§ ‘route-filter 192.168.0.0/16 exact’ matches only 192.168.0.0/16 prefix.

o orlonger

§ match all prefix >= specified prefix

§ ‘”route-filter 192.168.0.0/16 orlonger” matches 192.168.0.0/16 prefix and all prefix > /16

o longer

§ Same as above, but matches only prefix greater than prefix-length. >

o upto

§ Routes from starting prefix to an ending prefix-length. (,)

§ eg: “route-filter 192.168.0.0/16 upto /18”

o prefix-length range

§ Routes excluding starting prefix to an ending prefix-legth. {,}

§ eg: “route-filter 192.168.0.0/16 prefix-length-range /17-/18”

o through

§ Routes from the starting prefix to ending prefix along the radix tree.

§ eg: “route-filter 192.168.0.0/16 through 192.168.128.0/19” matches 192.168.0.0 /16 , 192.168.128.0 /19 , 192.168.128.0 /17 , 192.168.128.0 /18

· When there are multiple route-filter statements, a longest match lookup is taken place and the action of the matched route-filter will be performed.

· When there are multiple route-filter statements and other matching conditions, first longest match lookup is done and then other match conditions are checked with logical AND operation.

· When there is no match conditions, all routes are matched

· The action item of a term could be;

o accept

o reject

o next policy

o next term

o modify any of the attributes

DEFAULT POLICY:

· BGP:

o Import policy (all peers): BGP router will accept all routes

o Export policy (External peers): BGP router will advertise all active routes in inet.0 routing table to all configured external peers

o Export policy (Internal Peers): BGP router will advertise all active routes in inet.0 routing table to all configured external peers if route was originally received from EBGP peer.

· RIP:

o Default import policy is to accept all routes.

o Default export policy is not to advertise any routes to any neighbor.

§ Reason: Juniper routers are designed to run on core of the ISP. No need to advertise RIP routes.

· OSPF:

o No default import policy.

§ Reason: Link state database in all routers in an area should be same.

o Default export policy is to reject all routes.

§ Reason: LSAs are generated by protocol based on the ospf configuration in a router and not from the routing

· ISIS:

o No Default import policy. Same reason as for OSPF.

o Default export policy is to export all direct routes configured for IS-IS.

§ Reason: As all LSPs (Link State PDUs) are retrieved from the routing table.


Applying route-policy to protocol;

· Route policies are applied to protocol using ‘import’ and ‘export’ keyword.

· “Import [ policy1 policy2….]” . Default policy at the end is implicit

· Route policies can be applied at different levels;

o Global ( when configured inside protocol mode)

o Group (when configured inside a group)

o Neighbor (when configured for a specific neighbor)

· Neighbor level import/export is most preferred; and if not configured, then group level; if not configured global level import, export policies will be implemented.

· We can configure either individually (new policies are appended to already configured) or with single command (as in above second point)

· To insert a new policy at any location, use ‘insert’ command.

o Syntax: “insert export policy1 before|after policy2

· To rename a policy-statement or term, use ‘rename’ command.

o Syntax: “rename policy1 to policy2

· ‘Show route receive-protocol’

o To view routes before a policy is applied.

· ‘Show route advertising-protocol’

o To view outbound routes after a export policy was applied.

· To advertise OSPF routes to an ISIS neighbor, we need to configure an export policy under [edit protocol isis] that matches ospf routes and accept them

ADVANCED ROUTE-POLICY

Policy Processing;

· Advanced policy methods include policy chains, a subroutine, a prefix-list, and a policy expression to accomplish same task.

· Policy chain;

o Make each match-condition in separate terms/policy statements.

o Invoke those policies with export/import option.

o ‘Import [policy1 policy2 policy3]’. First a route is checked with policy1. If not matched, it is checked with policy2 and if still not matched it is checked with policy3. If still not matched default-policy is invoked.

· Policy Subroutine;

o In programming, a subroutine is a part code which can be referenced on regular basis.

o Similarly, we can refer a policy as match criterion for another policy.

o The evaluation of subroutine returns TRUE or FALSE Boolean result to main policy.

o TRUE means main policy has a match and the action for the matched route in the main policy will be performed. FALSE means main policy does not have a match.

o The default policy of the protocol where the subroutine is applied is always evaluated as a part of the subroutine itself.

o For Eg: If we provoke a subroutine in a policy applied to BGP protocol, default BGP policy is checked as a part of subroutine policy to determine True/False result.

o Syntax: Inside the policy-statement/term for matching condition, use ‘from policy subroutine-name’

· Prefix-list;

o A list of IP prefix that can be used as match criteria.

o A prefix-list is created with a name under [edit policy-option] mode. This list is invoked inside a term using ‘from prefix-list name’.

o JUNOS evaluates this list as route-filter with ‘exact’ option.

· Policy expressions;

o Combination of policies acted upon by logical operators.

o Possible logical operators are (in the order of precedence)

§ Logical NOT

· Reverses the logic evaluation of policy. A true result becomes false and vice versa. Denoted by !policy1

§ Logical AND

· Policy1 && policy2. If the result of first policy is true, second policy is evaluated. If the result of first policy is false, second is skipped.

§ Logical OR

· Policy1 || policy2. If the first policy is true, second policy is skipped. If the first policy result is false, second policy is executed.

§ Group operator

· In case we need to change the above order of execution, we can use group operator. (policy1 || policy2) && policy3.

  • Default policy is not evaluated within the expression. Evaluated as a part of normal policy chain.
  • Router evaluates individual policies to check for true or false result. A TRUE result when either accept or next policy action is found. ‘next policy’ can be either explicitly configured or when the route doesn’t match any term in the policy. A FALSE result when reject option is encountered.
  • Action depends on which policy evaluation guaranteed the result of an expression.

o OR operation: policy1 || policy2

§ When policy1 result is true, then it guaranteed the result of expression and hence action of policy1 is applied to the routes. Policy2 is skipped.

§ If policy1 result is false, router evaluates policy2 and its result will guarantee the expression result. Hence the action of policy2 is applied.

o AND operation: policy1 && policy2

§ When policy1 result is true, it doesn’t guarantee the result of expression and hence the policy2 is evaluated and its action is applied.

§ When policy1 result is false, it guaranteed the result of the expression and the policy2 is not evaluated. Action of policy1 is applied.

o NOT operation: !policy1

§ When the NOT operation result is true, router transforms that into false evaluation and the routes are rejected. When the operation result is not true, routes are accepted

COMMUNITIES;

An attribute attached to BGP routes.

Regular community;

· A 32-bit value divided into two sessions. First 16 bit represents AS number and the next 16 bit is user defined value community value. Represented in JUNOS as “AS number: community-value”

· A community name is created in policy-options mode. [edit policy-options]

· Syntax; “community name members [community ids]”

· When more than one community ID is used inside the braces, logical AND is performed. Ie; only routes with all community IDs will be matched.

· Use “show route” with “detail” option to see community attributes.

· Can be used as match criteria;

o “from community community-name

o “from community [name1 name2]”. Logical OR operation is performed between those two community names. Ie; route with either community will match.

· To modify current community values;

o add – Policy action ‘then community add community-name’ , adds the community value to the already existing community list.

o Set – Policy action ‘then community set community-name’ , deletes all available community values and adds the community-value present in the community-name.

o delete – Policy action ‘then community delete community-name’ , deletes the community values in the community-name and retains other values.

Extended Communities;

· Used for L2, L3 VPN. 64-bit value (8-octets). Three fields: Type, Administrator and assigned number.

· Type (2 –octet);

o Higher octet can be 0x00 which means 2-octet Administrator field and 4-octet assigned number field. 0x01 means vice versa.

o Lower order octet determines kind of community used. 0x02 implies route-target (RT) community and 0x03 implies route-origin community.

· Administrator field;

o Represents the AS where the community originates. Can be decimal number (if 2-octet) or it can be router-id (IP address) of the originating router (if 4-octet)

· Assigned number;

o A number to uniquely identify the community.

· Notation: “type: administrator: assigned number”. We need to provide either “target” or “origin” in the field of type.

· Same options available as for regular communities.

REGULAR EXPRESSIONS:

Community RegEx:

  • “.” represent single decimal value. “*” represents any value.
  • Complex RegEx operators;

Operator

Descriptions

{m,n}

Matches atleast m and at most n instances

{m}

Matches exactly m instance of the term

{m,}

Matches m or more instances of the term

*

Matches 0 or more instance. {0,}

+

Matches 1 or more instance. {1,}

?

Matches 0 or 1. {0,1}

^ and $

Beginning and end of community/AS

[]

Matches range/array of digit. Single term.

  • Usually, a term is followed by operator [term,operator]. For eg: in “3+4”. Operator “+” is for the term “3” and not “4”. It matches value of 34,334 and 3334.
  • Can be verified by using “test policy policy-name prefix
  • Same applies to AS path regular expression. Few examples;

AS Path Reg Ex

Description

To match

.* 65050

All BGP routes originated from particular AS

65050 .*

All BGP routes originated from particular neighboring AS

.* 65050 .*

All BGP routes routed via particular AS

.* (64512-65535) .*

To detect any private AS in As path

()

AS Path with length of 0. Local AS routes

  • We can check/verify AS path regex using “show route terse aspath-regex <expression>”

Advertisements
This entry was posted in jncis, Junos and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s