Interface basics on the Juniper MX

I’ve been spending more time on the MX recently and I thought it would be worthwhile to document some of the basics around interface configuration.  If you’re like me, and come from more of a Cisco background, some of configuration options when working with the MX weren’t as intuitive.  In this post, I want to walk through the bare bone basic of configuring interfaces on a MX router.

Basic L3 interface

The most basic interface configuration possible is a simple routed interface. You’ll note that the interface address is configured under a unit. To understand what a unit is you need to understand some basic terminology that Juniper uses. Juniper describes a physical interface as an IFD (Interface Device). In our example above the IFD would be the physical interface ge-0/0/0. We can then layer one or more IFL (Interface Logical) on top of the IFD. In our example the IFL would be the unit configuration, in this case ge-0/0/0.0. Depending on the configuration of the IFD you may be able to provision additional units. These additional units (Logical interfaces (IFLs)) can be thought of as sub-interfaces in Cisco parlance and would be identified by VLANs just as sub-interfaces are. However, in our current configuration, the MX thinks this is a standard L3 interface so it will not allow us to configure additional units…

Basic L3 interface with VLAN tags

As we mentioned above, a default L3 interface will only allow you define a single unit, unit 0. If you wish to define more units you have to enable the IFD to do this by providing the vlan-tagging configuration. This will allow the interface to handle single dot1q tags. Once the IFD is configured you simply provide the vlan-id to use for each IFL under the unit configuration. I’ll point out here that it is not a requirement for the unit numbers to correlate to the vlan-id but it is good practice to match these up.

Basic L3 interface with QinQ VLAN tags

In order to support QinQ vlan tagging we need to change the configuration on the IFD to stacked-vlan-tagging. However, in doing so, we break any IFL configuration that used the vlan-id parameter. The fix for this is to instead use the flexible-vlan-tagging option at the IFD which will allow both configurations to coexist…

Basic bridged interfaces

In this example we are simply bridging two interfaces together. In this case, the MX will treat these interfaces as access ports and simply switch frames between them. The interface configuration is straight forward as we define each interface to have an encapsulation of ethernet-bridge. In addition, it is required that each interface has a unit 0 definition. Notice that in addition to the interface configuration we must also define a bridge-domain and specifically add each interface which we want to participate in the domain.

Basic bridged interfaces with VLAN tags

In this example the ge-0/0/1 interface is VLAN aware and the ge-0/0/0 interface is still acting like an access port. The bridge domain configuration ties these two ports together meaning that a device connected to ge-0/0/1 passing a VLAN tag of 15 will be able to talk to the device connected to the access port.

IRB interfaces with VLAN tags

Here we provide a VLAN interface (Known as a SVI in Cisco land) by utilizing an IRB (Integrated routing and bridging) interface. The IRB interface is assigned to the VLAN by mapping it into the bridge domain as a routing-interface. Traffic that comes into interface ge0/0/1 with a VLAN tag of 15 will be able to reach the IRB interface of 10.20.20.254.

In the next post, we’ll dig further into this by discussing the specifics of bridge domains, learning domains, and VLAN mapping. Stay tuned!

Reply

Your email address will not be published. Required fields are marked *