Yesterday I did some lab work with an SE from Juniper with their hypervisor-based FW solution, vGW. As a virtual-networking guy (and in this case I mean the multi-tenant/multi-security zone “M(T/SZ) kind of virtual-networking), I wanted to ensure that VMs stayed in their proper environment and that new VMs could not arbitrarily be placed into an environment by a VMWare admin.
Additionally I wanted to ensure in the network itself that different environments had separate control and forwarding structures and that we could accomodate potential overlapping VLAN IDs. This was achieved using VPLS and VLAN normalization (aka, VLAN translation).
In the diagram we have two separate switched networks (i.e., they are isolated from each other): Red and Green. They both happen to be using a VLAN ID of 200. The Cisco 7200 represents a routed path in your production environment between Red and Green that might include an IPS or other appliances. Red and Green each have their own L2VPN in the MPLS network.
The bottom MX is performing VLAN normalization. What this means, effectively, is that the VLAN IDs on the trunk between the bottom MX and the VMWare host are only locally significant to that trunk. In this case we are translating Red’s VLAN 200 to VLAN 1000, and Green’s VLAN 200 to VLAN 1100. In the configuration of the bottom MX below, you can see that we created two virtual-switch instances. Within each instance we created a bridge-domain (a VLAN) and assigned logical-interfaces to them. VLAN translation happens automatically when the VLAN-ID of the logical-interface differs from the VLAN-ID of the bridge-domain the interface is assigned to.
On the VMWare host we have a single vSwitch with two port-groups, one for Red and one for Green. The VLAN IDs, predictably, are 1000 for Red and 1100 for Green.
The vGW firewall is configured with two groups, Red and Green, that are a “match-any” list of authorized VMs (specified by VM ID) for those environments. This list, in turn, is referenced in Inbound and Outbound firewall rules that only permit the authorized VMs for a given port-group to communicate within that port-group. Additionally the “match-any” lists are referenced in a compliance policy which will disconnect the vnic of any unauthorized VMs attached to a port-group.
Here is the configuration for the bottom MX (just the relevant bits highlighting how VLAN normalization works):
————————————————————————————————————
juniper@TL-MX960> show configuration interfaces ge-3/0/4
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 1000 {
encapsulation vlan-bridge;
vlan-id 1000;
}
unit 1100 {
encapsulation vlan-bridge;
vlan-id 1100;
}
juniper@TL-MX960> show configuration routing-instances VGW-TEST-RED
instance-type virtual-switch;
route-distinguisher 10.255.200.200:300;
vrf-target target:300:300;
protocols {
vpls {
no-tunnel-services;
site RED {
site-identifier 1;
}
}
}
bridge-domains {
VLAN-200 {
domain-type bridge;
vlan-id 200;
interface ge-3/0/4.1000;
}
}
juniper@TL-MX960> show configuration routing-instances VGW-TEST-GREEN
instance-type virtual-switch;
route-distinguisher 10.255.200.200:350;
vrf-target target:350:350;
protocols {
vpls {
no-tunnel-services;
site GREEN {
site-identifier 1;
}
}
}
bridge-domains {
VLAN-200 {
domain-type bridge;
vlan-id 200;
interface ge-3/0/4.1100;
}
}
————————————————————————————————————
Next are some screen shots from vGW showing the configured elements for the Red VMs. (I know it says Orange in the first one.. that should say Red). The first one is a Smart Group which represents a list of authorized VMs for the Red port-group. Each time you add a VM to this port-group, you will need to add additonal match items here.
This second item is a Smart Group that matches on all VMs attached to the port-group named “VLAN 1000.” (This was a bad choice for a name. Just to be clear, its not actually matching on VLAN 1000, its matching on a port-group named “VLAN 1000.” We probably should have named the port-group “Red.”) What this actually represents is a list of all VMs assigned to this port-group. This includes any unauthorized VMs as well as any VMs that are not powered on.
So now we take these two Smart Groups we have defined and we create a compliance rule. The compliance scope uses the second Smart Group we created. The match item in this rule (at the bottom) matches on the first Smart Group we created. What this rule effectively says is: “Any VMs attached to port-group “VLAN 1000″ that are not in the authorized list of VMs will have their vnic disconnected.”
In addition to these items, we also created Inbound and Outbound firewall rules in vGW that reference the first smart-group above that we created. Effectively these say that within the port-groups only authorized VMs are allowed to communicate.
So.. some final notes…. First, we are using VPLS internal to our data center to achieve virtual-switching. This means that we have an L2VPN defined for each M(T/SZ) environment in our datacenter. We can turn up VMs for any security-zone or tenant on any VMWare host by simply configuring a VPLS instance on the PE that the target VMWare host is attached to.
Having to keep track of the VLAN translations is not ideal. I recently discovered, however, that if you are using a switch blade in your VMWare host that runs BladeOS 6.3 or higher, than you have Q-in-Q capability! You can support up to thirty-two M(T/SZ) environments on one chassis this way. But that topic is a different blog post…
About Cloud Toad
