Mailing List Archive

vpn-apply-export
After upgrading yet another M5 from 5.5R1.2 to 5.7R3.4, I found out that a
customers connection through a L3 MPLS VPN was suddenly broken. Although the
VPN itself was apparently working, the upgraded M5 was not announcing the
static default route configured under the routing instance to the other PE
router (a Cisco 7206 running IOS 12.2(14)S3).

Here is what I had configured:

policy-statement to-ibgp-amis-routes {
term as8591 {
from community [ from-customer from-lix from-six ];
then accept;
}
term limited-routes {
from {
protocol [ bgp aggregate ];
as-path limited-routes;
}
then accept;
}
term everything-else {
then reject;
}
}
as-path limited-routes "[0-65535]{0,2}";

This was applied as an export policy on the BGP session towards the Cisco PE.
The Cisco does not have enough memory for the full BGP routing table, so I'm
limiting the number of routes with the above policy.

The routing instance for the L3 VPN had this config:

somevpn {
instance-type vrf;
interface fe-0/1/0.308;
route-distinguisher 12644:1;
vrf-import vpn-somevpn-import;
vrf-export vpn-somevpn-export;
routing-options {
static {
route 0.0.0.0/0 next-hop x.x.x.x;
}
}
}

I later replaced the vrf-import and vrf-export with "vrf-target
target:12644:1", because it's much nicer and easier.

The above static route was not distributed to the Cisco PE router for unknown
reasons. After some experimentation, I added "static" to this term:

term limited-routes {
from {
protocol [ bgp aggregate static ];
as-path limited-routes;
}
then accept;
}

The default route suddenly appeared on the Cisco PE router. Obviously the IPv4
unicast policy was affecting the VPNv4 routes, so in the end effect it behaved
like I had vpn-apply-export configured, but I did not.

Am I misunderstanding something or is this a bug? The same configuration was
working flawlessly with 5.5R1.2.
vpn-apply-export [ In reply to ]
Hi,

vrf-target should pick up static routes as well. Can you please contact
our JTAC and open a case so they can investigate this.

Thanks!
Cliff


> -----Original Message-----
> From: juniper-nsp-bounces@puck.nether.net
> [mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of Blaz Zupan
> Sent: Sunday, November 09, 2003 11:23 PM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] vpn-apply-export
>
>
> After upgrading yet another M5 from 5.5R1.2 to 5.7R3.4, I
> found out that a customers connection through a L3 MPLS VPN
> was suddenly broken. Although the VPN itself was apparently
> working, the upgraded M5 was not announcing the static
> default route configured under the routing instance to the
> other PE router (a Cisco 7206 running IOS 12.2(14)S3).
>
> Here is what I had configured:
>
> policy-statement to-ibgp-amis-routes {
> term as8591 {
> from community [ from-customer from-lix from-six ];
> then accept;
> }
> term limited-routes {
> from {
> protocol [ bgp aggregate ];
> as-path limited-routes;
> }
> then accept;
> }
> term everything-else {
> then reject;
> }
> }
> as-path limited-routes "[0-65535]{0,2}";
>
> This was applied as an export policy on the BGP session
> towards the Cisco PE. The Cisco does not have enough memory
> for the full BGP routing table, so I'm limiting the number of
> routes with the above policy.
>
> The routing instance for the L3 VPN had this config:
>
> somevpn {
> instance-type vrf;
> interface fe-0/1/0.308;
> route-distinguisher 12644:1;
> vrf-import vpn-somevpn-import;
> vrf-export vpn-somevpn-export;
> routing-options {
> static {
> route 0.0.0.0/0 next-hop x.x.x.x;
> }
> }
> }
>
> I later replaced the vrf-import and vrf-export with
> "vrf-target target:12644:1", because it's much nicer and easier.
>
> The above static route was not distributed to the Cisco PE
> router for unknown reasons. After some experimentation, I
> added "static" to this term:
>
> term limited-routes {
> from {
> protocol [ bgp aggregate static ];
> as-path limited-routes;
> }
> then accept;
> }
>
> The default route suddenly appeared on the Cisco PE router.
> Obviously the IPv4 unicast policy was affecting the VPNv4
> routes, so in the end effect it behaved like I had
> vpn-apply-export configured, but I did not.
>
> Am I misunderstanding something or is this a bug? The same
> configuration was working flawlessly with 5.5R1.2.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/junipe> r-nsp
>
vpn-apply-export [ In reply to ]
Hmmm. The static route does not appear to have the "from-customer from-lix
from-six" communities attached, nor does it have any as path attributes. I
do not think the static should be advertised in this context, regardless of
JUNOS version as you policy only accepts routes with these attributes. You
can add community/AS path attributes to a static on routing-options; perhaps
this information was there at one time?

