[j-nsp] vpn-apply-export

harry harry at juniper.net
Mon Nov 10 11:45:02 EST 2003


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 at puck.nether.net 
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of 
> Cliff DeGuzman
> Sent: Monday, November 10, 2003 8:17 AM
> To: Blaz Zupan; juniper-nsp at 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 at puck.nether.net
> > [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Blaz Zupan
> > Sent: Sunday, November 09, 2003 11:23 PM
> > To: juniper-nsp at 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 at puck.nether.net 
> > http://puck.nether.net/mailman/listinfo/junipe> r-nsp
> > 
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
> 




More information about the juniper-nsp mailing list