Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Troubleshooting Private VLANs on QFX Switches

Use the following information to troubleshoot a private VLAN configuration.

Limitations of Private VLANs

The following constraints apply to private VLAN configurations:

  • IGMP snooping is not supported with private VLANs.

  • Routed VLAN interfaces are not supported on private VLANs

  • Routing between secondary VLANs in the same primary VLAN is not supported.

  • If you want to change a primary VLAN to be a secondary VLAN, you must first change it to a normal VLAN and commit the change. For example, you would follow this procedure:

    1. Change the primary VLAN to be a normal VLAN.

    2. Commit the configuration.

    3. Change the normal VLAN to be a secondary VLAN.

    4. Commit the configuration.

    Follow the same sequence of commits if you want to change a secondary VLAN to be a primary VLAN. That is, make the secondary VLAN a normal VLAN and commit that change and then change the normal VLAN to be a primary VLAN.

Forwarding with Private VLANs

Problem

Description

  • When isolated VLAN or community VLAN tagged traffic is received on a PVLAN trunk port, MAC addresses are learned from the primary VLAN. This means that output from the show ethernet-switching table command shows that MAC addresses are learned from the primary VLAN and replicated to secondary VLANs. This behavior has no effect on forwarding decisions.

  • If a packet with a secondary VLAN tag is received on a promiscuous port, it is accepted and forwarded.

  • If a packet is received on a PVLAN trunk port and meets both of the conditions listed below, it is dropped.

    • The packet has a community VLAN tag.

    • The packet is destined to a unicast MAC address or multicast group MAC address that was learned on an isolated VLAN.

  • If a packet is received on a PVLAN trunk port and meets both of the conditions listed below, it is dropped.

    • The packet has an isolated VLAN tag.

    • The packet is destined to a unicast MAC address or multicast group MAC address that was learned on a community VLAN.

  • If a packet with a primary VLAN tag is received by a secondary (isolated or community) VLAN port, the secondary port forwards the packet.

  • If you configure a community VLAN on one device and configure another community VLAN on a second device and both community VLANs use the same VLAN ID, traffic for one of the VLANs can be forwarded to the other VLAN. For example, assume the following configuration:

    • Community VLAN comm1 on switch 1 has VLAN ID 50 and is a member of primary VLAN pvlan100.

    • Community VLAN comm2 on switch 2 also has VLAN ID 50 and is a member of primary VLAN pvlan200.

    • Primary VLAN pvlan100 exists on both switches.

    If traffic for comm1 is sent from switch 1 to switch 2, it will be sent to the ports participating in comm2. (The traffic will also be forwarded to the ports in comm1, as you would expect.)

Solution

These are expected behaviors.

Egress Firewall Filters with Private VLANs

Problem

Description

If you apply a firewall filter in the output direction to a primary VLAN, the filter also applies to the secondary VLANs that are members of the primary VLAN when the traffic egresses with the primary VLAN tag or isolated VLAN tag, as listed below:

  • Traffic forwarded from a secondary VLAN trunk port to a promiscuous port (trunk or access)

  • Traffic forwarded from a secondary VLAN trunk port that carries an isolated VLAN to a PVLAN trunk port.

  • Traffic forwarded from a promiscuous port (trunk or access) to a secondary VLAN trunk port

  • Traffic forwarded from a PVLAN trunk port. to a secondary VLAN trunk port

  • Traffic forwarded from a community port to a promiscuous port (trunk or access)

If you apply a firewall filter in the output direction to a primary VLAN, the filter does not apply to traffic that egresses with a community VLAN tag, as listed below:

  • Traffic forwarded from a community trunk port to a PVLAN trunk port

  • Traffic forwarded from a secondary VLAN trunk port that carries a community VLAN to a PVLAN trunk port

  • Traffic forwarded from a promiscuous port (trunk or access) to a community trunk port

  • Traffic forwarded from a PVLAN trunk port. to a community trunk port

If you apply a firewall filter in the output direction to a community VLAN, the following behaviors apply:

  • The filter is applied to traffic forwarded from a promiscuous port (trunk or access) to a community trunk port (because the traffic egresses with the community VLAN tag).

  • The filter is applied to traffic forwarded from a community port to a PVLAN trunk port (because the traffic egresses with the community VLAN tag).

  • The filter is not applied to traffic forwarded from a community port to a promiscuous port (because the traffic egresses with the primary VLAN tag or untagged).

Solution

These are expected behaviors. They occur only if you apply a firewall filter to a private VLAN in the output direction and do not occur if you apply a firewall filter to a private VLAN in the input direction.

Egress Port Mirroring with Private VLANs

Problem

Description

If you create a port-mirroring configuration that mirrors private VLAN (PVLAN) traffic on egress, the mirrored traffic (the traffic that is sent to the analyzer system) has the VLAN tag of the ingress VLAN instead of the egress VLAN. For example, assume the following PVLAN configuration:

  • Promiscuous trunk port that carries primary VLANs pvlan100 and pvlan400.

  • Isolated access port that carries secondary VLAN isolated200. This VLAN is a member of primary VLAN pvlan100.

  • Community port that carries secondary VLAN comm300. This VLAN is also a member of primary VLAN pvlan100.

  • Output interface (monitor interface) that connects to the analyzer system. This interface forwards the mirrored traffic to the analyzer.

If a packet for pvlan100 enters on the promiscuous trunk port and exits on the isolated access port, the original packet is untagged on egress because it is exiting on an access port. However, the mirror copy retains the tag for pvlan100 when it is sent to the analyzer.

Here is another example: If a packet for comm300 ingresses on the community port and egresses on the promiscuous trunk port, the original packet carries the tag for pvlan100 on egress, as expected. However, the mirrored copy retains the tag for comm300 when it is sent to the analyzer.

Solution

This is expected behavior.