© Network Knowledge

Table of Contents

Introduction
SNMP
Syslog
Cisco Switches
-SNMP
--SNMP v1/v2c Polling
--SNMP v1/v2c Polling and Traps
--SNMP v3 Polling
--SNMP v3 Polling and Traps
-Syslog
Juniper Firewalls
-SNMP
--SNMP v1/v2x Polling
--SNMP v1/v2c Polling and Traps
--SNMP v3 Polling
--SNMP v3 Polling and Traps
-Syslog
Conclusion

 

Introduction

In modern enterprise networks, visibility is critical to maintaining performance, reliability, and security across infrastructure. Network devices, firewalls, servers, and applications continuously generate operational data that administrators use to monitor system health and respond to issues before they become outages. Two of the most widely used technologies for this are Simple Network Management Protocol (SNMP) and Syslog. SNMP allows monitoring systems to collect information such as interface utilisation, CPU load, memory consumption, environmental statistics, and device status, while Syslog provides detailed event and logging information generated by network and server platforms. Together, SNMP and Syslog form the foundation of infrastructure monitoring and operational troubleshooting in both small and large enterprise environments.

Although SNMP and Syslog are often deployed together, they serve different purposes and should be interpreted differently. SNMP is primarily designed for polling and alerting, giving administrators measurable statistics and threshold based monitoring to identify performance degradation or hardware failures. Syslog, on the other hand, provides contextual event information, allowing engineers to investigate authentication failures, interface state changes, routing issues, configuration changes, and security events. Understanding how to read and interpret SNMP data alongside Syslog messages enables operations teams to build a complete picture of infrastructure health and quickly identify both immediate faults and developing trends across the environment. Key to piecing together infrastructure events using SNMP and Syslog, is the concept of a standard system time across all network devices. This is where Network Time Protocol (NTP) comes into its own as it allows the clocks on all network devices to be synchronised.

As environments scale, performance and log volume become important considerations when deploying SNMP and Syslog services. Excessive SNMP polling intervals, poorly designed monitoring policies, or overly verbose logging configurations can increase CPU utilisation, network bandwidth consumption, and storage requirements on both infrastructure devices and monitoring platforms. Syslog servers in particular can become overwhelmed in large environments if unnecessary informational or debugging logs are enabled globally. To address these challenges, organisations typically implement selective polling intervals, appropriate Syslog severity levels, log filtering, retention policies, and centralised monitoring architectures to balance operational visibility with infrastructure performance and scalability.

SNMP and Syslog communication rely on a client-server relationship between monitored devices and management platforms. Devices such as Cisco Switches, Juniper Firewalls, Windows servers, and Linux servers are configured to send SNMP responses, SNMP traps, and Syslog messages to designated monitoring or logging servers. Monitoring platforms then receive, process, and analyse this information to generate alerts, dashboards, reports, and historical data used by network and systems administrators. In this guide, we will explore how SNMP v1, v2c, and v3, alongside Syslog, can be configured across multiple platforms using practical implementation examples and best practices suitable for enterprise environments.

SNMP and Syslog is an enormous area to cover and has, therefore, been split into two parts. This part covers SNMP and Syslog configuration, verification and troubleshooting for Cisco Switches and Juniper Firewalls. Part 2 continues with the same configuration, verification and troubleshooting sections for both Windows and Linux Servers. It covers the situation where the server is sending SNMP and Syslog information to a remote server and also where the server is receiving the SNMP and Syslog information.

SNMP

Simple Network Management Protocol (SNMP) was developed in the late 1980s as a standardised method for monitoring and managing network connected devices across growing enterprise environments. As networks expanded beyond simple local infrastructures, administrators required a lightweight protocol capable of collecting operational statistics, monitoring device health, and detecting faults from a centralised platform. SNMP was introduced by the Internet Engineering Task Force (IETF) to address this need and quickly became one of the most widely adopted protocols for network management. Today, SNMP is supported by almost every enterprise grade switch, router, firewall, server, printer, wireless controller, and monitoring appliance, making it a foundational technology in modern infrastructure operations.

Over time, SNMP evolved through several versions, each introducing new functionality and security improvements. SNMP v1 was the original implementation and provided basic monitoring capabilities using simple community strings for authentication. However, SNMP v1 lacked encryption and strong security controls, making it unsuitable for modern production environments. SNMP v2c improved efficiency and introduced additional protocol operations and enhanced error handling, while still relying on insecure plaintext community strings. SNMP v3 was later introduced to address the security limitations of earlier versions by adding authentication, integrity checking, and encryption features. In enterprise environments today, SNMP v3 is strongly recommended wherever it is supported due to its significantly improved security model. SNMP v1/v2c are still commonly found in legacy environments and isolated monitoring networks but should generally be restricted or phased out where possible.

One of the most useful tools when working with SNMP is snmpwalk, which allows administrators to query entire sections of a device Management Information Base (MIB). Rather than requesting a single Object Identifier (OID), snmpwalk sequentially retrieves all available values beneath a specified branch of the MIB tree. This makes it particularly valuable for discovering supported device metrics, validating SNMP configurations, troubleshooting monitoring issues, and identifying interface indexes or hardware statistics required for monitoring platforms. Network engineers frequently use snmpwalk during deployment and troubleshooting to verify SNMP connectivity as UDP port 161 needs to be open, test authentication credentials, and confirm that monitoring systems can successfully retrieve operational data from infrastructure devices.

In addition to standard polling operations, SNMP also supports asynchronous notifications known as traps, which use UDP port 162. SNMP traps allow devices to proactively send alerts to monitoring systems whenever predefined events occur, such as interface failures, power supply issues, hardware alarms, temperature warnings, authentication failures, or routing protocol state changes. Unlike polling, which relies on monitoring systems repeatedly requesting information at scheduled intervals, traps provide near real time event notification with significantly reduced network overhead. When properly configured, SNMP traps improve operational awareness and accelerate incident response by immediately notifying administrators of critical infrastructure events without waiting for the next polling cycle.

A wide range of enterprise monitoring tools can process SNMP data and traps to provide visibility across network and server infrastructure. Platforms such as SolarWinds Network Performance Monitor, PRTG Network Monitor, Zabbix, LibreNMS, and Nagios use SNMP to collect metrics, generate alerts, build dashboards, and maintain historical performance data. These platforms typically operate by polling devices at regular intervals using configured SNMP credentials while simultaneously receiving SNMP traps for critical events. Administrators can use these tools to monitor interface utilisation, device availability, CPU and memory performance, hardware health, environmental sensors, and network latency across enterprise environments. Properly integrating SNMP into monitoring platforms enables operations teams to improve visibility, reduce troubleshooting time, and maintain proactive infrastructure management at scale.

Syslog

Syslog is one of the oldest and most widely adopted logging standards used in enterprise IT environments. Originally developed in the 1980s for UNIX based systems, Syslog was designed to provide a consistent method for generating, storing, and transmitting event messages across networked devices and operating systems. As enterprise infrastructure evolved, Syslog became a standard feature across routers, switches, firewalls, servers, applications, and security appliances, allowing administrators to centralise operational and security related events in a single location. Today, Syslog remains a critical component of infrastructure monitoring, troubleshooting, auditing, and security analysis in both small and large scale environments.

At its core, Syslog enables devices to generate event messages that describe operational activity, status changes, errors, warnings, and security events. These messages are categorised using severity levels ranging from emergency and critical alerts through to informational and debugging messages. Most platforms allow administrators to configure local logging, remote logging, or both, depending on operational requirements. Devices can send Syslog messages to one or more centralised Syslog servers using UDP or TCP transport protocols, commonly over port 514. Modern implementations may also support encrypted Syslog transport using TLS to improve security and protect sensitive logging information as it traverses the network.

Syslog messages are categorised using two primary values: facilities and severity levels. The facility identifies the process or subsystem that generated the event, while the severity level indicates the importance of the message. Severity levels range from Emergency, representing critical system failures, through to Informational and Debugging messages used for routine operational visibility and troubleshooting. A traditional Syslog message contains several key fields including a timestamp, hostname, facility, severity level, and the actual event description. While early Syslog implementations relied primarily on UDP port 514 due to its simplicity and low overhead, UDP provides no delivery guarantees and messages may be lost during congestion or network interruption. Modern implementations increasingly support TCP and Transport Layer Security (TLS), improving reliability and protecting log traffic from interception or tampering. These enhancements are particularly important in enterprise and security sensitive environments where log integrity and confidentiality are operational requirements.

Syslog configuration can vary significantly depending on the platform and operational requirements. Network devices such as Cisco Switches and Juniper Firewalls typically allow administrators to configure remote logging hosts, severity levels, source interfaces, message formatting, and local log buffering. Linux systems commonly use services such as rsyslog or syslog-ng to manage and forward logs, while Windows environments often rely on event forwarding agents or third party collectors to integrate Windows Event Logs into Syslog based monitoring systems. Choosing the appropriate severity levels and filtering policies is an important part of Syslog design, as excessive logging can quickly generate large volumes of data that impact storage, network bandwidth, and operational visibility.

