Here's an example of a config that I have in my lab. We use this out in production for managing customer CPE. We basically leak WAN subnets over and some management space back into the customer VRFs. There are a few superfluous things in here, but it should get you started. The big things to remember are auto-export and creating export policys for VRF import:
swo...@lab-m320> show configuration logical-routers VPN-TEST
interfaces {
ge-0/0/0 {
unit 10 {
vlan-id 10;
family inet {
address 11.11.11.2/30;
}
family mpls;
}
unit 20 {
vlan-id 20;
family inet {
address 12.12.12.2/24;
}
family mpls;
}
}
lo0 {
unit 10 {
family inet {
address 192.168.1.2/32;
}
}
unit 11 {
family inet {
address 1.1.1.1/32;
}
}
}
}
protocols {
mpls {
interface all;
}
bgp {
family inet {
unicast;
}
family inet-vpn {
unicast;
}
group internal {
type internal;
local-address 192.168.1.2;
neighbor 192.168.1.1;
}
}
ospf {
area 0.0.0.0 {
interface ge-0/0/0.10;
interface lo0.10;
}
}
ldp {
interface all;
}
}
policy-options {
policy-statement from-vpn {
term 1 {
from {
community vpn;
route-filter 100.100.100.1/32 exact;
route-filter 200.200.200.1/32 exact;
}
then {
community set man;
accept;
}
}
}
community man members target:65509:444;
community vpn members target:65509:555;
}
routing-instances {
VPN-1 {
instance-type vrf;
interface ge-0/0/0.20;
route-distinguisher 65509:555;
vrf-target target:65509:555;
routing-options {
auto-export;
}
protocols {
bgp {
group vpn-External {
type external;
peer-as 65511;
neighbor 12.12.12.1;
}
}
}
}
man {
instance-type vrf;
interface lo0.11;
route-distinguisher 65509:444;
vrf-import from-vpn;
vrf-target target:65509:444;
routing-options {
auto-export;
}
}
}
routing-options {
autonomous-system 65509;
}
{master}
swo...@lab-m320>
Scott Wolfe
Cybera, Inc
615-301-2346
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Mike Kiefer
Sent: Tuesday, February 02, 2010 9:22 AM
To: [email protected]
Subject: [j-nsp] VRF Leaking Without MPLS
Pardon my ignorance with Juniper gear. I have a problem that probably pretty
easy to fix, but I'm not sure how to do it.
I have a single M10i with multiple routing-instances. It's running what Cisco
would call "vrf-lite", i.e. no MPLS. Every remote site has either multiple
vlans/vrfs or PVCs/vrfs. Separate OSPF routing tables are maintained end to end.
I want to leak routes from one instance into the other and vice-versa. I ran a
test on Olives and used the next-table command on each of two routers. It
worked. When I try to leak between both tables on one router using the
next-table command, I get a next-table may loop error.
What I would like to do is generate a default route within the native VRF via
OSPF and have all of the route leaking happen on the M10i. The end nodes would
use the native VRF and default route to make it back to the M10i. I don't want
to provision a VRF/routing instance at the remote end just to do leaking.
Is there a way to make this work with next-table statics without getting the
"next-table may loop"?
Should I abandon the whole next-table option and do something entirely
different?
I would appreciate some pointers, and maybe a quick little config snipet if
possible.
Thanks,
Mike
_________________________________________________________________
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
http://clk.atdmt.com/GBL/go/201469229/direct/01/
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
PGP.sig
Description: PGP signature
_______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
