Juniper MX Series

Bridge Filtering Case Study

Up to this point, we have been discussing general MX platform filtering and policing capabilities. This section focuses on a practical filtering and policing deployment, along with the operational mode commands used to validate and confirm filter and policer operation in Junos.

Filter Processing in Bridged and Routed Environments

Before jumping into the case study, a brief review of packet flow and filter processing for MX routers that support simultaneous Layer 2 bridging and Layer 3 routing is in order. This is not only a common use case for the MX, but is also the basics for the upcoming case study, so be sure to follow along.

MX routers use an Integrated Routing Bridging (IRB) interface to interconnect a Bridge Domain (BD) with its Layer 3 routing functionality. On the MX, when traffic arrives at an L2 interface, it’s first inspected to determine whether it needs bridging, routing, or both.

Routed

If the packet’s L2 destination MAC address matches the router’s IRB MAC address, the traffic is routed. In this case, the traffic is mapped to the BD’s IRB, and all filters (or route table lookup) are driven by the IRB configuration. It’s important to note that any bridge family filters applied to the related Layer 2 IFLs, or to the FT in the BD itself, are not evaluated or processed for routed traffic, even though that traffic may ingress on a Layer 2 interface where a Layer 2 input filter is applied.

Bridged

When a packet’s destination MAC address (DMAC) is unicast ...