How to Find When an Alteon Configuration Was Changed

Retained audit records may show when an Alteon configuration changed. Start with audit evidence, system messages, and configuration snapshots. Current SLB group membership alone does not establish when a member was added.

1. Investigation question

In this fictional lab scenario, an engineer finds an unexpected Real Server in an SLB group and needs to establish when the membership changed, which account was involved, and whether it became active. The workflow combines documented capabilities with checks that still require validation on the installed release.

2. Environment

Item	Illustrative lab value
Platform	Radware Alteon ADC; hardware model intentionally unspecified
SLB group	Group 10
Expected members	Real servers 1 and 2: 192.0.2.11 and 192.0.2.12
Unexpected member	Real server 3: 192.0.2.13
External log collector	192.0.2.200, if configured

All addresses are documentation examples. No production records or device output are reproduced. Public Radware knowledgebase articles and release notes support the cited commands. The release-specific Command Reference and Application Guide required portal authentication and were not obtained. Exact-release behavior and SLB member audit fields were not tested on an appliance.

3. Available change evidence

BP4178 documents add, modify, and delete auditing, with console and configured syslog alerts when enabled. The feature began in 30.5.2.0; the audit setting defaults to disabled. [1] Radware also documents audit records at /disk/logs/syslogAudit, exportable through techdata regardless of the audit setting. The 31.0 release notes describe this too. Check retained local evidence even if Audit Trail is disabled; neither source promises unlimited retention. [1, 4]

Evidence	What it can establish	Boundary
Current configuration	The configuration visible at collection time	A supported per-member creation or last-change timestamp was not verified
Configuration audit records	Recorded change details and their event times, where present	Exact group/member fields and event timing are version-dependent and require validation
System messages	Management activity, apply/save events, and account/source context where recorded	A general apply event does not identify every changed object
Timestamped backups	Differences between captured states	Usually establish an interval, not an exact event time or author

4. Where to collect evidence

4.1 Preserve the current state

Capture the configuration before correcting it. BP3760 documents cc from 31.0, 30.5.5.0, and 30.2.7.0. It omits keys and certificates, but other sensitive content may remain. Store the capture securely. [5]

cc

This displays configuration without apply or save. Locate the group and Real Server definitions. The export's collection time is not the member's creation time.

4.2 Review local system messages and logging settings

BP3976 documents these display commands: [3]

/info/sys/log
/cfg/sys/syslog/cur

Preserve the displayed messages and settings. Check their time coverage and the audit configuration, while remembering that today's setting does not establish the setting at the suspected change time.

4.3 Examine retained disk audit evidence

If system messages are insufficient, use the installed release's supported techdata collection procedure. The disk path identifies a log location; it does not supply an Alteon CLI or shell command for reading it. [4]

4.4 Search the external collector and backups

Search the collector by device, instance, time range, group, Real Server, and address where those fields exist. Retain surrounding events and compare backups to distinguish membership additions from object creation, address changes, or configuration restores.

5. Establishing what, when, and who

Look for evidence of each:

What: A record or configuration comparison must identify the affected group and member.
When: Preserve the event timestamp, time zone, and collector receipt time separately. Check clock reliability.
Who: Use the account identity actually recorded and corroborate it with authorized authentication or automation records.

BP3976 examples include an account, SSH source address, and timestamp alongside apply/save messages. Use them to investigate management context; every audit event is not guaranteed to carry those fields. [3] Attribute activity to the recorded account first. Shared or automated credentials may not identify a person, and a nearby login or apply event does not prove who added the member.

BP2738 describes a shared pending configuration buffer and an apply operation that activates pending edits. The batch's apply account may therefore differ from an edit's author. This 2017 article describes historical behavior; check concurrency and locking on the deployed release. [6] Record edit, apply, and save separately. An audit time establishes the moment traffic behavior changed only if the event semantics and transition to active state have been validated.

6. Example: an unexpected group member

This invented timeline illustrates the evidence limits; it is not device output.

Evidence	Observation	Supported conclusion
Backup A, 09:00 UTC	Group 10 contains servers 1 and 2	Server 3 was absent in this captured state
Backup B, 10:00 UTC	Group 10 contains servers 1, 2, and 3	Membership differs between these snapshots
System event, 09:37 UTC	A configuration apply event exists	An apply occurred; its relationship to this membership is unproven

With only these records, report: “The membership appeared between the two captured states; an apply event occurred within that interval. The exact member-change time and author are not established.” Multiple changes between snapshots remain possible. If an audit event identifies the group/member operation, compare it with surrounding management events and the resulting configuration. Retain only fields actually present and preserve any ambiguity.

7. Limitations

Current configuration timestamps: Not verified: No reviewed source establishes a per-SLB-member timestamp query. Current membership alone cannot answer the historical question.
Member-level coverage: Version-dependent: General add/modify/delete auditing is documented, but the exact representation of SLB member addition and removal has not been verified for the target release.
Missing evidence: If local records, external logs, backups, and change records no longer cover the event, an exact time or author may be unrecoverable. Enabling logging now cannot recreate deleted records.
Retention: Not verified: No fixed audit retention period, disk rotation size, or reboot-survival guarantee is asserted.

The 31.0.6.0 fixes include blank delete-operation syslog (prod00261753) and incorrect audit-user identity in a WBM/TACACS scenario (prod00257517). Test addition and removal; these historical fixes do not establish defects in later releases. [8]

8. Recommended logging controls

Recommended operational controls:

Use individually assigned administrator accounts and distinct automation identities.
Maintain synchronized clocks and explicit time-zone handling.
Enable validated audit forwarding to a protected external collector; confirm receipt rather than relying only on device settings.
Define retention that covers the organization’s investigation window, and monitor collector availability.
Keep timestamped configuration snapshots before and after approved changes, with a reviewed diff and change ticket.
Record the editor, apply operator, and save outcome when those roles differ.

BP3816 and BP4178 document enabling audit with: [1, 2]

/c/sys/syslog/audit e

This changes configuration. Confirm behavior and the apply/save workflow for the installed release. BP3816 places external-host configuration under /c/sys/syslog/hst1; the complete argument sequence is omitted because release-specific syntax was not confirmed. [2] Review feature and destination filters too. KI437 explains that disabled aggregate log all status can indicate one disabled feature. The interactive /c/sys/syslog/log menu displays status and can change it, so it is not purely read-only. [7]

BP3976 documents /cfg/sys/syslog/extdlog e, followed by apply/save, to include the year and UTC offset. It notes a format issue in 31.0.3.0. Check release support and validate the resulting timestamps before relying on them. [3]

9. Verification

The public 34.0.10.0 release summary was located, but does not establish member-level audit semantics. Release-specific guides were not obtained from authenticated downloads, and no appliance test was performed. This workflow is not a tested procedure for an exact build. [9, 10] Before adoption, test in an isolated lab matching the release and management method:

Record the clock, logging settings, and baseline configuration.
Add a test real server member to an unused group through the supported interface.
Record edit, apply, and save times separately using the documented workflow.
Compare local messages, techdata audit evidence, collector events, and configuration snapshots.
Repeat for member removal and for each management method actually used.
Check object identifiers, account identity, event timing, forwarding, and the usable retention window.

Retained evidence must distinguish addition from removal, identify the group/member, and supply usable time and account context. Document missing fields and ambiguity.

10. Operational considerations

Preserve evidence before removing an unexpected member. Review the service and authorization context; correcting an active group requires a separate change decision. BP4178 warns of temporary management-processor CPU increases and longer apply times during large audited changes, especially filter changes in constrained virtual instances. Assess overhead in the lab before broad logging during a large change. [1] For service checks after an approved membership change, see:

Alteon Health Check Configuration & Troubleshooting Guide: verify backend availability.
Alteon Client IP Persistence Explained: review client-to-backend affinity.
Alteon Sessions Show Established, but HTTPS Authentication Fails Intermittently: investigate application behavior beyond TCP state.

11. References

These official Radware sources were reviewed on October 3, 2026. Some expose partial public content and require sign-in for the full article.

Search This Blog

NetOps Field