Single Stacking Juniper VME Interface on IPv6
Every few years I get the idea of migrating various management interfaces on different network devices to a single stacked IPv6 configuration. Most recently this has been Juniper EX series vme interfaces. I wanted to write about what appears to be a Junos bug, for which I haven’t been able to locate a Juniper PR.
What’s the VME interface?
VME stands for “virtual management ethernet”. It’s present on Juniper EX and QFX switches, since those are the models that support Juniper’s virtual chassis. This interface takes the physical me0 (management ethernet) interface, and virtualizes the configuration across the entire virtual chassis.
The functional benefit comes when all physical switches in a virtual chassis each have their me0’s cabled to the same L2 segment, allowing you to configure a single IP for all of the management ethernet interfaces. The vme IP will float to whichever switch is currently acting as the master switch in the virtual chassis.
However, with how virtual chassis work, even a stand-alone switch also acts as a virtual chassis, just with a single physical member. In this case, configuring the vme interface instead of the me0 interface, eases the pathway to any eventual virtual chassis you may want to configure in the future. I’m a big supporter of doing work once, and doing it in a way that supports seamless upgrades in the future. For this reason, I prefer to configure the vme interface on stand-alone switches.
(I realize that virtual chassis have fallen out of favor, but it’s 2025, and there’s still many of them deployed, and I’m confident that new virtual chassis will continue to be deployed in the future.)
Management Instance
In 2017 (specifically Junos 17.3R1) Juniper added support for a dedicated routing instance for the management ethernet interface. This functionality was something that had been requested by several customers for years, as mixing management ethernet traffic with the rest of your in-band traffic defeats the purpose of having a dedicated out-of-band interface.
(Prior to 17.3R1, it was reasonably common to have the management ethernet interface be the only interface in the default routing instance, and putting all other in-band interfaces in a separate, non-default, routing instance. This provided the same end result as using the management instance, albeit with a slightly more complicated configuration.)
Juniper has documentation on configuring the dedicated management instance, but here’s the basic config:
system {
management-instance;
}
interfaces {
vme {
unit 0 {
family inet6 {
address 2001:db8::2/64;
}
}
}
}
routing-instances {
mgmt_junos {
instance-type forwarding;
routing-options {
rib mgmt_junos.inet6.0 {
static {
route ::/0 next-hop 2001:db8::1;
}
}
}
}
}
As you see, I’m only using IPv6 for my management network. This is something that I’d expect to work, and it does work if you use me0, instead of vme as I’m using in my example.
However, when configuring vme in the management instance, and not including an IPv4 address in the configuration, the default route doesn’t get installed into the forwarding table:
user@ex3400> show route forwarding-table table mgmt_junos family inet6
Routing table: mgmt_junos.inet6
Internet6:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 331 1
::/128 perm 0 dscd 329 2
::1/128 perm 0 locl 332 1
fe80::/10 perm 0 dscd 329 2
ff00::/8 perm 0 mdsc 330 1
ff02::1/128 perm 0 ff02::1 mcst 333 1
{master:0}
user@ex3400>
Thankfully, there’s a simple workaround. All you have to do is add an IPv4 address to the vme interface configuration:
user@ex3400> show configuration interfaces vme
unit 0 {
family inet {
/* Needed to make mangement instance IPv6 routing work */
address 192.0.2.0/32;
}
family inet6 {
address 2001:db8::2/64;
}
}
{master:0}[edit]
user@ex3400>
Once this IPv4 address has been added, and the configuration has been committed, you’ll see the static routes added to the forwarding table:
user@ex3400> show route forwarding-table table mgmt_junos family inet6
Routing table: mgmt_junos.inet6
Internet6:
Destination Type RtRef Next hop Type Index NhRef Netif
default user 0 2001:db8::1 hold 344 3 vme.0
default perm 0 rjct 331 1
::/128 perm 0 dscd 329 2
::1/128 perm 0 locl 332 1
2001:db8::/64 intf 0 rslv 356 1 vme.0
2001:db8::/128 intf 0 2001:db8:: recv 355 1 vme.0
2001:db8::1/128 dest 0 2001:db8::1 hold 344 3 vme.0
2001:db8::3/128 intf 0 2001:db8::3 locl 353 2
2001:db8::3/128 dest 0 2001:db8::3 locl 353 2
fe80::/10 perm 0 dscd 329 2
fe80::/64 intf 0 rslv 360 1 vme.0
fe80::/128 intf 0 fe80:: recv 359 1 vme.0
fe80::1239:e9ff:fecd:6d4b/128
intf 0 fe80::1239:e9ff:fecd:6d4b
locl 357 2
fe80::1239:e9ff:fecd:6d4b/128
dest 0 fe80::1239:e9ff:fecd:6d4b
locl 357 2
ff00::/8 perm 0 mdsc 330 1
ff02::1/128 perm 0 ff02::1 mcst 333 1
ff02::1:ff00:3/128 intf 0 ff02::1:ff00:3 recv 354 1 vme.0
ff02::1:ffcd:6d4b/128 intf 0 ff02::1:ffcd:6d4b recv 358 1 vme.0
{master:0}
user@ex3400>
I tested this on the following hardware and software:
- EX3400 running 23.4R2-S2.1
- EX4300 running 21.4R3-S8.5
I don’t have support on my personal lab switches, so I’m not able to open a case with Juniper to have them fix this. Even if someone else does report this to Juniper, or they do otherwise fix this on their own, there’s years of code releases that will continue to have this bug, and likely be used somewhere for a long time to come. Hopefully sharing my workaround is helpful to others.