Management Interface in a Nondefault Instance
Why Use a Nondefault Management Interface?
By default, in Junos OS, the management Ethernet interface (usually named fxp0 or em0) provides the out-of-band management network for the device. There is no clear separation between either out-of-band management traffic and in-band protocol control traffic, that is, user traffic at the routing-instance or routing-table level. Instead, all traffic is handled through the default routing instance, giving rise to concerns over security, performance, and how to troubleshoot.
Starting with Junos OS Release 17.3R1, you can confine the em0 and fxp0 management interfaces in a nondefault virtual routing and forwarding (VRF) instance, the mgmt_junos routing instance. After you configure this management routing instance, management traffic no longer has to share a routing table (that is, the default inet.0 table) with other control or protocol traffic in the system. This improves security and makes it easier to use the management interface to troubleshoot.
Only the em0 and fxp0 interfaces are supported in the non-default management VRF. Other management interfaces such as em1 are not supported in the non-default management VRF.
Applications and Processes That Are VRF Aware
Many processes communicate through the management interface. In order for the nondefault management instance to support these processes, they must support a management VRF. To make many of these processes work with the nondefault VRF instance, you must configure the name of the new management routing instance (mgmt_junos) for these processes. Starting in Junos OS Release 17.4R1, these processes have been enhanced to be able to use the management routing instance.
For the processes that require this additional configuration and where to find more information for those processes, see Table 1.
Table 1: Junos Processes You Can Configure to Use the Management VRF
First Release to Support Managment VRF
For More Information
Junos OS Release 18.1R1
BGP Monitoring Protocol (BMP)
Junos OS Release 18.3R1
Domain Name System (DNS))
Junos OS Release 19.2R1
Junos OS Release 18.1R1
Junos OS Release 18.1R1
Junos OS Release 18.1R1
Junos OS Release 18.4R1
Junos OS Release 17.4R1
Junos OS Release 18.2R1
Configuring the mgmt_junos Routing Instance
Starting in Junos OS 17.3R1, you can confine the management interface in a dedicated management instance by configuring the management-instance configuration statement at the [edit system] hierarchy level. The name of the dedicated management instance is reserved and hardcoded as mgmt_junos; you are prevented from configuring any other routing instance by the name mgmt_junos. Once the mgmt_junos routing instance is deployed, management traffic no longer shares a routing table (that is, the default inet.0 table) with other control or protocol traffic in the system, nor is configuring dynamic protocols on the management interface supported.
Because there are FreeBSD and Junos OS applications that assume that the management interface is always present in the default inet.0 routing table, the mgmt_junos routing instance is not instantiated by default.
As part of configuring the mgmt_junos routing instance, you must also move static routes that have a next hop over the default management interface to the mgmt_junos routing instance. If needed, you must also configure the appropriate daemons or applications to use the mgmt_junos routing instance. All of these changes must be done in a single commit. Otherwise, the transition to mgmt_junos will not be smooth and you will have to repair the system later by logging in from the console.
After you commit the configuration, expect to lose, and then have to reestablish, the Telnet session.
For an example of using this feature, see the following sections:
Determining Static Routes
As part of configuring the mgmt_junos routing instance, you must move all the static routes that have a next hop through the default management interface from the default routing instance to mgmt_junos. Each setup is different. In these examples, you need to identify the static routes that have a next hop through the fxp0 interface. The next hop for any static route that is affected will have an IP address that falls under the subnet of the IP address configured for fxp0.
You can use the following commands to determine static routes that need to be changed.
Use the show interfaces command to find the IP address of the default management interface:
user@host> show interfaces fxp0 terse Interface Admin Link Proto Local Remote fxp0 up up fxp0.0 up up inet 10.102.183.152/20
In this case the default management interface is fxp0, But it could be em0 or re0:mgmt-*.
Use the show route forwarding-table command to look at the forwarding table for next-hop information for static routes (static routes show up as type user):
user@host> show route forwarding-table Routing table: default.inet Internet: Enabled protocols: Bridging, Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 36 1 0.0.0.0/32 perm 0 dscd 34 1 10.0.0.0/8 user 0 0:0:5e:0:1:d0 ucst 341 6 fxp0.0 10.0.1.0/24 intf 0 rslv 584 1 ge-0/0/0.0 10.0.1.0/32 dest 0 10.0.1.0 recv 582 1 ge-0/0/0.0 10.0.1.1/32 intf 0 10.0.1.1 locl 583 2 10.0.1.1/32 dest 0 10.0.1.1 locl 583 2 10.0.1.255/32 dest 0 10.0.1.255 bcst 581 1 ge-0/0/0.0 10.102.176.0/20 intf 0 rslv 340 1 fxp0.0 10.102.176.0/32 dest 0 10.102.176.0 recv 338 1 fxp0.0 10.102.176.3/32 dest 1 0:50:56:9f:1b:2e ucst 350 2 fxp0.0 10.102.183.152/32 intf 0 10.102.183.152 locl 339 2 10.102.183.152/32 dest 0 10.102.183.152 locl 339 2 10.102.191.253/32 dest 0 10:e:7e:b1:b0:80 ucst 348 1 fxp0.0 10.102.191.254/32 dest 0 0:0:5e:0:1:d0 ucst 341 6 fxp0.0 10.102.191.255/32 dest 0 10.102.191.255 bcst 337 1 fxp0.0 172.16.0.0/12 user 0 10.102.191.254 ucst 341 6 fxp0.0 192.168.0.0/16 user 0 10.102.191.254 ucst 341 6 fxp0.0 220.127.116.11/4 perm 0 mdsc 35 1 18.104.22.168/32 perm 0 22.214.171.124 mcst 31 1 255.255.255.255/32 perm 0 bcst 32 1
Another way to find your static routes is to use the show route protocol static command.
user@host> show route protocol static inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/8 *[Static/5] 2d 21:48:36 > to 10.102.191.254 via fxp0.0 172.16.0.0/12 *[Static/5] 2d 21:48:36 > to 10.102.191.254 via fxp0.0 192.168.0.0/16 *[Static/5] 2d 21:48:36 > to 10.102.191.254 via fxp0.0
Enabling the mgmt_junos Routing Instance
We recommend using the device console port for these operations,
because at the point where you commit the configuration, if you are
using SSH or telnet, the connection to the device will be dropped
and you will have to reestablish it. If using SSH or telnet anyway,
To enable the mgmt_junos routing instance:
- Configure the mgmt_junos routing instance at the [edit routing-instances hierarchy level:
 user@host# set routing-instances routing-instance-name description description
- Configure the management-instance statement.
 user@host# set system management-instance
- Move the appropriate static routes to the mgmt_junos routing
For how to determine static routes to change, see Determining Static Routes.
[edit routing-instances mgmt_junos routing-option static route] user@host# set 10.0.0.0/8 next-hop 10.102.191.254 user@host# set 172.16.0.0/12 next-hop 10.102.191.254 user@host# set 192.168.0.0/16 next-hop 10.102.191.254
If you are using configuration groups, you might want to set these changes as part of a group:
[edit groups global routing-instances mgmt_junos routing-options static route ] user@host# set 10.0.0.0/8 next-hop 10.102.191.254 user@host# set s172.16.0.0/12 next-hop 10.102.191.254 user@host# set 192.168.0.0/16 next-hop 10.102.191.254
- Commit the configuration.
- At this point you have configured the management-instance statement. Tables for the mgmt_junos table are set up for inet and
inet6 and marked as private tables. The management interface is moved
to the mgmt_junos routing table. Static routes with a next hop to
the management interface are moved from the default routing table
and added to the mgmt_junos routing instance.
However, if you have not configured the management routing-instance option in the tacplus server statement, the TACACS+ packets continue to be sent using the default routing instance only.
Removing the mgmt_junos Routing Instance
When you remove the mgmt_junos routing instance, you must also move the static routes back to the default routing instance and delete the TACACS+ settings for mgmt_junos.
To remove the dedicated management interface:
- Delete or deactivate the management routing-instance statement.
 user@host# delete system management-instance
- (Optional) Delete the TACACS+ settings for mgmt_junos.
- Move the static routes back to the default routing instance.
[edit routing-instances mgmt_junos routing-option static route] user@host# delete 10.0.0.0/8 next-hop 10.102.191.254 user@host# delete 172.16.0.0/12 next-hop 10.102.191.254 user@host# delete 192.168.0.0/16 next-hop 10.102.191.254