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

David Ball davidtball at gmail.com
Wed Sep 8 13:21:39 EDT 2010 

  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.

user at 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.holley at 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 <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