Einleitung

Der Zustand err-disable ist ein Schutzmechanismus von Cisco-Switches. Erkennt der Switch ein kritisches Problem auf einem Port, wird dieser in den Status err-disabled gesetzt und automatisch administrativ deaktiviert. Der Port verarbeitet ab diesem Zustand keinen Traffic mehr. Im Gegensatz zu einem normalen shutdown wurde der Port dabei nicht manuell, sondern durch eine interne Schutzfunktion deaktiviert.

Für Außenstehende wirkt das oft zunächst wie ein kaputter Port, tatsächlich handelt es sich aber im Regelfall um eine bewusst ausgelöste Sicherheits- oder Schutzfunktion. Häufig tritt dann der Fall ein, dass mehrere Ports am Switch getestet werden und somit eine große Zahl an Ports unabsichtlich gesperrt werden.

Typische Symptome

• Geräte verlieren plötzlich die Verbindung
• Der Link scheint „down“
• LEDs verhalten sich ungewöhnlich
• Der Port erscheint im Status err-disabled

Switch# show interface status

Port       Name        Status         Vlan
Gi1/0/1                err-disabled   10

Ziel und Zweck

Der err-disabled-Status ist also in vielen Fällen ein Schutzmechanismus für das gesamte Netzwerk.

• Netzwerkschleifen verhindern
• Broadcast-Stürme verhindern
• Fehlkonfigurationen erkennen
• Port-Security-Verstöße
• Hardwareprobleme isolieren

Ursachen

Diagnose

Prüfung der Err-Disabled-Konfiguration

show errdisable detect zeigt die aktuellen Einstellungen der Errdisable-Erkennung sowie, falls sich Ports derzeit im err-disabled-State befinden, den jeweiligen Grund für die automatische Deaktivierung des Ports an.

Switch# show errdisable detect
ErrDisable Reason             Detection Mode
-----------------             --------- ----
arp-inspection                Enabled  port
bpduguard                     Enabled  port
channel-misconfig             Enabled  port
community-limit               Enabled  port
dhcp-rate-limit               Enabled  port
dtp-flap                      Enabled  port
evpn-mh-core-isolation        Enabled  port
gbic-invalid                  Enabled  port
iif-reg-failure               Enabled  port
inline-power                  Enabled  port
invalid-policy                Enabled  port
l2ptguard                     Enabled  port
link-flap                     Enabled  port
link-monitor-failure          Enabled  port
loopback                      Enabled  port
loopdetect                    Enabled  port
lsgroup                       Enabled  port
oam-remote-failure            Enabled  port
mac-limit                     Enabled  port
pagp-flap                     Enabled  port
port-mode-failure             Enabled  port
pppoe-ia-rate-limit           Enabled  port
psecure-violation             Enabled  port/vlan
security-violation            Enabled  port
sfp-config-mismatch           Enabled  port
sgacl_limitation:enforcem     Enabled  port
sgacl_limitation:multiple     Enabled  port
storm-control                 Enabled  port
udld                          Enabled  port
psp                           Enabled  port
dual-active-recovery          Enabled  port
evc-lite input mapping fa     Enabled  port
vsl-and-non-vsl-port-pair     Enabled  port
fasthello-and-non-fasthel     Enabled  port
mvrp                          Enabled  port
mrp-miscabling                Enabled  port

show errdisable recovery zeigt den Zeitraum an, nach dem Ports bei bestimmten Errdisable-Ursachen automatisch wieder aktiviert werden. Außerdem werden die konfigurierten Errdisable-Recovery-Mechanismen angezeigt.

Switch# show errdisable recovery

ErrDisable Reason              Timer Status
-----------------              --------------
arp-inspection                 Disabled
bpduguard                      Disabled
channel-misconfig              Disabled
dhcp-rate-limit                Disabled
dtp-flap                       Disabled
evpn-mh-core-isolation         Disabled
gbic-invalid                   Disabled
inline-power                   Disabled
l2ptguard                      Disabled
link-flap                      Enabled
mac-limit                      Disabled
link-monitor-failure           Disabled
loopback                       Disabled
loopdetect                     Disabled
oam-remote-failure             Disabled
pagp-flap                      Disabled
port-mode-failure              Disabled
pppoe-ia-rate-limit            Disabled
psecure-violation              Disabled
security-violation             Disabled
sfp-config-mismatch            Disabled
storm-control                  Enabled
udld                           Enabled
psp                            Disabled
dual-active-recovery           Disabled
evc-lite input mapping fa      Disabled
mrp-miscabling                 Disabled

Timer interval: 900 seconds

Interfaces that will be enabled at the next timeout:

Status des Ports prüfen

Zunächst sollte geprüft werden, in welchem Zustand sich die Ports befinden.
Mit folgendem Befehl erhält man eine Übersicht aller Ports und deren aktuellen Status:

Switch# show interface status

Oder man lässt sich einen Port im Detail anzeigen.

Switch# show interface Gi1/0/1

Dabei lassen sich unter anderem folgende Zustände erkennen:

• err-disabled
• connected
• notconnect
• disabled

Err-disabled Ports gezielt anzeigen

Um ausschließlich Ports im err-disabled-Status inklusive Ursache anzuzeigen, kann folgender Befehl verwendet werden:

Switch# show interfaces status err-disabled

Port      Name        Status         Reason                Vlans
Gi1/0/1   ERRORPORT   err-disabled   psecure-violation     10

Event- und System-Logs prüfen

Für die eigentliche Fehleranalyse sind die System- und Event-Logs besonders wichtig. Dort protokolliert der Switch in der Regel sehr genau, warum ein Port in den err-disabled-State versetzt wurde.

Die Logs können mit folgendem Befehl angezeigt werden:

Switch# show logging

Die Logmeldungen liefern meist bereits den entscheidenden Hinweis auf die eigentliche Ursache des Problems und sollten daher immer als einer der ersten Schritte geprüft werden.

Entstörung

Fehlerursache beheben

Vor einem manuellen oder automatischen Recovery sollte immer zuerst die eigentliche Ursache des err-disabled-Status behoben werden, da der Fehler ansonsten unmittelbar erneut auftreten kann.

Ports manuell reaktivieren

Um einen Port aus dem Fehlerstatus zu befreien, muss der betroffene Port einmal deaktiviert und anschließend wieder aktiviert werden.

Switch# configure terminal

Switch(config)# interface Gi1/0/1
shutdown
no shutdown

Ports automatisch reaktivieren

Die folgenden Befehle zeigen, wie die automatische Entstörung konfiguriert wird.

Zunächst lassen wir uns die möglichen Optionen bzw. Ursachen anzeigen, welche wir konfigurieren können.

Switch# configure terminal
Switch(config)# errdisable recovery cause ?
  all                   Enable timer to recover from all causes
  arp-inspection        Enable timer to recover from arp inspection error
                        disable state
  bpduguard             Enable timer to recover from BPDU Guard error disable
                        state
  channel-misconfig     Enable timer to recover from channel misconfig disable
                        state
  dhcp-rate-limit       Enable timer to recover from dhcp-rate-limit error
                        disable state
  dtp-flap              Enable timer to recover from dtp-flap error disable
                        state
  gbic-invalid          Enable timer to recover from invalid GBIC error disable
                        state
  l2ptguard             Enable timer to recover from l2protocol-tunnel error
                        disable state
  link-flap             Enable timer to recover from link-flap error disable
                        state
  link-monitor-failure  Enable timer to recover from link monitoring failure
  loopback              Enable timer to recover from loopback disable state
  mac-limit             Enable timer to recover from mac limit disable state
  oam-remote-failure    Enable timer to recover from remote failure detected by
                        OAM
  pagp-flap             Enable timer to recover from pagp-flap error disable
                        state
  psecure-violation     Enable timer to recover from psecure violation disable
                        state
  security-violation    Enable timer to recover from 802.1x violation disable
                        state
  storm-control         Enable timer to recover from storm-control error
                        disable state
  udld                  Enable timer to recover from udld error disable state
  unicast-flood         Enable timer to recover from unicast flood disable
                        state
  vmps                  Enable timer to recover from vmps shutdown error
                        disable state

Danach definieren wir diese dann entweder einzeln oder allgemeingültig über den all-Parameter.

Switch(config)# errdisable recovery cause bpduguard

Über die zuvor genannten show-Befehle lässt sich die nun gültige Konfiguration anzeigen.

Quellen

• cisco.com – Wiederherstellung aus dem errdisable-Portstatus auf Cisco IOS-Plattformen
• firewall.cx – Cisco Catalyst Err-disabled Port State, Enable & Disable Autorecovery Feature

Der Beitrag Cisco – Err-Disabled-Status erschien zuerst auf Maximilian Krieg.

Zur Kontextualisierung, die Infrastruktur besteht aus Cisco Email Security Appliances (ESAs) und Cisco Security Management Appliances (SMAs). Die ESA ist eine virtuelle All-in-One-Appliance, die Schutz vor Spam, Malware, Viren und anderen ein- und ausgehenden E-Mail-Bedrohungen und Belästigungen bietet . Die SMA hingegen wird zur Zentralisierung von Diensten von ESAs verwendet. Die zentralisierten Dienste sind: Externe Spam-Quarantäne. Zentralisierte Richtlinien-, Viren- und Ausbruchsquarantänen.

