Training, Certification, and Career Topics
Training, Certification, and Career Topics

policy-option

‎01-03-2017 06:28 PM

Hi there,

Why is the section B correct in the following question? Aren't routes from between 172.27.0.0/25 -/32 rejected in line with its match type -longer?

 

[edit policy-option]

user@router#show

policy-statement my-policy{

term 1 { from {

router-filter 172.27.0.0/24 longer;

}}

then reject;

}

which statement is correct about the policy shown in the exhibit?

A- All routes are accepted

B- All routes are rejected

C- A 172.27.0.0./24 route will be accepted.

D-A 172.27.0.0./16 route will be accepted.

 

Thanks.

5 REPLIES 5
Training, Certification, and Career Topics

Re: policy-option

‎01-03-2017 08:08 PM

Hi,

 

I think your understanding is correct. Option B does not look to be the correct answer. In route-filter when we use "longer", it matches - if the prefix-length is greater than the route’s prefix length. In this case, it should match anything greater than 172.27.0.0/24.

 

IMO, if we look at all the options, option C looks to be best fit. In some cases, it also depends on what is the next-term or next-policy configured and if nothing is configured, it would use the default policy action.

 

For more details, please refer to following links:

Understanding Route Filters for Use in Routing Policy Match Conditions

Route Filter Match Conditions

Default Routing Policies and Actions

 

Hope it helps.

 

Thanks

Hope this helps

--------------------------------------------------------------------------------------------------------
If this post was helpful, please mark this post as an "Accepted Solution".
Kudos are always appreciated!
--------------------------------------------------------------------------------------------------------
Training, Certification, and Career Topics

Re: policy-option

‎01-03-2017 09:01 PM

 

Hi Folks,

Based on the above configuration; I would vote for both option C and D. Since the policy is configured to explicitly reject prefixes 172.27.0.0/25 -/32 and can accept all other prefixes based on the below assumptions! Please find this simple self-explanatory example,


+--------------+         +--------------+

|              |  ebgp   |              |

|   1.1.1.1    +---------+   1.1.1.2    |

|              |         |              |

|   lab A      |   <<----|    lab B     |

+--------------+   Prefixes advertised--+

                   1.1.56.0/30

                   172.27.0.0/16

                   172.27.0.0/24

                   172.27.0.8/30

                   172.27.0.104/30

                   192.168.1.106/32

Lab A is receiving multiple prefixes from my bgp peer 1.1.1.2 lab B

 

By default:

labA> show route receive-protocol bgp 1.1.1.2       

 

inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)

  Prefix                  Nexthop              MED     Lclpref    AS path

* 1.1.56.0/30             1.1.1.2                                 100 I

* 172.27.0.0/16           1.1.1.2                                 100 100 I

* 172.27.0.0/24           1.1.1.2                                 100 100 I

* 172.27.0.8/30           1.1.1.2                                 100 100 I

* 172.27.0.104/30         1.1.1.2                                 100 100 I

* 192.168.1.106/32        1.1.1.2                                 100 100 I

 

Applying Policy:

 

labA> show configuration policy-options

policy-statement my-policy {

    term 1 {

        from {

            route-filter 172.27.0.0/24 longer;

        }

        then reject;

    }

}

 

labA> show configuration protocols bgp    

import my-policy; <<<<<<

export connected_to_bgp;

group PE_PEERING {

    neighbor 1.1.1.2 {

        local-address 1.1.1.1;

        peer-as 100;

    }

}

 

Post Applying the Policy, 172.27.0.8/30 and 172.27.0.104/30 are no more accepted in the routing table

lab> show route receive-protocol bgp 1.1.1.2                 

 

inet.0: 9 destinations, 9 routes (7 active, 0 holddown, 2 hidden)

  Prefix                  Nexthop              MED     Lclpref    AS path

* 1.1.56.0/30             1.1.1.2                                 100 I

* 172.27.0.0/16           1.1.1.2                                 100 100 I

* 172.27.0.0/24           1.1.1.2                                 100 100 I

* 192.168.1.106/32        1.1.1.2                                 100 100 I

 

To see all the routes recived from my peer:

lab> show route receive-protocol bgp 1.1.1.2 all

 

inet.0: 9 destinations, 9 routes (7 active, 0 holddown, 2 hidden)

  Prefix                  Nexthop              MED     Lclpref    AS path

* 1.1.56.0/30             1.1.1.2                                 100 I

* 172.27.0.0/16           1.1.1.2                                 100 100 I

* 172.27.0.0/24           1.1.1.2                                 100 100 I

  172.27.0.8/30           1.1.1.2                                 100 100 I

  172.27.0.104/30         1.1.1.2                                 100 100 I

* 192.168.1.106/32        1.1.1.2                                 100 100 I

 

The reason for not being selected:

lab> show route receive-protocol bgp 1.1.1.2 detail hidden

 

inet.0: 9 destinations, 9 routes (7 active, 0 holddown, 2 hidden)

  172.27.0.8/30 (1 entry, 0 announced)

     Nexthop: 1.1.1.2

     AS path: 100 100 I

     Communities: target:100:111111

     Hidden reason: rejected by import policy

 

  172.27.0.104/30 (1 entry, 0 announced)

     Nexthop: 1.1.1.2

     AS path: 100 100 I

     Communities: target:100:111111

     Hidden reason: rejected by import policy

 

lab>

 

Few Pointers:

https://www.juniper.net/documentation/en_US/junos14.1/topics/usage-guidelines/policy-configuring-act...

https://www.juniper.net/documentation/en_US/junos14.1/topics/concept/policy-routing-policies-actions...

http://www.juniper.net/documentation/en_US/junos15.1/topics/usage-guidelines/policy-configuring-rout...

 

-Python

#Please mark my solution as accepted if it helped, Kudos are appreciated as well.

-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.
Training, Certification, and Career Topics

Re: policy-option

‎01-04-2017 09:59 PM

i beleive the question is incomplete as its not known on which protocol the policy is applied and wether as import or export policy. Every potocol will have it default actions for importing and exporting routes and this default behavior should get executed if there is no match found in policy.

 

Now if the policy mentioned by you is a export policy on RIP, then option B is correct answer as the default  export action on RIP is to reject.

Training, Certification, and Career Topics

Re: policy-option

[ Edited ]
‎01-04-2017 10:10 PM

That is absolutely true; the question was quite open! That's the reason i have confined my examples/results with specific highlighted assumptions* and shared the pointers for Default Routing Policies.

 

-Python

-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.
Training, Certification, and Career Topics

Re: policy-option

[ Edited ]
‎12-28-2017 02:05 PM

After long thinking I think the answer B is actually correct(at first wanted c or D but single answer question). 

Because there is no routes accepted like static,bgp,direct, etc. then ALL routes will be rejected.

there is no term 2 that would be accepting anything else.

 

as somebody said it is unclear from the output in the question...

 

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

p.s. EDIT

 

had a second thought about it:

1. question asks about this policy only

2. there is no info to which protocol will be applied

3. the lab that PYTHON has done is applying it to BGP which has a default policy that accepts imported and exported routes. 

So if the question would apply the policy to BGP then the lab would make sense but not here. 

For example RIP rejects routes by default in the export policy. if this would be applied to it the result would be different. 

4. REJEcT is terminating action so flow is killed at this point too. there is no action: 'next term' nor 'next policy'