L3 VPN Management
saku at ytti.fi
Wed Mar 7 02:57:09 CST 2012
On (2012-03-07 07:07 +0000), Leigh Porter wrote:
> What's the nicest way of allowing the ops servers all talk to each VPN instance? At the moment I just us pretty normal L3VPN techniques so that every VPN sees routes tagged with the ops VPN target community and so that the ops VPN sees all the other VPN routes but the division between VPNs is maintained.
You might want to peek at MPLS VPN Security book by Behringer for some
But personally I'd do it by having RT for MGMT servers and different RT for
addresses needing centralized MGMT. So two special-use RTs.
The NMS network would export routes with this RT:Servers (only the servers
actually poking the VPN network, not everything)
And the customer VRFs would import this RT:Servers.
The customer VRFs would export (only the nodes actually needing NSM, not
whole network) routes with RT:CPEs.
And the NMS network would import RT:CPEs.
One way to do latter part is
JunOS: set routing-instance FOO rib FOO.inet.0 static route CPE/32 qualified-next-hop CPE interface xe-4/2/0.42 tag 2000
IOS: ip route vrf FOO CPE 255.255.255.255 ten4/2/0.42 CPE tag 2000
And have policy which matches to 2000 and add RT:CPE.
Annoyingly in JunOS you cannot easily import more than one RT, I hope
they'll fix it so that you can do IOS style RT + policy imports.
So in JunOS you almost certainly want chained import policy like
'vrf-import [ VRFOO-IMPORT VRF-MGMT-IMPORT ]' where VRFOO-IMPORT is just
'from community VRFFOO; then default-action accept' and VRF-MGMT-IMPORT is
'from community RT:Servers; then default-action accept'
> Or, would it be nicer to have the firewall have a foot in each VPN, advertise routes to ops systems to each VPN instance and receive routes from all the other VPNs?
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
More information about the NANOG