Routing
Highlighted
Routing

Policy Statement

‎11-30-2017 11:01 AM

Hello,

I am new to using Junos!

I am trying to learn how to use the policy to send routes into routing protocols.

root> show configuration policy-options
policy-statement Test {
    term 1 {
        from {
            route-filter 2.2.2.2/32 address-mask 255.255.255.0;
        }
        then accept;
    }
}


---------------------------------------------------------

root> show configuration protocols bgp
export Test;
group test {
    neighbor 1.1.1.1 {
        peer-as 100;
    }
}

I expected this policy to match just the IP 2.2.2.2 with a mask /24. But this one matches other IP as well. I am wondering how this is working.

 

root> show interfaces terse | match lo0.0
lo0.0                   up    up   inet     2.2.2.3/24

Peer device:

 

root> show route protocol bgp

inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2.2.2.3/32         *[BGP/170] 00:06:49, localpref 100
                      AS path: 200 I
                    > to 1.1.1.2 via em0.0

root>
11 REPLIES 11
Highlighted
Routing

Re: Policy Statement

‎11-30-2017 03:52 PM

which route exactly u want to export?

 

if u just want to export 2.2.2.2/32 then write following statement..

 

route-filter 2.2.2.2/32 exact;

 

If you want to export route with 2.2.2.2/24 then you may use following statement in policy options.

 

route-filter 2.2 2.0/24 exact;


*************************************
HTH.
Accept this as solution if it resolved your issue.
Kudos would be appreciated too.
Highlighted
Routing

Re: Policy Statement

‎11-30-2017 04:10 PM
Hello Milind,

Thanks for the reply.

Can you please tell me what does this match 'route-filter 2.2.2.2/32 address-mask 255.255.255.0'? I was under the impression that it would match the host 2.2.2.2 with a /24 mask.

Highlighted
Routing

Re: Policy Statement

‎11-30-2017 07:50 PM

Hi,

 

Please read the below document which has a very good explanation about your query.

 

https://www.juniper.net/documentation/en_US/junos/topics/usage-guidelines/policy-configuring-route-l...

 

Example

 

Accept incoming IPv4 routes with a destination prefix of 10.1.0/24 and the third byte an even number from 0 to 14, inclusive:

[edit]
policy-options {policy-statement from_customer_a {term term_1 {from {route-filter 10.1.0.0/24 address-mask 255.255.241.0;}then {...reject;}}}}

The route filter in routing policy term term_1 matches the following incoming IPv4 route addresses:

  • 10.1.0.0/24
  • 10.1.2.0/24
  • 10.1.4.0/24
  • 10.1.6.0/24
  • 10.1.8.0/24
  • 10.1.10.0/24
  • 10.1.12.0/24
  • 10.1.14.0/24

The bit-wise logical AND of the netmask value and the candidate route address must match the bit-wise logical AND of the netmask value and the match prefix address. That is, where the netmask bit pattern 255.255.241.0 contains a set bit, the incoming IPv4 route address being evaluated must match the value of the corresponding bit in the destination prefix address 10.1.0.0/24.

 

Regards,

Rahul N

Highlighted
Routing

Re: Policy Statement

‎11-30-2017 07:56 PM

Accepting Incoming IPv4 Routes by Applying an Address Mask to the Route Address and the Destination Match Prefix

Accept incoming IPv4 routes with a destination prefix of 10.1.0/24 and the third byte an even number from 0 to 14, inclusive:

[edit]
policy-options {policy-statement from_customer_a {term term_1 {from {route-filter 10.1.0.0/24 address-mask 255.255.241.0;}then {...reject;}}}}

The route filter in routing policy term term_1 matches the following incoming IPv4 route addresses:

  • 10.1.0.0/24
  • 10.1.2.0/24
  • 10.1.4.0/24
  • 10.1.6.0/24
  • 10.1.8.0/24
  • 10.1.10.0/24
  • 10.1.12.0/24
  • 10.1.14.0/24

