[j-nsp] Filtering the export of VRF routes with iBGP export filters....

Keegan Holley keegan.holley at sungard.com
Wed Sep 1 10:56:59 EDT 2010


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 <davidtball at 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.holley at sungard.com>wrote:
>
>> I guess your depends on how "transit" you are.
>>
>>
>>
>> On Wed, Sep 1, 2010 at 7:03 AM, Krasimir Avramski <krasi at 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.holley at 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 <davidtball at 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 <krasi at 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 <davidtball at 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 at puck.nether.net
>>> >> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
>>> >> > >
>>> >> >
>>> >> _______________________________________________
>>> >> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> >> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>>
>>
>


More information about the juniper-nsp mailing list