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