The bit-wise logical AND of the netmask value and the candidate route address must match the bit-wise logical AND of the netmask value and the match prefix address. That is, where the netmask bit pattern 255.255.241.0 contains a set bit, the incoming IPv4 route address being evaluated must match the value of the corresponding bit in the destination prefix address 10.1.0.0/24.

  • The first two bytes of the netmask value are binary 1111 1111   1111 1111, which means that a candidate route address will fail the match if the first two bytes are not 10.1.
  • The third byte of the netmask value is binary 1111 0001, which means that a candidate route address will fail the match if the third byte is greater than 15 (decimal), an odd number, or both.
  • The prefix length of the match prefix address is 24 (decimal), which means that a candidate route address will fail the match if its prefix length is not exactly 24.

As an example, suppose that the candidate route address being tested in the policy is 10.1.8.0/24 (binary 0000 1010   0000 0001   0000 1000).

  • When the netmask value is applied to this candidate route address, the result is binary 0000 1010   0000 0001   0000 0000.
  • When the netmask value is applied to the configured destination prefix address, the result is also binary 0000 1010   0000 0001   0000 0000.
  • Because the results of both AND operations are the same, the match continues to the second match criteria.
  • Because the prefix lengths of the candidate address and the configured destination prefix address are the same (24 bits), the match succeeds.

As another example, suppose that the candidate route address being tested in the policy is 10.1.3.0/24 (binary 0000 1010   0000 0001   0000 0011).

  • When the netmask value is applied to this candidate route address, the result is binary 0000 1010   0000 0001   0000 0001.
  • However, when the netmask value is applied to the configured destination prefix address, the result is binary 0000 1010   0000 0001   0000 0000.
  • Because the results of the two AND operations are different (in the third byte), the match fails.

Accepting Incoming IPv4 Routes with Similar Patterns But Different Prefix Lengths

Accept incoming IPv4 route addresses of the form 10.*.1/24 or 10.*.1.*/32:

[edit]
policy-options {policy-statement from_customer_b {term term_2 {from {route-filter 10.0.1.0/24 address-mask 255.0.255.0;route-filter 10.0.1.0/32 address-mask 255.0.255.0;}then {...reject;}}}}

The route filter match criteria 10.0.1.0/24 address-mask 255.0.255.0 matches an incoming IPv4 route address of the form 10.*.1/24. The route’s prefix length must be exactly 24 bits long, and any value is acceptable in the second byte.

The route filter match criteria 10.0.1.0/32 address-mask 255.0.255.0 matches an incoming IPv4 route address of the form 10.*.1.*/32. The route’s prefix length must be exactly 32 bits long, and any value is acceptable in the second byte and the fourth byte.

Evaluation of an Address Mask Match Type with Longest-Match Lookup

This example illustrates how a longest-match lookup evaluates a route filter that contains two address-mask match types. Consider the route filter configured in the routing policy term term_3 below:

[edit]
policy-options {policy-statement from_customer_c {term term_3 {from {route-filter 10.0.1.0/24 address-mask 255.0.255.0;route-filter 10.0.2.0/24 address-mask 255.240.255.0;}then {...}}}}

