This article describes the issue of being from an external subnet and unable to access the management IP on the fxp0 interface of the primary node in a chassis cluster with only the backup-router setting. This behavior is expected and works this way by design.
From an external subnet, unable to access the management IP on the fxp0 interface of the primary node in a chassis cluster if only with backup-router setting.
set groups node0 system host-name SRX-220-1 set groups node0 system backup-router 192.168.10.254 set groups node0 system backup-router destination 10.1.1.0/24 <-- Only setting backup-router without setting static route to 10.1.1.0/24 set groups node0 interfaces fxp0 unit 0 family inet address 192.168.10.1/24 set groups node1 system host-name SRX-220-2 set groups node1 system backup-router 192.168.10.254 set groups node1 system backup-router destination 10.1.1.0/24 set groups node1 interfaces fxp0 unit 0 family inet address 192.168.10.2/24 set apply-groups "$[NODE]" commit {primary:node0}[edit] root@SRX# run show route forwarding-table node 0 | match 10.1.1.0 <-- No route information in Node 0(Primary node) {primary:node0}[edit] root@SRX# run show route forwarding-table node 1 | match 10.1.1.0 <-- Backup-router information will be added in forwarding-table of Node1(Secondary node) 10.1.1.0/24 user 0 192.168.10.254 ucst 331 2 fxp0.0
After reboot node0, then reboot node1 (To make sure node0 keeping working as primary node)
{primary:node0} root@SRX> show route forwarding-table node 0 | match 10.1.1.0 10.1.1.0/24 user 0 192.168.10.254 ucst 324 2 fxp0.0 <-- At first, the route information can be seen. {primary:node0}[edit] root@SRX# run show route forwarding-table | match 10.1.1.0 <-- After a few minutes, the route information disappeared.
This is due to the primary node. When the router is booting, the RPD (Routing Protocol Process) is not running. Therefore, the router has no static or default routes. To allow the router to boot and ensure that the router is reachable over the network if the routing protocol process fails to start properly, you configure a backup router.
This is an expected behavior and works as designed. To have the address remain in these tables, configure a static route for that address by including the static statement at the [edit routing-options] hierarchy level.
set routing-options static route 10.1.1.0/24 next-hop 192.168.10.254 commit{primary:node0}[edit]root@SRX# run show route forwarding-table | match 10.1.1.010.1.1.0/24 user 0 192.168.10.254 ucst 324 3 fxp0.0
<--
Suppose a route cannot be added via the fxp0 interface. We have a method using routing instances. For adding fxp0 to a routing-instance we need to instantiate mgmt_junos routing instance which is a dedicated management VRF. Once this is configured, fxp0 is automatically added to the mgmt_junos routing-instance. The steps are explained under the section "Configure the mgmt_junos VRF Instance" in the below article. https://www.juniper.net/documentation/us/en/software/junos/junos-getting-started/topics/topic-map/management-interface-in-non-default-instance.html
2020-07-03: Article reviewed for accuracy; no changes required.