Log rotation plays a critical role in maintaining the stability and performance of Syslog environments. Without proper rotation and retention policies, log files can rapidly consume disk space and negatively affect both operating systems and logging platforms. Most Linux based Syslog implementations use tools such as logrotate to archive, compress, and remove older log files automatically according to predefined schedules and retention periods. Best practice recommendations typically include separating critical logs from informational messages, implementing retention periods aligned with operational or compliance requirements, compressing archived logs to reduce storage consumption, and forwarding important events to centralised logging platforms for long term analysis and correlation.

A wide range of monitoring and analysis platforms can process Syslog data to provide centralised visibility and alerting across enterprise infrastructure. Solutions such as Splunk, Graylog, SolarWinds, and PRTG Network Monitor can ingest, index, search, and analyse Syslog messages from multiple devices and operating systems. These platforms allow administrators to create dashboards, configure alerts, perform forensic analysis, identify security threats, and troubleshoot infrastructure issues in real time. By centralising Syslog collection and implementing effective logging strategies, organisations can significantly improve operational visibility, incident response times, and long term infrastructure management.

Cisco Switches

SNMP

SNMP v1/v2 Polling

For a Cisco Catalyst 3560 running classic IOS, the following configuration provides a secure, legacy SNMP v1/v2c implementation using:

Because this is a production legacy deployment, restricting SNMP access using ACLs is extremely important, as SNMP v1/v2c transmits community strings in plaintext and provides no encryption or authentication security beyond the community string itself.

Configuration

!
! Standard ACL permitting only the SNMP monitoring server
!
access-list 10 permit 10.1.1.1
access-list 10 deny any log
!
! Configure read-only SNMP v1/v2c community string
! Restricted to ACL 10
!
snmp-server community examplestring RO 10
!
! Configure device contact information
!
snmp-server contact Network Operations Team
!
! Configure device physical location
!
snmp-server location London Datacentre - Rack B12
!

Configuration Breakdown

The Access Control List (ACL) restriction ensures only the monitoring server at 10.1.1.1 can communicate with the SNMP service on the switch. The log keyword is useful operationally because it records unauthorised SNMP access attempts in the device logs.

access-list 10 permit 10.1.1.1
access-list 10 deny any log

The Read-Only community string should be used as opposed to the Read-Write community string. Read-Write should be avoided in production environments as it grants the capability to change settings on the end device. This enables SNMP v1/v2c polling, restricts access via ACL 10 and prevents write access to the switch configuration.

snmp-server community examplestring RO 10

Device metadata such as contact and location information, can be configured to appear in monitoring platforms and help operational teams quickly identify devices and escalation contacts.

snmp-server contact Network Operations Team
snmp-server location London Datacentre - Rack B12

SNMP v2c introduced several operational improvements over SNMP v1, including:

GETBULK significantly reduces polling overhead by allowing monitoring systems to retrieve large amounts of data in fewer requests, improving scalability across larger environments. Although SNMP v2c is operationally superior to SNMP v1, it still transmits community strings in plaintext and should only be used on isolated management networks, with ACL restrictions and with read-only permissions wherever possible. Modern enterprise best practice is to migrate to SNMP v3 using authentication and encryption.

SNMP v1/v2 Polling and Traps

For a Catalyst 3560 access/distribution switch, I would recommend enabling only the following trap types:

This gives good operational visibility without overwhelming the monitoring platform.

Configuration

!
! Standard ACL permitting only the SNMP monitoring server
!
access-list 10 permit 10.1.1.1
access-list 10 deny any log
!
! Configure SNMP v2c read-only community string
!
snmp-server community examplestring RO 10
!
! Configure device metadata
!
snmp-server contact Network Operations Team
snmp-server location London Datacentre - Rack B12
!
! Configure SNMP trap destination
!
snmp-server host 10.1.1.1 version 2c examplestring
!
! Source SNMP traffic from the management VLAN
!
snmp-server trap-source Vlan100
!
! Enable recommended production traps
!
snmp-server enable traps snmp authentication
snmp-server enable traps config
snmp-server enable traps syslog
snmp-server enable traps entity
snmp-server enable traps envmon
snmp-server enable traps spanning-tree
snmp-server enable traps cpu threshold
snmp-server enable traps snmp linkdown linkup
!
! Dedicated management interface
!
interface Vlan100
 description Management VLAN
 ip address 10.1.100.10 255.255.255.0
 no shutdown
!

Recommended Trap Categories Explained

Authentication Traps

snmp-server enable traps snmp authentication

Alerts on: invalid community strings, SNMP scans and authentication failures.

Configuration Change Traps

snmp-server enable traps config

Useful for: configuration auditing, change tracking, and compliance monitoring.

Link State Traps

snmp-server enable traps snmp linkdown linkup

Provides immediate notification of: interface failures, cable disconnects and switch uplink outages. This can become noisy on user access ports so proceed with care.

Environmental Monitoring Traps

snmp-server enable traps envmon

Monitors: temperature, power supplies, fans and hardware conditions.

Spanning Tree Traps

snmp-server enable traps spanning-tree

Important for detecting: topology changes, STP instability and accidental loops.

It is worth noting that enabling too many trap types or on too many devices can result in overloading monitoring systems, especially in large access layer deployments. To provide the best outcome, a mix of snmp polling on a scheduled basis combined with the immediate notification of snmp traps should be considered. The mix should be continually tuned to ensure optimal coverage.

SNMP v3 Polling

The below SNMP v3 configuration provides the following:

Configuration

!
! ==========================================================
! EXTENDED ACL - SNMP v3 ACCESS CONTROL
! Only allow SNMP polling from 10.1.1.1 to the switch
! UDP/161 explicitly restricted
! ==========================================================
!
ip access-list extended SNMP-V3-ACL
 permit udp host 10.1.1.1 host 10.1.100.10 eq 161
 deny   udp any any eq 161 log
 deny   ip any any log
!
! ==========================================================
! SNMP v3 GROUP (FULL MIB ACCESS)
! authPriv enforced (SHA + AES)
! ==========================================================
!
snmp-server group SNMP-GROUP v3 priv read v1default access SNMP-V3-ACL
!
! ==========================================================
! SNMP v3 USER (GENERIC USERNAME)
! Authentication: SHA
! Privacy: AES 128
! ==========================================================
!
snmp-server user snmpuser SNMP-GROUP v3 auth sha SimpleAuthPass priv aes 128 SimplePrivPass
!
! ==========================================================
! DEVICE IDENTIFICATION
! ==========================================================
!
snmp-server contact Network Operations Team
snmp-server location London Datacentre - Rack B12
!
! ==========================================================
! MANAGEMENT INTERFACE (VLAN 100)
! ==========================================================
!
interface Vlan100
 description Management VLAN
 ip address 10.1.100.10 255.255.255.0
 no shutdown
!
! Bind SNMP traffic source to management VLAN
!
snmp-server trap-source Vlan100
!

Key Design Explanation

1. SNMP v3 full MIB access

snmp-server group SNMP-GROUP v3 priv read v1default

This enables access to the full standard MIB tree, has no view restrictions and is suitable for trusted internal monitoring systems. This is simpler but less secure than scoped views — but is acceptable in controlled management networks.

2. authPriv Security Model (Mandatory)

auth sha + priv aes 128

This provides authentication (prevents spoofing), encryption (protects SNMP payloads) and integrity (prevents tampering). This is the enterprise standard SNMP configuration.

3. Extended ACL Protection

ip access-list extended SNMP-V3-ACL
 permit udp host 10.1.1.1 host 10.1.100.10 eq 161
 deny   udp any any eq 161 log
 deny   ip any any log

This enforces that only the monitoring server can poll SNMP and only UDP/161 is allowed while all other SNMP attempts are logged and dropped. This is critical because SNMP v3 still exposes service availability, response behaviour and potential enumeration patterns.

4. VLAN 100 Management Plane Binding

interface Vlan100
ip address 10.1.100.10

and:

snmp-server trap-source Vlan100

Ensures predictable SNMP source identity, clean firewall rules and isolation from user/data VLANs.

5. SNMP v3 User Model

snmp-server user snmpuser SNMP-GROUP v3 ...

Provides a single reusable monitoring account, avoids user sprawl and aligns with NMS credential storage models.

As can be seen, while SNMP v3 is the only secure SNMP standard. ACLS are still important, despite the encryption overlay, as they support the defence in depth model. Full MIB access simplifies operations but also reduces control granularity. VLAN segmentation is critical for SNMP security and finally, legacy SNMP versions must be fully removed and not coexist.

SNMP v3 Polling and Traps

In this example configuration, I have tuned the SNMP v3 traps to be signal rich but still volume controlled, with:

Configuration

!
! ==========================================================
! EXTENDED ACL - SNMP v3 CONTROL PLANE
! ==========================================================
!
ip access-list extended SNMP-V3-ACL
 permit udp host 10.1.1.1 host 10.1.100.10 eq 161
 permit udp host 10.1.100.10 host 10.1.1.1 eq 162
 deny   udp any any eq 161 log
 deny   udp any any eq 162 log
 deny   ip any any log
