Nesting vLANs?

June 26, 2006 1:17 PM

Is it possible to nest virtual LANs within a larger virtual LAN, which has its uplink to the backbone?

We have one virtual LAN established in a subnet with its own NAT box and servers inside the vLAN. The virtual LAN has wired outlets in different rooms, and they can all talk to each other and to the "outside" world.

What I would like to do is create a larger vLAN with its uplink to the backbone, and have the smaller vLAN's uplink connected to the larger vLAN.

If it helps to know, the reasoning for this is partially logistic and political:

1. The smaller vLAN would not like to open its services to the larger vLAN.

2. The larger vLAN will be given a direct connection to a Linux computational cluster in a second building. The folks in the smaller vLAN would like access to this cluster.

If I nest the smaller vLAN in the larger vLAN, I figure that I can provide them with access to both the computational cluster and backbone without rewiring the building.

With common switching hardware and software, is this arrangement possible or likely?

Also, have problems with accessing servers within a vLAN from the outside world been solved? Are there ways to configure a server for outside access, or to set up a NAT box to provide outside access to a server?

posted by Mr. Six to computers & internet (7 comments total)

This would be trivial to accomplish with the addition of a router. There's no need to nest VLANs. Each group gets its own VLAN. Then put the cluster on its own VLAN. The router ties them all together and controls what each vlan can access.
posted by pmbuko at 2:04 PM on June 26, 2006

As to your world access question, yes, that's possible as well. You need to use a NAT solution that can handle two-way static mapping (either by port or or full address). Your inside private address can be mapped to a real-world IP address or port of a real-world IP address. The NAT device will then forward all requests to that IP address on to the correct device on your private network.

I'm used to cisco hardware, and setting up a network to accomplish what your asking is not difficult.
posted by pmbuko at 2:08 PM on June 26, 2006

This would be trivial to accomplish with the addition of a router. There's no need to nest VLANs. Each group gets its own VLAN. Then put the cluster on its own VLAN. The router ties them all together and controls what each vlan can access.

Can't do that as we would need to be able to control the routing arrangement. We have to fit these vLANs and private connections within the framework of a larger subnet managed by another group.
posted by Mr. Six at 2:12 PM on June 26, 2006

Questions about your question:

- Is the entire building part of the SAME VTP domain? Meaning do both the external and internal interfaces of the NATdevice plug into the same switch or set of switches? If so do you have the abillity to create (or request the creation of) additional non-routed VLANs?

- Does the 'NAT box' translate through a single public IP on it's external interface or multiple? Does it have multiple, distinctly-addressable internal ports? Can it do any rudimentary routing?
posted by datacenter refugee at 4:08 PM on June 26, 2006

- Is the entire building part of the SAME VTP domain? Meaning do both the external and internal interfaces of the NATdevice plug into the same switch or set of switches? If so do you have the abillity to create (or request the creation of) additional non-routed VLANs?

The external and internal interfaces plug into the same set of switches in our subnet. I don't know if we're using Cisco's VTP arrangement, but I would expect the answer is yes, that we are in the same domain.

Part of our subnet (about 20 ports) has been set aside for this one vLAN. One port connects to a "public" uplink, routed up to the backbone.

We can create multiple non-routed vLANs, but (and I don't have a choice about this) the Linux cluster that sits in another building will only be connected to one vLAN (of our choice) in our subnet.

If I create multiple vLANs, I need them all to be able to connect to the cluster.

Another possibility would be to somehow route cluster traffic between distinct vLANs but I think this would involve reconfiguration work of the cluster network that I may not be able to convince them of (I don't manage the cluster), so that we can somehow forward the traffic between NAT'ed networks.

Does the 'NAT box' translate through a single public IP on it's external interface or multiple? Does it have multiple, distinctly-addressable internal ports? Can it do any rudimentary routing?

It translates through a single IP address. I don't administer the "NAT box"; I believe it's a Sonicwall of one model or another, and it does have a DHCP server and does some routing between hosts within the private network.

Thanks very much!
posted by Mr. Six at 4:28 PM on June 26, 2006

better judgement is screaming at me to diagram this . . .

There are a few ways to do this, and most of them require a better NAT device (or more smaller devices) than your describing. For the sake of example let's say your current private address space is 10.0.0.0/8.

Cheap, Hackish Way:
Leave your current NAT setup as is. Request an additional non-routed VLAN for each nested network you want to set up. Buy a cheap FW or router for each nested network. For each desired nested network, configure each new NAT device with an uplink IP in 10.x.x.x space. Use another private range (192.168 comes to mind) on the private side of each new NAT device. Wire the external int of each nat device to your current 10.x.x.x VLAN and the internal int to a new non-routed VLAN. Re-assign internal VLAN ports accordingly. Leave your servers in the DMZ of the Sonicwall (as is) or you'll lose external connectivity to them. Connect to the cluster network using an IP in the 10.x.x.x space.

Each new 192.168 host will have no path out of it's non-routed VLAN besides the new NAT boxes. The cluster, peering with the Sonicwall's internal range, will be accessible by all clients behind each new NAT device. The nested NAT devices (and consequently, hosts) will then translate (again) through the Sonciwall for external connectivity.

Other (better) ways to do this:
- Have the cluster peer with an IP in your public IP range (no fuss!)
- Buy a multi-interface firewall (each new network = one interface).
- (perfect world) Buy a real router and ask for actual networks from your ISP. Take them in via static routes over an uplink network. Even without nesting the router will be intelligent enough to send shit in the right direction if simple route preferences are applied.

In closing, I'd like to venture a guess that this is to be done in a University setting. I, too, work in education and can smell the fetid stink of political infighting and proponency flag-waving miles away.
posted by datacenter refugee at 5:42 PM on June 26, 2006

Re-assign internal VLAN ports accordingly

So it can technically be done, excellent. Thank you so much for confirming this.

I don't believe I can install routers but the peering with public IPs is something I may look more into, if it might more simply solve external-to-internal access problems.

In closing, I'd like to venture a guess that this is to be done in a University setting. I, too, work in education and can smell the fetid stink of political infighting and proponency flag-waving miles away.

Yeah, basically I have to delicately juggle the desires of a couple specific strong-minded investigators who bring in a lot of research money, with what the networking people (themselves a powerful entity) will acquiesce to installing and configuring, since it is an "unorthodox" and admittedly complex setup.

Thanks again for your very informative answer. I'm hopeful this will help give everyone what they want with as little controversy as possible.
posted by Mr. Six at 6:12 PM on June 26, 2006