LogoفارسیFA

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 min read · Updated Sep 23, 2026

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.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring OSPF Virtual Links

This hands-on lab connects a disconnected area to the backbone using an OSPF virtual link, addressing a design violation where an area does not have a direct physical connection to Area 0, and verifies routes flow correctly once the virtual link is established.

Continue

Hands-On Lab: Configuring an OSPF NSSA Area

This hands-on lab configures Area 1 as an NSSA, redistributing a local external route directly from within that area and verifying it propagates as a Type 7 LSA before being translated to Type 5 at the ABR, while inter-area routes from elsewhere remain blocked exactly as in a standard stub area.

Continue

Hands-On Lab: Configuring OSPF Stub and Totally Stubby Areas

This hands-on lab configures a leaf area as a standard stub area, then upgrades it to a totally stubby area, comparing the routing table size at each stage and verifying only a default route remains once fully configured.

Continue

Hands-On Lab: Configuring Multi-Area OSPF with Route Summarization

This hands-on lab configures multi-area OSPF across three routers, designating an ABR that summarizes several subnets from a leaf area into a single route advertised toward the backbone, tying together the area design and summarization concepts covered earlier in this series.

Continue

Hands-On Lab: Configuring EIGRP for IPv6

This hands-on lab configures EIGRP for IPv6 between two routers, activating the protocol directly on each interface similar to OSPFv3's approach, and highlights the mandatory router ID requirement unique to EIGRPv6.

Continue

Hands-On Lab: Configuring OSPFv3 for IPv6

This hands-on lab configures OSPFv3 between two routers to dynamically route IPv6 traffic, comparing its configuration syntax against the OSPFv2 labs covered earlier in this series while highlighting the interface-level activation approach OSPFv3 uses.

Continue
Previous ArticleNext Article