!
! ==========================================================
! SNMP v3 GROUP (FULL MIB ACCESS, AUTHPRIV)
! ==========================================================
!
snmp-server group SNMP-GROUP v3 priv read v1default access SNMP-V3-ACL
!
! ==========================================================
! SNMP v3 USER (SHARED POLLING + TRAPS)
! SHA + AES128
! ==========================================================
!
snmp-server user snmpuser SNMP-GROUP v3 auth sha SimpleAuthPass priv aes 128 SimplePrivPass
!
! ==========================================================
! DEVICE IDENTIFICATION
! ==========================================================
!
snmp-server contact Network Operations Team
snmp-server location London Datacentre - Rack B12
!
! ==========================================================
! TRAP DESTINATION (SNMP v3 ONLY)
! ==========================================================
!
snmp-server host 10.1.1.1 version 3 priv snmpuser
!
! ==========================================================
! SOURCE INTERFACE FOR ALL SNMP TRAFFIC
! ==========================================================
!
snmp-server trap-source Vlan100
!
! ==========================================================
! TRAP CONFIGURATION (PRODUCTION BALANCED)
! ==========================================================
!
! --- Security / monitoring integrity
snmp-server enable traps snmp authentication
!
! --- Configuration change auditing
snmp-server enable traps config
!
! --- CPU utilisation / threshold alerts
snmp-server enable traps cpu threshold
!
! --- Environmental monitoring (fans, PSU, temperature)
snmp-server enable traps envmon
!
! --- Spanning-tree topology changes
snmp-server enable traps spanning-tree
!
! --- Link state changes (UPLINK/TRUNK FOCUS)
snmp-server enable traps snmp linkdown linkup
!
! ==========================================================
! MANAGEMENT INTERFACE
! ==========================================================
!
interface Vlan100
 description Management VLAN
 ip address 10.1.100.10 255.255.255.0
 no shutdown
!

Key Engineering Decisions

1. SNMP v3 is the only management plane protocol

2. Trap set is operationally meaningful”

snmp-server enable traps snmp authentication

Detects SNMP scanning, invalid credentials and enumeration attempts

snmp-server enable traps config

Detects CLI changes and unauthorised modifications

snmp-server enable traps cpu threshold

Detects sustained high utilisation, potential control plane stress and process anomalies

snmp-server enable traps envmon

Detects PSU failure, fan degradation and temperature thresholds

snmp-server enable traps spanning-tree

Detects Spanning Tree Protocol (STP) loops, reconvergence events, and topology changes or instability

snmp-server enable traps snmp linkdown linkup

Detects link state changes (uplinks/trunks focus)

3. ACL enforces full SNMP control plane security

This ensures only the monitoring system can poll and receive traps.

4. VLAN100 is the authoritative management identity so traps do not originate from a routed interface

snmp-server trap-source Vlan100

Ensures consistent monitoring system identity mapping, simpler firewall rules and cleaner routing behaviour

SNMP traps are event driven asynchronous telemetry and are not logging. CPU and environmental traps can provide an early warning of infrastructure degradation, while linkUp/down traps are only valuable when applied to uplinks/trunks (or filtered intelligently). SNMP v3 ensures secure event transport, but not noise control so continually tune to get the right mix of performance and coverage. ACLs are still essential even with encryption (defence in depth).

Verification & troubleshooting

SNMP v1/v2c recommended verification commands include:

show snmp host
show snmp
show snmp community
show running-config | include snmp

To test from the monitoring server (10.1.1.1 in the above examples)

snmpwalk -v2c -c examplestring 10.1.100.10 system

To generate a test event (trap), change the state of an interface using shut/no shut and save the configuration change or intentionally use an invalid community string. You can then verify that the relevant traps are received by reviewing on the monitoring platform.

SNMP v3 verification commands include:

show snmp user
show snmp group
show access-lists SNMP-V3-ACL
show snmp
show running-config | include snmp

To test from the monitoring server (10.1.1.1)

snmpwalk -v3 -l authPriv -u snmpuser -a SHA -A SimpleAuthPass -x AES -X SimplePrivPass 10.1.100.10 sysUpTime

Use the same method as described above for v1/v2c, to generate a test SNMP trap and check that it arrives safely at the monitoring system.

Syslog

This section provides a production ready Syslog configuration for Cisco Catalyst 3560 and 3750 switches running classic Cisco IOS. The configuration is designed using operational best practice and includes:

The Syslog server in this example is located at 10.1.1.1, and the switch uses VLAN 100 as the dedicated management VLAN. The recommended deployment model is:

Although UDP/514 remains widely used, it provides no delivery guarantees and no encryption. TCP improves reliability through session- based delivery, while TLS provides both encryption and integrity protection. In production environments, encrypted Syslog should always be preferred where it is supported.

Configuration

!
! Enable timestamp logging
!
service timestamps log datetime msec localtime show-timezone
service sequence-numbers
!
! Disable console logging
!
no logging console
!
! Enable Syslog logging
!
logging on
!
! Specify Syslog source interface
!
logging source-interface Vlan100
!
! Remote Syslog server using legacy UDP
!
logging host 10.1.1.1 transport udp port 514
!
! TCP logging (preferred over UDP where supported)
!
logging host 10.1.1.1 transport tcp port 514
!
! Send severity level warnings and above
!
logging trap warnings
!
! Log login events
!
login on-success log
login on-failure log
!
! AAA configuration logging
!
aaa new-model
!
aaa authentication login default local
!
aaa authorization exec default local
!
aaa accounting exec default start-stop logging
!
! Archive configuration logging
!
archive
 log config
  logging enable
  notify syslog
  hidekeys
!
! Secure management access
!
ip access-list extended MGMT-SYSLOG-ACL
 remark Permit Syslog to central server
 permit udp host 10.1.100.10 host 10.1.1.1 eq 514
 permit tcp host 10.1.100.10 host 10.1.1.1 eq 514
 remark Permit NTP
 permit udp host 10.1.100.10 host 10.1.1.1 eq 123
 remark Permit SSH management
 permit tcp 10.1.100.0 0.0.0.255 host 10.1.1.1 eq 22
 remark Deny all other management traffic
 deny ip any any log
!
! Apply ACL to management VLAN
!
interface Vlan100
 description Management VLAN
 ip address 10.1.100.10 255.255.255.0
 ip access-group MGMT-SYSLOG-ACL out
 no shutdown
!
! SSH hardening
!
ip ssh version 2
!
line vty 0 4
 transport input ssh
 logging synchronous
 exec-timeout 10 0
!

Configuration Explanation

service timestamps log datetime msec localtime show-timezone
service sequence-numbers

The timestamp configuration is necessary as accurate timestamps are critical for troubleshooting, event correlation, and forensic investigations. These commands ensure that all Syslog messages contain:

interface Vlan100

Using a dedicated management VLAN isolates infrastructure traffic from user and production data traffic. This improves both security and operational visibility.

logging buffered 16384 warnings

Buffered logging stores Syslog messages locally in switch memory. The value 16384 defines the local buffer size in bytes. The severity level warnings ensures that only warning level events and more critical messages are stored locally. Benefits include:

no logging console

Console logging is disabled in production environments because excessive console message generation can:

This is particularly important on busy access layer switches.

logging source-interface Vlan100

This command forces all Syslog traffic to use the IP address assigned to VLAN 100 as the source address. Using a fixed source interface is considered operational best practice. Without this configuration, the switch may select different source interfaces depending on routing behaviour, making:

logging host 10.1.1.1 transport udp port 514

Remote syslog transport option uses UDP as it is widely supported and lightweight but has significant limitations:

UDP should be used for legacy compatibility only.

logging host 10.1.1.1 transport tcp port 514

Remote syslog transport option used TCP as it provides:

TCP is strongly preferred over UDP in enterprise environments. The preferred operational choice for Syslog transport is via TLS. However, classic Catalyst 3560/3750 IOS platforms have limited native TLS Syslog support compared to modern IOS-XE platforms. Where TLS is available in the wider environment, encrypted Syslog should always be used because it provides:

Where TLS is not available on legacy hardware, organisations commonly:

logging trap warnings

This command restricts remotely forwarded Syslog messages to severity level 4 (warnings) and above. This prevents excessive low level informational or debugging messages from overwhelming:

Severity level 4 typically captures:

These commands ensure successful and failed authentication attempts are written to the Syslog system. This level is a good compromise between performance and coverage. This improves:

AAA accounting further records administrative session activity.

archive
 log config

Configuration Change Logging records configuration changes and generates Syslog notifications whenever the running configuration is modified. The hidekeys option prevents sensitive information such as passwords from appearing in logs. This provides:

ip access-list extended MGMT-SYSLOG-ACL

The ACL restricts management plane traffic to only authorised services. This significantly reduces exposure of the management interface. The policy:

Verification Commands

show logging

Verify logging status as this command displays:

show running-config | include logging source-interface

Confirms the configured Syslog source interface.

show running-config | include logging host

Verify remote logging host as this command displays configured Syslog destination servers.

show access-lists MGMT-SYSLOG-ACL

Verify ACL counters is used to confirm:

show ntp status
show clock

Verify the NTP synchronisation as accurate timestamps depend on correct NTP synchronisation.

ping 10.1.1.1 source vlan100

Connectivity testing confirms the reachability between the switch and the Syslog server using the correct source interface.

Debug and Troubleshooting Commands

debug logging

Enable Syslog debugging as it displays real time Syslog activity and transmission attempts. However, use with great caution in production environments because debugging can significantly increase CPU utilisation.

terminal monitor

Used during remote SSH sessions to display live logging messages.

Useful packet level troubleshooting checks include:

When troubleshooting Syslog delivery:

For enterprise deployments, the following operational best practices are strongly recommended:

Juniper Firewalls

SNMP

SNMP v1/v2 Polling

SNMP v1/v2c are considered obsolete and insecure by modern operational and security standards. The protocol transmits community strings in clear text, provides no encryption, no integrity validation, and no meaningful authentication controls. Any attacker capable of capturing SNMP traffic can potentially identify the community string and use it to query network infrastructure information.

Despite these limitations, SNMP v1/v2c may still be encountered in legacy monitoring environments where older Network Management Systems (NMS) or embedded operational tooling do not support SNMP v3. In these situations, the security posture of the surrounding infrastructure becomes critically important. Where SNMP v1/v2c must be used, operational hardening should include:

The following example demonstrates a hardened SNMP v1/v2c deployment on a Juniper SRX firewall running Junos OS. The firewall management interface resides in VLAN100 using the IP address 10.1.100.10/24, while the monitoring platform is located at 10.1.1.1.

Configuration Using set Commands

set system host-name SRX-FW-01

set interfaces vlan unit 100 family inet address 10.1.100.10/24

set vlans MANAGEMENT vlan-id 100
set vlans MANAGEMENT l3-interface vlan.100

set snmp community examplestring authorization read-only
set snmp community examplestring clients 10.1.1.1/32

set snmp location "Primary Data Centre"
set snmp contact "Network Operations"

set security zones security-zone MANAGEMENT interfaces vlan.100 host-inbound-traffic system-services snmp
set security zones security-zone MANAGEMENT interfaces vlan.100 host-inbound-traffic system-services ping
set security zones security-zone MANAGEMENT interfaces vlan.100 host-inbound-traffic system-services ssh

set firewall family inet filter PROTECT-SNMP term ALLOW-SNMP from source-address 10.1.1.1/32
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMP from destination-address 10.1.100.10/32
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMP from protocol udp
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMP from destination-port 161
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMP then accept

set firewall family inet filter PROTECT-SNMP term DENY-SNMP from protocol udp
set firewall family inet filter PROTECT-SNMP term DENY-SNMP from destination-port 161
set firewall family inet filter PROTECT-SNMP term DENY-SNMP then log
set firewall family inet filter PROTECT-SNMP term DENY-SNMP then discard

set interfaces vlan unit 100 family inet filter input PROTECT-SNMP

set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy ALLOW-NMS-SNMP match source-address NMS-HOST
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy ALLOW-NMS-SNMP match destination-address SRX-MGMT
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy ALLOW-NMS-SNMP match application junos-snmp
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy ALLOW-NMS-SNMP then permit

set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy DENY-OTHER-SNMP match source-address any
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy DENY-OTHER-SNMP match destination-address SRX-MGMT
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy DENY-OTHER-SNMP match application junos-snmp
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy DENY-OTHER-SNMP then log session-init
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy DENY-OTHER-SNMP then deny

set security address-book global address NMS-HOST 10.1.1.1/32
set security address-book global address SRX-MGMT 10.1.100.10/32

Configuration Using Hierarchical Format

system {
    host-name SRX-FW-01;
}

interfaces {
    vlan {
        unit 100 {
            family inet {
                address 10.1.100.10/24;
                filter {
                    input PROTECT-SNMP;
                }
            }
        }
    }
}

vlans {
    MANAGEMENT {
        vlan-id 100;
        l3-interface vlan.100;
    }
}

snmp {
    location "Primary Data Centre";
    contact "Network Operations";

    community examplestring {
        authorization read-only;
        clients {
            10.1.1.1/32;
        }
    }
}

security {
    zones {
        security-zone MANAGEMENT {
            interfaces {
                vlan.100 {
                    host-inbound-traffic {
                        system-services {
                            snmp;
                            ping;
                            ssh;
                        }
                    }
                }
            }
        }
    }

    address-book {
        global {
            address NMS-HOST 10.1.1.1/32;
            address SRX-MGMT 10.1.100.10/32;
        }
    }

    policies {
        from-zone MANAGEMENT to-zone MANAGEMENT {
            policy ALLOW-NMS-SNMP {
                match {
                    source-address NMS-HOST;
                    destination-address SRX-MGMT;
                    application junos-snmp;
                }
                then {
                    permit;
                }
            }

            policy DENY-OTHER-SNMP {
                match {
                    source-address any;
                    destination-address SRX-MGMT;
                    application junos-snmp;
                }
                then {
                    log {
                        session-init;
                    }
                    deny;
                }
            }
        }
    }
}

firewall {
    family inet {
        filter PROTECT-SNMP {
            term ALLOW-SNMP {
                from {
                    source-address {
                        10.1.1.1/32;
                    }
                    destination-address {
                        10.1.100.10/32;
                    }
                    protocol udp;
                    destination-port 161;
                }
                then accept;
            }

            term DENY-SNMP {
                from {
                    protocol udp;
                    destination-port 161;
                }
                then {
                    log;
                    discard;
                }
            }
        }
    }
}

Configuration Explanation

set interfaces vlan unit 100 family inet address 10.1.100.10/24

The firewall management interface is isolated within VLAN100, a dedicated management vlan. Separating management traffic from production traffic reduces operational exposure and limits the attack surface available to unauthorised systems.

set snmp community examplestring authorization read-only

Only read-only access is permitted. Read-write SNMP communities should never be configured in production environments, particularly when using SNMP v1/v2c. The community string examplestring is used purely for demonstration purposes. In operational environments:

set snmp community examplestring clients 10.1.1.1/32

This source IP restriction ensures that SNMP polling is limited to the authorised monitoring platform only. Even though SNMP v1/v2c are insecure, strict source IP validation significantly reduces exposure to unauthorised polling attempts.

host-inbound-traffic system-services snmp

Host inbound traffic restrictions within Junos security zones explicitly control which management services may access the firewall control plane. Only the required management services are enabled:

All other services remain implicitly denied.

filter PROTECT-SNMP

The stateless firewall filter provides additional protection directly at the interface level. The filter:

This provides an additional enforcement layer before traffic reaches the control plane.

policy ALLOW-NMS-SNMP

Security policies provide stateful inspection and operational visibility. The configuration explicitly:

Using both firewall filters and security policies creates defence in depth protection.

Operational Hardening Recommendations

When SNMP v1/v2c cannot be avoided, the following controls are strongly recommended:

SNMP v1 should only exist as a temporary operational compromise for legacy compatibility requirements.

Verification Commands

show configuration snmp

Displays the active SNMP configuration.

show firewall filter PROTECT-SNMP

Displays the firewall filter counters which can confirm:

show security policies

Displays the active security policy configuration

show snmp statistics

Verify snmp statistics provides the below information:

show interfaces vlan terse

Confirms the operational state of VLAN100.

show log messages | match SNMP

Displays logged SNMP related events and denied access attempts.

monitor traffic interface vlan.100 matching "port 161"

Captures live SNMP traffic at a packet level directly on the management interface. It is useful for confirming:

show system connections | match 161

This command can confirm that the firewall is actively listening for SNMP traffic on UDP/161.

SNMP v1/v2 Polling and Traps

The hardened configuration (set Format) including SNMP v1/v2c traps

set system host-name SRX-FW-01

set interfaces vlan unit 100 family inet address 10.1.100.10/24

set vlans MANAGEMENT vlan-id 100
set vlans MANAGEMENT l3-interface vlan.100

set snmp location "Primary Data Centre"
set snmp contact "Network Operations"

set snmp community examplestring authorization read-only
set snmp community examplestring clients 10.1.1.1/32

set snmp trap-group NMS-TRAPS version v2
set snmp trap-group NMS-TRAPS categories authentication
set snmp trap-group NMS-TRAPS categories chassis
set snmp trap-group NMS-TRAPS categories link
set snmp trap-group NMS-TRAPS categories startup
set snmp trap-group NMS-TRAPS targets 10.1.1.1
set snmp trap-group NMS-TRAPS source-address 10.1.100.10

set security zones security-zone MANAGEMENT interfaces vlan.100 host-inbound-traffic system-services snmp
set security zones security-zone MANAGEMENT interfaces vlan.100 host-inbound-traffic system-services ping
set security zones security-zone MANAGEMENT interfaces vlan.100 host-inbound-traffic system-services ssh

