Private vlan with fabric attach

[SimoneZ]

Hello,

we want to deploy private vlans in our fabric attach infrastructure, in order to limit the traffic in the same subnet.

All the endpoints are connected to access switches (that are in SwitchEngine/EXOS), while core switches are used only as distribution layer.

For EXOS, I had this link as a reference

https://documentation.extremenetworks.com/exos_30.4/GUID-56B81F2C-8A3B-4303-A212-92322613EFAA.shtml

Where it is possible to extend the private vlans between switches. My question is, which configuration is needed on backbone switches (fabric engine), to extend the private vlans between access switches?

[SimoneZ · Accepted solution]

Hi Ludovico,

thanks for your answer. Very interesting. I will set up a lab and try what you said. Since the goal is to limit traffic in the same subnet, could another approach be to configure policies in XIQ-SE specifying services to allow and not and push them to EXOS switches? Are there any limitation for this feature with EXOS switches (except TCAM limitations)?

[Myra1 · Accepted solution]

To set up a Private VLAN (PVLAN) with Fabric Attach, integrating a context like "Animesuge" for easier understanding, let's break down the basics: Private VLAN (PVLAN): A PVLAN is used in network segmentation to isolate traffic within the same VLAN, allowing for more secure and efficient traffic management. It consists of primary and secondary VLANs, where the secondary VLANs are either isolated or community VLANs, offering different levels of isolation among devices. Fabric Attach: This is a network automation protocol often used in Software Defined Networking (SDN) to simplify the deployment of network services. With Fabric Attach, the network automatically assigns VLANs and other configurations to connected devices, making network setup faster and less error-prone. Using Animesuge as an Example Context: Imagine Animesuge needs to isolate its servers (database, content delivery, web servers) for security while still being part of a larger network. By setting up a PVLAN, you can place each server type into isolated or community VLANs. Using Fabric Attach would then allow these servers to be dynamically assigned to the correct VLANs as they come online or change location within the network, enhancing both security and management efficiency.

[Leslie11]

Private VLAN with Fabric Attach: Overview and Explanation

Private VLANs (PVLANs) are an advanced VLAN feature that provides enhanced network isolation and segmentation within a single VLAN domain. They allow for granular traffic control between devices in the same VLAN, supporting security and scalability. Fabric Attach (FA), on the other hand, is an automated network provisioning protocol designed to simplify the deployment of services like VLANs or PVLANs in complex networks.

How Private VLANs Work

1. Primary VLAN: Acts as the overarching VLAN where all devices are associated.
2. Secondary VLANs: Subdivided into:
   • Isolated VLANs: Devices can only communicate with the promiscuous port (typically connected to a router or gateway) and not with each other.
   • Community VLANs: Devices within the same community can communicate but are isolated from other communities and isolated VLANs. Visit: https://zoroxtv.mom/

[Ludovico_Steven]

Private VLANs (PVLANs) are always defined using 2 VLAN-ids, a primary & secondary (and additional VLAN-ids if implemented with PVLAN communities which EXOS supports but VOSS does not).

If you want to extend a PVLAN between 2 switches, you always need to trunk all those VLAN-ids between the 2 switches. On VOSS the port can be configured as private-vlan isolated|promiscuous|trunk; trunk is what you need.

Now, if you have Fabric Engine/VOSS in the core/distribution but Switch Engine/EXOS as the access, you are most likely using Fabric Attach (FA) between the two. And there's the problem, FA was never designed to handle PVLANs. FA TLVs can only signal a single VLAN-id associated to an I-SID and cannot signal PVLAN vs. regular VLAN.

If you want to use PVLANs in such a setup you will need to do away with FA and manually configure your Switch Engine/EXOS, at both ends. The PVLAN will also need to be configured manually on all switches (XIQ-SE has no PVLAN support).

A better approach, if you have universal hardware, is to go completely fabric to the edge, and run Fabric Engine on you access switches as well. Now you can have the PVLAN only created on these (the creation and assignment to access ports as well as I-SID association can be fully automated via RADIUS VSA, this XIQ-SE can do) and in fabric a PVLAN with an I-SID assigned becomes an ETREE service which can be extended anywhere else in the fabric (no need to set any ports to trunk mode, no need for FA).

[SimoneZ · Accepted solution]

Hi Ludovico,

thanks for your answer. Very interesting. I will set up a lab and try what you said. Since the goal is to limit traffic in the same subnet, could another approach be to configure policies in XIQ-SE specifying services to allow and not and push them to EXOS switches? Are there any limitation for this feature with EXOS switches (except TCAM limitations)?