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;
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 {
then action1;
term test12 {
from {
then {
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-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 exact’ matches only prefix.

o orlonger

§ match all prefix >= specified prefix

§ ‘”route-filter orlonger” matches 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 upto /18”

o prefix-length range

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

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

o through

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

§ eg: “route-filter through” matches /16 , /19 , /17 , /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


· 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.


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


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


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


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.


Community RegEx:

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




Matches atleast m and at most n instances


Matches exactly m instance of the term


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


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>”

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

1 Response to Route-policy in JUNOS

  1. Mohamed Ibrahim says:

    Hello, Many thanks for great explanation ..
    I have one question , in this point related to regular community
    ” 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”

    Is there any way to make it logical OR

    Thanks alot


Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s