Suppose that the incoming IPv4 route source address 10.1.1.0/24 is tested against the route filter configured in the policy term term_3:

  1. The longest-match lookup tree for routing policy term term_3 contains two match prefixes: one prefix for 10.0.1.0/24 address-mask 255.0.255.0 and one prefix for 10.0.2.0/24 address-mask 255.240.255.0. When searching the tree for the longest-prefix match for a candidate, the longest-match lookup considers the number of contiguous high-order bits in the configured netmask-value instead of the length of the configured destination-prefix:

    • For the first route filter match criteria, the longest-match lookup entry is 10.0.0.0/8 because the netmask value contains 8 contiguous high-order bits.
    • For second route filter match criteria, the longest-match lookup entry is 10.0.0.0/12 because the netmask value contains 12 contiguous high-order bits.
    For the candidate route address 10.1.1.0/24, the longest-match lookup returns the tree entry 10.0.0.0/12, which is corresponds to the route filter match criteria 10.0.2.0/24 address-mask 255.240.255.0.
  2. Now that the longest-match prefix in term_3 has been identified for the candidate route address, the candidate route address is evaluated against the route filter match criteria 10.0.2.0/24 address-mask 255.240.255.0:

    1. To test the incoming IPv4 route address 10.1.1.0/24, the netmask value 255.240.255.0 is applied to 10.1.1.0/24. The result is 10.0.1.0.
    2. To test the configured destination prefix address 10.0.2.0/24, the netmask value 255.240.255.0 is applied to 10.0.2.0/24. The result is 10.0.2.0.
    3. Because the results are different, the route filter match fails. No actions, whether specified with the match criteria or with the then statement, are taken. The incoming IPv4 route address is not evaluated against any other match criteria.

*************************************
HTH.
Accept this as solution if it resolved your issue.
Kudos would be appreciated too.
Highlighted
Routing

Re: Policy Statement

‎11-30-2017 08:02 PM

Unlike firewall filters, the default action on policy-statement is accept .

So when you dont specify a default term to reject/deny everything else other than your match condition, everything else will be accepted.


root> show configuration policy-options
policy-statement Test {
    term 1 {
        from {
            route-filter 2.2.2.2/32 address-mask 255.255.255.0;
        }
        then accept;
    }
}


you need to add term 2 with action reject . If you have multiple policies use action as next-policy and configure reject on the last policy.

Ref: https://kb.juniper.net/KB27448

Thanks,
Suraj
Please Mark My Solution Accepted if it Helped, Kudos are Appreciated too
Highlighted
Routing

Re: Policy Statement

‎12-01-2017 07:04 PM

Hello Suraj,

Will this config work?

root@R2> show configuration policy-options policy-statement Test
term 1 {
    from {
        route-filter 2.2.2.2/32 address-mask 255.255.255.0;
    }
    then accept;
}
term 2 {
    then reject;
}

root@R2>
Highlighted
Routing

Re: Policy Statement

‎12-01-2017 07:17 PM

It will not block 2.2.2.3/24

 

root@R2> show configuration policy-options policy-statement Test
term 1 {
    from {
        route-filter 2.2.2.2/32 exact;
    }
    then accept;
}
term 2 {
    then reject;
}

 

Regards,

Rahul

 

 

Highlighted
Routing

Re: Policy Statement

‎12-01-2017 07:22 PM
Hello Rahul,

But will this block everything else? Or do I have to write a from statement as well. From should be any.

term 2 {
then reject;
}

Just trying to learn basics.. Smiley Happy
Highlighted
Routing

Re: Policy Statement

‎12-01-2017 07:28 PM

term 2 reject is enough Smiley Happy

 

Regards,

Rahul

Highlighted
Routing

Re: Policy Statement

‎12-23-2017 09:22 AM

Hi Folks,

Just to add…

 

Please avoid using /24 network for the loopback interface. Junos OS requires that the loopback interface always be configured with a /32 network mask because the Routing Engine is essentially a host.

 

 

 

-Python JNCIE 3X [SP|DC|ENT] JNCIP-SEC JNCDS 3X [ WAN | DC|SEC] JNCIS-Cloud JNCIS-DevOps CCIP ITIL
#Please mark my solution as accepted if it helped, Kudos are appreciated as well.
Highlighted
Routing

Re: Policy Statement

‎01-02-2018 04:20 PM

Here is a great source of information to understand routing policy and firewall filters.

https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-routing-overview.html

 

[KUDOS PLEASE! If you think I earned it!
If this solution worked for you please flag my post as an "Accepted Solution" so others can benefit..]