As for why it works with vrf-target, this is easy. This option exports all
active routes in the VRF, which includes the static default.


HTHs




> -----Original Message-----
> From: juniper-nsp-bounces@puck.nether.net
> [mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of Blaz Zupan
> Sent: Sunday, November 09, 2003 11:23 PM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] vpn-apply-export
>
>
> After upgrading yet another M5 from 5.5R1.2 to 5.7R3.4, I
> found out that a customers connection through a L3 MPLS VPN
> was suddenly broken. Although the VPN itself was apparently
> working, the upgraded M5 was not announcing the static
> default route configured under the routing instance to the
> other PE router (a Cisco 7206 running IOS 12.2(14)S3).
>
> Here is what I had configured:
>
> policy-statement to-ibgp-amis-routes {
> term as8591 {
> from community [ from-customer from-lix from-six ];
> then accept;
> }
> term limited-routes {
> from {
> protocol [ bgp aggregate ];
> as-path limited-routes;
> }
> then accept;
> }
> term everything-else {
> then reject;
> }
> }
> as-path limited-routes "[0-65535]{0,2}";
>
> This was applied as an export policy on the BGP session
> towards the Cisco PE. The Cisco does not have enough memory
> for the full BGP routing table, so I'm limiting the number of
> routes with the above policy.
>
> The routing instance for the L3 VPN had this config:
>
> somevpn {
> instance-type vrf;
> interface fe-0/1/0.308;
> route-distinguisher 12644:1;
> vrf-import vpn-somevpn-import;
> vrf-export vpn-somevpn-export;
> routing-options {
> static {
> route 0.0.0.0/0 next-hop x.x.x.x;
> }
> }
> }
>
> I later replaced the vrf-import and vrf-export with
> "vrf-target target:12644:1", because it's much nicer and easier.
>
> The above static route was not distributed to the Cisco PE
> router for unknown reasons. After some experimentation, I
> added "static" to this term:
>
> term limited-routes {
> from {
> protocol [ bgp aggregate static ];
> as-path limited-routes;
> }
> then accept;
> }
>
> The default route suddenly appeared on the Cisco PE router.
> Obviously the IPv4 unicast policy was affecting the VPNv4
> routes, so in the end effect it behaved like I had
> vpn-apply-export configured, but I did not.
>
> Am I misunderstanding something or is this a bug? The same
> configuration was working flawlessly with 5.5R1.2.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/junipe> r-nsp
>
vpn-apply-export [ In reply to ]
I think that the presence of explicit vrf import/export policy negate the
effects of vrf-target automatic policy. IOW, once you specify vrf-target you
should delete the vrf-import and vrf-export statements.



