This is documentation of a part of a Juniper MX router configuration that took me a bit time and reading to get working. I had a number of specific goals.
- 802.3ad (LACP) to aggregate physical links between the MX router and uplinked switches. In the configuration below, you’ll notice I’ve only assigned one physical interface to the link bundle. The idea is that I can scale the configuration sideways with a minimum of effort by simply adding an additional interface to the aggregated link bundle. Even though I’m only using one today, I could use two or more tomorrow.
- 802.1q (VLAN tagging) to virtualize the physical links. The idea is that I can run subinterfaces, one per VLAN. I don’t have to dedicate the physical interface to one specific IP or function. As with my logic behind 802.3ad, I want maximum flexibility with a minimum of reconfiguration should my requirements change in the future.
- Multiple routing instances to allow a single physical MX router to be used for a variety of purposes while maintaining routing table separation. Essentially, I need to create multiple logical routers.
Here we go with the configuration I settled on that is working in my early testing. I’ll update this page if I end up making any significant changes, as there’s several different options available to do almost everything on the MX. The MX is quite flexible.
# Create some number of virtual aggregated Ethernet (ae) interfaces. In this case, interfaces ae0 – ae3 will be created. This is roughly equal to manually creating “Port-Channel” interfaces on a Cisco device.
set chassis aggregated-devices ethernet device-count 4
# Assign a physical interface to an aggregated Ethernet interface. This is similar to the “channel-group” interface command on a Cisco IOS switch, although in Junos, we’re merely assigning membership of the physical interface to the aggregated interface. We aren’t setting the link aggregation method, i.e. LACP, yet.
set interfaces ge-1/0/0 gigether-options 802.3ad ae0
# Enable 802.1q VLAN tagging on the aggregated Ethernet interface.
set interfaces ae0 vlan-tagging
# As implied by the name, “flexible-ethernet-services” allow for unique services to be assigned per unit interface. Think of a unit interface like a sub interface in the Cisco realm. So, one unit interface could be configured for simple 802.1q tagging, while another could be configured for service-provider oriented services like VPLS. In my specific use-case, I don’t technically require this flexibility. But, my idea is to keep my options open and minimize interface reconfiguration requirements in the future.
set interfaces ae0 encapsulation flexible-ethernet-services
# This turns on LACP in active mode (i.e. try to talk to an LACP neighbor). Without this statement, LACP is not enabled at all, and the MX will not respond to LACP advertisements from the other side of the aggregated interface.
set interfaces ae0 aggregated-ether-options lacp active
# Here, we create a unit (sub) interface, and assign it to participate in a VLAN bridge. Remember than an MX router is not a switch, and therefore interfaces on the MX must be specifically configured to participate in a bridge. This is what a switch does by default; by definition, a switch is a bridge.
set interfaces ae0 unit 1111 encapsulation vlan-bridge
# The unit interface is assigned to tag frames with VLAN identifier 1111.
set interfaces ae0 unit 1111 vlan-id 1111
# While we created the bridge and assigned a VLAN tag to traffic flowing through a specific unit interface, we haven’t yet assigned an IP address to the router itself to participate in the VLAN bridge. In my case, I need the MX to participate in OSPF on this bridge. Therefore we’re creating an “IRB” interface – integrated routing & bridging. Cisco routers have IRB interfaces much like this. Cisco switching platforms (like the venerable Catalyst 6500) have switched virtual interfaces (SVIs).
set interfaces irb unit 1111 family inet address 192.168.111.1/30
# I am using this MX platform to service different logical network segments. I’m landing provider-supplied circuits on it, some of which are for my core network to interconnect colo facilities. Other circuits will face third-party customers of mine. And yet other circuits are anticipated to serve purposes as yet undefined. A logical network diagram would represent this as multiple routers, dedicating one router per network region or purpose. I don’t have (or even want) unique physical routers per region, as even the smallest MX platform has enough firepower to meet my aggregate forwarding needs. Instead, I’m going to virtualize the routing tables, dedicating a unique Junos “routing instance” per need. The idea here is to keep routing tables separated, while sharing the same physical platform. In Cisco’s world, I believe VRF-lite is equivalent to the “virtual-router” type of routing instance I’m creating below. The MX is capable of several other types of routing instances, including a full VRF implementation.
# We are creating a routing instance called “CORE” and assigning the IRB.1111 interface created above to it.
set routing-instances CORE instance-type virtual-router
set routing-instances CORE interface irb.1111
# I’m using IRB.1111 to form an OSPF relationship with a neighbor in area 0, and setting the OSPF interface type to be “point to point”. All routes learned through OSPF on IRB.1111 will be confined to the routing instance CORE. Traffic arriving on interfaces that do not participate in the CORE routing instance will be not be impacted by this specific OSPF instance.
set routing-instances CORE protocols ospf area 0.0.0.0 interface irb.1111 interface-type p2p
# Last in the configuration is the creation of the bridge domain – the group of MX interfaces (physical or logical) participating in the same VLAN. I gave the bridge domain a name that indicates it’s part of my CORE topology and servicing VLAN 1111, but I could have called it anything. I’m a big fan of self-documenting by naming network objects I created something logical and repeatable. I also tend to use all capital letters to help distinguish objects I’ve created from default objects or CLI keywords.
set bridge-domains CORE-VLAN-1111 vlan-id 1111
set bridge-domains CORE-VLAN-1111 interface ae0.1111
set bridge-domains CORE-VLAN-1111 routing-interface irb.1111
As always, I’m happy to hear about better or alternate ways to achieve this configuration. I’m still relatively new to Junos, and the MX platform can do about anything you could imagine.