[j-nsp] Nested subroutine behaviour

Jason Lixfeld jason-jnsp at lixfeld.ca
Tue Feb 26 17:01:39 EST 2019


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 at 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 at 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?


More information about the juniper-nsp mailing list