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?

[Myra1]

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.

[Richard13]

A Private VLAN (PVLAN) with Fabric Attach is a networking concept that combines the isolation benefits of private VLANs with the automated provisioning and configuration capabilities of Fabric Attach in modern network architectures.

Private VLAN Overview

• Purpose: Used to enhance security and limit broadcast domains in a larger VLAN by subdividing it into smaller, isolated groups.
• Types of Ports in PVLAN:
  • Promiscuous Ports: Can communicate with all other ports in the PVLAN.
  • Isolated Ports: Can only communicate with promiscuous ports, not with other isolated or community ports.
  • Community Ports: Can communicate with other community ports and promiscuous ports but not with isolated ports.

Fabric Attach Overview

• Purpose: Simplifies the deployment of VLANs, PVLANs, and other network services by automating their configuration through dynamic signaling mechanisms.
• Key Features:
  • Auto-discovery of VLANs and PVLAN configurations.
  • Integration with management platforms like IEEE 802.1Qbg (Edge Virtual Bridging) for network virtualization.
  • Simplified scaling for complex network architectures.
  • Visit for more information: https://aniwave.com.pl/

[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]

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)?