Massive Switch-Probleme (ports down and up)

[Muetze74]

Hallo Ihr,

ich brauche dringend(!) Unterstützung, da es mir (noch) an praktischer Erfahrung fehlt!

Habe seit kurzem einen neuen Job. Homogene Cisco-Umgebung mit >600 Arbeitsplätzen. Etwa 40 Access-Switches, c2950 - c3550.

Seit wenigen Wochen schaukelt sich die Situation hoch, wir kriegen massive Anwender-Beschwerden, dass arbeiten wegen ständiger Verbindungsabbrüchen und "rotzlahmen Netzwerks" kaum noch möglich sei (kein Wunder!).

Ein "show logging" auf entsprechenden Switches:

Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)

Console logging: level debugging, 58318 messages logged

Monitor logging: level debugging, 0 messages logged

Buffer logging: level debugging, 58318 messages logged

File logging: disabled

Trap logging: level informational, 58322 message lines logged

Log Buffer (4096 bytes):

Line protocol on Interface FastEthernet0/18, changed state to up

058280: Aug 25 05:12:35: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/18, changed state to down

058281: Aug 25 05:12:36: %LINK-3-UPDOWN: Interface FastEthernet0/18, changed state to up

058282: Aug 25 05:12:40: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/18, changed state to up

058283: Aug 25 05:21:11: %LINK-3-UPDOWN: Interface FastEthernet0/29, changed state to up

058284: Aug 25 05:21:13: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/29, changed state to up

058285: Aug 25 05:40:34: %LINK-3-UPDOWN: Interface FastEthernet0/13, changed state to up

058286: Aug 25 05:40:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/13, changed state to up

058287: Aug 25 05:47:15: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/32, changed state to down

058288: Aug 25 05:47:16: %LINK-3-UPDOWN: Interface FastEthernet0/32, changed state to up

058289: Aug 25 05:47:20: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/32, changed state to up

058290: Aug 25 06:08:51: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/9, changed state to down

058291: Aug 25 06:08:54: %LINK-3-UPDOWN: Interface FastEthernet0/9, changed state to up

058292: Aug 25 06:08:56: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/9, changed state to up

058293: Aug 25 06:19:06: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/14, changed state to down

058294: Aug 25 06:19:07: %LINK-3-UPDOWN: Interface FastEthernet0/14, changed state to up

058295: Aug 25 06:19:11: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/14, changed state to up

058296: Aug 25 06:30:31: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/47, changed state to down

058297: Aug 25 06:30:32: %LINK-3-UPDOWN: Interface FastEthernet0/47, changed state to up

058298: Aug 25 06:30:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/47, changed state to up

058299: Aug 25 06:34:16: %LINK-3-UPDOWN: Interface FastEthernet0/26, changed state to up

058300: Aug 25 06:34:18: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/26, changed state to up

058301: Aug 25 06:35:02: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/26, changed state to down

058302: Aug 25 06:35:03: %LINK-3-UPDOWN: Interface FastEthernet0/26, changed state to up

058303: Aug 25 06:35:06: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/26, changed state to up

058304: Aug 25 06:50:27: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/21, changed state to down

058305: Aug 25 06:50:28: %LINK-3-UPDOWN: Interface FastEthernet0/21, changed state to up

058306: Aug 25 06:50:32: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/21, changed state to up

058307: Aug 25 07:33:40: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/6, changed state to down

058308: Aug 25 07:33:55: %LINK-3-UPDOWN: Interface FastEthernet0/6, changed state to up

058309: Aug 25 07:33:57: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/6, changed state to up

058310: Aug 25 07:59:25: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/3, changed state to down

058311: Aug 25 09:37:53: %LINK-3-UPDOWN: Interface FastEthernet0/3, changed state to up

058312: Aug 25 09:37:55: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/3, changed state to up

058313: Aug 25 11:02:21: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/26, changed state to down

058314: Aug 25 11:10:16: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/6, changed state to down

058315: Aug 25 11:10:24: %LINK-3-UPDOWN: Interface FastEthernet0/6, changed state to up

058316: Aug 25 11:10:26: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/6, changed state to up

058317: Aug 25 12:22:45: %LINK-3-UPDOWN: Interface FastEthernet0/26, changed state to up

058318: Aug 25 12:22:47: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/26, changed state to up

Ein "show interface" eines betroffenen Ports:

FastEthernet0/18 is up, line protocol is up

Hardware is Fast Ethernet, address is 000b.4699.0012 (bia 000b.4699.0012)

MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

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

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s

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

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

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

Last clearing of "show interface" counters never

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

Queueing strategy: fifo

Output queue :0/40 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

156494621 packets input, 1435982371 bytes, 0 no buffer

Received 103232 broadcasts, 0 runts, 0 giants, 0 throttles

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

0 watchdog, 4220 multicast, 0 pause input

0 input packets with dribble condition detected

1141334199 packets output, 295741145 bytes, 17941327 underruns

4191 output errors, 5632 collisions, 1 interface resets

0 babbles, 4191 late collision, 1785 deferred

0 lost carrier, 0 no carrier, 0 PAUSE output

17941327 output buffer failures, 0 output buffers swapped out

show version:

Cisco Internetwork Operating System Software

IOS C3550 Software (C3550-I9Q3L2-M), Version 12.1(11)EA1a, RELEASE SOFTWARE (fc1)

Copyright © 1986-2002 by cisco Systems, Inc.

Compiled Thu 17-Oct-02 23:02 by antonino

Image text-base: 0x00003000, data-base: 0x005C6A0C

ROM: Bootstrap program is C3550 boot loader

sw1v3 uptime is 2 years, 10 weeks, 2 days, 19 hours, 14 minutes

System returned to ROM by power-on

System restarted at 17:27:43 UTC Thu Jun 14 2007

System image file is "flash:c3550-i9q3l2-mz.121-11.EA1a/c3550-i9q3l2-mz.121-11.EA1a.bin"

cisco WS-C3550-48 (PowerPC) processor (revision H0) with 65526K/8192K bytes of memory.

Processor board ID CAT0641X0U9

Last reset from warm-reset

Running Layer2/3 Switching Image

Ethernet-controller 1 has 12 Fast Ethernet/IEEE 802.3 interfaces

Ethernet-controller 2 has 12 Fast Ethernet/IEEE 802.3 interfaces

Ethernet-controller 3 has 12 Fast Ethernet/IEEE 802.3 interfaces

Ethernet-controller 4 has 12 Fast Ethernet/IEEE 802.3 interfaces

Ethernet-controller 5 has 1 Gigabit Ethernet/IEEE 802.3 interface

Ethernet-controller 6 has 1 Gigabit Ethernet/IEEE 802.3 interface

48 FastEthernet/IEEE 802.3 interface(s)

2 Gigabit Ethernet/IEEE 802.3 interface(s)

The password-recovery mechanism is enabled.

384K bytes of flash-simulated non-volatile configuration memory.

Base ethernet MAC Address: 00:0B:46:99:00:00

Motherboard assembly number: 73-5701-07

Power supply part number: 34-0967-01

Motherboard serial number: CAT064105PE

Power supply serial number: DCA063521SY

Model revision number: H0

Motherboard revision number: A0

Model number: WS-C3550-48-SMI

System serial number: CAT0641X0U9

Configuration register is 0x10F

show running-config:

Building configuration...

Current configuration : 4380 bytes

!

! NVRAM config last updated at 15:45:37 UTC Sun Feb 22 2009

!

version 12.1

no service pad

service timestamps debug uptime

service timestamps log datetime

service password-encryption

service sequence-numbers

!

hostname xxxxx

!

enable password 7 xxxxxxxxx

!

ip subnet-zero

ip routing

!

!

spanning-tree extend system-id

!

!

interface FastEthernet0/1

no ip address

spanning-tree portfast

!

interface FastEthernet0/2

no ip address

duplex full

speed 100

spanning-tree portfast

!

interface FastEthernet0/3

no ip address

spanning-tree portfast

!

interface FastEthernet0/4

no ip address

duplex full

speed 100

spanning-tree portfast

!

interface FastEthernet0/5

no ip address

duplex full

speed 100

spanning-tree portfast

!

interface FastEthernet0/6

no ip address

spanning-tree portfast

!

interface FastEthernet0/7

no ip address

spanning-tree portfast

!

interface FastEthernet0/8

no ip address

spanning-tree portfast

!

interface FastEthernet0/9

no ip address

spanning-tree portfast

!

interface FastEthernet0/10

no ip address

spanning-tree portfast

!

interface FastEthernet0/11

no ip address

spanning-tree portfast

!

interface FastEthernet0/12

no ip address

spanning-tree portfast

!

interface FastEthernet0/13

no ip address

spanning-tree portfast

!

interface FastEthernet0/14

no ip address

spanning-tree portfast

!

interface FastEthernet0/15

no ip address

spanning-tree portfast

!

interface FastEthernet0/16

no ip address

spanning-tree portfast

!

interface FastEthernet0/17

no ip address

spanning-tree portfast

!

interface FastEthernet0/18

no ip address

spanning-tree portfast

!

interface FastEthernet0/19

no ip address

duplex full

speed 100

spanning-tree portfast

!

interface FastEthernet0/20

no ip address

duplex full

speed 100

spanning-tree portfast

!

interface FastEthernet0/21

no ip address

spanning-tree portfast

!

interface FastEthernet0/22

no ip address

spanning-tree portfast

!

interface FastEthernet0/23

no ip address

spanning-tree portfast

!

interface FastEthernet0/24

no ip address

spanning-tree portfast

!

interface FastEthernet0/25

no ip address

duplex full

speed 100

spanning-tree portfast

!

interface FastEthernet0/26

no ip address

spanning-tree portfast

!

interface FastEthernet0/27

no ip address

duplex full

speed 100

spanning-tree portfast

!

interface FastEthernet0/28

no ip address

duplex full

speed 100

spanning-tree portfast

!

interface FastEthernet0/29

no ip address

spanning-tree portfast

!

interface FastEthernet0/30

no ip address

spanning-tree portfast

!

interface FastEthernet0/31

no ip address

spanning-tree portfast

!

interface FastEthernet0/32

no ip address

spanning-tree portfast

!

interface FastEthernet0/33

no ip address

spanning-tree portfast

!

interface FastEthernet0/34

no ip address

spanning-tree portfast

!

interface FastEthernet0/35

no ip address

spanning-tree portfast

!

interface FastEthernet0/36

no ip address

spanning-tree portfast

!

interface FastEthernet0/37

no ip address

spanning-tree portfast

!

interface FastEthernet0/38

no ip address

spanning-tree portfast

!

interface FastEthernet0/39

no ip address

spanning-tree portfast

!

interface FastEthernet0/40

no ip address

duplex full

speed 100

spanning-tree portfast

!

interface FastEthernet0/41

no ip address

duplex full

speed 100

spanning-tree portfast

!

interface FastEthernet0/42

no ip address

spanning-tree portfast

!

interface FastEthernet0/43

no ip address

spanning-tree portfast

!

interface FastEthernet0/44

no ip address

duplex full

speed 100

spanning-tree portfast

!

interface FastEthernet0/45

no ip address

spanning-tree portfast

!

interface FastEthernet0/46

no ip address

duplex full

speed 100

spanning-tree portfast

!

interface FastEthernet0/47

no ip address

spanning-tree portfast

!

interface FastEthernet0/48

no ip address

duplex full

speed 100

spanning-tree portfast

!

interface GigabitEthernet0/1

no ip address

!

interface GigabitEthernet0/2

no ip address

!

interface Vlan1

ip address 10.5.2.1 255.0.0.0

no ip route-cache

!

no ip classless

ip http server

!

!

!

snmp-server engineID local xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

snmp-server community public RW

snmp-server community private RW

snmp-server community RW view v1default RO

snmp-server host xxxxxx RW

!

line con 0

line vty 0 4

password 7 xxxxxxxx

login

line vty 5 15

password 7 xxxxxxxx

login

!

end

Warum was wie konfiguriert wurde, weiß mein Vorgänger aufgrund fehlenden Know-Hows selbst nicht. Er ist froh, dass er eine Konfig über den Cisco Network Assistent halbwegs hingekriegt hat...

Umso schwieriger für mich, mich in die neue Umgebung einzuarbeiten!

Wie auch immer, unser Monitoring-Tool (theGuard) meldet, dass CPU/RAM der Switches kaum ausgelastet sind, port utilization <1% und 0 errors.

Mein Problem: ich weiß die Ursache nicht einzugrenzen, da ich bis jetzt nicht rausgekriegt habe, warum die Ports auf fast allen Switches runter- und wieder hochgefahren werden.

Mein Chef hat dieses Problem zu meiner ersten Bewährungsprobe gemacht und erwartet aufgrund massiver Beschwerden diverser Fachdienstleiter, dass ich das bis Freitag in den Griff kriege...

Und nun zu Euch:

Habt Ihr weitere Denkanstöße für mich, wie ich die Ursache weiter eingrenzen kann. Könnt Ihr anhand der geposteten Meldungen Rückschlüsse ziehen? Vorschläge, wie ich weiter vorgehen kann?

Vielen leben Dank schonmal!

[ardcore]

Die Ausgabe von "show buffers" wäre interessant.

Gruss,

ardcore.

[jeronimonino]

Ich nehme einfach mal an das du schon auf der Website von Cisco Systems, Inc nach geguckt bzw hilfe gesucht hast.

Was hast du den bisher alles gemacht ?

Hast du vll ein switch das du zum Testen nehmen kannst, um die Fehler nach zustellen?

OS Upgrade

Google

Oder wie ich oben schon gepostet habe bei cisco einmal nachfragen die sind eigentlich recht Supportfreundlich.

[Muetze74]

show buffers:

Buffer elements:

484 in free list (500 max allowed)

1377099672 hits, 0 misses, 0 created

Public buffer pools:

Small buffers, 104 bytes (total 53, permanent 50, peak 74 @ 7w0d):

53 in free list (20 min, 150 max allowed)

650815204 hits, 142 misses, 257 trims, 260 created

0 failures (0 no memory)

Middle buffers, 600 bytes (total 25, permanent 25, peak 64 @ 7w0d):

23 in free list (10 min, 150 max allowed)

80372 hits, 23 misses, 69 trims, 69 created

0 failures (0 no memory)

Big buffers, 1524 bytes (total 163, permanent 128, peak 475 @ 7w0d):

158 in free list (128 min, 512 max allowed)

298423643 hits, 223806 misses, 308537 trims, 308572 created

160 failures (0 no memory)

VeryBig buffers, 4520 bytes (total 0, permanent 0, peak 11 @ 05:37:29):

0 in free list (0 min, 0 max allowed)

123023 hits, 773515 misses, 1547030 trims, 1547030 created

0 failures (0 no memory)

Large buffers, 5024 bytes (total 0, permanent 0):

0 in free list (0 min, 0 max allowed)

0 hits, 0 misses, 0 trims, 0 created

0 failures (0 no memory)

Huge buffers, 18024 bytes (total 0, permanent 0, peak 2 @ 7w0d):

0 in free list (0 min, 0 max allowed)

153 hits, 179 misses, 358 trims, 358 created

0 failures (0 no memory)

Interface buffer pools:

Ram Access buffers, 1524 bytes (total 103, permanent 100, peak 151 @ 7w0d):

103 in free list (100 min, 150 max allowed)

276527002 hits, 9681 misses, 29040 trims, 29043 created

0 failures (0 no memory)

CPU1 buffers, 1524 bytes (total 6, permanent 6):

1 in free list (0 min, 6 max allowed)

829094676 hits, 138182446 fallbacks

CPU13 buffers, 1524 bytes (total 32, permanent 32):

1 in free list (0 min, 32 max allowed)

103 hits, 3 fallbacks

CPU11 buffers, 1524 bytes (total 16, permanent 16):

0 in free list (0 min, 16 max allowed)

6224 hits, 394 fallbacks

CPU6 buffers, 1524 bytes (total 10, permanent 10):

1 in free list (0 min, 10 max allowed)

1710286 hits, 171052 fallbacks

CPU3 buffers, 1524 bytes (total 20, permanent 20):

10 in free list (0 min, 20 max allowed)

10 hits, 0 misses

CPU0 buffers, 1524 bytes (total 16, permanent 16):

1 in free list (0 min, 16 max allowed)

40877089 hits, 3677834 fallbacks

CPU5 buffers, 1524 bytes (total 16, permanent 16):

1 in free list (0 min, 16 max allowed)

3328112 hits, 208397 fallbacks

CPU8 buffers, 1524 bytes (total 32, permanent 32):

16 in free list (0 min, 32 max allowed)

16 hits, 0 misses

CPU4 buffers, 1524 bytes (total 150, permanent 150):

74 in free list (0 min, 150 max allowed)

132704128 hits, 146 misses

CPU2 buffers, 1524 bytes (total 10, permanent 10):

1 in free list (0 min, 10 max allowed)

276551161 hits, 119113288 fallbacks

CPU10 buffers, 1524 bytes (total 8, permanent 8):

0 in free list (0 min, 8 max allowed)

8 hits, 0 fallbacks

CPU9 buffers, 1524 bytes (total 32, permanent 32):

16 in free list (0 min, 32 max allowed)

16 hits, 0 misses

Bis jetzt habe ich noch nichts Großes veranstaltet, da ich mir nicht sicher bin, wo ich ansetzen soll...

Cisco supported uns nicht direkt, da über Reseller.

Da die IOS-Images praktisch noch im Auslieferungszustand sind (teilweise Geräte von 2002), habe ich ein Update angedacht. Aber Try and Error ist nicht unbedingt meine bevorzugte Arbeitsweise. Bis letzte Woche hatte diese Port-Probleme auch nur ein (8 Jahre alter) Switch, jetzt sind aber alle anderen (bis auf der zentrale 4510er) dazugekommen und das Problem wird ernst!

Mein primäres Bestreben liegt ersteinmal darin, das Problem aufzudecken, um es abzustellen. Die (offensichtlichen) Probleme wie veraltete IOS-Images, fehlendes Konzept, undurchdachte Topologie, etc. werden endlich angegangen, wenn die Anwender wieder arbeiten können und mir die Fachdienstleiter nicht mehr so im Nacken hängen, so dass ich mich vernünftig an die Neukonzeption heranwagen kann...

[Muetze74]

Achja, Google erzählt immer wieder was über Link Flaps bezüglich fehlerhafter Duplex-Einstellungen. In unserem Fall sind die beidseitig auf Autonegotiation, bei Problem-Clients auch mal auf Full 100. Bisher lief das anstandslos, weitreichende Änderungen wurden nicht vorgenommen.

[Muetze74]

show errdisable detect:

ErrDisable Reason Detection status

----------------- ----------------

pagp-flap Enabled

dtp-flap Enabled

link-flap Enabled

l2ptguard Enabled

gbic-invalid Enabled

show errdisable recovery:

ErrDisable Reason Timer Status

----------------- --------------

udld Disabled

bpduguard Disabled

channel-misconfig Disabled

pagp-flap Disabled

dtp-flap Disabled

link-flap Disabled

l2ptguard Disabled

psecure-violation Disabled

gbic-invalid Disabled

[ardcore]

Achja, Google erzählt immer wieder was über Link Flaps bezüglich fehlerhafter Duplex-Einstellungen. In unserem Fall sind die beidseitig auf Autonegotiation, bei Problem-Clients auch mal auf Full 100. Bisher lief das anstandslos, weitreichende Änderungen wurden nicht vorgenommen.

Nein, Linkflapping sieht anderst aus. Dort "flappt" das Interface min. 5mal innerhalb von 10sek und geht dann in den State "errdisabled". Dies wird auch im Logfile vermerkt. Das ist bei Euch nicht der Fall.

Könntest du noch den Auszug von "show proc cpu | excl 0.00%__0.00%__0.00%" angeben? (zwei Unterstriche).

Danke.

[Muetze74]

Hey, danke für Deine Unterstützung ardcore!

Wie gewünscht:

show proc cpu | excl 0.00%__0.00%__0.00%

CPU utilization for five seconds: 1%/0%; one minute: 2%; five minutes: 2%

PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process

5 218424 1635934 133 0.00% 0.16% 0.12% 0 Pool Manager

9 75106008 263784783 284 0.08% 0.14% 0.14% 0 ARP Input

24 276643744 207282734 1334 0.40% 0.40% 0.40% 0 Vegas Statistics

33 20679516 101527820 203 0.00% 0.16% 0.13% 0 IP Input

39 47397716 154640620 306 0.00% 0.03% 0.00% 0 Spanning Tree

70 676948 2724212 248 0.16% 0.42% 0.36% 0 IP SNMP

71 121848 918677 132 0.00% 0.13% 0.08% 0 PDU DISPATCHER

72 485728 917873 529 0.16% 0.57% 0.47% 0 SNMP ENGINE

Ich muss aber auch dazu sagen, dass der sh buffers und der sh proc cpu außerhalb der Prduktivzeiten abgesetzt wurden, sprich nach 16 Uhr, wenn hier jeder alles stehen und liegen lässt (außer mir)...

[ardcore]

Ich muss aber auch dazu sagen, dass der sh buffers und der sh proc cpu außerhalb der Prduktivzeiten abgesetzt wurden, sprich nach 16 Uhr, wenn hier jeder alles stehen und liegen lässt (außer mir)...

Das ist egal. Ich wollte nur ausschliessen das es sich um einen Buffer- oder CPU-Leak handelt. Ein Buffer- oder CPU-Leak ist nicht der Grund für dein Problem.

Was gibt den "show interface xxx counters errors" auf einem der betroffenen Interfaces aus?

PS: Wichtig ist das auf den betroffenen Geräten die Power-Management-Funktionalität deaktiviert ist, die es erlaubt die NIC zu deaktivieren.

Bearbeitet 25. August 2009 von ardcore

[Muetze74]

So, habe mir jetzt erlaubt, auch Feierabend zu machen. Von daher kann ich Dir die Ausgabe erst morgen früh posten. Wäre klasse von Dir, wenn Du da am Ball bleiben könntest, da ich - wie gesagt - bis Freitag Erfolge vorweisen muss...

Achja, die Power-Management-Funktion habe ich leider schon gleich zu Anfang bei diversen Clients aktiviert vorgefunden. Aber auch die PCs, wo ich es bisher schon deaktiviert habe, sind vom "lahmen Netzwerk" betroffen.

Was mich wundert, ist die Tatsache, dass diese Port-Probleme bisher nur bei einem Switch auftraten, bei dem es auf seine 9-jährige Dienstzeit geschoben wurde, jetzt aber von heute auf morgen ohne gravierende Änderungen fast alle Switches dieses Verhalten aufweisen.

Andererseits, wenn sich ganze Abteilungen beschweren, dass Anwendungen ständig abschmieren, teilweise bis zu 20 min stehen bleiben, Anmeldevorgänge mal ne halbe Stunde dauern, Ereignisprotokolle voller Verbindungsprobleme sowohl auf den Servern als auch auf den Clients sind, kann doch eigentlich ein sekündiger Port-Wegfall (selbst wenn er alle 1-2 Stunden) auftaucht, nicht so gravierend in seiner Auswirkung sein, oder irre ich mich?! Dass es MAL zu Timeouts kommt, sehe ich ja ein, aber dass das komplette Netzwerk innerhalb von 1-2 Wochen nahezu zum Stillstand kommt? Das schaukelt sich hier richtig hoch...!

[ardcore]

Ach das werden wir bis Freitag schon schaukeln Interessiert mich selbst das Problem.

Was du noch machen kannst ist, dir einen Switch rauspicken und dort einen Testclient hinhängen. Am besten der 3550 von dem die Outputs stammen.

An dem Testport am besten einen Laptop mit Live-CD o.ä. betreiben. Powermanagement im BIOS und OS am besten ganz Ausschalten. Speed und Duplexeinstellungen der NIC fest einstellen.

Dann den Switch neubooten, natürlich angekündigt und in Low-Usage-Time (Mittagspause etc.). Dann jag Traffic drüber über den Port. Ein paar Endlosspings mit erhöhter Grösse an unterschiedliche Destinations reichen schon.

Sollte dann wieder Fehler auf dem Gerät auftauchen oder sich User beschweren, den Output von "show tec" hier posten.

Gruss,

ardcore.

[Muetze74]

Lieben Dank, ardcore! Das baut mich doch wieder auf...

Werde das gleich morgen mal angehen.

Schönen Abend noch!

[DocInfra]

Mal überlegt jemanden mit dem fachlichen Knowhow einzukaufen, der sich das ansieht? Also einen Dienstleister zu beauftragen? Per Forum rumzustochern, unter Zeitdruck und ohne das notwendige Wissen halte ich für wenig zielführend.

[Muetze74]

Nabend bla!zilla,

ja, das habe ich in Erwägung gezogen...

Ich bin aber der Meinung, dass dies der letzte Schritt sein sollte und halte das Problem (wenn auch noch undefiniert) für selbständig lösbar. Zumindest momentan noch...

Es stellt durchaus eine Herausforderung dar, durch die ich jedoch endlich bei der Einarbeitung in die neue (Netzwerk-)Umgebung einen entscheidenden Schritt vorwärtskomme. Andererseits habe ich aber auch einen gewissen Anspruch an mich selbst, gefördert durch die Tatsache, dass es sich hier um eine Bewährungsprobe für mich handelt.

Man muss aber auch dazusagen, dass ich im Öffentlichen Dienst eingestiegen bin, d.h., dass Gelder für solche Aktionen nicht mal ebenso locker zu machen sind.

Nichtsdestotrotz, ich will und werde das Problem lösen, gerne auch mit konstruktiver Unterstützung von Dir, bla!zilla!

[DocInfra]

Das geht immer - auch im öffentlichen Dienst. Oft genug war ich selber in solchen Situationen "der Externe". Lass deinen Chef doch mal rechnen: Einsatz eines Externen vs. Kosten durch Produktivitätsverlust der Mitarbeiter.

[Muetze74]

Wie gesagt, das ist für mich der letzte Schritt. Zuvor will ich mein Bestmöglichstes tun, um die Nuss zu knacken.

Wenn Du also irgendeinen Ansatz hast, mit dem ich weiterkommen, nur zu!

Ich werde jetzt erstmal nen Laptop an einen der Problem-Switches hängen und nen Netzwerk Monitor laufen lassen...

[Muetze74]

So, dann nochmal neues Info-Futter:

Als ich herkam, war ich ob der Umgebung erfreut. Homogene Cisco-Struktur in einer Stadtverwaltung ist ja auch nicht unbedingt die Regel.

Ebenso schnell kam aber auch die Ernüchterung, da ich recht schnell mitkriegte, dass die IT-Abteilung sich hier einen schweren Stand verschafft hat. Seit mittlerweile Jahren beschweren sich die Anwender über das saulahme Netzwerk. Dass technisch Unwissende pauschal alles aufs Netzwerk schieben, lasse ich einfach mal dahingestellt. Woher sollen sie auch wissen, dass schlecht konfigurierte Inventarisierungsapplikationen die Clients extrem ausbremsen, Infrastrukturdienste unsauber und fehlerhaft konfiguriert sind, etc.

Nichtsdestotrotz, das Netzwerk hier hat mächtige Probleme:

über 600 Clients in einer einzigen Broadcastdomäne, keine Segmentierung, keine Redundanzen, zig Access-Switches und ein einziger 4510er als Core-Switch, und so weiter und so fort...

Meine erste große Aufgabe wird also sein, das Netzwerk hier komplett neu zu strukturieren. Dazu will ich ein geswitchtes Backbone über Distribution-Switches aufbauen, VLAN-Segmentierung einführen, eine RSTP-Domäne implementieren, Steuerungsfunktionen über ACLs, etc. pp.

Also vom aktuellen Zustand her nicht die beste Voraussetzung. Es lief bisher mehr schlecht als recht, aber es lief. Seit ein paar Wochen nimmt die Performance aber dramatisch ab. Neue 'störende' Applikationen sind nicht hinzugekommen. Gravierende Veränderungen gab es auch nicht.

Jedenfalls hat sich die Situation dramatisch zugespitzt, und genau zu diesem Zeitpunkt bin ich hier eingestiegen als neuer Netzwerkadministrator. Man erwartet jetzt einiges von mir, auch wenn klar ist, dass ich in diesem Bereich noch nicht die umfassende praktische Erfahrung habe, die ich gerne hätte.

Ich sehe das aber als Chance, denn genau so eignet man sich das nötige Tiefenwissen ja an...

So, was fiel mir bisher also alles auf?

Die (Access-)Switches fahren mehrmals am Tag (siehe Datensammlung) aus unerfindlichen Gründen Ports runter und wieder hoch. Die Anwender beschweren sich zunehmends, dass sie kaum noch arbeiten können. Ich bringe das aber nicht unbedingt in Zusammenhang, da sekündige Connection-Abbrüche deren massives Störverhalten nicht zwingend erklären, oder?

Bearbeitet 26. August 2009 von Muetze74

[ardcore]

über 600 Clients in einer einzigen Broadcastdomäne

Cisco rät zu maximal 500 Clients in einer Broadcastdomäne. 600 sind sicherlich noch okay, wenn auch nicht optimal.

keine Redundanzen, zig Access-Switches und ein einziger 4510er als Core-Switch

Keine Redundanz und nur ein Core-Gerät ist natürlich bescheiden.

Dazu will ich ein geswitchtes Backbone über Distribution-Switches aufbauen

Ist weniger sinnvoll. Ne Collapsed-Backbone-Struktur ist in der grössen Ordnung schon okay. Was Definitiv sein sollte ist nen 2tes Core-Gerät.

VLAN-Segmentierung einführen

Sinnvoll. Denk aber dran das du dann Routen musst.

eine RSTP-Domäne implementieren

Darum wirst du kaum herrumkommen wenn du Redundanz willst.

Die Anwender beschweren sich zunehmends, dass sie kaum noch arbeiten können. Ich bringe das aber nicht unbedingt in Zusammenhang, da sekündige Connection-Abbrüche deren massives Störverhalten nicht zwingend erklären, oder?

Das kommt ganz auf die Anwendungen an. Web-Traffic interessiert das eher weniger. SAP und Konsorten reagieren sehr allergisch darauf.

PS: Du schuldest mir noch ein "show int counters errors" von einem der betroffenen Ports

Gruss,

ardcore.

[Muetze74]

Guten Morgen ardcore!

Hier die Outputs:

sw1v3#sh logg

Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)

Console logging: level debugging, 58447 messages logged

Monitor logging: level debugging, 0 messages logged

Buffer logging: level debugging, 58447 messages logged

File logging: disabled

Trap logging: level informational, 58451 message lines logged

Log Buffer (4096 bytes):

%LINK-3-UPDOWN: Interface FastEthernet0/8, changed state to up

058409: Aug 26 05:01:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/8, changed state to up

058410: Aug 26 05:01:39: %LINK-3-UPDOWN: Interface FastEthernet0/38, changed state to up

058411: Aug 26 05:01:41: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/38, changed state to up

058412: Aug 26 05:08:16: %LINK-3-UPDOWN: Interface FastEthernet0/13, changed state to up

058413: Aug 26 05:08:18: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/13, changed state to up

058414: Aug 26 05:16:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/36, changed state to down

058415: Aug 26 05:16:52: %LINK-3-UPDOWN: Interface FastEthernet0/36, changed state to up

058416: Aug 26 05:16:54: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/36, changed state to up

058417: Aug 26 05:39:07: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/32, changed state to down

058418: Aug 26 05:39:08: %LINK-3-UPDOWN: Interface FastEthernet0/32, changed state to up

058419: Aug 26 05:39:11: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/32, changed state to up

058420: Aug 26 05:48:02: %LINK-3-UPDOWN: Interface FastEthernet0/29, changed state to up

058421: Aug 26 05:48:04: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/29, changed state to up

058422: Aug 26 05:58:56: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/9, changed state to down

058423: Aug 26 05:59:00: %LINK-3-UPDOWN: Interface FastEthernet0/9, changed state to up

058424: Aug 26 05:59:02: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/9, changed state to up

058425: Aug 26 06:12:43: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/3, changed state to down

058426: Aug 26 06:12:44: %LINK-3-UPDOWN: Interface FastEthernet0/3, changed state to up

058427: Aug 26 06:12:47: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/3, changed state to up

058428: Aug 26 06:13:51: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/47, changed state to down

058429: Aug 26 06:13:52: %LINK-3-UPDOWN: Interface FastEthernet0/47, changed state to up

058430: Aug 26 06:13:56: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/47, changed state to up

058431: Aug 26 06:14:32: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/14, changed state to down

058432: Aug 26 06:14:33: %LINK-3-UPDOWN: Interface FastEthernet0/14, changed state to up

058433: Aug 26 06:14:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/14, changed state to up

058434: Aug 26 06:16:58: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/21, changed state to down

058435: Aug 26 06:16:59: %LINK-3-UPDOWN: Interface FastEthernet0/21, changed state to up

058436: Aug 26 06:17:02: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/21, changed state to up

058437: Aug 26 06:17:35: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/18, changed state to down

058438: Aug 26 06:17:36: %LINK-3-UPDOWN: Interface FastEthernet0/18, changed state to up

058439: Aug 26 06:17:40: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/18, changed state to up

058440: Aug 26 06:17:51: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/18, changed state to down

058441: Aug 26 06:17:52: %LINK-3-UPDOWN: Interface FastEthernet0/18, changed state to up

058442: Aug 26 06:17:56: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/18, changed state to up

058443: Aug 26 06:43:18: %LINK-3-UPDOWN: Interface FastEthernet0/26, changed state to up

058444: Aug 26 06:43:20: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/26, changed state to up

058445: Aug 26 06:44:11: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/26, changed state to down

058446: Aug 26 06:44:12: %LINK-3-UPDOWN: Interface FastEthernet0/26, changed state to up

058447: Aug 26 06:44:15: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/26, changed state to up

sw1v3#

sw1v3#

sw1v3#

sw1v3#

sw1v3#sh int fa0/32 counters errors

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

Fa0/32 0 0 57086854 4 0

Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants

Fa0/32 857 7 824 0 0 0 0

Der Core-Switch soll natürlich auch redundant ausgelegt werden. Das Routen soll dann über die beiden laufen.

SAP setzen wir hier nicht ein, aber zahlreiche andere Netzwerk-Anwendungen.

Eine Collapsed-Backbone-Struktur sagt mir jetzt auf Anhieb nichts, damit befasse ich mich nachher mal... Ich hatte angedacht, auf Distribution-Ebene vier weitere redundant miteinander verbundene Switches in die Topologie einzubauen, da bisher alle Access-Switches (teilweise in Reihe geschaltet) direkt an den zentralen L3-Knoten gehen, der bis jetzt nicht routet.

Immerhin haben wir auch ca. 20 Standorte, die alle über eigene LWLs an uns angebunden sind. Später, wenn das 'neue' Netzwerk steht, soll dann stadtweit VoIP hinzukommen, was entsprechende Netzwerkressourcen voraussetzt. Nicht zu vergessen, dass wir gesetzlich zur Verfügbarkeit und Ausfallsicherheit verpflichtet sind.

[Muetze74]

Dieses Collapsed Backbone entspricht ja eigentlich unserer jetzigen Situation, wenn man bedenkt, dass alles an einen zetralen Knotenpunkt angebunden ist...

Aufgrund des historischen Wachstums (mittlerweile etwa 70 Server) der IT-Umgebung, bei der das Netzwerk aber noch auf dem Stand von vor 10 Jahren steht (als es nur 5 Serversysteme und max. 200 Clients waren), sehe ich hier einen der ursächlichen Faktoren für die zunehmende Netzwerverlangsamung (Broadcast-Anteil zwischen 50 und 80%). Von daher hatte ich - unter Berücksichtigung der später einzuführenden VoIP-Implementierung - angedacht, eine Redundanz und Lastverteilung über besagtes Switch-Backbone zu erreichen. Die vier Backbone-Switches auf Distributionsebene und den zweiten Core-Switch wollte ich dann so verteilen, dass die eine Hälfte davon hier im Gebäude steht und die andere im Gebäude des Innenstadtverteilers (über den der Großteil der Standorte angebunden ist), so dass bei einem Ausfall der neu zu legenden LWLs in die Innenstadt bei Unterbrechung dieser zumindest die Außenstandorte weiterhin netzwerkseitig weiterlaufen können.

[ardcore]

sw1v3#sh int fa0/32 counters errors

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

Fa0/32 0 0 57086854 4 0

Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants

Fa0/32 857 7 824 0 0 0 0

Da haben wir´s doch. Jede Menge Transmit-Error´s. Dh. die Transmit-Buffer auf deinen Ports laufen voll. Wenn die Queues voll sind und Packete in den Queues für mehrere Sekunden nicht versendet werden können, resettet sich das Interface automatisch. Sieht man schön in deinen Logs.

Schnapp dir mal nen Port, stelle dort Duplex und Speed fest ein.

Ebenso auf dem am Port hängenden Endgerät.

Anschliessend bitte ein "clear counters int xxx" absetzen.

[Muetze74]

Ah, endlich ein Ansatzpunkt... Dankeschön dafür!

Gibt es einen bestimmten Grund, warum Du die Transmit-Errors auf fehlerhafte Duplex-Einstellungen beziehst oder sind das Erfahrungswerte Deinerseits?

Wenn man die heruntergefahrenen Ports aus den Syslogs im Eröffnungsthread mit den Duplex-Einstellungen aus der running-config vergleicht, fällt schon auf, dass es ausnahmslos autokonfigurierte Ports sind, die abgeschaltet werden.

Andererseits, der Anwender, der sich gestern am massivsten beschwerte (an Port 6), hatte "lediglich" 2 Verbindungsabbrüche, Das wiederum beschreibt nicht wirklich, warum er dermaßen Ausfallzeiten hatte. Heute z.B. wurde 'sein' Port nicht abgeschaltet...

[ardcore]

Gibt es einen bestimmten Grund, warum Du die Transmit-Errors auf fehlerhafte Duplex-Einstellungen beziehst oder sind das Erfahrungswerte Deinerseits?

Die Transmit-Errors treten nur auf, wenn der Transmit-Buffer des Interfaces ständig überfüllt ist und deshalb Frames aus ihm verworfen werden. Für ständig volle Transmit-Buffer gibt es mehrere Möglichkeiten. Eine Möglichkeit davon ist ein Speed/Duplex-Mismatch.

Wenn man die heruntergefahrenen Ports aus den Syslogs im Eröffnungsthread mit den Duplex-Einstellungen aus der running-config vergleicht, fällt schon auf, dass es ausnahmslos autokonfigurierte Ports sind, die abgeschaltet werden.

Deshalb meine Vermutung mit der nicht richtig funktionierenden Autonegotiation.

Andererseits, der Anwender, der sich gestern am massivsten beschwerte (an Port 6), hatte "lediglich" 2 Verbindungsabbrüche,

Manche Leute brüllen wenn sie sich mit ner Nadel in den Finger picksen, andere Leute geben bei ner Fraktur keinen Laut von sich. Nur wer am lautesten Brüllt muss nicht die grössten Schmerzen haben, du verstehst?

Das wiederum beschreibt nicht wirklich, warum er dermaßen Ausfallzeiten hatte. Heute z.B. wurde 'sein' Port nicht abgeschaltet..

Das das Interface runterbricht, kommt einem "Herzinfarkt" gleich. Auch wenn es zu keinem "Herzinfarkt" kommt, wird der Betroffene keine 100m mehr unter 10sek sprinten und sich über "Trägheit und Schlappheit" beschweren.

[Muetze74]

So, auf dem zentralen L3-Core-Switch habe ich nun Folgendes vorgefunden:

sh logg

Syslog logging: enabled (0 messages dropped, 1 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled)

Console logging: disabled

Monitor logging: level debugging, 0 messages logged, xml disabled,

filtering disabled

Buffer logging: level debugging, 5292 messages logged, xml disabled,

filtering disabled

Exception Logging: size (8192 bytes)

Count and timestamp logging messages: disabled

Trap logging: level informational, 5293 message lines logged

Logging to 10.0.0.88, 78 message lines logged, xml disabled,

filtering disabled

Log Buffer (4096 bytes):

a9/12 and port Fa9/10

005263: Aug 25 09:14:59: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005264: Aug 25 09:45:02: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005265: Aug 25 10:15:01: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005266: Aug 25 10:19:58: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/8 and port Fa9/12

005267: Aug 25 10:45:06: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005268: Aug 25 11:08:35: %C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET: (Suppressed 360 times)Packet received with invalid source MAC address (00:00:00:00:00:00) on port Fa9/6 in vlan 1

005269: Aug 25 11:15:02: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005270: Aug 25 11:45:12: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005271: Aug 25 12:15:05: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005272: Aug 25 12:45:16: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005273: Aug 25 14:15:21: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005274: Aug 25 14:17:02: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005275: Aug 25 14:29:20: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005276: Aug 25 17:18:25: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005277: Aug 26 04:32:39: %C4K_EBM-4-HOSTFLAPPING: Host 00:07:0E:25:C4:60 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005278: Aug 26 04:33:39: %C4K_EBM-4-HOSTFLAPPING: Host 00:07:0E:25:C4:60 in vlan 1 is flapping between port Fa9/10 and port Fa9/12

005279: Aug 26 05:14:16: %C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET: (Suppressed 112 times)Packet received with invalid source MAC address (00:00:00:00:00:00) on port Fa9/6 in vlan 1

005280: Aug 26 06:10:46: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005281: Aug 26 06:26:36: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/8 and port Fa9/12

005282: Aug 26 06:40:50: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005283: Aug 26 07:22:15: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005284: Aug 26 07:23:26: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005285: Aug 26 07:40:57: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005286: Aug 26 08:11:00: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005287: Aug 26 08:41:04: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005288: Aug 26 09:11:07: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005289: Aug 26 09:13:50: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005290: Aug 26 10:03:56: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005291: Aug 26 10:04:59: %C4K_EBM-4-HOSTFLAPPING: Host 00:1C:BF:BA:66:F3 in vlan 1 is flapping between port Fa9/12 and port Fa9/10

005292: Aug 26 11:15:13: %C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET: (Suppressed 318 times)Packet received with invalid source MAC address (00:00:00:00:00:00) on port Fa9/6 in vlan 1

[Muetze74]

Fix und alle...

Nachdem ich etwa 150 Problem-Ports identifizierte mit entsprechend vielen Hosts dahinter, war ich umso erfreuter, dass keine Aufstellungen/Listen existieren, welcher Client an welcher Netzwerkdose und welche Netzwerkdose an welchem Switch-Port hängt. Nicht sehr vorteilhaft, wenn man beidseitige Duplex-Anpassungen vornehmen möchte...

Also haben wir zu dritt die Verteilerräume durchkämmt, die Kabel der Switch-Ports am Patchpanel verfolgt und knappe 100 Büros bezüglich Netzwerkdosen und daran hängenden PCs abgeklappert.

Morgen werde ich dann die Konfigurationen Switch- und Clientseitig vornehmen und berichten, wie das Resultat aussieht.

Was den Output des Core-Switches betrifft, läuft über Nacht ein IP-Scan des Netzwerks, damit wir die MAC-Adresse hinter dem Hostflapping identifizieren können. Die ist bisher gänzlich unbekannt.

Ich hoffe ja inständig, dass tatsächlich die Duplex-Einstellungen der Grund der Transmit-Errors sind, denn mein Bauchgefühl ist sich da nicht so sicher.

Einen schönen Feierabend allen!