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.
Applications and Processes That Are VRF Aware
Starting with Junos OS Release 17.3R1, you can confine the management interface in a nondefault virtual routing and forwarding (VRF) instance, the mgmt_junos routing instance. After you configure this management routing instance as described in Configuring the mgmt_junos 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.
However, for the nondefault management instance to support all processes that communicate through the management interface, these processes must have support for a management VRF. In many cases, the new configuration to make these processes work with the nondefault VRF instance is to configure the name of the new management routing instance (mgmt_junos) for these processes. Information on how to configure mgmt_junos for the following processes is in the topics listed in the See Also section at the end of the list.
Automation scripts—Starting in Junos OS Release 18.1R1, configuration of commit, event, JET, op, and SNMP scripts is upgraded to support the nondefault management routing instance mgmt_junos as an option when specifying the source URL for refreshing or downloading Automation scripts. You can also specify some other routing instance (not a management instance) for refreshing or downloading Automation scripts.
BGP Monitoring Protocol (BMP)—Starting in Junos OS Release 18.3R1, a BMP station is now reachable over the management VRF instance.
Domain Name System (DNS)—Starting in Junos OS Release 19.2R1, you can route traffic between a dedicated management routing instance and DNS name server. When this configuration is set for at least for one name server, DNS resolution goes through.
NTP—Starting in Junos OS Release 18.1R1, NTP clients can support the nondefault management routing instance mgmt_junos when specifying the routing instance that is used to reach a server for NTP time synchronization.
RADIUS—Starting in Junos OS Release 18.1R1, we have enhanced the existing RADIUS support to include a management interface in a nondefault VRF instance.
syslog—In Junos OS Release 17.3R1, the syslog-event daemon was able to handle the dedicated management routing instance for IPv4 addressed remote host. As of Junos OS Release 18.1R1, the syslog-event daemon supports IPv6-based configuration when connecting to a remote host or an archival site, when the default management interface is moved to the dedicated management instance mgmt_junos. Statements at the [edit system syslog] hierarchy level support IPv6 addresses, too. Starting in Junos OS Release 18.4R1, you can configure the routing instance through which the remote server is reachable.
TACACS+—Starting in Junos OS Release 17.4R1, existing TACACS+ behavior is enhanced to support a management interface in a nondefault VRF instance.
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. The following commands are useful 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 188.8.131.52/4 perm 0 mdsc 35 1 184.108.40.206/32 perm 0 220.127.116.11 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
Each setup is different. What you are identifying are 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.
Enabling the mgmt_junos Routing Instance
Make sure to configure the mgmt_junos routing instance at the [edit routing-instances hierarchy level, for example:
To enable the mgmt_junos routing instance:
- Configure the management-instance statement. user@host# set system management-instance
- Move the appropriate static routes to the mgmt_junos routing
For a discussion of determining 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.254user@host# set s172.16.0.0/12 next-hop 10.102.191.254user@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.254user@host# set 172.16.0.0/12 next-hop 10.102.191.254user@host# set 192.168.0.0/16 next-hop 10.102.191.254
- Commit the configuration.
Expect to lose the Telnet connection at commit.
- Reestablish the Telnet connection.
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@hot# user@host# delete system management-instance
- Move the static routes back to the default routing instance.[edit routing-instances mgmt_junos routing-options static route ]user@host# delete 10.0.0.0/8 next-hop 10.102.191.254user@host# delete 172.16.0.0/12 next-hop 10.102.191.254user@host# delete 192.168.0.0/16 next-hop 10.102.191.254