IRB Interfaces in Private VLANs on MX Series Routers

PVLANs are supported on MX80 routers, on MX240, MX480, and MX960 routers with DPCs in LAN mode, and on MX Series routers with MPC1, MPC2, and Adaptive Services PICs. This functionality is supported only on MX240, MX480, and MX960 routers that function in enhanced LAN mode (by entering the network-services lan statement at the [edit chassis] hierarchy level).

IRB in PVLANs replaces the external router used for routing across VLANs. The routing operations in the absence of IRB occur through external router connected to promiscuous port. This behavior takes care of all the routed frames for all the ports defined under the PVLAN domain. In this case, no layer 3 exchange occurs on MX Series routers in enhanced LAN mode for this PVLAN bridge domain. In the case of IRB, the Layer 3 interface is associated with the primary VLAN that is configured and is considered to be a single Layer 3 interface for the entire PVLAN domain. The ingress routed traffic from all ports in the PVLAN domain needs to be mapped to this IRB interface. The egress of the IRB interface take places under the PVLAN. For a PVLAN domain spanning multiple switches, only one IRB interface can be configured in one switch. This IRB interface represent whole PVLAN domain to interact with the Layer 3 domains. An IRB interface only associates with the primary bridge domain and all Layer 3 forwarding occurs only in the primary bridge domain. When a Layer 3 packet is received in an isolated port or a promiscuous port, the device first locates the secondary bridge domain, based on secondary bridge domain to find primary bridge domain identifier. If the destination MAC address is the local IRB MAC address, the microcode transmits the packet to IRB interface associated with primary bridge domain for further processing. The same procedure occurs for receiver Layer 3 packets in an interswitch link (ISL) port with the isolated or community VLAN tag.

For the ingress Layer 3 packet with Layer 3 forwarding logic sent to IRB interfaces associated with a PVLAN bridge domain, the device processes and determines the ARP entry to send packet to the related interface that might be an isolated port or a community port. The microcode appends or translates the packet VLAN ID to the isolation or community vlan ID based on the port type. The VLAN ID is removed if the related port is untagged. A special operational case exists for Layer 3 packets that are forwarded to remote isolated or community port through the ISL link. The Layer 3 packet might contain the primary bridge domain VLAN ID and the remote node performs the translation or pop operation when it sends the packet out on the related port. This method of processing is different from Layer 2 domains. Because all forwarding base on ARP must be unicast traffic and in the remote node, the port that must be used to forward is known and the transmission of PVLAN ID occurs properly.

An ARP entry carries only the primary bridge domain information. When an ARP response is received from an isolated port or a promiscuous port, the system identifies the secondary bridge domain, and based on the secondary bridge domain, it attempts to retrieve the primary bridge domain identifier. ARP packets eventually reach the IRB interface associated with the primary bridge domain. The kernel considers this ARP packet as a normal bridge domain and creates and maintains the ARP entry only for the primary bridge domain. The same procedure is adopted for ARP request packets that are destined for the local IRB MAC address. The response is transmitted through the IRB interface and appropriate VLAN translation or a pop operation is performed, depending on the received interface.