Sophos Switch: Securely manage CDP, LLDP and address tables

Under Discovery, Sophos Switch bundles two different tasks: CDP and LLDP describe the switch and directly connected neighbors, while ARP, MAC and NDP contain address mappings. The MAC filtering list in turn implements VLAN approval for specific MAC addresses. These areas are treated separately: a correct LLDP neighbor entry does not confirm an ARP association, and a static MAC entry does not activate a discovery protocol.

Important: Changes to ARP, MAC, NDP and especially MAC filter entries can interrupt a device’s traffic or direct it to an incorrect VLAN. Before each change, document the original entry, port, VLAN, management path and return path. Do not use management access to the switch being edited as the first test case.

Prerequisites and preparation for changes

Required:

• Administrator access to the correct tenant, location and switch in Sophos Fusion;
• an accessible switch with a synchronous, known configuration status;
• the expected physical topology with local and remote ports;
• VLAN plan, voice VLAN, native VLANs, duplex and LAG mapping;
• for static entries the confirmed IP/MAC assignment, the VLAN and for MAC entries the physical port;
• a second management route or a local fallback option;
• for production changes, a maintenance window and a documented initial state.

The workspace opens on the selected switch:

switch > Discovery

Before saving, note Configuration source for each affected value. Not set means that Sophos Fusion does not configure the setting and the switch uses its local configuration. Not set is therefore neither synonymous with Disabled nor evidence of a product default. When replacing Not set with an explicit value, you transfer control of the setting to Sophos Fusion and must know the previous local value for rollback.

To ensure safe changes, screenshots or exports of the affected tables, the time and the expected effect are also recorded. Only one logically related change is saved per test step. Update saves configuration changes; Clear only discards unsaved changes.

Part 1: Topology discovery with CDP and LLDP

CDP and LLDP are used for inventory of directly connected devices. CDP is Cisco proprietary; LLDP is the IEEE 802.1AB standard. The discovery information can reveal device names, management addresses, VLANs, platform, software level, capabilities and PoE data. The protocols are therefore only activated on ports on which this visibility is technically intended.

Configure global CDP settings

Menu path:

switch > Discovery > Settings > CDP settings

The switches accept Enabled, Disabled or, if applicable, Not set:

• Status: Turns CDP on or off globally.
• Voice VLAN advertisement: Advertises the Voice VLAN on all CDP-enabled ports that are members of this Voice VLAN.
• Mandatory TLV validation: Drops incoming CDP packets without the mandatory TLVs.
• Notify voice VLAN mismatch: Generates a syslog message when voice VLAN in the incoming frame and local configuration do not match.
• Notify VLAN mismatch: Generates a syslog message if the native VLAN is different.
• Notify duplex mismatch: Generates a syslog message if duplex information differs.

Other fields:

Safe procedure:

1. Record the existing global values and Configuration source.
2. Check which ports actually require CDP and whether the information disclosed there is acceptable.
3. Select Version to match the directly connected peers. Do not change the entire environment preemptively.
4. Only activate Voice VLAN advertisement if the voice VLAN is correctly defined and the intended ports are members of this VLAN.
5. Activate notifications about different settings and ensure that syslog is monitored.
6. Activate Mandatory TLV validation only after known neighbors with complete CDP information are visible. Otherwise, incomplete frames may be discarded and neighbors may appear to disappear.
7. Save with Update and then check the global and port effect.

Shorter intervals increase discovery-protocol traffic, but update this switch’s information on its peers more quickly. A longer local Hold time lets peers retain stale information about the switch for longer. However, the TTL advertised by each neighbor determines how long a received neighbor entry remains visible on this switch. Extreme values only make sense when they serve a measurable objective.

Configure global LLDP settings

Menu path:

switch > Discovery > Settings > LLDP settings

Transmission interval × Holdtime multiplier gives the LLDP TTL advertised by the switch. With 30 seconds and a multiplier of 4, peers may retain its LLDP information for up to 120 seconds without a new LLDP message. This local value does not determine the aging of received neighbor entries; the TTL of the respective neighbor applies. Calculate this relationship before making a change so that the expected effect on peers is clear.

Procedure:

1. Document initial values ​​and Configuration source.
2. Change Status only for the intended discovery operation.
3. Set interval, multiplier and delays within the documented ranges.
4. Save with Update.
5. After at least one complete transmission interval, check the information under Self. Then verify on a controlled peer that the LLDP message and advertised TTL arrive as expected. Assess received neighbor entries under Neighbours using their own TTL.

The LLDP settings in this area apply globally. On the other hand, under Ports only CDP-related settings are available; LLDP control per port is not described here.

Control CDP per port

Menu path:

switch > Discovery > Ports

Drop-down lists for these fields are available per port:

• CDP Status: Enable or disable CDP on this port.
• Notify VLAN mismatch: Syslog with different native VLAN.
• Notify voice VLAN mismatch: Syslog with different voice VLAN.
• Notify duplex mismatch: Syslog if duplex information differs.
• Configuration source: Origin of the port configuration.

Globally enabled CDP does not need to be enabled on every port. Include uplinks to managed network devices and approved voice ports selectively; leave untrusted access ports disabled in accordance with the security policy. On trunks, check the native VLAN and voice VLAN at both ends before treating a notification as evidence of a configuration mismatch.

Once selected, Update saves the changes. Clear is used when the unsaved selection is to be discarded.

Check your own announcements under Self

Menu path:

switch > Discovery > Self

Self shows the information that the switch advertises to its neighbors. This area is the first check after a change: it shows the local transmission state but does not confirm reception by the peer.

Device details

The CDP display contains:

• System name: Hardware name of the switch
• Capabilites: network capabilities of the switch; the interface can display this different spelling
• CDP version: CDP version used
• Platform: Manufacturer and model
• Software: Firmware version

The LLDP display contains:

• System name: Name of the switch
• System description: Hardware name
• Chassis ID subtype: Chassis ID type
• Chassis ID: Chassis ID of the switch
• Port ID subtype: Port ID type
• Supported capabilities: supported network capabilities
• Capabilities turned on: enabled network capabilities

Ports information

The table contains per port:

• Port , CDP status, Device ID, Address, VLAN, Voice VLAN and Duplex;
• Extended trust for trusting QoS markings of the neighboring device;
• CoS for untrusted ports for CoS priority on ports that are classified as untrusted;
• Power consumption , Power request ID, Power management ID and Available power for PoE;
• Neighbour as an indication of whether a neighbor is recognized on the port.

For acceptance, at least the switch name, firmware, expected device ID, VLAN/Voice VLAN and the affected port are compared. PoE fields are only useful evidence where a PoE device is connected.

Check directly connected neighbors

Menu path:

switch > Discovery > Neighbours

The tables show directly connected CDP or LLDP capable devices. They do not represent the complete topology or the routing state. In particular, no OSPF function can be derived from the neighboring tables; Detection and routing status are assessed separately.

CDP table fields

• Port: local port with the neighbor
• Device ID: Neighbor device ID
• System name: Neighbor’s name
• Self interface: local interface to the neighbor
• Version: CDP version of the neighbor
• TTL: Remaining period of validity of the neighboring information
• Neighbour interface: remote interface to the switch
• Address: Neighbor’s IP address
• Capabilites: networking capabilities; the interface can use this notation
• Software: Neighbor’s software version
• Platform: Manufacturer and model
• Self VLAN: local VLAN ID
• Voice VLAN: Voice VLAN ID
• Duplex: Neighbor duplex setting
• Extended trust: Neighbor trust in switch QoS markings
• CoS for untrusted ports: CoS priority for ports that are classified as untrusted
• Management address: Neighbor management IP address
• Power consumption , Power request ID, Power management ID, Available power: PoE negotiation and performance data

LLDP table fields

• Port: local port with the neighbor
• Chassis ID subtype and Chassis ID: Chassis ID type and value
• Port ID subtype: type of the remote port ID
• Neighbour ID: remote port ID; Interpret the value according to Port ID subtype, for example as a MAC address, interface name or locally assigned value
• Neighbour IP: Neighbor’s IP address
• System name and System description: configured name and hardware description
• Supported capabilities and Capabilities turned on: supported and enabled abilities
• TTL: remaining validity period
• Auto-negotiation: Auto-negotiation skills
• Operation type: LLDP operation type executed by the neighbor
• Max frame size: maximum frame size of the neighbor
• LAG: shows whether the remote port is a member of a Link Aggregation Group

Reliable evidence compares local Port and Self interface with the documented cabling as well as Neighbour interface or LLDP port ID with the remote station. The LLDP port ID is compared according to its Port ID subtype and not necessarily as a MAC address. An IP or management address alone is not sufficient because it may be missing, outdated or not accessible via the data path.

Part 2: ARP, MAC and NDP tables and MAC filters

Do not modify address or filter tables until the VLAN, port and owner of the address have been confirmed. Dynamic entries are observations made by the switch; static entries are administrative assignments and do not age out like dynamically learned mappings. Converting an entry to static therefore creates an ongoing operational responsibility.

Note on the Mapping column: Mapping distinguishes dynamic and static. With MAC and NDP entries, however, it is not possible to determine which protocol the switch used to learn the assignment.

Check and manage ARP table

Menu path:

switch > Discovery > ARP

The table shows:

• IP address: IPv4 address learned through ARP
• MAC address: assigned MAC address
• VLAN: associated VLAN ID or VLAN IDs
• Mapping: dynamic or static entry
• Configuration source: Origin of ARP information

Add static ARP entry

1. Check existing ARP and MAC mapping for the device.
2. Select Add.
3. Enter IP address and MAC address exactly.
4. Select the confirmed VLAN from the drop-down list.
5. Save with Save.
6. Check the new entry, the accessibility and the return path in the same VLAN.

No additional format or value ranges are specified for these input fields. The validation of the current interface and the local address plan are crucial. If the interface rejects a value, alternative notations or VLANs are not attempted.

Delete entries or make them static

• To delete, mark the intended entries and select Delete.
• For a permanent assignment, highlight a confirmed dynamic entry and select Move to static.

Before Move to static, it is excluded that the address belongs to DHCP, failover, cluster, VRRP or a mobile device. According to the interface, static MAC addresses remain in the MAC table until they are manually removed. The change plan must therefore also take into account the MAC table and the later dismantling.

ARP statistics opens detailed statistics on ARP traffic. They help distinguish between missing requests, non-responses and incorrect static mapping.

Global ARP settings

About ARP global settings are available:

• Maximum number of retries: maximum number of attempts that the switch will make to confirm the presence of a device after a failed ARP request;
• Timeout (seconds): How long ARP entries are retained before removal.

Acceptable ranges and default values ​​are not specified in this range. Therefore, the initial values ​​displayed are documented, only values ​​that the interface validates are accepted, and changes are saved with Update. The number of attempts and the timeout are changed separately so that their effect remains individually measurable.

Check and manage MAC address table

Menu path:

switch > Discovery > MAC

The table shows:

• MAC address: known MAC address
• Port: Port through which the device is reached
• VLAN: associated VLAN ID or VLAN IDs
• Mapping: dynamic or static entry
• Configuration source: Origin of MAC information

The switch sends data to a known MAC address via the assigned port. An incorrect static port can therefore misdirect or completely interrupt data traffic.

Add static MAC entry

1. Verify current dynamic entry, VLAN and physical port.
2. For LAGs or uplinks, check whether the UI expects a logical or physical port; do not save unless this is unambiguous.
3. Select Add.
4. Enter MAC address.
5. Select VLAN from the drop-down list.
6. Select the confirmed Port.
7. Save with Save.
8. Then check traffic in both directions and verify the table mapping.

Further actions:

• Delete: Remove marked MAC entries.
• Move to static: convert confirmed dynamic entries into static entries.
• Move to filters: Move selected MAC address to the MAC filter table.

Move to filters is not a harmless label or a global blacklist. Before taking this action, the VLAN effect described in the MAC filtering section must be approved.

MAC aging time is set via MAC global settings and saved with Update. Unit, range and standard value are taken directly from the current input mask. A value that is too short can cause frequent relearning and unnecessary flooding of unknown destination addresses; a value that is too long will retain outdated port mappings for longer. After a change, learning behavior and port changes are specifically observed.

Check and manage NDP table for IPv6

Menu path:

switch > Discovery > Neighbour discovery

The NDP table shows:

• IP address: IPv6 address learned by NDP
• MAC address: assigned MAC address
• VLAN: associated VLAN ID or VLAN IDs
• Mapping: dynamic or static entry
• Configuration source: Origin of NDP information

Create static NDP entry:

1. Confirm IPv6 address, MAC address and VLAN on the end device or router.
2. Select Add.
3. Enter IP address and MAC address.
4. Select VLAN from the drop-down list.
5. Select Save.
6. Check IPv6 reachability, neighbor resolution and table value.

With Move to static a selected dynamic entry becomes static. After the move, both the NDP and MAC tables are checked because static MAC addresses can remain permanently in the MAC table. There is no separate Delete process described here for NDP. If the current interface does not offer a clear deletion action with confirmation, the entry will not be tentatively changed; Instead, Sophos Support should be called in.

Securely manage MAC filter entries

Menu path:

switch > Discovery > MAC filtering

The table shows:

• MAC address ;
• the associated VLAN;
• Configuration source as the origin of the filter information.

One entry serves as a VLAN allow list: the MAC address is only allowed to connect to the specified VLANs and is blocked in all other VLANs. MAC filtering is therefore not a blacklist. If a required VLAN is missing, the device can immediately lose access to this network.

Security limitation: A MAC address can be faked. The filter only implements an additional VLAN admission for the specified address; it does not authenticate device or user and does not replace port-based access control such as 802.1X or other appropriate NAC measures.

Add filter entry

1. Capture all VLANs that the device actually needs, including voice, management, or transition VLANs.
2. Document current MAC, ARP and, if necessary, NDP entries.
3. Ensure that neither switch management nor the only return path is affected.
4. Select Add.
5. Enter MAC address.
6. Select the approved VLAN from the drop-down list.
7. Save with Save.
8. Test permitted VLAN positive and at least one prohibited VLAN negative.

If the same MAC address requires several VLANs, a check is made in advance to see how the current table represents this assignment. As long as the interface does not clearly show the effect of additional entries, no further entries will be created.

To remove, highlight the intended MAC filter entry and select Delete. It is then checked whether the normal dynamic MAC learning function and the data traffic work as expected again. Deleting a filter entry is not the same as deleting the MAC address from the MAC table.

Validation after changes

Topology discovery

1. Reread values ​​stored under Settings and Configuration source.
2. Under Ports, check the CDP status and the three mismatch switches of the changed ports.
3. Under Self, check whether your own device, port, VLAN, voice VLAN, duplex and PoE information is correct.
4. Under Neighbours compare local port, remote interface or port ID, chassis/device ID and TTL.
5. Independently check on the remote site whether the Sophos switch is visible with the expected data.
6. Check the expected syslog messages for VLAN, voice VLAN or duplex mismatches; a negative test must not disrupt any production port.
7. For an aging test, stop the CDP or LLDP messages on a controlled remote site or disconnect the test link. As long as the remote station continues sending messages, the expected aging does not begin.
8. Under Neighbours, observe whether the TTL of the remote station displayed there expires and its entry disappears.
9. Reactivate the messages or the connection and check whether the neighbor is recognized again.
10. Validate the locally set CDP-Hold time or LLDP-TTL separately on the remote station.

Address tables and filters

1. Reload the affected entry and check Mapping and Configuration source.
2. ARP: Compare IPv4, MAC and VLAN mapping in ARP and MAC table.
3. MAC: Compare port and VLAN with the real connection; When a port change is planned, no outdated static entry may be left behind.
4. NDP: Check IPv6, MAC and VLAN mapping as well as real IPv6 reachability.
5. MAC filtering: Test access positively in a permitted VLAN and negatively in a non-permitted VLAN.
6. Check new and existing connections in both directions. A single ping is not complete proof.
7. After a planned restart of the device or a short link interruption, check tables and data traffic again.

A change is only considered successful if the configuration display and the actual data path match. If the table looks correct but traffic fails, restore the documented initial state.

Troubleshoot by symptom

No CDP device appears under Neighbors

Check port global Status, CDP Status and Configuration source. Then check the cabling, connection, CDP support and CDP status of the remote station. When Mandatory TLV validation is active, a packet without mandatory TLVs can be dropped; The switch is only reset to the documented previous state in the maintenance window and is not permanently deactivated as a quick fix.

LLDP neighbor missing or disappearing too early

Check LLDP-Status and LLDP status of the remote station. For outgoing information, compare the local values ​​Transmission interval and Holdtime multiplier with the TTL observed on the remote site. However, for a neighbor entry received on the Sophos Switch, the TTL specified by this neighbor is decisive. The check only takes place after a complete transmission interval. Reinitialization delay and Transmit delay are not changed at the same time to hide a cabling or remote station problem.

Incorrect VLAN, Voice VLAN or Duplex warning

Compare local port, native VLAN, voice VLAN and duplex on both ends of the connection. For trunks, also check the port identity and the VLAN assignment. The notification is not simply switched off until it has been ruled out that there are actually different configurations.

Self is correct, but the remote site sees different data

Check whether the expected physical port is being considered, whether CDP or LLDP is active on the remote station and whether old information only expires after its TTL. Self only shows the content of the message sent locally. This does not rule out an error in the packet path, LAG or port.

ARP entry shows incorrect MAC address

First check for a duplicate IPv4 address, incorrect VLAN, an HA/cluster change, or an outdated static entry. Compare ARP statistics, the MAC table and the endpoint over the same period. Do not add a new static entry until the address conflict has been resolved.

MAC address appears on wrong port

Check whether the device has been replugged, is behind a telephone, access point, hypervisor, uplink or LAG or whether a static entry records the old port. Do not shorten MAC aging time too quickly. If there are frequent changes, first clarify the loop, LAG state and real topology.

IPv6 does not work despite visible NDP entry

Check IPv6 address, prefix, VLAN, MAC address and remote station. Then determine whether the entry is static and out of date. A visible NDP entry does not prove correct routing or a complete IPv6 data path. ARP settings are not the appropriate lever for this IPv6 problem.

Device can no longer be reached after Move to filters

In MAC filtering, check which VLAN authorization was actually saved. Reset the filter entry to the documented previous state or remove it with Delete, then check the MAC learning function and data traffic again. Additional static ARP, MAC or NDP entries do not help here as they do not remove the VLAN filtering effect.

Change doesn’t seem to be applied

Check whether Update or Save was executed, whether the page still shows unsaved values ​​and which origin Configuration source reports. With Not set, the local configuration remains decisive. A local configuration and a Sophos Fusion set configuration must not be overwritten alternately as a fix; first the desired control point is set.

Rollback and completion

During dismantling, the documented initial state is restored:

1. Remove the last changed static or filter entry or restore the previous entry.
2. Reset global CDP/LLDP values ​​and port values ​​to the noted values.
3. If Not set was previously valid, only return to Not set if the local initial value is known and continues to be correct.
4. Complete with Update, Save or the clearly offered deletion action.
5. Recheck Self, Neighbours, ARP, MAC and NDP table and real data path.
6. Document syslog, time, affected addresses, VLANs and the result in the change log.

Final check:

• Topology discovery and address tables were checked as separate tasks.
• Configuration source and all initial values ​​are documented.
• CDP/LLDP intervals and hold times are within the permissible ranges.
• Your own announcements and neighboring views match the cabling.
• Static IP/MAC/VLAN/port assignments are technically confirmed.
• Mapping was not interpreted as unreliable protocol evidence.
• MAC filters were treated as a bypassable, additional VLAN allow list, rather than a block list or device authentication.
• Positive, negative and return tests were successful.
• No unintentional static entries or filters were left behind.