we have srx1500s set up in HA. currently our NMS only monitor the liveliness of the active node. is there a way to monitor the back up node to alert us by NMS if it reboots or goes down? thanks
You should be able monitor the secondary node of a cluster provided FXP IP address and backup router settings are configured properly.
Please find the sample configuration in page 11 in the following document:
Backup router configuration example:
thanks for that. im a little bit confused about the back up router's config, please help me to understand;
"set groups node0/1 backup-router <back-up router's ip> destination <admin's subnet>"
what if the SRX is the admin subnet's gateway and we dont have managment subnet (we use srx reth interface ip to manage it). what ip should we put on back up router's IP config on each node? can we use the admin's subnet on destination instead of /32 IP?
I think this will help aid your understanding of backup routers.
The 'backup router sample topology' provides a topology of sorts, in terms of where this backup router sits.
Feel free to post questions after.
Please Mark My Solution Accepted if it Helped, Kudos are Appreciated too!!!
Are you meaning that you are not using FXP interface but the reth interface to manage? Please find my answers inline for your other questions.
what ip should we put on back up router's IP config on each node?
The IP address of the next-hop to reach the destination NSM device subnet should be the IP address on each node.
can we use the admin's subnet on destination instead of /32 IP?
Yes you can use admin's subnet. It is just like creating a static route for the nodes to reach any destination using the FXP interface.
If you are planning to use the reth interface, I think you can use Virtual Chassis feature to monitor the cluster. Secondary node will not be able to send any information to NSM and but JSRPD log viewer on the NSM would be able to report the status of the secondary node in the cluster. More information in the link below:
Did you get a chance to review the details shared by some of us on here?
Did you have any further questions?
Whenever you access/manage a cluster via a reth interface you will be accessing the SRX acting as the primary node for Redundancy-group 0 (RG0), that represents the Routing-Engines. At any given time only one Routing-Engine will be handling the whole cluster.
The same happens if you do SNMP polling over a reth interface, you end up monitoring only the primary node for RG0. The way of monitoring/accessing the nodes separately is via their fxp0 interfaces and the same applies for SNMP monitoring purposes:
However, the fxp0 interfaces are aimed for networks where there is a out-of-band management network; this is an isolated subnet used exclusively for manage the devices in your network. Based on your comments you dont have this kind of subnet created as of yet because you manage the SRX via a reth interface. Being this the case I can see two possible scenarios:
1. You create this out-of-band network and connect the fxp0 interfaces to it and monitor the SRX via its fxp0 interfaces. Please note that the fxp0 interfaces are for out-of-band management hence you cannot received traffic via a regular port and route it via a fxp0 interface or viceversa. This is usually a concept that people is not familiar with hence I will share some light here:
In-band Management: When you access your devices via the regular production network. This means that your management traffic is competing for bandwidth with the rest of the production traffic. If there is an outage in your production network (lets say a broadcast storm affecting your switches and routers), you could loose or see affected your ability to manage your networking devices.
Out-of-band Management: When you create a network that is isolated from your production network and that will be used only for managing your networking devices. This way if there is an outage on your production network your ability to manage the devices wont be compromised. Your fxp0 interfaces are designed to be connected to this isolated network.
2. Try the workaround mentioned in the following document. Note that in this example, the SRX is reached via a VPN interface (you can think of it as your reth interface). Bascially you will have to move all your regular interfaces to a virtual-router (because you cannot configure your fxp0 interfaces in a virtual-router) and communicate this new virtual-router with the default routing-instance where we left the fxp0 interfaces. In the example they connect the fxp0s to a switch where reth 2 is connected two and the interfaces shared the same subnet but are in different routing-instances:
Hope it helps.