Mailing List Archive: Nested subroutine behaviour

Nested subroutine behaviour

Feb 26, 2019, 2:01 PM

Post #1 of 4 (713 views)

Hi,

I’m having a hard time wrapping my head around behaviour with route policies that consist of nested subroutines.

Consider the sample below:

jlixfeld@mx# run show route receive-protocol bgp 4.4.4.4 table internet.i.0 hidden extensive

i.inet.0: 32 destinations, 37 routes (28 active, 0 holddown, 6 hidden)
1.1.1.1/32 (1 entry, 0 announced)
Nexthop: 4.4.4.4
MED: 0
AS path: 4444 ?
Hidden reason: rejected by import policy

8.8.8.8/32 (1 entry, 0 announced)
Nexthop: 4.4.4.4
MED: 0
AS path: 4444 ?
Hidden reason: rejected by import policy

[edit]
jlixfeld@mx#

policy-options {
policy-statement P-TEST1 {
term SUB1 {
from policy SUB1;
then reject;
}
}
policy-statement SUB1 {
term SUB2 {
from policy SUB2;
}
}
policy-statement SUB2 {
term NOMATCH {
from route-filter 1.1.1.1/32 exact;
}
}
}
routing-instances {
i {
protocols {
bgp {
group G {
type external;
neighbor 4.4.4.4 {
import P-TEST;
peer-as 4444
}
}
}
}
}
}

From the docs I’ve, the policy should not reject 8.8.8.8/32, yet it says it is rejected by import policy.

My understanding of the above policy is:

Policy P-TEST1 calls subroutine SUB1
Policy SUB1 calls subroutine SUB2
Policy SUB2 does not match 8.8.8.8/32 against term NOMATCH, so it passes false to SUB1
SUB1 passes false to P-TEST1
P-TEST1 has no default action, so it permits 8.8.8.8/32 as BGP’s default action is permit.

Conversely, 1.1.1.1/32 gets rejected as expected:

Policy P-TEST1 calls subroutine SUB1
Policy SUB1 calls subroutine SUB2
Policy SUB2 matches 1.1.1.1/32 against term NOMATCH, so it passes true to SUB1
SUB1 passes true to P-TEST1
P-TEST1 action for match/permit is reject, so it rejects 1.1.1.1/32.

I’m obviously missing something…

Anyone got a light?
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: Nested subroutine behaviour [ In reply to ]

adamv0025 at netconsultings

Feb 27, 2019, 12:15 AM

Post #2 of 4 (710 views)

Permalink

Try adding:
policy-options {
policy-statement P-TEST1 {
term ALLOW_REST {
then accept;
}
}

adam
> -----Original Message-----
> From: juniper-nsp <juniper-nsp-bounces@puck.nether.net> On Behalf Of
> Jason Lixfeld
> Sent: Tuesday, February 26, 2019 10:02 PM
> To: juniper-nsp <juniper-nsp@puck.nether.net>
> Subject: [j-nsp] Nested subroutine behaviour
>
> Hi,
>
> I’m having a hard time wrapping my head around behaviour with route
> policies that consist of nested subroutines.
>
> Consider the sample below:
>
> jlixfeld@mx# run show route receive-protocol bgp 4.4.4.4 table internet.i.0
> hidden extensive
>
> i.inet.0: 32 destinations, 37 routes (28 active, 0 holddown, 6 hidden)
> 1.1.1.1/32 (1 entry, 0 announced)
> Nexthop: 4.4.4.4
> MED: 0
> AS path: 4444 ?
> Hidden reason: rejected by import policy
>
> 8.8.8.8/32 (1 entry, 0 announced)
> Nexthop: 4.4.4.4
> MED: 0
> AS path: 4444 ?
> Hidden reason: rejected by import policy
>
> [edit]
> jlixfeld@mx#
>
> policy-options {
> policy-statement P-TEST1 {
> term SUB1 {
> from policy SUB1;
> then reject;
> }
> }
> policy-statement SUB1 {
> term SUB2 {
> from policy SUB2;
> }
> }
> policy-statement SUB2 {
> term NOMATCH {
> from route-filter 1.1.1.1/32 exact;
> }
> }
> }
> routing-instances {
> i {
> protocols {
> bgp {
> group G {
> type external;
> neighbor 4.4.4.4 {
> import P-TEST;
> peer-as 4444
> }
> }
> }
> }
> }
> }
>
> From the docs I’ve, the policy should not reject 8.8.8.8/32, yet it says it is
> rejected by import policy.
>
> My understanding of the above policy is:
>
> Policy P-TEST1 calls subroutine SUB1
> Policy SUB1 calls subroutine SUB2
> Policy SUB2 does not match 8.8.8.8/32 against term NOMATCH, so it passes
> false to SUB1
> SUB1 passes false to P-TEST1
> P-TEST1 has no default action, so it permits 8.8.8.8/32 as BGP’s default action
> is permit.
>
> Conversely, 1.1.1.1/32 gets rejected as expected:
>
> Policy P-TEST1 calls subroutine SUB1
> Policy SUB1 calls subroutine SUB2
> Policy SUB2 matches 1.1.1.1/32 against term NOMATCH, so it passes true to
> SUB1
> SUB1 passes true to P-TEST1
> P-TEST1 action for match/permit is reject, so it rejects 1.1.1.1/32.
>
> I’m obviously missing something…
>
> Anyone got a light?
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: Nested subroutine behaviour [ In reply to ]

Markus.Weber at kpn

Feb 27, 2019, 3:51 AM

Post #3 of 4 (707 views)

Permalink

Jason wrote:
> I’m having a hard time wrapping my head around behaviour with route
> policies that consist of nested subroutines.
> policy-options {
> policy-statement P-TEST1 {
> term SUB1 {
> from policy SUB1;
> then reject;
> }
> }
> policy-statement SUB1 {
> term SUB2 {
> from policy SUB2;
> }
> }
> policy-statement SUB2 {
> term NOMATCH {
> from route-filter 1.1.1.1/32 exact;
> }
> }
> }

To my knowledge:

Subroutines match if they accept and don't match if they reject. If you
don't specify an action, the default should be accept and thus results
in a match.
Accepts/rejects in subroutines aren't used for accepting/rejecting the
route, but used as condition for the from.

As your SUB1 has no explicit action, it will return (default) "accept"
and thus in P-TEST1 "from policy SUB1" will always match. SUB2 adds
nothing here.

It's best if you explicit add reject and accept in sub routines (unless
you just use the sub routine for route manipulation like adding communities,
changing local-pref, but even then it doesn't harm).

https://www.juniper.net/documentation/en_US/junos/topics/usage-guidelines/policy-configuring-subroutines-in-routing-policy-match-conditions.html

Markus

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: Nested subroutine behaviour [ In reply to ]

jason-jnsp at lixfeld

Mar 1, 2019, 6:03 AM

Post #4 of 4 (702 views)

Permalink

Thanks to everyone for the comments. In certain cases my comprehension was just plain broken. This has helped clear that up.

> On Feb 27, 2019, at 6:51 AM, Weber, Markus <Markus.Weber@kpn.de> wrote:
>
> Jason wrote:
>> I’m having a hard time wrapping my head around behaviour with route
>> policies that consist of nested subroutines.
>> policy-options {
>> policy-statement P-TEST1 {
>> term SUB1 {
>> from policy SUB1;
>> then reject;
>> }
>> }
>> policy-statement SUB1 {
>> term SUB2 {
>> from policy SUB2;
>> }
>> }
>> policy-statement SUB2 {
>> term NOMATCH {
>> from route-filter 1.1.1.1/32 exact;
>> }
>> }
>> }
>
> To my knowledge:
>
> Subroutines match if they accept and don't match if they reject. If you
> don't specify an action, the default should be accept and thus results
> in a match.
> Accepts/rejects in subroutines aren't used for accepting/rejecting the
> route, but used as condition for the from.
>
> As your SUB1 has no explicit action, it will return (default) "accept"
> and thus in P-TEST1 "from policy SUB1" will always match. SUB2 adds
> nothing here.
>
> It's best if you explicit add reject and accept in sub routines (unless
> you just use the sub routine for route manipulation like adding communities,
> changing local-pref, but even then it doesn't harm).
>
> https://www.juniper.net/documentation/en_US/junos/topics/usage-guidelines/policy-configuring-subroutines-in-routing-policy-match-conditions.html
>
> Markus
>
>

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp