Hands-On Lab: Configuring Syslog

This hands-on lab configures a router to send log messages to a centralized syslog server, sets an appropriate logging severity level, and verifies messages are actually received and correctly categorized on the server side.

Syslog Server ConfigurationLogging Severity LevelsCentralized Log Collection

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۱ مهر ۱۴۰۵

Lab Objective

Configure a router to forward its log messages to a centralized syslog server, set the logging severity level appropriately, and verify both that messages are transmitted and that they appear correctly categorized on the receiving server.

Lab Purpose

Reviewing logs on each device individually does not scale across dozens or hundreds of network devices. Centralized syslog collection lets an administrator review events from every device in one place, and understanding severity levels ensures the right amount of detail is captured without overwhelming the server with excessive noise.

Lab Topology

R1 ---- Gi0/0: 192.168.90.1/24

Syslog server: 192.168.90.50/24

Task 1: Configure Basic Addressing

Configure R1's interface connecting to the segment where the syslog server resides.

Task 2: Configure the Syslog Server Destination

Point R1 to the syslog server's IP address.

Task 3: Set the Logging Severity Level

Configure logging to send messages at the informational level and above.

Task 4: Generate a Test Log Message

Trigger an interface state change to generate a log message and confirm it appears locally.

Task 5: Verify the Message Arrives at the Syslog Server

Confirm the same message is received and logged on the syslog server.

Solution and Verification

R1(config)# interface gigabitethernet0/0
R1(config-if)# ip address 192.168.90.1 255.255.255.0
R1(config-if)# no shutdown

R1(config)# logging host 192.168.90.50

R1(config)# logging trap informational

-- Severity levels range from 0 (emergencies,
-- most severe) to 7 (debugging, most verbose)
-- -- "informational" is severity 6, capturing
-- routine operational events without the
-- excessive volume of full debug-level logging

R1(config)# interface gigabitethernet0/1
R1(config-if)# shutdown
R1(config-if)# no shutdown

*Jun 15 14:10:22.101: %LINK-3-UPDOWN: Interface
GigabitEthernet0/1, changed state to down
*Jun 15 14:10:25.204: %LINK-3-UPDOWN: Interface
GigabitEthernet0/1, changed state to up
-- Confirmed appearing in the local console
-- output first

-- On the syslog server:

Jun 15 14:10:22 192.168.90.1 %LINK-3-UPDOWN:
Interface GigabitEthernet0/1, changed state to down
Jun 15 14:10:25 192.168.90.1 %LINK-3-UPDOWN:
Interface GigabitEthernet0/1, changed state to up
-- The exact same messages arrived at the
-- centralized server, tagged with the
-- source device's address

Key Takeaway

Severity level 3 (errors) is the level assigned to this particular link state change message, and since the configured trap level (informational, severity 6) captures everything at severity 6 and more severe (lower-numbered) levels, this message and every less-severe informational event both get forwarded — understanding that lower severity numbers mean higher importance is essential for setting a logging trap level that captures what actually matters without drowning the server in noise.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه