[j-nsp] Filtering the export of VRF routes with iBGP export filters....
David Ball
davidtball at gmail.com
Thu Dec 16 17:49:18 EST 2010
Resuscitating a thread from Sept 2010 here, where I was trying to filter
VRF routes across a route-reflector iBGP session using BGP export policies.
Use of vpn-apply-export knob helped, in that it's now evaluating the VRF
export policies AND BGP export policies, but not quite in the way I had
hoped.
Previously, I was hoping to only send a default route to the RR-client,
and vpn-apply-export helped me achieve this, and I was just matching on a
route-filter 0.0.0.0/0. However, I now have a requirement/desire to send a
few more routes down, but this time I wish to match based on the original
community set on the route in the instance.inet.0 RIB. Unfortunately, that
community, along with the as-path and local pref, get hidden in the AttrSet
when the routes from instance.inet.0 are sent to bgp.l3vpn.0 prior to export
to my BGP neighbor (which is done because it's configured as a route
reflector). The community on the route is now set to the VRF-target
community in bgp.l3vpn.0, as specified in the VRF config, with the route's
*original* community now stored in AttrSet.
In a nutshell, I believe I need my BGP export filter to match attributes
now only found in the AttrSet of a route in bgp.l3vpn.0. JTAC haven't been
able to help thus far....thought I'd poll the masses for ideas. I tried
using vrf-export in my routing-instance in hopes of adding TWO communities
to a route as it's being moved to bgp.l3vpn.0 (the one specified in
vrf-target, plus another community that I can hopefully match on in a BGP
export policy), but to no avail thus far.
David
On 8 September 2010 11:21, David Ball <davidtball at gmail.com> wrote:
> 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