If there is anything I really don’t like about Juniper Routers or Firewalls, it is the SNMP part of the devices, especially if routing instances are involved. We had to use a vSRX in Azure to avoid some IP-Fragmentation issues in Azure with their VPN-Gateway and internal networking (details in an upcoming post). As the design of the vSRX within the Azure Infrastructure requires a routing instance, to get the production traffic separated from the fxp0 interface1, we couldn’t avoid them.
The following is a working example config to monitor a vSRX within a routing instance, behaving like the default instance, so no need to use special “magic” with instances in SNMP or custom communities to monitor the vSRX VM.
set snmp v3 usm local-engine user <username> authentication-sha authentication-key <password> set snmp v3 usm local-engine user <username> privacy-aes128 privacy-key <password> set snmp v3 vacm security-to-group security-model usm security-name <username> group <group> set snmp v3 vacm access group <group> default-context-prefix security-model any security-level privacy read-view <snmp-view> set snmp v3 management-routing-instance <routing-instance> set snmp view <snmp-view> oid iso include set snmp routing-instance-access
Important is the third to last and last line. The management-routing-instance command2 is used to set the specified instance as the default-instance for SNMP. The routing-instance-access is needed to accept SNMP from any routing-instance. Without the command, every SNMP-Request arriving in a routing-instance is dropped.
Just in case, don’t forget to allow the incoming traffic within the right security zone on an SRX, otherwise, it’s still not working ;).
- https://www.juniper.net/documentation/us/en/software/vsrx/vsrx-consolidated-deployment-guide/vsrx-consolidated-deployment-guide.pdf Page 415 or Page 410/Figure 95 for a picture
- Introduced with 17.3R1 https://www.juniper.net/documentation/us/en/software/junos/junos-overview/topics/ref/statement/management-instance-edit-system.html