> -----Original Message-----
> From: juniper-nsp-bounces@puck.nether.net
> [mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of
> Cliff DeGuzman
> Sent: Monday, November 10, 2003 8:17 AM
> To: Blaz Zupan; juniper-nsp@puck.nether.net
> Subject: RE: [j-nsp] vpn-apply-export
>
>
> Hi,
>
> vrf-target should pick up static routes as well. Can you
> please contact our JTAC and open a case so they can investigate this.
>
> Thanks!
> Cliff
>
>
> > -----Original Message-----
> > From: juniper-nsp-bounces@puck.nether.net
> > [mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of Blaz Zupan
> > Sent: Sunday, November 09, 2003 11:23 PM
> > To: juniper-nsp@puck.nether.net
> > Subject: [j-nsp] vpn-apply-export
> >
> >
> > After upgrading yet another M5 from 5.5R1.2 to 5.7R3.4, I
> > found out that a customers connection through a L3 MPLS VPN
> > was suddenly broken. Although the VPN itself was apparently
> > working, the upgraded M5 was not announcing the static
> > default route configured under the routing instance to the
> > other PE router (a Cisco 7206 running IOS 12.2(14)S3).
> >
> > Here is what I had configured:
> >
> > policy-statement to-ibgp-amis-routes {
> > term as8591 {
> > from community [ from-customer from-lix from-six ];
> > then accept;
> > }
> > term limited-routes {
> > from {
> > protocol [ bgp aggregate ];
> > as-path limited-routes;
> > }
> > then accept;
> > }
> > term everything-else {
> > then reject;
> > }
> > }
> > as-path limited-routes "[0-65535]{0,2}";
> >
> > This was applied as an export policy on the BGP session
> > towards the Cisco PE. The Cisco does not have enough memory
> > for the full BGP routing table, so I'm limiting the number of
> > routes with the above policy.
> >
> > The routing instance for the L3 VPN had this config:
> >
> > somevpn {
> > instance-type vrf;
> > interface fe-0/1/0.308;
> > route-distinguisher 12644:1;
> > vrf-import vpn-somevpn-import;
> > vrf-export vpn-somevpn-export;
> > routing-options {
> > static {
> > route 0.0.0.0/0 next-hop x.x.x.x;
> > }
> > }
> > }
> >
> > I later replaced the vrf-import and vrf-export with
> > "vrf-target target:12644:1", because it's much nicer and easier.
> >
> > The above static route was not distributed to the Cisco PE
> > router for unknown reasons. After some experimentation, I
> > added "static" to this term:
> >
> > term limited-routes {
> > from {
> > protocol [ bgp aggregate static ];
> > as-path limited-routes;
> > }
> > then accept;
> > }
> >
> > The default route suddenly appeared on the Cisco PE router.
> > Obviously the IPv4 unicast policy was affecting the VPNv4
> > routes, so in the end effect it behaved like I had
> > vpn-apply-export configured, but I did not.
> >
> > Am I misunderstanding something or is this a bug? The same
> > configuration was working flawlessly with 5.5R1.2.
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > http://puck.nether.net/mailman/listinfo/junipe> r-nsp
> >
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>
vpn-apply-export [ In reply to ]
Maybe I misunderstood the question.

I thought everything was working correctly with vrf-import/export and
stopped working when the policies were "replaced" with vrf-target.

Cliff

> -----Original Message-----
> From: Harry Reynolds
> Sent: Monday, November 10, 2003 8:45 AM
> To: Cliff DeGuzman; 'Blaz Zupan'; juniper-nsp@puck.nether.net
> Subject: RE: [j-nsp] vpn-apply-export
>
>
> I think that the presence of explicit vrf import/export
> policy negate the effects of vrf-target automatic policy.
> IOW, once you specify vrf-target you should delete the
> vrf-import and vrf-export statements.
>
>
>
> > -----Original Message-----
> > From: juniper-nsp-bounces@puck.nether.net
> > [mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of
> > Cliff DeGuzman
> > Sent: Monday, November 10, 2003 8:17 AM
> > To: Blaz Zupan; juniper-nsp@puck.nether.net
> > Subject: RE: [j-nsp] vpn-apply-export
> >
> >
> > Hi,
> >
> > vrf-target should pick up static routes as well. Can you
> > please contact our JTAC and open a case so they can
> investigate this.
> >
> > Thanks!
> > Cliff
> >
> >
> > > -----Original Message-----
> > > From: juniper-nsp-bounces@puck.nether.net
> > > [mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of
> Blaz Zupan
> > > Sent: Sunday, November 09, 2003 11:23 PM
> > > To: juniper-nsp@puck.nether.net
> > > Subject: [j-nsp] vpn-apply-export
> > >
> > >
> > > After upgrading yet another M5 from 5.5R1.2 to 5.7R3.4, I
> found out
> > > that a customers connection through a L3 MPLS VPN was suddenly
> > > broken. Although the VPN itself was apparently working,
> the upgraded
> > > M5 was not announcing the static default route configured
> under the
> > > routing instance to the other PE router (a Cisco 7206 running IOS
> > > 12.2(14)S3).
> > >
> > > Here is what I had configured:
> > >
> > > policy-statement to-ibgp-amis-routes {
> > > term as8591 {
> > > from community [ from-customer from-lix from-six ];
> > > then accept;
> > > }
> > > term limited-routes {
> > > from {
> > > protocol [ bgp aggregate ];
> > > as-path limited-routes;
> > > }
> > > then accept;
> > > }
> > > term everything-else {
> > > then reject;
> > > }
> > > }
> > > as-path limited-routes "[0-65535]{0,2}";
> > >
> > > This was applied as an export policy on the BGP session
> towards the
> > > Cisco PE. The Cisco does not have enough memory for the full BGP
> > > routing table, so I'm limiting the number of routes with
> the above
> > > policy.
> > >
> > > The routing instance for the L3 VPN had this config:
> > >
> > > somevpn {
> > > instance-type vrf;
> > > interface fe-0/1/0.308;
> > > route-distinguisher 12644:1;
> > > vrf-import vpn-somevpn-import;
> > > vrf-export vpn-somevpn-export;
> > > routing-options {
> > > static {
> > > route 0.0.0.0/0 next-hop x.x.x.x;
> > > }
> > > }
> > > }
> > >
> > > I later replaced the vrf-import and vrf-export with "vrf-target
> > > target:12644:1", because it's much nicer and easier.
> > >
> > > The above static route was not distributed to the Cisco PE router
> > > for unknown reasons. After some experimentation, I added
> "static" to
> > > this term:
> > >
> > > term limited-routes {
> > > from {
> > > protocol [ bgp aggregate static ];
> > > as-path limited-routes;
> > > }
> > > then accept;
> > > }
> > >
> > > The default route suddenly appeared on the Cisco PE router.
> > > Obviously the IPv4 unicast policy was affecting the VPNv4
> routes, so
> > > in the end effect it behaved like I had vpn-apply-export
> configured,
> > > but I did not.
> > >
> > > Am I misunderstanding something or is this a bug? The same
> > > configuration was working flawlessly with 5.5R1.2.
> > > _______________________________________________
> > > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > > http://puck.nether.net/mailman/listinfo/junipe> r-nsp
> > >
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > http://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
>
vpn-apply-export [ In reply to ]
> I think that the presence of explicit vrf import/export policy negate the
> effects of vrf-target automatic policy. IOW, once you specify vrf-target you
> should delete the vrf-import and vrf-export statements.

I did.
vpn-apply-export [ In reply to ]
> Maybe I misunderstood the question.
>
> I thought everything was working correctly with vrf-import/export and
> stopped working when the policies were "replaced" with vrf-target.

You misunderstood it. Everything was working with 5.5R1.2 and
vrf-import/export. It stopped working when I upgraded to 5.7 and no changes to
the configuration. I changed vrf-import/export to vrf-target to simplify the
configuration, I should have mentioned it, it just confused the heck out of
you guys :-)
vpn-apply-export [ In reply to ]
> Hmmm. The static route does not appear to have the "from-customer from-lix
> from-six" communities attached, nor does it have any as path attributes. I
> do not think the static should be advertised in this context, regardless of
> JUNOS version as you policy only accepts routes with these attributes. You
> can add community/AS path attributes to a static on routing-options; perhaps
> this information was there at one time?

As I understand the documentation, if vpn-apply-export is not configured, only
vpn-import/vpn-export or vpn-target policy apply to the routes created under
the routing-instance. At least that's how it worked with 5.5R1.2. When you
configure vpn-apply-export, it should first apply the vpn-import/vpn-export or
vpn-target and after that the normal BGP policy. Problem is, it behaves for me
like I have vpn-apply-export configured, but I don't have it.
vpn-apply-export [ In reply to ]
I think I need to see the complete config to get a better handle. It sounds
like you are saying:

term limited-routes {
from {
protocol [ bgp aggregate static ];
as-path limited-routes;
}
then accept;
}


Is part of your unicast PE-PE BGP routing policy. I assumed this was part of
your VRF related policies.



> -----Original Message-----
> From: Blaz Zupan [mailto:blaz@inlimbo.org]
> Sent: Monday, November 10, 2003 8:58 AM
> To: harry
> Cc: juniper-nsp@puck.nether.net
> Subject: RE: [j-nsp] vpn-apply-export
>
>
> > Hmmm. The static route does not appear to have the "from-customer
> > from-lix from-six" communities attached, nor does it have
> any as path
> > attributes. I do not think the static should be advertised in this
> > context, regardless of JUNOS version as you policy only
> accepts routes
> > with these attributes. You can add community/AS path
> attributes to a
> > static on routing-options; perhaps this information was
> there at one
> > time?
>
> As I understand the documentation, if vpn-apply-export is not
> configured, only vpn-import/vpn-export or vpn-target policy
> apply to the routes created under the routing-instance. At
> least that's how it worked with 5.5R1.2. When you configure
> vpn-apply-export, it should first apply the
> vpn-import/vpn-export or vpn-target and after that the normal
> BGP policy. Problem is, it behaves for me like I have
> vpn-apply-export configured, but I don't have it.
>
vpn-apply-export [ In reply to ]
> I think I need to see the complete config to get a better handle. It sounds
> like you are saying:
>
> term limited-routes {
> from {
> protocol [ bgp aggregate static ];
> as-path limited-routes;
> }
> then accept;
> }
>
>
> Is part of your unicast PE-PE BGP routing policy. I assumed this was part of
> your VRF related policies.

Below is the relevant part of the configuration. This is the configuration
that worked with 5.5. With 5.7, I need to add "static" to the "limited-routes"
term of the "to-ibgp-amis-routes" policy, otherwise the static default route
does not propagate to the Cisco PE. I believe this is supposed to be needed
only when I configure vpn-apply-export, but I did not configure it.

protocols {
mpls {
interface e3-0/0/2.0;
interface fe-0/1/0.308;
}
bgp {
group ibgp {
type internal;
local-address 212.18.32.166;
peer-as 8591;
neighbor 212.18.32.175 {
family inet {
unicast;
}
family inet-vpn {
unicast;
}
export to-ibgp-amis-routes;
cluster 212.18.32.166;
}
}
}
ldp {
interface e3-0/0/2.0;
}
}
policy-options {
policy-statement to-ibgp-amis-routes {
term as8591 {
from community [ from-customer from-lix from-six ];
then accept;
}
term limited-routes {
from {
protocol [ bgp aggregate ];
as-path limited-routes;
}
then accept;
}
term everything-else {
then reject;
}
}
policy-statement vpn-telemach-import {
term a {
from {
protocol bgp;
community vpn-telemach;
}
then accept;
}
term b {
then reject;
}
}
policy-statement vpn-telemach-export {
term a {
then {
community add vpn-telemach;
accept;
}
}
term b {
then reject;
}
}
community from-customer members 8591:1000;
community from-lix members 8591:1002;
community from-six members 8591:1001;
community vpn-telemach members target:12644:1;
as-path limited-routes "[0-65535]{0,2}";
}

routing-instances {
telemach {
instance-type vrf;
interface fe-0/1/0.308;
route-distinguisher 12644:1;
vrf-import vpn-telemach-import;
vrf-export vpn-telemach-export;
routing-options {
static {
route 0.0.0.0/0 next-hop 213.143.77.41;
}
}
}
}
vpn-apply-export [ In reply to ]
Odd. Can you confirm that the static route is active in the VRF?

It seems that:

policy-statement vpn-telemach-export {
term a {
then {
community add vpn-telemach;
accept;
}
}
term b {
then reject;

Should match on all active routes in the VRF and export them. Once a route
is accepted it cannot be later rejected (as I understand), so I am not sure
why modifying your PE-PE export policy should have any effect. Your AS path
reg x seems to match on a null AS path, so this explains why adding static
allows the export of the static despite no as path parameters being
configured for that static. You may want to open a case with JTAC as this
does not seem to be the desired behavior.



> -----Original Message-----
> From: Blaz Zupan [mailto:blaz@inlimbo.org]
> Sent: Monday, November 10, 2003 9:20 AM
> To: harry
> Cc: juniper-nsp@puck.nether.net
> Subject: RE: [j-nsp] vpn-apply-export
>
>
> > I think I need to see the complete config to get a better
> handle. It
> > sounds like you are saying:
> >
> > term limited-routes {
> > from {
> > protocol [ bgp aggregate static ];
> > as-path limited-routes;
> > }
> > then accept;
> > }
> >
> >
> > Is part of your unicast PE-PE BGP routing policy. I assumed
> this was
> > part of your VRF related policies.
>
> Below is the relevant part of the configuration. This is the
> configuration that worked with 5.5. With 5.7, I need to add
> "static" to the "limited-routes" term of the
> "to-ibgp-amis-routes" policy, otherwise the static default
> route does not propagate to the Cisco PE. I believe this is
> supposed to be needed only when I configure vpn-apply-export,
> but I did not configure it.
>
> protocols {
> mpls {
> interface e3-0/0/2.0;
> interface fe-0/1/0.308;
> }
> bgp {
> group ibgp {
> type internal;
> local-address 212.18.32.166;
> peer-as 8591;
> neighbor 212.18.32.175 {
> family inet {
> unicast;
> }
> family inet-vpn {
> unicast;
> }
> export to-ibgp-amis-routes;
> cluster 212.18.32.166;
> }
> }
> }
> ldp {
> interface e3-0/0/2.0;
> }
> }
> policy-options {
> policy-statement to-ibgp-amis-routes {
> term as8591 {
> from community [ from-customer from-lix from-six ];
> then accept;
> }
> term limited-routes {
> from {
> protocol [ bgp aggregate ];
> as-path limited-routes;
> }
> then accept;
> }
> term everything-else {
> then reject;
> }
> }
> policy-statement vpn-telemach-import {
> term a {
> from {
> protocol bgp;
> community vpn-telemach;
> }
> then accept;
> }
> term b {
> then reject;
> }
> }
> policy-statement vpn-telemach-export {
> term a {
> then {
> community add vpn-telemach;
> accept;
> }
> }
> term b {
> then reject;
> }
> }
> community from-customer members 8591:1000;
> community from-lix members 8591:1002;
> community from-six members 8591:1001;
> community vpn-telemach members target:12644:1;
> as-path limited-routes "[0-65535]{0,2}";
> }
>
> routing-instances {
> telemach {
> instance-type vrf;
> interface fe-0/1/0.308;
> route-distinguisher 12644:1;
> vrf-import vpn-telemach-import;
> vrf-export vpn-telemach-export;
> routing-options {
> static {
> route 0.0.0.0/0 next-hop 213.143.77.41;
> }
> }
> }
> }
>
vpn-apply-export [ In reply to ]
> Odd. Can you confirm that the static route is active in the VRF?

It is.

> Should match on all active routes in the VRF and export them. Once a route
> is accepted it cannot be later rejected (as I understand), so I am not sure
> why modifying your PE-PE export policy should have any effect. Your AS path
> reg x seems to match on a null AS path, so this explains why adding static
> allows the export of the static despite no as path parameters being

Another way to make it work is to modify policy-statement to-ibgp-amis-routes
like this (new "term mpls" below):

policy-statement to-ibgp-amis-routes {
term mpls {
from community vpn;
then accept;
}
term as8591 {
from community [ from-customer from-lix from-six ];
then accept;
}
term limited-routes {
from {
protocol [ bgp aggregate ];
as-path limited-routes;
}
then accept;
}
}
community vpn members target:12644:1

> configured for that static. You may want to open a case with JTAC as this
> does not seem to be the desired behavior.

Thanks for confirming that I'm not smoking crack :-)
vpn-apply-export [ In reply to ]
A behavioural change was indeed introduced in 5.7R1 to do an implicit
vpn-apply-export when RR or ASBR functionality is enabled. This was
introduced as part of PR27920.

So what you are seeing is the following:

Your vrf policy is accepting the vrf static route which which moves it
to the l3vpn.bgp table.

The route attributes are maintained and it is therefore still seen as
static.

The next stage is to apply the pe-pe policy to routes in the l2vpn.bgp
table, which in your case rejects the route - your final statement is
to reject all.

As you have seen the addition of protocol static or the addition to a
match on the vrf-target fixed your problem.

In short, as you first speculated, the router does have an implicit
vpn-apply-export and hence you see this behaviour.

I have taken steps to document more clearly this change in behaviour.

Sorry for the earlier confusion, I missed the cluster id which should
have alerted me to the fact that this was an PE-RR combined
configuration.


Gary
Re: vpn-apply-export [ In reply to ]
l3vpn.bgp** table - sorry for typo

On Monday, Nov 10, 2003, at 15:05 US/Pacific, Gary Tate wrote:

> A behavioural change was indeed introduced in 5.7R1 to do an implicit
> vpn-apply-export when RR or ASBR functionality is enabled. This was
> introduced as part of PR27920.
>
> So what you are seeing is the following:
>
> Your vrf policy is accepting the vrf static route which which moves it
> to the l3vpn.bgp table.
>
> The route attributes are maintained and it is therefore still seen as
> static.
>
> The next stage is to apply the pe-pe policy to routes in the
> l2vpn.bgp** table, which in your case rejects the route - your final
> statement is to reject all.
>
> As you have seen the addition of protocol static or the addition to a
> match on the vrf-target fixed your problem.
>
> In short, as you first speculated, the router does have an implicit
> vpn-apply-export and hence you see this behaviour.
>
> I have taken steps to document more clearly this change in behaviour.
>
> Sorry for the earlier confusion, I missed the cluster id which should
> have alerted me to the fact that this was an PE-RR combined
> configuration.
>
>
> Gary
>
Re: vpn-apply-export typos corrected [ In reply to ]
Have corrected the typo's so no one is confused. Sorry

On Monday, Nov 10, 2003, at 15:05 US/Pacific, Gary Tate wrote:

> A behavioural change was indeed introduced in 5.7R1 to do an implicit
> vpn-apply-export when RR or ASBR functionality is enabled. This was
> introduced as part of PR27920.
>
> So what you are seeing is the following:
>
> Your vrf policy is accepting the vrf static route which which moves it
> to the bgp.l3vpn table.
>
> The route attributes are maintained and it is therefore still seen as
> static.
>
> The next stage is to apply the pe-pe policy to routes in the bgp.l3vpn
> table, which in your case rejects the route - your final statement is
> to reject all.
>
> As you have seen the addition of protocol static or the addition to a
> match on the vrf-target fixed your problem.
>
> In short, as you first speculated, the router does have an implicit
> vpn-apply-export and hence you see this behaviour.
>
> I have taken steps to document more clearly this change in behaviour.
>
> Sorry for the earlier confusion, I missed the cluster id which should
> have alerted me to the fact that this was an PE-RR combined
> configuration.
>
>
> Gary
>