[j-nsp] l3vpn

[Alexander Arsenyev (GU/ETL)]

This probably will work but let me recall what the original question was -
"Can we configure multiple vrfs for a single interface?"
The config below implies that interface on [pe] facing [aggr] is in routing-instance "aggr", or, in other words,
single vrf named "aggr" is assigned to the interface on [pe] which faces [aggr].
So the answer I guess would be "single interface could have only 1 VRF assigned but there are workarounds for the specific circumstances".
Regards
Alex


-----Original Message-----
From: Pedro Roque Marques [mailto:roque at juniper.net]
Sent: 19 October 2005 18:41
To: Alexander Arsenyev (GU/ETL)
Cc: Pablo Varela; juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] l3vpn


Alexander Arsenyev GU/ETL wrote:
> OK, how the return packets are going to be routed/forwarded? 

Lets assume a given problem:

	customer 1 ---
			[aggr] --- [pe] --- [vpn network]
	customer 2 ---


We have 2 customers being aggregated by a non VPN capable box... and we 
want to be able to actually deliver VPN service to them bypassing this 
limitation.

So we create 3 VRFs on the PE.
o customer 1
o customer 2
o aggr

The interface(s) go into the aggr VRF.

Then lets assume BGP as PE-CE, just to make things easy.

You have:

routing-instances {
     aggr {
         instance-type vrf;
	vrf-import reject-all;
	vrf-export aggr-export;
	interface foo;			/* switch interface */
	routing-options auto-export;
	no-vrf-advertise;
	forwarding-options family inet filter input <apply-scu>;
	protocols bgp {
	    group pe-ce {
		neighbor <1> {
		    peer-as <1>;
		    import <policy-1>;  /* set customer community*/
		}
		neighbor <2> {
		    peer-as <2>;
		    import <policy-2>;
		}
	    }
	}
     }
     customer-1 {
	instance-type vrf;
	vrf-target target:<vpn-1>;
	routing-options auto-export;
     }
     customer-2 {
	instance-type vrf;
	vrf-target target:<vpn-2>;
	routing-options auto-export;
     }
}

routing-options forwarding-table export <set-scu>;
interfaces foo unit x family inet accounting source-class-usage;

policy-options {
     policy-statement set-scu {
	term a {
	    from community customer-1;
	    then source-class customer-1;
	}
	term b {
	    from community customer-2;
	    then source-class customer-2;
         }
     }
     policy-statment aggr-export {
	term a {
	    from community customer-1;
	    then community add target:<vpn-1>;
	}
	term b {
	    from community customer-2;
	    then community add target:<vpn-2>;
	}
	then reject;
     }
}

firewall filter apply-scu {
     term a {
	from source-class customer-1;
	then routing-instance customer-1;
     }
     term b {
	from source-class customer-2;
	then routing-instance customer-2;
     }
}

In english:
o The aggregation VRF does receive routing from the CEs, and use the 
received routes to do a source lookup and assign traffic to the 
respective VRFs.

o The aggregation vrf-export policy is doing the same thing for control 
information... routes tagged w/ target:<vpn-1> will then be 
auto-exported to the customer-1 vrf, which will give you the return path.

[note that the config above was untested and all from memory... i may 
have goofed up some of the config commands].

have fun,
   Pedro.