So during my efforts to study for the Juniper JNCIP-Ent ( Enterprise Routing & Switching ) exam, I happened to come across a Juniper switching feature called Filter-based VLANs.
In normal VLAN-based switching, a device’s assigned VLAN is configured on it’s access port and can’t be changed no matter what is connected to that port.
Filter-based VLANs work a bit differently – they allow the engineer to map the VLAN based on packet properties.
With this you could conceivably do something like the following diagram shows:
Here we have a Juniper EX-series switch connected to an un-managed hub or switch. We want to map the PC into one VLAN and the VOIP phone into another. The EX switch then trunks the 2 VLANs up to a core switch. We do this with Filter-based VLANs.
Firstly, create the 2 VLANs:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
vlans { GREEN { vlan-id 1; interface { ge-0/0/0.0 } } RED { vlan-id 2; interface { ge-0/0/0.0 { mapping { policy; } } } } } |
And now create a firewall policy to assign the device MAC addresses into each VLAN:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
firewall { family ethernet-switching { filter VLAN_map { term 1 { from { source-mac-address { 00:aa:bb:00:00:01/48; } } then vlan GREEN; } term 2 { from { source-mac-address { 00:aa:cc:00:00:01/48; } } then vlan RED; } term default { then accept; } } } } |
And now in the interface configuration, apply the firewall filter to the physical interface:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
interfaces { ge-0/0/0 { unit 0 { family ethernet-switching { port-mode access; filter { input VLAN_map; } } } } } |
Filter-based VLANs can also match frames on other criteria, such as the IP address – although be aware that this might not work as you expect. ARP packets for instance won’t get properly mapped, so I think that for most practical purposes mapping by MAC address is probably the most useful option. You can also map by MAC prefixes such as the device vendor OUI, for example the above policy rules could have been written as:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
firewall { family ethernet-switching { filter VLAN_map { term 1 { from { source-mac-address { 00:aa:bb/24; } } then vlan GREEN; } term 2 { from { source-mac-address { 00:aa:cc/24; } } then vlan RED; } term default { then accept; } } } } |
which makes things a bit more flexible if the same rule is going to be applied to many interfaces, or across multiple switches.
I admit, there aren’t a lot of circumstances where Filter-based VLANs would be useful (maybe in service provider edge aggregation?). Most enterprises will be using managed switches everywhere – but then again, it’s a handy feature to know about.
