Door Bitwiper: Door Anoniem: Door Bitwiper: Heb je in WireShark met de netwerkinterface in promiscuous mode gekeken?
De alle ledjes van servers parallel knipperen is bijna zeker broadcast/multicast verkeer, bijvoorbeeld een management agent, of een dropbox client, windows fileservers etc.
Je weet niet wat hier aan de hand is. Kijk dus met alle middelen die je hebt!
(ben dezelfde anoniem). Natuurlijk, het is een kleine moeite.
Zoals de vraag van de OP lees verwacht ik weinig meer dan management agents of ander regelmatig broadcast verkeer.
Het moet een behoorlijk rustig netwerkje zijn als je een "Hé, de ledjes knipperen telkens tegelijk" patroon ziet.
Een spanning tree loop geeft een kerstboom, geen geknipper.
Trouwens, als ik Wireshark niet in prmiscuous mode opstart (Dell notebook, Broadcom NIC, XPSP3) zie ik geen multicast verkeer (STP, IGMP etc).
Multicast is ook op ethernet niveau (mac) multicast. Je zult wel multicast verkeer zien voor groepen waar je zelf aan gejoined zit, maar ander multicast verkeer inderdaad niet.
Daarin is IPv6 (router announcement/discovery, neighbour discovery etc.) net even slimmer en efficienter dan IPv4 (arp is broadcast).
Als je switch voldoende slim is, zul je ander (ip) multicast verkeer ook niet zien op je switchpoort; De switch doet IGMP snooping en stuurt multicast verkeer dan alleen naar poorten waarvoor een passende IGMP join gezien is.
Als je 200 Mbit multicast verkeer (handjevol video kanalen) hebt gaan over een paar devices met GigE poorten is het niet zo fijn om dat op 100M poorten ook nog uit te sturen, wat een switch zonder IGMP snooping wel zou moeten doen.
STP (en CDP,LLDP e.a.) zul je zonder promiscuous mode inderdaad niet zien omdat je OS niet joined aan een (IP) multicast groep die mapped naar hun ethernet multicast mac adres.
Andere (niet gangbare) reden: als een aanvaller alle switches in het netwerk ervan wil overtuigen dat zijn (waarschijnlijk gespoofde) MAC adres X aan een specifieke switch hangt, kan hij dat stilletjes doen door regelmatig ethernetpakketjes naar een niet bestaand MAC adres Y te sturen. Omdat geen enkele switch weet waar Y zit zullen ze dit pakketje "flooden" (ondertussen leren ze allemaal wel de route terug naar X). Gevolg: knipperende LEDjes maar omdat het om unicast verkeer gaat zal niemand het "oppakken". Dit soort pakketjes zie je alleen in promiscuous mode.
Zo'n situatie kan ook per ongeluk onstaan bij een static ARP entry en een bijbehorende NIC die is vervangen (of een computer die uitstaat). Denk bijv. aan een oude unix bak met een static ARP entry voor een ondertussen afgevoerde syslog server.
De meer gebruikelijke reden is een voldoende stille host, inderdaad een (read only) syslog server in combinatie met lange arp timeouts en korte cam table timeouts.
(4 uur / 5 minuten zijn bekende defaults). Het hoeft niet eens een afgevoerde syslog hosts te zijn dan,
als het om een nogal centrale log server gaat kan dat behoorlijke flooding volumes geven. Eventueel zelfs verlies van log packets als de switch een rate limit op unknown unicast floods ingesteld heeft.
Een feed van puur één weg verkeer (video stroom van een bewakings camera ofzo) zonder retour verkeer kan ook dat effect hebben.
En tenslotte is het een risico in een topologie met twee (L3) switches waarbij een verschillende switch HSRP master is voor heen- en retour verkeer.
Maar anyway, eens kijken met een sniffer en een beeld hebben van wat "normaal" is, en snappen waarom je bepaald verkeer ziet (of niet) is bijzonder nuttig.
Hoe ouder een netwerk, hoe meer WTF's je ziet...
mww. competentie van beheerders speelt nogal mee.