Die Störung betrifft daher nach vorheriger Definition somit die SMA und nicht die ESA. Da der Kunde einen Fehler auf den vorgeschalteten Systemen ausschließt, beginnen wir mit der Untersuchung auf der aktiven SMA-Einheit. Bei der ersten Prüfung stellt sich bereits heraus, dass ein System-Backup ausgeführt wird, wodurch Dienste eingeschränkt oder pausiert sind. Dies ist ein normales und erwartetes Verhalten; jedoch läuft das Backup üblicherweise täglich, und dieser Fehler tritt zum ersten Mal auf.

Wir überprüfen daher die Backup-Einstellungen und -Status auf der Kommandozeile der SMA, indem wir in die Backup-Konfiguration navigieren. Da die SMA die gleichen Befehle im Folgenden immer wieder präsentieren wird, schneide ich diesen Auszug aus den folgenden Ausgaben heraus. Die relevanten Befehle sind hier VIEW, VERIFY, SCHEDULE, CANCEL, STATUS und SETUP.

SMA01> backupconfig

Choose the operation you want to perform:
- VIEW - View scheduled backups
- VERIFY - Verify if backup can be scheduled to a remote machine
- SCHEDULE - Schedule backup to an appliance
- CANCEL - Cancel a scheduled backup
- STATUS - Show the status of a backup in progress.
- SETUP - Configure backup parameters.

Zunächst überprüfen wir die laufenden Backup-Jobs und stellen fest, dass die Backups täglich um 2 Uhr von der aktiven SMA01 zur passiven SMA02 durchgeführt werden. Wir verifizieren ebenfalls, dass ein Backup-Job noch aktiv ist, wie in der AdminGUI angezeigt wird.

[]> view

Scheduled Backups:
# Name                 IP                  Schedule           Features
= ==================== =================== ================== ==================
1 SMA01_to_SMA02       To 10.10.10.2       In Progress        Email Tracking
                                                              Web Tracking
                                                              Spam Quarantine
                                                              Reporting
                                                              Policy Quarantine
                                                              Safelist/Blocklist
2 SMA01_to_SMA02       To 10.10.10.2       every day at       Email Tracking
                                           02:00              Web Tracking
                                                              Spam Quarantine
                                                              Reporting
                                                              Policy Quarantine
                                                              Safelist/Blocklist

Aus diesem Grund überprüfen wir den Status des laufenden Backup-Jobs. Obwohl das Backup wie geplant um 2 Uhr gestartet ist, läuft es nun bereits seit über zwei Stunden. Normalerweise sind die Backups innerhalb weniger Minuten abgeschlossen. Um sicherzustellen, dass alles korrekt verläuft, warten wir etwa 10 Minuten. Bei einer Datentransferrate von 14 MB/s sollte eine messbare Veränderung im übertragenen Datenvolumen von 81 GB auftreten.

[]> STATUS

Backup Name: SMA01_to_SMA02
Begin Time: 29 Dec 2023 02:00    Time elapsed: 2hr 32min
Transfer Rate: 14MB/s
Phase: Two
Data Transferred: 81GB (44%)
        Web Tracking: Completed
        Reporting: Completed
        Email Tracking: Completed
        Policy Quarantine: Completed
        Spam Quarantine: In Progress  Transferred: 0GB (0%)
Phase: One
Data Transferred: 0GB
        Web Tracking: Completed
        Reporting: Completed
        Email Tracking: Completed
        Policy Quarantine: Completed
        Spam Quarantine: Completed
        Safelist/Blocklist: Completed

Bei der nächsten Kontrolle ergibt sich, dass bei angeblich anhaltenden 14MB/s keine Veränderung am transferierten Datenvolumen stattgefunden hat. Es ist wahrscheinlich, dass das Backup hängengeblieben ist und nicht fortgesetzt wird.

[]> STATUS

Backup Name: SMA01_to_SMA02
Begin Time: 29 Dec 2023 02:00    Time elapsed: 2hr 45min
Transfer Rate: 14MB/s
Phase: Two
Data Transferred: 81GB (44%)
        Web Tracking: Completed
        Reporting: Completed
        Email Tracking: Completed
        Policy Quarantine: Completed
        Spam Quarantine: In Progress  Transferred: 0GB (0%)
Phase: One
Data Transferred: 0GB
        Web Tracking: Completed
        Reporting: Completed
        Email Tracking: Completed
        Policy Quarantine: Completed
        Spam Quarantine: Completed
        Safelist/Blocklist: Completed

Wir brechen das Backup manuell ab, damit der Wartungsmodus beendet wird und die SMA wieder ihre normale Operation aufnimmt.

[]> CANCEL

Scheduled Backups:
# Name                 IP                  Schedule           Features
= ==================== =================== ================== ====================
1 SMA01_to_SMA02       To 10.10.10.2       In Progress        Email Tracking
                                                              Web Tracking
                                                              Spam Quarantine
                                                              Reporting
                                                              Policy Quarantine
                                                              Safelist/Blocklist
2 SMA01_to_SMA02       To 10.10.10.2       every day at       Email Tracking
                                           02:00              Web Tracking
                                                              Spam Quarantine
                                                              Reporting
                                                              Policy Quarantine
                                                              Safelist/Blocklist

Select the name or number of the backup
[]> 1

Canceling a backup in progress is not recommended. The data will be incomplete
and may not be usable until a subsequent backup is completed, especially if you
receive an error. If you must cancel a backup in progress, be sure to run a
complete backup as soon as possible to ensure that you always have a usable
current backup.

Do you really want to cancel the backup? [N]> Y

Backup "SMA01_to_SMA02" has been cancelled.

Wir lassen uns nochmals den Status anzeigen, um den korrekten Abbruch zu verifizieren.

[]> STATUS

No backup in progress

Auf der AdminGUI ist die Fehlermeldung nun verschwunden und der Zugriff auf die Spam-Quarantäne-Seite ist wieder erfolgreich. Um das versäumte Backup nachzuholen, planen wir ein einmaliges Backup und führen dieses durch.

[]> SCHEDULE

Enter the IP address of a machine to transfer data to.
[]> 10.10.10.2

Enter a name to identify the remote appliance
[]> SMA02

Please enter username and passphrase:
Username:
[]> admin

Passphrase:
[]>
Would you like to backup all the data, including Email Tracking, Web Tracking,
Spam Quarantine, Reporting, Policy Quarantine, Safelist/Blocklist ? [Y]> Y

Verifying target machine for version compatibility and disk space...
1. Set up a repeating backup schedule
2. Schedule a single backup
3. Start a single backup now
[1]> 3

Please enter a name for this backup job:
[]> Test-Backup

Backup "Test-Backup" has been initiated and will begin in a few seconds.

Das temporäre Backup ist, wie erwartet, innerhalb weniger Minuten durchgelaufen. Als abschließende Maßnahme überprüfen wir die Schedules, um sicherzustellen, dass die Backups auch am Folgetag ordnungsgemäß durchgeführt werden, sowie den Zugriff auf die Spam-Quarantäne-Seite.

Quellen

• Ansetzen einer Sicherung eines aktiven Datensets von einer primären SMA zu einer sekundären SMA – Cisco

Der Beitrag Cisco SMA – Spam-Quarantäne-Seite ausgefallen erschien zuerst auf Maximilian Krieg.

Symptom

Ein Desktop-PC ist physisch direkt mit dem Management-Interface eines Layer-3-Switches verbunden. Der Ping von dem PC zum Switch auf die IP-Adresse 192.168.1.1 funktioniert problemlos. Ein Ping vom Switch zum PC auf die IP-Adresse 192.168.1.3 hingegen nicht. Dieses Problem bleibt auch bestehen, wenn die Firewall des PCs deaktiviert wird. Mit Hilfe eines zweiten Switches kann verifiziert werden, dass der PC generell auf einen Ping anspricht.

Mit diesen Informationen übernehme ich das Problem. Ich überprüfe alle getätigten Einstellungen und rekonstruiere dann das beschriebene Verhalten. Das Problem wird vermutlich auf dem Switch und in seiner Konfiguration zu suchen sein. Ich pinge zunächst selbst den PC und versuche dann die eigene Adresse zu pingen.

switch# ping 192.168.1.3
PING 192.168.1.3 (192.168.1.3): 56 data bytes
ping: sendto 192.168.1.3 64 chars, No route to host
Request 0 timed out
ping: sendto 192.168.1.3 64 chars, No route to host
Request 1 timed out

(...)

--- 192.168.1.3 ping statistics ---
5 packets transmitted, 0 packets received, 100.00% packet loss

switch# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
ping: sendto 192.168.1.1 64 chars, No route to host
Request 0 timed out
ping: sendto 192.168.1.1 64 chars, No route to host
Request 1 timed out

(...)

--- 192.168.1.1 ping statistics ---
5 packets transmitted, 0 packets received, 100.00% packet loss

Letzteres Resultat habe ich nicht erwartet. Wieso sollte sich der Layer-3-Switch nicht auf seinem eigenen Interface pingen können? Es erhärtet meinen Verdacht, dass bei der Konfiguration etwas schiefgegangen ist.

Problem

Zunächst hole ich mir Informationen über die Netzwerkschnittstellen des Layer-3-Switches ein. Mich interessiert, ob das Management-Interface überhaupt aktiv gelistet wird. Ich weiß natürlich, dass es aktiv sein muss, damit der Ping vom PC aus überhaupt funktioniert, aber irgendwo muss ich die Fehlersuche beginnen.

switch# show interface brief

------------------------------------------------------------------------------------------
Ethernet 	VLAN	Type	Mode	Status	Reason			Speed	Port Ch
Interface#	
------------------------------------------------------------------------------------------
Eth1/1		1	eth	access	down	SFP not inserted	10G(D)	--

(...)

Eth2/6		1	eth	access	down	SFP not inserted	40G(D)	--

------------------------------------------------------------------------------------------
Port	VRF	Status	IP Address					Speed	MTU
------------------------------------------------------------------------------------------
mgmt0	--	up	192.168.1.1					1000	1500

Offensichtlich ist das Interface aktiv und auch mit der korrekten IP-Adresse versehen. Auf den ersten Blick scheint es doch nicht an der aktiven Konfiguration zu liegen. Um dies zu verifizieren, lasse ich mir die aktuelle Konfiguration anzeigen

switch# show running-config

(...)

vlan 1
vrf context management

(...)

interface Ethernet1/1

(...)

interface mgmt0
  vrf member management
  ip address 192.168.1.1/24

line console
line vty

boot kickstart bootflash:/n6000-uk9-kickstart.7.0.2.N1.1.bin
boot system bootflash:/n6000-uk9.7.0.2.N1.1.bin

poap transit

Ich bin nun mehrmals über die Abkürzung VRF gestolpert, die mir bisher auch nicht bekannt ist. Eine kleine Recherche hierzu ergibt auch schon des Rätsels Lösung.

Lösungsstrategie

Die Abkürzung VRF steht für Virtual Routing and Forwarding. Eine VRF-Instanz bezeichnet eine im Cisco IOS und Routing Hardware anderer Hersteller implementierte Funktion, die einen neuen virtuellen Router auf einem physischen Router anlegt. Durch das Anlegen eines virtuellen Routers entsteht ein komplett neues Netz, d. h. in der VRF-Instanz 1, 2, 3, …, n kann jedes mal der komplette Adressraum vergeben werden und jedes ausgehende Interface einer jeder Instanz mit der gleichen IP-Adresse vergeben werden, obwohl für die angeschlossenen Hosts nur die Hosts derselben Instanz sichtbar sind. Eine Kommunikation zwischen Instanzen ist ohne internes, explizites Routing nicht möglich.Wikipedia

Ein genauer Blick in die Hilfe zum ping-Befehl zeigt mir, dass man als optionalen Parameter auch die VRF-Instanz angeben kann.

switch# ping -help
usage: ping {<host> | multicast <group>} [count <count>]
        [packet-size <size>] [vrf <vrf>] [interval <interval] [df-bit]

Ich passe meine Eingabe an und ergänze diese um den den Parameter VRF-Context.

switch# ping
Vrf context to use [default] :management
Target IP address or Hostname: 192.168.1.1
Repeat count [5] : 5
Packet-size [56] :
Timeout in seconds [2] :
Sending interval in seconds [0] :
Extended commands [no] :
Sweep range of sizes [no] :
Sending 5, 56-bytes ICMP Echos to 192.168.1.1
Timeout is 2 seconds, data pattern is 0xABCD

64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=0.298 ms

(...)

--- 192.168.1.1 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.156/0.195/0.298 ms

switch# ping
Vrf context to use [default] :management
Target IP address or Hostname: 192.168.1.3
Repeat count [5] :
Packet-size [56] :
Timeout in seconds [2] :
Sending interval in seconds [0] :
Extended commands [no] :
Sweep range of sizes [no] :
Sending 5, 56-bytes ICMP Echos to 192.168.1.3
Timeout is 2 seconds, data pattern is 0xABCD

64 bytes from 192.168.1.3: icmp_seq=0 ttl=127 time=0.659 ms

(...)

Sowohl der Ping auf die lokale und die entfernte Schnittstellenadresse funktioniert. Es wurde einfach vergessen anzugeben von welcher Instanz der Ping abgesetzt werden soll. Die Kurzform für diesen Befehl wäre ping 192.168.1.3 vrf management.

Der Beitrag Layer-3-Switch kann keinen Ping absetzen erschien zuerst auf Maximilian Krieg.