Arista EOS Private VLAN (PVLAN) Configuration Guide

Private VLANs let you segment a single broadcast domain without spending a VLAN and an IP subnet per customer or per server tier. Arista EOS implements 802.1Q private VLANs with the usual three port types — promiscuous, isolated and community — inside a primary VLAN that maps one or more secondary VLANs. This walkthrough builds a working PVLAN on EOS, including the parts people get wrong: the primary/secondary association direction, the fact that a private VLAN still needs its SVI on the primary VLAN, and the verification output that proves isolation is actually enforced in hardware.

What a private VLAN buys you

An ordinary VLAN is one broadcast domain with one IP subnet: everybody sees everybody's broadcasts and, unless ACLs get involved, everybody can reach everybody. A private VLAN splits that domain into:

• Promiscuous ports — typically the uplink or the gateway. They can talk to every port in the primary VLAN.
• Isolated ports — can talk to promiscuous ports only. Two isolated hosts cannot reach each other.
• Community ports — can talk to each other and to promiscuous ports, but not to hosts in other communities.

That is exactly the shape of a hosting cage, a DMZ with several tenants behind one firewall, or a lab where you want servers to reach the gateway but never each other.

Step 1 — create the primary and secondary VLANs

switch(config)# vlan 100
switch(config-vlan-100)# name PVLAN-PRIMARY
switch(config-vlan-100)# private-vlan primary
switch(config-vlan-100)# exit

switch(config)# vlan 101
switch(config-vlan-101)# name PVLAN-ISOLATED
switch(config-vlan-101)# private-vlan isolated
switch(config-vlan-101)# exit

switch(config)# vlan 102
switch(config-vlan-102)# name PVLAN-COMMUNITY
switch(config-vlan-102)# private-vlan community
switch(config-vlan-102)# exit

The primary VLAN is the only one that carries an SVI. Secondary VLANs exist purely as membership labels; never assign an IP address to them.

Step 2 — associate secondaries with the primary

switch(config)# vlan 100
switch(config-vlan-100)# private-vlan association 101,102

Association direction is one-way and always points from primary to secondary. If you see the secondaries listed by show vlan 100 but host ports still cannot forward, this statement is the first thing to check.

Step 3 — configure the host ports

! Isolated host
switch(config)# interface Ethernet3
switch(config-if-Et3)# switchport mode private-vlan host
switch(config-if-Et3)# switchport private-vlan host-association 100 101

! Community host
switch(config)# interface Ethernet4
switch(config-if-Et4)# switchport mode private-vlan host
switch(config-if-Et4)# switchport private-vlan host-association 100 102

! Promiscuous uplink toward the gateway
switch(config)# interface Ethernet5
switch(config-if-Et5)# switchport mode private-vlan promiscuous
switch(config-if-Et5)# switchport private-vlan mapping 100 101,102

In EOS, setting the port mode to private-vlan host automatically applies switchport mode access semantics underneath; the host association is what decides which secondary VLAN frames are tagged into on ingress.

Step 4 — the gateway

switch(config)# interface Vlan100
switch(config-if-Vl100)# ip address 10.10.100.1/24
switch(config-if-Vl100)# no shutdown

One SVI on the primary VLAN serves every secondary VLAN. All hosts in isolated and community VLANs share the default gateway, and the switch enforces isolation before any traffic reaches that SVI.

Verification: prove isolation in hardware

switch# show vlan
switch# show vlan 100
switch# show interfaces Ethernet3 switchport
switch# show interfaces private-vlan mapping

! behavioural check, not just config check
switch# ping 10.10.100.10 source 10.10.100.11

The last check is the one that matters. Configuration can look perfect while the ASIC still forwards between isolated ports — usually because the port was in private-vlan host mode without a valid host association, so EOS falls back to ordinary VLAN behaviour. Send a ping between two hosts in the same isolated VLAN; it must fail, while both must still reach the promiscuous gateway.

Private VLANs with MLAG and trunks

A PVLAN can span an MLAG pair: the primary VLAN and every associated secondary VLAN must exist on both members with identical associations, and the peer link must carry the primary VLAN as a trunk. If the association lists differ between members, traffic that ingresses on one chassis and egresses through the other loses its secondary label and isolation silently disappears. See the EOS MLAG runbook for the peer-link VLAN requirements.

Common mistakes

• Putting an IP address on a secondary VLAN SVI (isolation still works, but the subnet is unreachable from the gateway).
• Forgetting private-vlan association and testing with the uplink — hosts reach nothing and it looks like a cabling fault.
• Trunking a secondary VLAN to another switch without also trunking the primary; frames arrive with a label the far switch has no mapping for and are dropped.
• Mixing PVLAN and normal access ports for the same subnet, which bypasses isolation entirely through the normal port.

Where private VLANs earn their keep

The common thread is a shared IP subnet with a policy requirement that hosts must not talk to each other. When hosts need separate subnets anyway, ordinary VLANs are simpler — a private VLAN is the right tool specifically when you want isolation without allocating a subnet per group.

Scaling and platform notes

• Private VLANs consume VLAN IDs as secondary VLANs, so a design with many groups still needs VLAN budget planning (4094 total, and internal VLANs use part of that range on routed ports).
• Secondary VLANs do not get SVIs, so you cannot apply per-community Layer 3 policy. Use ACLs on the promiscuous port or on the gateway if different communities need different treatment.
• DHCP relay and snooping behave on the primary VLAN; make sure the DHCP helper or relay address is configured on the primary SVI, not the secondaries.
• Spanning tree operates on the primary VLAN. If you enable PVLAN alongside MSTP, review instance-to-VLAN mappings so the secondaries follow the primary's topology decisions.
• Monitoring and SPAN sessions must mirror the primary VLAN; a session set up on a secondary VLAN alone will miss promiscuous port traffic.

Verification command reference

If show vlan 100 lists the associations but host ports still exchange traffic, drop to the hardware view: clear the MAC table entry for one host and watch which ports learn it after a ping. In a correctly configured PVLAN, the destination MAC is only ever learned on the promiscuous port.

Related VLAN guides

For the base VLAN and SVI mechanics, start with Arista EOS VLAN configuration step by step; trunk and port-channel specifics are in the EOS VLAN trunk and port-channel guide.

原文链接：https://www.arista.com/en/um-eos/eos-virtual-lans-vlans?print=1&tmpl=component