[j-nsp] leaking into a VRF from inet.0?

[Dave Diller]

> Unfortunately the only way I have been able to make this work is  
> with rib groups....here is what I did to put all the direct  
> interfaces into my VRF.
>
> }
> routing-options {
>     interface-routes {
>         rib-group inet interface-routes;
>     }
>     rib-groups {
>         interface-routes {
>             import-rib [ inet.0 vrf.inet.0 ];
>         }
>     }
>


Yeah, I've got it working for direct using the same mechanism.   
That's not the issue... I'm trying to leak BGP routes from inet.0.

I've got auto-export on the main routing-options,  but it doesn't do  
anything. Could just be unsupported for inet.0 since not a VPN, but  
it commits, for whatever that's worth.

dave at RE1-lab-t640# show routing-options auto-export
family inet {
     unicast {
         rib-group LEAK-to-TEST2;
     }
}

dave at RE1-lab-t640# show routing-options rib-groups LEAK-to-TEST2
import-rib [ inet.0 TEST2.inet.0 ];

Doesn't work with just  "import-rib TEST2.inet.0" in that rib-group  
either, which is less proper for rib groups in a classical sense, but  
appropriate for auto-export, as documented here:
http://www.juniper.net/techpubs/software/junos/junos82/feature- 
guide-82/html/fg-sirs7.html#1017692

"There is a significant difference in how routing table groups are  
used in this case and how they are used more generally. Typically,  
routing table groups require the exporting routing table to be  
referenced as the primary import routing table in the rib-group  
configuration. In this case, the restriction is lifted and the  
routing table group functions as an additional list of tables that  
export routes."

So I would think that applying it as above, to the main routing- 
options, would allow for inet.0 to be exported to TEST2. No dice yet.

-dd