[j-nsp] forwarding traffic between VRFs
Krasimir Avramski
krasi at smartcom.bg
Fri Apr 29 08:35:33 EDT 2005
Hi,
This can avoided this way:
global routing-options config:
rib-groups {
x-y {
import-rib [ CorpX_VRF.inet.0 CorpY_VRF.inet.0 ];
}
}
and at:
[edit routing-instances CorpX_VRF]
routing-options {
interface-routes {
rib-group inet x-y;
}
}
The second one will import direct and local routers from CorpX_VRF to CorpY_VRF.
Krasi
------------------------------------------------------------------------
---Original Message----------------------------------
FROM: Bosco.Sachanandani at orange.co.in
TO: krasi at smartcom.bg, juniper-nsp at puck.nether.net
SUBJECT: Re: RE: [j-nsp] forwarding traffic between VRFs
SENT: APRIL 29, 2005 10:20AM
--------------------------------------------------------
>
> Yes, I had tried this earlier and it does not give me errors, but I presume this is true only for the FORWARD path. What about to the reverse routes ? I am using Junos 6.4
>
>
> [edit routing-instances CorpX_VRF]
>
> instance-type vrf;
> interface gr-1/0/0.2;
> route-distinguisher 65010:08;
> vrf-import CorpX_import;
> vrf-export CorpX_export;
> routing-options {
> static {
> route 10.12.17.64/26 next-hop 10.11.210.81;
> route 10.1.8.0/24 next-table CorpY_VRF.inet.0;
> }
> }
>
> [edit routing-instances CorpX_VRF]
> boscos at srmum1-re0#
>
>
> COMMIT SUCCEEDS AT THIS POINT
>
>
>
> [edit routing-instances CorpY_VRF]
>
> instance-type vrf;
> interface ds-0/1/1:0.0;
> interface gr-0/0/0.0;
> inactive: interface fe-1/3/3.0;
> route-distinguisher 65010:06;
> vrf-import reject-all;
> vrf-export reject-all;
> routing-options {
> static {
> route 10.12.16.0/26 next-hop 10.11.210.1;
> route 0.0.0.0/0 next-hop 10.11.207.2;
> route 10.12.17.64/26 next-table CorpX_VRF.inet.0;
> }
> }
>
>
> COMMIT FAILS HERE
>
>
> error: [rib CorpX_VRF.inet.0 routing-options static]
> next-table may loop
> error: configuration check-out failed
>
>
> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Krasimir Avramski
> Sent: Thursday, April 28, 2005 9:16 PM
> To: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] forwarding traffic between VRFs
>
>
> Hi,
>
> Beginning with junos 6.4R2 ( 7.1 for sure ) it is possile to use something like this:
>
> CorpX {
> routing-options {
> static {
> route 10.1.8.0/24 next-table CorpY.inet.0;
> }
> }
> }
>
> Krasi
>
> ------------------------------------------------------------------------
>
>
>
> ---Original Message----------------------------------
> FROM: Bosco.Sachanandani at orange.co.in
> TO: juniper-nsp at puck.nether.net
> SUBJECT: Re: [j-nsp] forwarding traffic between VRFs
> SENT: APRIL 28, 2005 07:28PM
> --------------------------------------------------------
> >
> > Hello Folks, I was reading through 'Layer 3 VPN Configuration Examples' herehttp://www.juniper.net/techpubs/software/junos/junos64/swconfig64-vpns/frameset.htm but could not come up with a solution.
> > The requirement is "fairly" simple:
> > 2 separate L3 VPNs CorpX and CorpY configured on 2 PE routers at
> > 2separate geographically dispersed locations. Static routes used to routepackets towards the CPE. The local leased lines connected for CorpX and are part of their respective VRFs (LL for CorpX is part ofCorpX_VRF) and not part of inet.0 The requirement is to "mix" traffic for a particular subnet 10.1.8.0/24between the 2VRFs i.e. at CorpX's ingress interface, a filter for anygiven subnet, should hop all traffic for 10.1.8.0/24 into CorpY_VRF anduse the default route in CorpY_VRF to go on upstream.
> > The problem here is that filter-based forwarding works only if theinterface (CorpX's ingress interface) lies in inet.0, which is notapplicable in my setup.
> > Excerpt from the documentation:
> > " For this configuration to work, the following must be true:
> > 1) The interfaces that use filter-based forwarding must not be bound tothe VPN. 2) Static routing must be used as the means of routing. 3) You must define an interface routing table group that is shared amonginet.0 and the VRFs to provide local routes to the VRF. "
> >
> > Points 2 and 3 can be expedited but point 1 remains a constraint forwhich I cannot figure out a workaround.
> > Following this
> > linkhttp://boulder.noaa.gov/noc/juniper/software/junos54/swconfig54-vpns/html/vpnl3-examples43.html also talks about importing routes from inet.0 Configure the routing options as follows:
> > [edit]
> > routing-options {
> > rib-groups {
> > inet-access {
> > import-rib inet.0;
> > }
> > }
> > }
> >
> > Would be great is someone can provide any pointers for a workaround.
> > Thanks
> >
> >
> > “The information in this message is confidential and may be legally
> > privileged. It is intended solely for the addressee. Access to this
> > message by anyone else is unauthorized. If you are not the intended
> > recipient, any disclosure, copying, or distribution of the message, or
> > any action or omission taken by you in reliance on it, is prohibited
> > and may be unlawful. Please immediately contact the sender if you
> > have received this message in error. Thank you. Hutchison Max Telecom
> > Limited.” _______________________________________________juniper-nsp
> > mailing list
> > juniper-nsp at puck.nether.nethttp://puck.nether.net/mailman/listinfo/jun
> > iper-nsp
> >
> >
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net http://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
> “The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. Thank you. Hutchison Max Telecom Limited.”
>
>
More information about the juniper-nsp
mailing list