Have you tried rib-groups? It allows you to export copies of a routing table to others without wasting memory on the routes or creating yet another routing table. We leave the full table in inet.0 and then use rib groups to send them into the vrf's. You might have to create a second vrf, though. Something along the lines of internet-jr.inet.0, but this will allow you much more control over what goes into these routers since it will be a separate vrf. My next question would have been how you planned to keep the filters updated. You could have nasty side effects if too many routes are allowed/denied or different routes are allowed/denied at different points in the network. Also, the rib-group routes should not use additional memory if they are already in the original vrf.
On Tue, Aug 31, 2010 at 7:41 PM, David Ball <davidtb...@gmail.com> wrote: > Haven't tried them yet, no. The application is a full routing table > inside a VRF, which is being exported to 'lesser' devices which can't handle > a full table. > > David > > > > On 31 August 2010 11:56, Keegan Holley <keegan.hol...@sungard.com> wrote: > >> Have you tried any of the other suggestions? I don't think I've ever had >> to export a group of routes and then filter then anyway. Just out of >> curiosity where did this requirement come from? Route reflection usually >> provides enough reduction in the routing table size. >> >> >> >> On Tue, Aug 31, 2010 at 10:44 AM, David Ball <davidtb...@gmail.com>wrote: >> >>> Thanks Krasimir. I'd run across that knob previously, but my >>> understanding >>> is that the functionality provided by vpn-apply-export is enabled when a >>> router is configured as a route-reflector, which mine are already. Will >>> give it a whirl anyways, though. >>> >>> David >>> >>> >>> On 31 August 2010 04:25, Krasimir Avramski <kr...@smartcom.bg> wrote: >>> >>> > You probably missing " vpn-apply-export" stanza in your bgp cluster >>> group. >>> > >>> > HTH >>> > Krasi >>> > >>> > On Mon, Aug 30, 2010 at 11:25 PM, David Ball <davidtb...@gmail.com> >>> wrote: >>> > > Ts/MXs running 10.0.R3.10 >>> > > >>> > > I don't have access to my actual configs, but think I can verbalize >>> > > anyways. >>> > > >>> > > Does anyone know if it's possible to filter a given VRF route prior >>> to >>> > > export to an iBGP peer? Naturally, the route itself includes an RD >>> and >>> > RT, >>> > > and I can't get my 'match' clauses to work. >>> > > >>> > > I've been trying matching on things like community (ie. community >>> > SOMENAME >>> > > members target:###:###), on RIB (ie. rib bgp.l3vpn.0), and also using >>> a >>> > > route-filter (which I don't believe supports VRF routes), but with no >>> > > success. For interest's sake, I'm running in 'route-reflector-ready' >>> > mode, >>> > > in that routes are being exported from bgp.l[2|3]vpn.0 rather than >>> from >>> > the >>> > > individual routing tables themselves, hence my trying to match on the >>> > > bgp.l3vpn.0 RIB instead of an individual VRF's RIB. >>> > > >>> > > I was sure I saw a workaround listed here, but can't find it in the >>> > > archives for the life of me. >>> > > >>> > > David >>> > > _______________________________________________ >>> > > 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 >>> >>> >>> >> > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp