[Check_mk (deutsch)] Betrifft Rule: Network interfaces and switch ports - OutDiscards und Xmit-Err

Archive checkmk-de
1

Hallo,

Wir setzen seit ca. einem 3/4 Jahr Check_MK v1.4.0p34 ein.
Mein erster Beitrag für die Mailingliste ist gleich mal eine Frage.
Folgender Aufbau:
Access-Switch Modell WS-C3560CG-8PC-S an dem Endanwender via GigabitEthernet angeschlossen sind.
Dieser Access-Switch wiederum hängt an einem Distribution-Switchstack 3x WS-C3850-48U-S mit einem GigabitEthernet-Port.
Der Distribution-Switchstack hängt mit zweimal TenGigabitEthernet am Core-Switch.
Abfrage-Intervall = 5 minütllich
Jetzt kommt es am Distribution-Switch an dem die Access-Switche hängen immer wieder zu solchen Meldung:
Output of check plugin: CRIT - [GigabitEthernet1/0/47](up) MAC: xx:xx:xx:xx:xx:xx, 1 Gbit/s, in: 17.8 Kbit/s(0.0%), out: 300.3 Kbit/s(0.0%), out-errors: 13.63%CRIT >= 10.0%

sh interfaces counters errors
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
...
Gi1/0/47 0 0 224594741 0 0 224594741
...
sh int gi 1/0/47
GigabitEthernet1/0/47 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet, address is f8a5.c539.33af (bia f8a5.c539.33af)
  Description: xxxxxxxxx
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:05, output never, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 224594741
  Queueing strategy: Class-based queueing
  Output queue: 0/40 (size/max)
  5 minute input rate 6000 bits/sec, 6 packets/sec
  5 minute output rate 237000 bits/sec, 204 packets/sec
     187707304 packets input, 40104455250 bytes, 0 no buffer
     Received 16828979 broadcasts (9864521 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 9864521 multicast, 0 pause input
     0 input packets with dribble condition detected
     4376058644 packets output, 604767426947 bytes, 0 underruns
     224594741 output errors, 0 collisions, 1 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out

Meinem Verständnis nach sind, wenn OutDiscards und Xmit-Err identisch sind, Queue-Drops des senden Switches, in meinem Fall des Distribution-Switches wobei ich mir das
bei diesem Durchsatz nur schwer vorstellen kann.

Die Werte des dazugehörigen Service Graphs
Errors:
      Minimum Maximum Average Last
Output Discards 0/s 155.79/s 12.2/s 0/s
Output Errors 0/s 155.79/s 12.2/s 0/s
Input Discards 0/s 0/s 0/s 0/s
Input Errors 0/s 0/s 0/s 0/s

Wie habt ihr die Rule konfiguriert um solche Mini-Bursts zu unterdrücken?
Bin für alle Tipps und Hinweise dankbar.

Danke im Voraus.
Basti

2

Hallo Bastian,

meine Frage wäre warum du diese Meldungen unterdrücken willst? Oder sollen diese einfach nur keine Benachrichtigung erzeugen?

Für den Punkt keine Benachrichtigung würde es ja reichen den Parameter “Maximum number of check attempts for service” auf einen höheren Wert zu setzen.

Damit wird der Hard State für die Benachrichtigung hinausgezögert und der Port hat etwas Zeit wieder “normale” Werte zu liefern.

Interessant würde ich es hier eher finden wie dieses Problem aussieht wenn man das Abfrageintervall auf dem Default Wert von einer Minute lässt.

Gibt es dann nur eine Minute lang einen richtig großen Spike von Out-Discards oder verteilt sich das dann auch auf mehrere Minuten?

Gruß

Andreas

···

Brachner, Bastian Bastian.Brachner@brose.com schrieb am Do., 6. Sep. 2018 um 18:42 Uhr:

Hallo,

Wir setzen seit ca. einem 3/4 Jahr Check_MK v1.4.0p34 ein.

Mein erster Beitrag für die Mailingliste ist gleich mal eine Frage.

Folgender Aufbau:

Access-Switch Modell WS-C3560CG-8PC-S an dem Endanwender via GigabitEthernet angeschlossen sind.

Dieser Access-Switch wiederum hängt an einem Distribution-Switchstack 3x WS-C3850-48U-S mit einem GigabitEthernet-Port.

Der Distribution-Switchstack hängt mit zweimal TenGigabitEthernet am Core-Switch.

Abfrage-Intervall = 5 minütllich

Jetzt kommt es am Distribution-Switch an dem die Access-Switche hängen immer wieder zu solchen Meldung:

Output of check plugin: CRIT - GigabitEthernet1/0/47 MAC: xx:xx:xx:xx:xx:xx, 1 Gbit/s, in: 17.8 Kbit/s(0.0%), out: 300.3 Kbit/s(0.0%), out-errors: 13.63%CRIT >= 10.0%

sh interfaces counters errors

Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards

…

Gi1/0/47 0 0 224594741 0 0 224594741

…

sh int gi 1/0/47

GigabitEthernet1/0/47 is up, line protocol is up (connected)

Hardware is Gigabit Ethernet, address is f8a5.c539.33af (bia f8a5.c539.33af)

Description: xxxxxxxxx

MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,

 reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX

input flow-control is off, output flow-control is unsupported

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:05, output never, output hang never

Last clearing of “show interface” counters never

Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 224594741

Queueing strategy: Class-based queueing

Output queue: 0/40 (size/max)

5 minute input rate 6000 bits/sec, 6 packets/sec

5 minute output rate 237000 bits/sec, 204 packets/sec

 187707304 packets input, 40104455250 bytes, 0 no buffer

 Received 16828979 broadcasts (9864521 multicasts)

 0 runts, 0 giants, 0 throttles

 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

 0 watchdog, 9864521 multicast, 0 pause input

 0 input packets with dribble condition detected

 4376058644 packets output, 604767426947 bytes, 0 underruns

 224594741 output errors, 0 collisions, 1 interface resets

 0 unknown protocol drops

 0 babbles, 0 late collision, 0 deferred

 0 lost carrier, 0 no carrier, 0 pause output

 0 output buffer failures, 0 output buffers swapped out

Meinem Verständnis nach sind, wenn OutDiscards und Xmit-Err identisch sind, Queue-Drops des senden Switches, in meinem Fall des Distribution-Switches wobei ich mir das

bei diesem Durchsatz nur schwer vorstellen kann.

Die Werte des dazugehörigen Service Graphs

Errors:

                    Minimum Maximum Average Last

Output Discards 0/s 155.79/s 12.2/s 0/s

Output Errors 0/s 155.79/s 12.2/s 0/s

Input Discards 0/s 0/s 0/s 0/s

Input Errors 0/s 0/s 0/s 0/s

Wie habt ihr die Rule konfiguriert um solche Mini-Bursts zu unterdrücken?

Bin für alle Tipps und Hinweise dankbar.

Danke im Voraus.

Basti

checkmk-de mailing list

checkmk-de@lists.mathias-kettner.de

Verwaltung & Abmeldung unter

http://lists.mathias-kettner.de/mailman/listinfo/checkmk-de

3

Hallo Bastian,

das eigentliche Problem ist ein Bug der 3650/3850 Switche. Diese zählen Output Discards als Xmit Errors, was schlicht falsch ist. Es ist schon etwas her, dass ich mich damit beschäftigt habe, aber damals gab es über lange Zeit keinen Fix dazu. Kannst ja mal auf eine neuere Software updaten und sehen, ob das hilft.
Wir haben damals per Rule sehr hohe Output Errors erlaubt, um die Fehlermeldung zu unterdrücken. Da Output Errors sonst sehr selten auftreten (die meisten echten Probleme sind Input Errors) ist das auch kein Problem.

Gruß

Udo

----- Ursprüngliche Mail -----

···

Von: "Brachner, Bastian" <Bastian.Brachner@brose.com>
An: "checkmk-de" <checkmk-de@lists.mathias-kettner.de>
Gesendet: Donnerstag, 6. September 2018 18:42:02
Betreff: [Check_mk (deutsch)] Betrifft Rule: Network interfaces and switch ports - OutDiscards und Xmit-Err

Hallo,

Wir setzen seit ca. einem 3/4 Jahr Check_MK v1.4.0p34 ein.
Mein erster Beitrag für die Mailingliste ist gleich mal eine Frage.
Folgender Aufbau:
Access-Switch Modell WS-C3560CG-8PC-S an dem Endanwender via GigabitEthernet angeschlossen sind.
Dieser Access-Switch wiederum hängt an einem Distribution-Switchstack 3x WS-C3850-48U-S mit einem GigabitEthernet-Port.
Der Distribution-Switchstack hängt mit zweimal TenGigabitEthernet am Core-Switch.
Abfrage-Intervall = 5 minütllich
Jetzt kommt es am Distribution-Switch an dem die Access-Switche hängen immer wieder zu solchen Meldung:
Output of check plugin: CRIT - [GigabitEthernet1/0/47](up) MAC: xx:xx:xx:xx:xx:xx, 1 Gbit/s, in: 17.8 Kbit/s(0.0%), out: 300.3 Kbit/s(0.0%), out-errors: 13.63%CRIT >= 10.0%

sh interfaces counters errors
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
...
Gi1/0/47 0 0 224594741 0 0 224594741
...
sh int gi 1/0/47
GigabitEthernet1/0/47 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet, address is f8a5.c539.33af (bia f8a5.c539.33af)
  Description: xxxxxxxxx
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:05, output never, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 224594741
  Queueing strategy: Class-based queueing
  Output queue: 0/40 (size/max)
  5 minute input rate 6000 bits/sec, 6 packets/sec
  5 minute output rate 237000 bits/sec, 204 packets/sec
     187707304 packets input, 40104455250 bytes, 0 no buffer
     Received 16828979 broadcasts (9864521 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 9864521 multicast, 0 pause input
     0 input packets with dribble condition detected
     4376058644 packets output, 604767426947 bytes, 0 underruns
     224594741 output errors, 0 collisions, 1 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out

Meinem Verständnis nach sind, wenn OutDiscards und Xmit-Err identisch sind, Queue-Drops des senden Switches, in meinem Fall des Distribution-Switches wobei ich mir das
bei diesem Durchsatz nur schwer vorstellen kann.

Die Werte des dazugehörigen Service Graphs
Errors:
      Minimum Maximum Average Last
Output Discards 0/s 155.79/s 12.2/s 0/s
Output Errors 0/s 155.79/s 12.2/s 0/s
Input Discards 0/s 0/s 0/s 0/s
Input Errors 0/s 0/s 0/s 0/s

Wie habt ihr die Rule konfiguriert um solche Mini-Bursts zu unterdrücken?
Bin für alle Tipps und Hinweise dankbar.

Danke im Voraus.
Basti
_______________________________________________
checkmk-de mailing list
checkmk-de@lists.mathias-kettner.de
Verwaltung & Abmeldung unter
http://lists.mathias-kettner.de/mailman/listinfo/checkmk-de

4

Hallo Udo,

danke für den Hinweis, du spricht mit hoher Wahrscheinlichkeit hiervon:
https://quickview.cloudapps.cisco.com/quickview/bug/CSCvb65304

Grüße
Bastian

···

-----Original Message-----
From: Udo Woehler [mailto:uw@bsw-com.de]
Sent: Sunday, September 09, 2018 7:14 PM
To: Brachner, Bastian <Bastian.Brachner@brose.com>
Cc: checkmk-de <checkmk-de@lists.mathias-kettner.de>
Subject: Re: [Check_mk (deutsch)] Betrifft Rule: Network interfaces and switch ports - OutDiscards und Xmit-Err

Hallo Bastian,

das eigentliche Problem ist ein Bug der 3650/3850 Switche. Diese zählen Output Discards als Xmit Errors, was schlicht falsch ist. Es ist schon etwas her, dass ich mich damit beschäftigt habe, aber damals gab es über lange Zeit keinen Fix dazu. Kannst ja mal auf eine neuere Software updaten und sehen, ob das hilft.
Wir haben damals per Rule sehr hohe Output Errors erlaubt, um die Fehlermeldung zu unterdrücken. Da Output Errors sonst sehr selten auftreten (die meisten echten Probleme sind Input Errors) ist das auch kein Problem.

Gruß

Udo

----- Ursprüngliche Mail -----
Von: "Brachner, Bastian" <Bastian.Brachner@brose.com>
An: "checkmk-de" <checkmk-de@lists.mathias-kettner.de>
Gesendet: Donnerstag, 6. September 2018 18:42:02
Betreff: [Check_mk (deutsch)] Betrifft Rule: Network interfaces and switch ports - OutDiscards und Xmit-Err

Hallo,

Wir setzen seit ca. einem 3/4 Jahr Check_MK v1.4.0p34 ein.
Mein erster Beitrag für die Mailingliste ist gleich mal eine Frage.
Folgender Aufbau:
Access-Switch Modell WS-C3560CG-8PC-S an dem Endanwender via GigabitEthernet angeschlossen sind.
Dieser Access-Switch wiederum hängt an einem Distribution-Switchstack 3x WS-C3850-48U-S mit einem GigabitEthernet-Port.
Der Distribution-Switchstack hängt mit zweimal TenGigabitEthernet am Core-Switch.
Abfrage-Intervall = 5 minütllich
Jetzt kommt es am Distribution-Switch an dem die Access-Switche hängen immer wieder zu solchen Meldung:
Output of check plugin: CRIT - [GigabitEthernet1/0/47](up) MAC: xx:xx:xx:xx:xx:xx, 1 Gbit/s, in: 17.8 Kbit/s(0.0%), out: 300.3 Kbit/s(0.0%), out-errors: 13.63%CRIT >= 10.0%

sh interfaces counters errors
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
...
Gi1/0/47 0 0 224594741 0 0 224594741
...
sh int gi 1/0/47
GigabitEthernet1/0/47 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet, address is f8a5.c539.33af (bia f8a5.c539.33af)
  Description: xxxxxxxxx
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:05, output never, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 224594741
  Queueing strategy: Class-based queueing
  Output queue: 0/40 (size/max)
  5 minute input rate 6000 bits/sec, 6 packets/sec
  5 minute output rate 237000 bits/sec, 204 packets/sec
     187707304 packets input, 40104455250 bytes, 0 no buffer
     Received 16828979 broadcasts (9864521 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 9864521 multicast, 0 pause input
     0 input packets with dribble condition detected
     4376058644 packets output, 604767426947 bytes, 0 underruns
     224594741 output errors, 0 collisions, 1 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out

Meinem Verständnis nach sind, wenn OutDiscards und Xmit-Err identisch sind, Queue-Drops des senden Switches, in meinem Fall des Distribution-Switches wobei ich mir das bei diesem Durchsatz nur schwer vorstellen kann.

Die Werte des dazugehörigen Service Graphs
Errors:
      Minimum Maximum Average Last
Output Discards 0/s 155.79/s 12.2/s 0/s
Output Errors 0/s 155.79/s 12.2/s 0/s
Input Discards 0/s 0/s 0/s 0/s
Input Errors 0/s 0/s 0/s 0/s

Wie habt ihr die Rule konfiguriert um solche Mini-Bursts zu unterdrücken?
Bin für alle Tipps und Hinweise dankbar.

Danke im Voraus.
Basti
_______________________________________________
checkmk-de mailing list
checkmk-de@lists.mathias-kettner.de
Verwaltung & Abmeldung unter
http://lists.mathias-kettner.de/mailman/listinfo/checkmk-de