[j-nsp] Change in routing policy functionality somewhere between 9.2 and 10.0 ?

[David Ball]

  We recently completed an upgrade from 9.2 to 10.0R3.10 (2-step
manual upgrade, stopping at 9.4R4.5 on the way) on our core T640 and
MX480 routers.  All went well, with the exception of something that
popped up the next day, only affecting L3VPN customers.
  For more than 3yrs, we've had an import and export policy (the value
of which I'm questioning) on our core iBGP sessions which had a
'reject' statement for any RFC1918 blocks.  It's a legacy policy that
somehow stuck when we migrated from some old M10s that only used to
handle internet.  Anyhow, up to at least 9.2, these policies actually
permitted (despite the policy) RFC1918 space for any L3VPN/VRFs that
we had set up, so it's never been a problem.  Our L3VPN customers who
used this space worked fine.
  But, following our upgrade to 10.0R3.10, those policies suddenly
started acting differently.  The export policy which was supposed to
deny RFC1918 space still wasn't doing its job, so 192.168/x space was
still being advertised to a neighbor.  On the neighbor though, the
import policy is having a different effect now, and is storing them as
'hidden' routes (whereas, prior to upgrade, they worked fine).
  Ticket is open with JTAC, but wondered if anyone else had stumbled
upon this.  I re-verified in the lab by using 9.2 the moving to 10.0
with identical config.

This is the 1st policy applied to iBGP sessions on import and export:

me at router> ...options policy-statement reject-bad-routes
term reject {
    from {
        prefix-list-filter martian-space orlonger;
    }
    then reject;
}

{master}
me at router> show configuration policy-options prefix-list martian-space
0.0.0.0/8;
10.0.0.0/8;
127.0.0.0/8;
169.254.0.0/16;
172.16.0.0/12;
192.0.2.0/24;
192.168.0.0/16;
198.18.0.0/15;
224.0.0.0/3;

David