set firewall family inet filter PROTECT-SNMP term ALLOW-SNMP-POLLING from source-address 10.1.1.1/32
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMP-POLLING from destination-address 10.1.100.10/32
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMP-POLLING from protocol udp
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMP-POLLING from destination-port 161
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMP-POLLING then accept

set firewall family inet filter PROTECT-SNMP term ALLOW-SNMP-TRAPS from source-address 10.1.100.10/32
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMP-TRAPS from destination-address 10.1.1.1/32
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMP-TRAPS from protocol udp
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMP-TRAPS from destination-port 162
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMP-TRAPS then accept

set firewall family inet filter PROTECT-SNMP term DENY-SNMP from protocol udp
set firewall family inet filter PROTECT-SNMP term DENY-SNMP from destination-port 161
set firewall family inet filter PROTECT-SNMP term DENY-SNMP then log
set firewall family inet filter PROTECT-SNMP term DENY-SNMP then discard

set firewall family inet filter PROTECT-SNMP term DENY-SNMP-TRAPS from protocol udp
set firewall family inet filter PROTECT-SNMP term DENY-SNMP-TRAPS from destination-port 162
set firewall family inet filter PROTECT-SNMP term DENY-SNMP-TRAPS then log
set firewall family inet filter PROTECT-SNMP term DENY-SNMP-TRAPS then discard

set interfaces vlan unit 100 family inet filter input PROTECT-SNMP

set security address-book global address NMS-HOST 10.1.1.1/32
set security address-book global address SRX-MGMT 10.1.100.10/32

set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy ALLOW-NMS-SNMP match source-address NMS-HOST
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy ALLOW-NMS-SNMP match destination-address SRX-MGMT
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy ALLOW-NMS-SNMP match application junos-snmp
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy ALLOW-NMS-SNMP then permit

set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy DENY-OTHER-SNMP match source-address any
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy DENY-OTHER-SNMP match destination-address SRX-MGMT
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy DENY-OTHER-SNMP match application junos-snmp
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy DENY-OTHER-SNMP then log session-init
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy DENY-OTHER-SNMP then deny

Configuration Explanation

set interfaces vlan unit 100 family inet address 10.1.100.10/24

The dedicated management interface is isolated within VLAN100 to separate infrastructure management traffic from production user traffic. This reduces attack surface exposure and improves operational security. All SNMP polling and trap traffic is restricted to this dedicated management network.

set snmp community examplestring authorization read-only

The SNMP community is configured as read-only to prevent configuration modification via SNMP. Read-write communities should never be permitted in production environments, especially when using SNMP v1/v2c. The community string itself should ideally:

set snmp community examplestring clients 10.1.1.1/32

The source IP restricts SNMP polling access to the authorised monitoring platform only. Even though SNMP v1 is inherently insecure, strict source IP restrictions significantly reduce the risk of unauthorised polling activity.

set snmp trap-group NMS-TRAPS version v2

Although polling remains SNMP v1 based, Junos permits the use of SNMP v2 style traps independently, using a trap group configuration. This is operationally beneficial because SNMP v2 traps provide:

set snmp trap-group NMS-TRAPS categories authentication
set snmp trap-group NMS-TRAPS categories chassis
set snmp trap-group NMS-TRAPS categories link
set snmp trap-group NMS-TRAPS categories startup

Only operationally significant trap categories are enabled:

This controlled approach avoids excessive trap generation while still maintaining operational visibility.

set snmp trap-group NMS-TRAPS targets 10.1.1.1

SNMP traps are sent exclusively to the authorised monitoring platform. No additional trap destinations are configured.

set snmp trap-group NMS-TRAPS source-address 10.1.100.10

The trap source address configuration forces all SNMP traps to originate from VLAN100. Using a fixed source address:

term ALLOW-SNMP-POLLING

SNMP polling protection is provided by only permitting UDP/161 traffic from the authorised NMS host.

term ALLOW-SNMP-TRAPS

Outbound SNMP traps are restricted exclusively to:

This prevents unauthorised trap forwarding.

then log
then discard

Logged denial rules ensure that unauthorised SNMP polling and trap traffic is:

This provides operational visibility into suspicious management plane activity.

host-inbound-traffic system-services snmp

Security zone restrictions ensure that only explicitly authorised services are permitted to access the SRX control plane. The configuration allows:

All other inbound management services remain implicitly denied.

policy ALLOW-NMS-SNMP

The security policy explicitly permits SNMP polling from the authorised monitoring server only.

policy DENY-OTHER-SNMP

All other SNMP traffic is denied and logged. This provides additional operational auditing and intrusion visibility.

Operational Considerations and Trap Storm Prevention

SNMP traps should be carefully controlled in production environments. Excessive trap generation can:

For this reason, only high value operational categories should be enabled. Debug level or highly verbose traps should generally be avoided unless temporarily required for troubleshooting.

Verification Commands

show configuration snmp

Verify the SNMP configuration by displaying the active SNMP polling and trap configuration.

show configuration snmp trap-group

The above trap groups command confirms:

show snmp statistics

Show snmp statistics displays:

This is particularly useful for identifying failed polling or authentication issues.

show firewall filter PROTECT-SNMP

Use show firewall filter counters to display packet counters for:

show security policies

Confirms the operational state of SNMP related security policies.

monitor traffic interface vlan.100 matching "port 161 or port 162"

Captures live SNMP polling and trap traffic directly on the management VLAN. This is useful for confirming:

show system connections | match 161

Confirms that the firewall is actively listening for SNMP polling traffic.

show log messages | match SNMP

Monitor log messages to see:

SNMP v3 Polling

The following configuration demonstrates an operationally hardened SNMP v3 deployment for a standalone Juniper SRX firewall running Junos OS. The configuration is designed for secure enterprise monitoring using SNMP v3 with the authPriv security model, SHA-256 authentication, and AES-256 encryption. The monitoring platform is located at 10.1.1.1, while the SRX management interface resides within VLAN100 using the IP address 10.1.100.10/24. No SNMP traps are configured in this example as they are shown in the next one. The configuration includes:

Full Configuration (set Format)

set system host-name SRX-FW-01

set interfaces vlan unit 100 family inet address 10.1.100.10/24

set vlans MANAGEMENT vlan-id 100
set vlans MANAGEMENT l3-interface vlan.100

set snmp v3 usm local-engine user snmpv3user authentication-sha authentication-password ""
set snmp v3 usm local-engine user snmpv3user privacy-aes128 privacy-password ""

set snmp v3 vacm security-to-group security-model usm security-name snmpv3user group SNMPV3-GROUP

set snmp view ALL-OIDS oid .1 include

set snmp v3 vacm access group SNMPV3-GROUP default-context-prefix security-model any security-level privacy read-view ALL-OIDS

set snmp client-list NMS-CLIENTS 10.1.1.1/32

set snmp community restrict-access clients NMS-CLIENTS

set snmp location "Primary Data Centre"
set snmp contact "Network Operations"

set security zones security-zone MANAGEMENT interfaces vlan.100 host-inbound-traffic system-services snmp
set security zones security-zone MANAGEMENT interfaces vlan.100 host-inbound-traffic system-services ssh
set security zones security-zone MANAGEMENT interfaces vlan.100 host-inbound-traffic system-services ping

set firewall family inet filter PROTECT-SNMP term ALLOW-SNMPV3 from source-address 10.1.1.1/32
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMPV3 from destination-address 10.1.100.10/32
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMPV3 from protocol udp
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMPV3 from destination-port 161
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMPV3 then accept

set firewall family inet filter PROTECT-SNMP term DENY-SNMPV3 from protocol udp
set firewall family inet filter PROTECT-SNMP term DENY-SNMPV3 from destination-port 161
set firewall family inet filter PROTECT-SNMP term DENY-SNMPV3 then log
set firewall family inet filter PROTECT-SNMP term DENY-SNMPV3 then discard

set interfaces vlan unit 100 family inet filter input PROTECT-SNMP

set security address-book global address NMS-HOST 10.1.1.1/32
set security address-book global address SRX-MGMT 10.1.100.10/32

set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy ALLOW-NMS-SNMPV3 match source-address NMS-HOST
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy ALLOW-NMS-SNMPV3 match destination-address SRX-MGMT
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy ALLOW-NMS-SNMPV3 match application junos-snmp
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy ALLOW-NMS-SNMPV3 then permit

set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy DENY-OTHER-SNMPV3 match source-address any
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy DENY-OTHER-SNMPV3 match destination-address SRX-MGMT
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy DENY-OTHER-SNMPV3 match application junos-snmp
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy DENY-OTHER-SNMPV3 then log session-init
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy DENY-OTHER-SNMPV3 then deny

Full Configuration (Hierarchical Format)

system {
    host-name SRX-FW-01;
}

interfaces {
    vlan {
        unit 100 {
            family inet {
                address 10.1.100.10/24;

                filter {
                    input PROTECT-SNMP;
                }
            }
        }
    }
}

vlans {
    MANAGEMENT {
        vlan-id 100;
        l3-interface vlan.100;
    }
}

snmp {
    location "Primary Data Centre";
    contact "Network Operations";

    client-list NMS-CLIENTS {
        10.1.1.1/32;
    }

    view ALL-OIDS {
        oid .1 include;
    }

    v3 {
        usm {
            local-engine {
                user snmpv3user {
                    authentication-sha {
                        authentication-password "";
                    }

                    privacy-aes128 {
                        privacy-password "";
                    }
                }
            }
        }

        vacm {
            security-to-group {
                security-model usm {
                    security-name snmpv3user {
                        group SNMPV3-GROUP;
                    }
                }
            }

            access {
                group SNMPV3-GROUP {
                    default-context-prefix {
                        security-model any {
                            security-level privacy {
                                read-view ALL-OIDS;
                            }
                        }
                    }
                }
            }
        }
    }

    community restrict-access {
        clients {
            NMS-CLIENTS;
        }
    }
}

security {
    zones {
        security-zone MANAGEMENT {
            interfaces {
                vlan.100 {
                    host-inbound-traffic {
                        system-services {
                            snmp;
                            ssh;
                            ping;
                        }
                    }
                }
            }
        }
    }

    address-book {
        global {
            address NMS-HOST 10.1.1.1/32;
            address SRX-MGMT 10.1.100.10/32;
        }
    }

    policies {
        from-zone MANAGEMENT to-zone MANAGEMENT {
            policy ALLOW-NMS-SNMPV3 {
                match {
                    source-address NMS-HOST;
                    destination-address SRX-MGMT;
                    application junos-snmp;
                }

                then {
                    permit;
                }
            }

            policy DENY-OTHER-SNMPV3 {
                match {
                    source-address any;
                    destination-address SRX-MGMT;
                    application junos-snmp;
                }

                then {
                    log {
                        session-init;
                    }

                    deny;
                }
            }
        }
    }
}

firewall {
    family inet {
        filter PROTECT-SNMP {
            term ALLOW-SNMPV3 {
                from {
                    source-address {
                        10.1.1.1/32;
                    }

                    destination-address {
                        10.1.100.10/32;
                    }

                    protocol udp;
                    destination-port 161;
                }

                then accept;
            }

            term DENY-SNMPV3 {
                from {
                    protocol udp;
                    destination-port 161;
                }

                then {
                    log;
                    discard;
                }
            }
        }
    }
}

Configuration Explanation

set interfaces vlan unit 100 family inet address 10.1.100.10/24

The SRX management interface resides within VLAN100 using the address 10.1.100.10/24. Separating management traffic from production traffic improves operational control and reduces unnecessary exposure of management services.

set snmp v3 usm local-engine user snmpv3user authentication-sha authentication-password ""
set snmp v3 usm local-engine user snmpv3user privacy-aes128 privacy-password ""

The SNMP v3 user is configured using the User based Security Model (USM). The configuration enables:

The user snmpv3user authenticates against the local SNMP engine on the SRX firewall.

set snmp v3 vacm security-to-group security-model usm security-name snmpv3user group SNMPV3-GROUP

The View based Access Control Model (VACM) maps the SNMP v3 user into a logical access group. This controls which OIDs the user may access.

set snmp view ALL-OIDS oid .1 include

The view permits access to the full ISO OID tree. This allows standard enterprise monitoring platforms to poll:

set snmp v3 vacm access group SNMPV3-GROUP default-context-prefix security-model any security-level privacy read-view ALL-OIDS

This read-only access control configuration enforces:

set snmp client-list NMS-CLIENTS 10.1.1.1/32

SNMP access is restricted exclusively to the monitoring platform at 10.1.1.1. This limits exposure of the SNMP service and reduces unauthorised access attempts.

host-inbound-traffic system-services snmp

The SRX control plane permits only explicitly authorised management services are allowed on VLAN100:

term ALLOW-SNMPV3

Firewall filter protection permits only UDP/161 traffic from the authorised monitoring platform.

term DENY-SNMPV3

Unauthorised SNMP traffic is:

This provides operational visibility into invalid or malicious polling attempts.

policy ALLOW-NMS-SNMPV3

The security policy explicitly permits SNMP traffic from the monitoring platform to the management interface.

policy DENY-OTHER-SNMPV3

Unauthorised SNMP traffic is denied and logged at session initiation. This improves auditing and troubleshooting visibility.

Verification Commands

show configuration snmp

Displays the active SNMP v3 configuration.

show snmp v3 usm users

Displays configured SNMP v3 users and authentication configuration.

show snmp v3 engine-id

Displays the local SNMP engine ID used by the SRX firewall. This is useful when troubleshooting authentication and engine synchronisation issues.

show snmp statistics

SNMP statistics displays:

show firewall filter PROTECT-SNMP

Show firewall filter counters displays:

Useful for confirming filter behaviour and identifying blocked polling attempts.

show security policies

Confirms operational security policy state and rule matching.

show security flow session application junos-snmp

Displays active SNMP sessions traversing the SRX firewall.

monitor traffic interface vlan.100 matching "port 161"

Captures live SNMP traffic directly on the management interface. Useful for confirming:

show log messages | match SNMP

Show log messages relating to SNMP displays:

Example SNMP v3 Polling Commands

snmpwalk performs a full SNMP walk against the SRX firewall using authenticated and encrypted SNMP v3.

snmpwalk -v3 -l authPriv -u snmpv3user -a SHA-256 -A  -x AES-256 -X  10.1.100.10

Interface Table Walk retrieves interface descriptions from the SRX firewall.

snmpwalk -v3 -l authPriv -u snmpv3user -a SHA-256 -A  -x AES-256 -X  10.1.100.10 IF-MIB::ifDescr

Operational Troubleshooting Guidance

When troubleshooting SNMP v3 connectivity:

SNMP v3 Polling and Traps

The following configuration demonstrates a hardened enterprise SNMP v3 deployment with SNMP v3 traps for a standalone Juniper SRX firewall running Junos OS. The configuration provides:

The monitoring platform and trap receiver is located at 10.1.1.1, while the SRX management interface resides within VLAN100 using 10.1.100.10/24. Only operationally significant SNMP trap categories are enabled in order to reduce unnecessary management plane load and minimise the risk of trap storms.

Full Configuration (set Format)

set system host-name SRX-FW-01

set interfaces vlan unit 100 family inet address 10.1.100.10/24

set vlans MANAGEMENT vlan-id 100
set vlans MANAGEMENT l3-interface vlan.100

set snmp location "Primary Data Centre"
set snmp contact "Network Operations"

set snmp v3 usm local-engine user snmpv3user authentication-sha authentication-password ""
set snmp v3 usm local-engine user snmpv3user privacy-aes128 privacy-password ""

set snmp v3 vacm security-to-group security-model usm security-name snmpv3user group SNMPV3-GROUP

set snmp view ALL-OIDS oid .1 include

set snmp v3 vacm access group SNMPV3-GROUP default-context-prefix security-model any security-level privacy read-view ALL-OIDS

set snmp client-list NMS-CLIENTS 10.1.1.1/32

set snmp trap-options source-address 10.1.100.10

set snmp v3 target-address NMS-TRAP-TARGET address 10.1.1.1
set snmp v3 target-address NMS-TRAP-TARGET tag-list NMS-TRAPS
set snmp v3 target-address NMS-TRAP-TARGET target-params NMS-PARAMS

set snmp v3 target-parameters NMS-PARAMS parameters-message-processing-model v3
set snmp v3 target-parameters NMS-PARAMS parameters-security-model usm
set snmp v3 target-parameters NMS-PARAMS parameters-security-name snmpv3user
set snmp v3 target-parameters NMS-PARAMS parameters-security-level privacy

set snmp trap-group NMS-TRAPS categories authentication
set snmp trap-group NMS-TRAPS categories chassis
set snmp trap-group NMS-TRAPS categories link
set snmp trap-group NMS-TRAPS categories startup
set snmp trap-group NMS-TRAPS targets 10.1.1.1

set security zones security-zone MANAGEMENT interfaces vlan.100 host-inbound-traffic system-services snmp
set security zones security-zone MANAGEMENT interfaces vlan.100 host-inbound-traffic system-services ssh
set security zones security-zone MANAGEMENT interfaces vlan.100 host-inbound-traffic system-services ping

set firewall family inet filter PROTECT-SNMP term ALLOW-SNMPV3-POLLING from source-address 10.1.1.1/32
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMPV3-POLLING from destination-address 10.1.100.10/32
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMPV3-POLLING from protocol udp
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMPV3-POLLING from destination-port 161
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMPV3-POLLING then accept

set firewall family inet filter PROTECT-SNMP term ALLOW-SNMPV3-TRAPS from source-address 10.1.100.10/32
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMPV3-TRAPS from destination-address 10.1.1.1/32
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMPV3-TRAPS from protocol udp
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMPV3-TRAPS from destination-port 162
set firewall family inet filter PROTECT-SNMP term ALLOW-SNMPV3-TRAPS then accept

set firewall family inet filter PROTECT-SNMP term DENY-SNMPV3-POLLING from protocol udp
set firewall family inet filter PROTECT-SNMP term DENY-SNMPV3-POLLING from destination-port 161
set firewall family inet filter PROTECT-SNMP term DENY-SNMPV3-POLLING then log
set firewall family inet filter PROTECT-SNMP term DENY-SNMPV3-POLLING then discard

set firewall family inet filter PROTECT-SNMP term DENY-SNMPV3-TRAPS from protocol udp
set firewall family inet filter PROTECT-SNMP term DENY-SNMPV3-TRAPS from destination-port 162
set firewall family inet filter PROTECT-SNMP term DENY-SNMPV3-TRAPS then log
set firewall family inet filter PROTECT-SNMP term DENY-SNMPV3-TRAPS then discard

set interfaces vlan unit 100 family inet filter input PROTECT-SNMP

set security address-book global address NMS-HOST 10.1.1.1/32
set security address-book global address SRX-MGMT 10.1.100.10/32

set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy ALLOW-NMS-SNMPV3 match source-address NMS-HOST
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy ALLOW-NMS-SNMPV3 match destination-address SRX-MGMT
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy ALLOW-NMS-SNMPV3 match application junos-snmp
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy ALLOW-NMS-SNMPV3 then permit

set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy DENY-OTHER-SNMPV3 match source-address any
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy DENY-OTHER-SNMPV3 match destination-address SRX-MGMT
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy DENY-OTHER-SNMPV3 match application junos-snmp
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy DENY-OTHER-SNMPV3 then log session-init
set security policies from-zone MANAGEMENT to-zone MANAGEMENT policy DENY-OTHER-SNMPV3 then deny

Full Configuration (Hierarchical Format)

system {
    host-name SRX-FW-01;
}

interfaces {
    vlan {
        unit 100 {
            family inet {
                address 10.1.100.10/24;

                filter {
                    input PROTECT-SNMP;
                }
            }
        }
    }
}

vlans {
    MANAGEMENT {
        vlan-id 100;
        l3-interface vlan.100;
    }
}

snmp {
    location "Primary Data Centre";
    contact "Network Operations";

    client-list NMS-CLIENTS {
        10.1.1.1/32;
    }

    trap-options {
        source-address 10.1.100.10;
    }

    view ALL-OIDS {
        oid .1 include;
    }

    v3 {
        usm {
            local-engine {
                user snmpv3user {
                    authentication-sha {
                        authentication-password "";
                    }

                    privacy-aes128 {
                        privacy-password "";
                    }
                }
            }
        }

        vacm {
            security-to-group {
                security-model usm {
                    security-name snmpv3user {
                        group SNMPV3-GROUP;
                    }
                }
            }

            access {
                group SNMPV3-GROUP {
                    default-context-prefix {
                        security-model any {
                            security-level privacy {
                                read-view ALL-OIDS;
                            }
                        }
                    }
                }
            }
        }

        target-address NMS-TRAP-TARGET {
            address 10.1.1.1;
            tag-list NMS-TRAPS;
            target-params NMS-PARAMS;
        }

        target-parameters NMS-PARAMS {
            parameters-message-processing-model v3;
            parameters-security-model usm;
            parameters-security-name snmpv3user;
            parameters-security-level privacy;
        }
    }

    trap-group NMS-TRAPS {
        categories authentication;
        categories chassis;
        categories link;
        categories startup;
        targets {
            10.1.1.1;
        }
    }
}

security {
    zones {
        security-zone MANAGEMENT {
            interfaces {
                vlan.100 {
                    host-inbound-traffic {
                        system-services {
                            snmp;
                            ssh;
                            ping;
                        }
                    }
                }
            }
        }
    }

    address-book {
        global {
            address NMS-HOST 10.1.1.1/32;
            address SRX-MGMT 10.1.100.10/32;
        }
    }

    policies {
        from-zone MANAGEMENT to-zone MANAGEMENT {
            policy ALLOW-NMS-SNMPV3 {
                match {
                    source-address NMS-HOST;
                    destination-address SRX-MGMT;
                    application junos-snmp;
                }

                then {
                    permit;
                }
            }

            policy DENY-OTHER-SNMPV3 {
                match {
                    source-address any;
                    destination-address SRX-MGMT;
                    application junos-snmp;
                }

                then {
                    log {
                        session-init;
                    }

                    deny;
                }
            }
        }
    }
}

firewall {
    family inet {
        filter PROTECT-SNMP {
            term ALLOW-SNMPV3-POLLING {
                from {
                    source-address {
                        10.1.1.1/32;
                    }

                    destination-address {
                        10.1.100.10/32;
                    }

                    protocol udp;
                    destination-port 161;
                }

                then accept;
            }

            term ALLOW-SNMPV3-TRAPS {
                from {
                    source-address {
                        10.1.100.10/32;
                    }

                    destination-address {
                        10.1.1.1/32;
                    }

                    protocol udp;
                    destination-port 162;
                }

                then accept;
            }

            term DENY-SNMPV3-POLLING {
                from {
                    protocol udp;
                    destination-port 161;
                }

                then {
                    log;
                    discard;
                }
            }

            term DENY-SNMPV3-TRAPS {
                from {
                    protocol udp;
                    destination-port 162;
                }

                then {
                    log;
                    discard;
                }
            }
        }
    }
}

Configuration Explanation

set snmp v3 usm local-engine user snmpv3user authentication-sha authentication-password ""
set snmp v3 usm local-engine user snmpv3user privacy-aes128 privacy-password ""

The SNMP v3 user is configured using the User based Security Model (USM). The configuration enables:

The read-only monitoring access means that the user authenticates locally against the SRX SNMP engine.

set snmp v3 vacm access group SNMPV3-GROUP default-context-prefix security-model any security-level privacy read-view ALL-OIDS

The View based Access Control Model (VACM) restricts the user to encrypted (privacy) SNMP sessions only. The user receives read-only access to the full ISO OID tree.

set snmp trap-options source-address 10.1.100.10

All SNMP v3 traps originate from the management interface on VLAN100. Using a fixed source address:

set snmp v3 target-address NMS-TRAP-TARGET address 10.1.1.1

The trap receiver is restricted exclusively to the authorised monitoring platform. No additional trap destinations are configured.

set snmp v3 target-parameters NMS-PARAMS parameters-security-level privacy

SNMP v3 traps are transmitted using encrypted authPriv security. The trap configuration uses:

set snmp trap-group NMS-TRAPS categories authentication
set snmp trap-group NMS-TRAPS categories chassis
set snmp trap-group NMS-TRAPS categories link
set snmp trap-group NMS-TRAPS categories startup

Only operationally significant trap categories are enabled.

Restricting enabled categories reduces unnecessary trap generation and limits management-plane load.

term ALLOW-SNMPV3-POLLING

The firewall filter ensures that only UDP/161 SNMP polling traffic from the authorised NMS is permitted.

term ALLOW-SNMPV3-TRAPS

Only outbound UDP/162 SNMP traps destined for 10.1.1.1 are permitted.

then log
then discard

Unauthorised SNMP polling or trap traffic is logged and discarded. This provides operational visibility into suspicious management plane activity.

Verification Commands

show configuration snmp

Displays the complete active SNMP v3 configuration.

show snmp v3 usm users

Displays configured SNMP v3 users and associated security parameters.

show snmp v3 engine-id

Displays the local SNMP engine ID. This command is useful when troubleshooting authentication or engine synchronisation issues.

show snmp statistics

This command displays:

show configuration snmp trap-group

Displays configured trap groups and categories.

show firewall filter PROTECT-SNMP

This commands shows the firewall filter counters i.e.:

show security policies

Confirms active SNMP related security policy configuration.

monitor traffic interface vlan.100 matching "port 161 or port 162"

Captures live SNMP polling and trap traffic directly on the management interface. This is useful for confirming:

show log messages | match SNMP

The log messages relating to SNMP show:

Example SNMP v3 Polling Commands

snmpwalk -v3 -l authPriv -u snmpv3user -a SHA-256 -A  -x AES -X  10.1.100.10

Performs a full encrypted SNMP v3 walk against the SRX firewall.

snmpwalk -v3 -l authPriv -u snmpv3user -a SHA-256 -A  -x AES -X  10.1.100.10 IF-MIB::ifDescr

Interface polling example which retrieves interface descriptions from the SRX firewall.

Operational Troubleshooting Guidance

When troubleshooting SNMP v3 polling or traps:

Syslog

This example provides a production ready syslog configuration for a standalone branch SRX firewall running Junos. The configuration is designed for:

Configuration Block (Hierarchical Format)

interfaces {
    vlan {
        unit 100 {
            family inet {
                address 10.1.100.10/24;
            }
        }
    }
}

security {
    log {
        mode stream;

        source-address 10.1.100.10;

        stream SYSLOG-UDP {
            host 10.1.1.1;
            transport udp;
            port 514;
            format sd-syslog;

            category {
                all;
            }
        }

        stream SYSLOG-TCP {
            host 10.1.1.1;
            transport tcp;
            port 514;
            format sd-syslog;
            facility local5;
            severity info;
            category {
                all;
            }
        }

        stream SYSLOG-TLS {
            host 10.1.1.1;
            transport tls;
            port 6514;
            format sd-syslog;
            facility local5;
            severity info;
            category {
                all;
            }

            tls-details {
                local-certificate SRX-SYSLOG-CERT;
                trusted-ca-group SYSLOG-CA;
            }
        }
    }

    policies {
        default-policy {
            deny-all;
        }
    }
}

system {
    syslog {
        source-address 10.1.100.10;

        host 10.1.1.1 {
            any notice;

            structured-data;

            facility-override local5;

            log-prefix SRX-BRANCH01;

            transport udp;
        }

        file messages {
            any notice;
            authorization info;
        }

        file interactive-commands {
            interactive-commands any;
        }
    }

    ntp {
        source-address 10.1.100.10;
    }
}

policy-options {
    prefix-list SYSLOG-SERVER {
        10.1.1.1/32;
    }
}

firewall {
    family inet {
        filter PROTECT-RE {
            term ALLOW-SYSLOG-UDP {
                from {
                    source-address {
                        10.1.1.1/32;
                    }
                    protocol udp;
                    source-port 514;
                }
                then accept;
            }

            term ALLOW-SYSLOG-TCP {
                from {
                    source-address {
                        10.1.1.1/32;
                    }
                    protocol tcp;
                    source-port [ 514 6514 ];
                }
                then accept;
            }

            term ALLOW-ESTABLISHED {
                from {
                    tcp-established;
                }
                then accept;
            }

            term DENY-UNTRUSTED {
                then {
                    count DENY-UNTRUSTED-COUNT;
                    discard;
                }
            }
        }
    }
}

interfaces {
    lo0 {
        unit 0 {
            family inet {
                filter {
                    input PROTECT-RE;
                }
            }
        }
    }
}

Configuration Block (Set Format)

set interfaces vlan unit 100 family inet address 10.1.100.10/24

set security log mode stream
set security log source-address 10.1.100.10

set security log stream SYSLOG-UDP host 10.1.1.1
set security log stream SYSLOG-UDP transport udp
set security log stream SYSLOG-UDP port 514
set security log stream SYSLOG-UDP format sd-syslog
set security log stream SYSLOG-UDP facility local5
set security log stream SYSLOG-UDP severity info
set security log stream SYSLOG-UDP category all

set security log stream SYSLOG-TCP host 10.1.1.1
set security log stream SYSLOG-TCP transport tcp
set security log stream SYSLOG-TCP port 514
set security log stream SYSLOG-TCP format sd-syslog
set security log stream SYSLOG-TCP facility local5
set security log stream SYSLOG-TCP severity info
set security log stream SYSLOG-TCP category all

set security log stream SYSLOG-TLS host 10.1.1.1
set security log stream SYSLOG-TLS transport tls
set security log stream SYSLOG-TLS port 6514
set security log stream SYSLOG-TLS format sd-syslog
set security log stream SYSLOG-TLS facility local5
set security log stream SYSLOG-TLS severity info
set security log stream SYSLOG-TLS category all
set security log stream SYSLOG-TLS tls-details local-certificate SRX-SYSLOG-CERT
set security log stream SYSLOG-TLS tls-details trusted-ca-group SYSLOG-CA

set security policies default-policy deny-all

set system syslog source-address 10.1.100.10
set system syslog host 10.1.1.1 any notice
set system syslog host 10.1.1.1 structured-data
set system syslog host 10.1.1.1 facility-override local5
set system syslog host 10.1.1.1 log-prefix SRX-BRANCH01
set system syslog host 10.1.1.1 transport udp

set system syslog file messages any notice
set system syslog file messages authorization info
set system syslog file interactive-commands interactive-commands any

set system ntp source-address 10.1.100.10

set policy-options prefix-list SYSLOG-SERVER 10.1.1.1/32

set firewall family inet filter PROTECT-RE term ALLOW-SYSLOG-UDP from source-address 10.1.1.1/32
set firewall family inet filter PROTECT-RE term ALLOW-SYSLOG-UDP from protocol udp
set firewall family inet filter PROTECT-RE term ALLOW-SYSLOG-UDP from source-port 514
set firewall family inet filter PROTECT-RE term ALLOW-SYSLOG-UDP then accept

set firewall family inet filter PROTECT-RE term ALLOW-SYSLOG-TCP from source-address 10.1.1.1/32
set firewall family inet filter PROTECT-RE term ALLOW-SYSLOG-TCP from protocol tcp
set firewall family inet filter PROTECT-RE term ALLOW-SYSLOG-TCP from source-port 514
set firewall family inet filter PROTECT-RE term ALLOW-SYSLOG-TCP from source-port 6514
set firewall family inet filter PROTECT-RE term ALLOW-SYSLOG-TCP then accept

set firewall family inet filter PROTECT-RE term ALLOW-ESTABLISHED from tcp-established
set firewall family inet filter PROTECT-RE term ALLOW-ESTABLISHED then accept

set firewall family inet filter PROTECT-RE term DENY-UNTRUSTED then count DENY-UNTRUSTED-COUNT
set firewall family inet filter PROTECT-RE term DENY-UNTRUSTED then discard

set interfaces lo0 unit 0 family inet filter input PROTECT-RE

Logical Section Breakdown and Explanation

1. Source Interface Configuration

interfaces {
    vlan {
        unit 100 {
            family inet {
                address 10.1.100.10/24;
            }
        }
    }
}

Explanation: this defines the VLAN100 interface used as the source of all syslog traffic. Why this matters:

Best practice: always explicitly define the syslog source address in enterprise environments.

2. Security Logging Configuration

security {
    log {
        mode stream;
        source-address 10.1.100.10;

Explanation: mode stream enables remote streaming of security logs. The source address statement forces all security logs to originate from VLAN100. Without this:

3. UDP Syslog Stream

stream SYSLOG-UDP {
    host 10.1.1.1;
    transport udp;
    port 514;

Explanation: UDP syslog is:

But it is also:

So use UDP when:

4. TCP Syslog Stream

stream SYSLOG-TCP {
    host 10.1.1.1;
    transport tcp;
    port 514;

Explanation: TCP syslog provides:

Compared to UDP:

TCP is usually the best operational compromise.

5. TLS Syslog Stream (Recommended)

stream SYSLOG-TLS {
    host 10.1.1.1;
    transport tls;
    port 6514;

Explanation: TLS syslog is the most secure option. Benefits:

Recommended for:

6. TLS Mutual Authentication

tls-details {
    local-certificate SRX-SYSLOG-CERT;
    trusted-ca-group SYSLOG-CA;
}

Explanation: this enables certificate based authentication. The SRX:

This prevents:

7. Structured Syslog Format

format sd-syslog;
structured-data;

Explanation: structured syslog provides machine readable metadata. Advantages:

8. Severity Tuning

severity info;

Explanation: this provides a balanced operational logging level. Debug logging:

so info is a good operational baseline.

9. Facility Override

facility local5;

Explanation: using a dedicated facility simplifies SIEM classification. Benefits:

10. Routing Engine Protection Filter

filter PROTECT-RE

Explanation: this firewall filter protects the SRX control plane. It only permits expected management traffic from trusted sources. This is critical because:

11. Loopback Filter Application

interfaces {
    lo0 {
        unit 0 {
            family inet {
                filter {
                    input PROTECT-RE;
                }
            }
        }
    }
}

Explanation: applying filters to lo0 protects the routing engine globally. This is a standard Junos hardening practice.

The recommended transport choice for production enterprise deployments is TLS on port 6514.

Verification Commands

show security log

Review the security logging

show configuration system syslog

Review the syslog configuration

show security log stream

Verify that the TLS sessions are functioning correctly

monitor start messages

Monitor the live logs for any troubleshooting information

ping 10.1.1.1 source 10.1.100.10

Test Connectivity between the SRX and the monitoring platform.

Operational Recommendations for a Branch Juniper Firewall

Avoid

Conclusion

This blog post covers two of the most popular types of networking equipment i.e. Cisco Switches and Juniper Firewalls. Although, there are obviously many other manufacturers and types of network equipment, this post gives a flavour of what to consider when monitoring such equipment. Probably the most important decision is what version of SNMP to use, with v3 being the most recommended. However, not all equipment or network monitoring platforms (NMS) can support v3 and therefore v1 or v2c should be considered. Regardless of version, the configuration should be hardened as much as possible. The next decision involves whether to also capture Syslog messages. If so, the recommendation method is encrypted via TLS, rather than TCP or UDP. The final decision is whether to also collect SNMP traps or just rely on SNMP polling. SNMP traps can provide near real time status updates but care needs to be taken to ensure not to overload the network or NMS with too many SNMP traps. As in all things related to network monitoring, this is not a fit and forget activity but requires tuning on an ongoing basis in order for the NMS to preserve its value to the organisation.