[j-nsp] i suck at bgp import policy - help?

[Stacy W. Smith]

Ryan,

You're causing unnecessary complication for yourself by using policy subroutines (from policy <policy name>). Here's why you're seeing the behavior you reported...

When a policy is called as a subroutine, it simply returns a "true" or "false" value to the calling policy. A "true" value means the from clause in the calling policy matches, a "false" value means the from clause in the calling policy does not match. In the context of the called policy, a "then accept" is defined as "true" and a "then reject" is defined as "false". All good so far.

The catch is that the called policy must determine a "true" or "false" value for every prefix that is evaluated against that policy. In your example, the DEFAULT-ROUTE policy returns "true" for 0.0.0.0/0, but what does it do for all other prefixes? The answer is it evaluates all other prefixes against the protocol's default policy. In your case, because this is applied as a BGP import policy, the BGP default policy is applied. The BGP default policy is essentially:

term 1 {
	from protocol bgp;
	then accept;
}
term 2 {
	then reject;
}

This means that any BGP routes will be accepted by your DEFAULT-ROUTE policy. Since all the routes it gets evaluated against are BGP routes, the DEFAULT-ROUTE policy is always returning a "true" valued to the calling policy. This means every BGP route is matching your DENY-BASICS term and is being rejected.

I recommend using a prefix list instead:

[edit policy-options]
user at host# show 
prefix-list DEFAULT-ROUTE {
    0.0.0.0/0;
}
policy-statement ALL-TRANSIT-IN {
    term DENY-BASICS {
        from {
            prefix-list DEFAULT-ROUTE;
        }
        then reject;
    }
    term GENERAL-ACCEPT {
        then {
            local-preference 200;
            community set COMM-TRANSIT;
            accept;
        }
    }
}


If you really insist on using policy subroutines, then you should always write any called policy to return an explicit "true" or "false" for all prefixes so you don't fall into this trap where the protocol's default policy is evaluated. In your case, it would look like this:

[edit policy-options]
user at host# show 
policy-statement ALL-TRANSIT-IN {
    term DENY-BASICS {
        from policy DEFAULT-ROUTE;
        then reject;
    }
    term GENERAL-ACCEPT {
        then {
            local-preference 200;
            community set COMM-TRANSIT;
            accept;
        }
    }
}
policy-statement DEFAULT-ROUTE {
    term 1 {
        from {
            route-filter 0.0.0.0/0 exact;
        }
        then accept;
    }
    term 2 {
        then reject;
    }
}                                       


Hope this helps,
--Stacy


On Jan 19, 2013, at 4:30 PM, ryanL <ryan.landry at gmail.com> wrote:
> hi. i am certainly doing something wrong.
> 
> on a bgp neighbor i have the following policy:
> 
> import ALL-TRANSIT-IN;
> 
> i've reduced it to basics, which says:
> 
> term DENY-BASICS {
>    from policy DEFAULT-ROUTE;
>    then reject;
> }
> term GENERAL-ACCEPT {
>    then {
>        local-preference 200;
>        community set COMM-TRANSIT;
>        accept;
>    }
> }
> 
> where policy DEFAULT-ROUTE is:
> 
> from {
>    route-filter 0.0.0.0/0 exact;
> }
> then accept;
> 
> accept AND reject = reject, right? i performed a no-term basic test
> for a reject AND reject, which accepted all routes, so i'm pretty sure
> my head isn't too far up my...
> 
> anyways, the above policies unfortunately result in all routes being
> received, but not accepted.
> 
> Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last
> Up/Dwn State|#Active/Received/Accepted/Damped...
> <removed>          <removed>     163888        184       0       0
> 1:15:38 0/431093/0/0         0/0/0/0
> 
> if i remove the DENY-BASICS term, all routes go active and get stamped
> with my community and local-pref value.
> 
> i've tried other DENY related terms, such as filtering out long
> as-paths, or just RFC1918, or even just spoofs of my own netblock.
> normal stuff. routes stay hidden due to:
> 
>   State: <Hidden Ext>
>   Inactive reason: Unusable path
> 
> so, what am i screwing up on here? this is on 12.2R2.4. i'm
> effectively trying to follow the cymru secure junos bgp template,
> among others.
> 
> thanks.
> 
> ryan
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp