Many thanks to those who replied, including Krasimir who insisted on the vpn-apply-export knob. Despite the documentation here:
http://www.juniper.net/techpubs/software/junos/junos91/swconfig-vpns/applyingboth-the-vrf-export-and-the-bgp-export-policies.html#id-10143422 which indicates that a route-reflector will automatically perform this way, I ended up having to use the 'vpn-apply-export' knob under my BGP config in order for this to work, which it appears to. That doc is from 9.1 and I'm running 10.0, so perhaps that was a bad assumption on my part. For those who inquired about my config, it's nothing special, but includes the 'vpn-apply-export' knob under [edit protocols bgp group foo] and mentions the appropriate policy in the 'export' section of the same BGP config. Here are a couple of snippets from the lab RR config, but you get the idea. Thanks again. u...@router> show configuration protocols bgp group RR-1.4.0.1 type internal; local-address 172.16.0.1; import [ reject-bad-routes accept-all-else ]; family inet { unicast; } family inet-vpn { unicast; } family inet6 { unicast; } family inet6-vpn { unicast; } family l2vpn { signaling; } family route-target; export [ reject-bad-routes *filter-dia-routes-to-agg* accept-all-else ]; *vpn-apply-export;* cluster 1.4.0.1; peer-as 64555; neighbor 172.16.0.2; neighbor 172.16.0.3; [edit policy-options policy-statement filter-dia-routes-to-agg] term allow-DIA-default-only { from { community DIA-VRF-community; route-filter 0.0.0.0/0 exact; } then accept; } term deny-other-DIA-routes { from { community DIA-VRF-community; } then reject; } term accept-all-else { then accept; } [edit policy-options] community DIA-VRF-community members target:xxxx:xxxx; David On 1 September 2010 08:56, Keegan Holley <keegan.hol...@sungard.com> wrote: > We have slightly different requirements, but we bring all the upstreams > into inet.0 and then use rib-groups to provision customer vrf's. Some > have separate service for private connections some do both or have internet > only. It depends on the customer and their requirements. Now that I think > of it the rbi-groups will not keep the full table from being advertised into > bgp.l3vpn, so we're back to filtering. The filter I sent you is a modified > version of something I personally configured in a production router. It is > working in the vrf-export chain of a particular vrf, but the filter should > work applied directly to a peer. Be sure to post what works for you, this > will make an interesting addition to the bag of tricks. > > On Wed, Sep 1, 2010 at 10:14 AM, David Ball <davidtb...@gmail.com> wrote: > >> Well, we only ever keep a full table in the one big VRF currently. If >> customers have their own private VRF as well, they typically choose not to >> gain internet access through that private VRF, but will instead prefer a >> completely separate service for the internet. Otherwise, I am totally >> on-board with rib-groups and importing/exporting them wherever they're >> needed. >> >> The case I'm working on is with respect to building aggregation rings >> off redundant core devices. The cores have the full table in a VRF, but in >> this particular application, I have little reason to propagate all those >> routes to the aggregation devices which also hold sites in that same VRF. >> Sending a default or small subset of a full table would more than suffice >> (BGP customers wanting a full table will have to multihop to a box that has >> it, but no biggy). >> >> Many thanks for the many suggestions....I hope to dig into some of them >> today. >> >> David >> >> >> >> On 1 September 2010 05:20, Keegan Holley <keegan.hol...@sungard.com>wrote: >> >>> I guess your depends on how "transit" you are. >>> >>> >>> >>> On Wed, Sep 1, 2010 at 7:03 AM, Krasimir Avramski <kr...@smartcom.bg>wrote: >>> >>>> Well, a typical scenario is interpovider vpn(option B,C) where ASBR >>>> should advertise vpn nlri only from selected customer sites(vrfs) to >>>> external peers."Route Target Filtering"(rfc4684) is another option but >>>> although great automation/reduction achieved regarding route >>>> information flows, care should be taken when external peering is >>>> involved. >>>> >>>> Cheers, >>>> Krasi >>>> >>>> On Tue, Aug 31, 2010 at 8:56 PM, 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