SMB verkeer tussen servers vanaf werkplekken inzichtelijk

[TBK001]

Ik hoop dat iemand mij / ons kan helpen. Bij het bedrijf waar ik werk zijn onlangs nieuwe switches uitgerold. Hierna zijn toevallig tijdens een pentest door een extern bedrijf metingen verricht op ons netwerk waarbij opviel dat er netwerkverkeer inzichtelijk was vanaf een willekeurige netwerk aansluiting. Naderhand zijn wij zelf gaan meten en het probleem zelf ook geconstateerd. We hebben het bedrijf welke de nieuwe switches heeft uitgerold erbij gehaald, maar niemand komt er zo uit wat het probleem is.

Wat hebben we:
Beide switches, zijn er 2, zijn van het merk en type: HP 5130 Series Switch JG934A.
De servers, 2 Linux servers waar Samba op draait als fileshare, 2 Windows servers waar een specifiek stuk software op draait die data van de Linux file shares afhaalt.

Waarmee heb ik gemeten:
Wireshark in Linux vanaf een werkstation aangesloten op 1 van de switches.

VLAN:
Momenteel nog niet ingericht.

Wat zie ik voorbij komen:
Pakketten van protocol SMB tussen de genoemde Linux servers en Windows servers.
Ik zie hier en daar ook wat verkeer tussen werkstations en de Linux servers die bijzelfde shares komen.
De Windows servers en werkstations hebben zelf geen shares.

De leverancier van de switches die deze hier heeft uitgerold, een bedrijf wat goed bekend staat, garandeerd ons dat alles goed ingesteld staat, deze kan echter niet aangeven waar het probleem wel vandaan zou moeten komen.
Als ik echter de verschijnselen zie ben ik toch nog steeds erg geneigd naar de switches te wijzen.

Heeft iemand ervaring met een dergelijk probleem?
Kan iemand wat handvaten geven hoe e.e.a. door te meten?

We hebben geprobeerd om NetBios uit te zetten, dit heeft het echter niet mogen verhelpen.

Alvast heel erg bedankt,


Sebastiaan

[DukeBox]

Gebruik je NLB ? Neem aan dat je geen port mirror hebt aan staan op je switches ?

[TBK001]

Ik was al een beetje bang voor dergelijke vragen, ikzelf ben geen netwerk guru, bij ons niemand echt. Dat was juist de reden dat er een bedrijf bijgehaald werd om dit uit te rollen. Kan dit softwarematig ingesteld worden op de Switch allemaal?

[TBK001]

Ik heb begrepen dat wij alleen via SSH bij de switches kunnen komen.

[Kees]

https://www.wireshark.org...sers/200811/msg00165.html

Zoiets al bekeken?

[Verwijderd]

Dan zou je maar 1 pakket moeten zien, tenzij de CAM tabel van 1 van de switches niet goed werkt.
Kun je een stukje van de capture plaatsen? Even opletten dat je geen gevoelige info plaatst natuurlijk.
Ik ben vooral benieuwd naar de source/destination adressen.
En een uitdraai van de mac tabel op de switch zou ook helpen (een uitdraai van de config ook).

[muppet99]

Even alles rustig op een rijtje zetten:
1. Wat verwacht jij dat er gescheiden is? Dus welk verkeer mag niet welk wel?
2. Wat heeft de leverancier hiervoor gedaan?
3. Wat zijn de risico's (in jullie optiek)?
4. Wat zijn de risico's(uitkomst van de pentest)?
5. Zijn dit voor jullie kritieke punten?

Om even een voorbeeld te geven, thuis zie ik ook SMB verkeer voorbij komen, echter dat kan niet buiten zijn subnet komen. Dus voor mij is het risico 0, omdat niemand verder mijn netwerk op komt en de fysieke toegang tot de switches is bemoeilijkt)

[ Voor 29% gewijzigd door muppet99 op 05-07-2016 16:11 ]

[jvanhambelgium]

@TBK001

VLAN:
Momenteel nog niet ingericht.


Dit wil dus zeggen dat alle poorten eigenlijk gewoon in 1 groot "broadcast domain" gaan zitten en dan ga jij gegarandeerd héél wat brol zien voorbijvliegen op een (Windows) netwerk...
Het is van belang in detail na te gaan WAT soort "SMB verkeer" je ziet voorbijvliegen op je werkstation dat ergens op een aparte poort zit.

Welke SMB versie (1.0 , 2.x , 3.x ?) en welke SAMBA release draai je ?

[TBK001]

Dankjulliewel voor jullie antwoord. Ik ben nu thuis en kan niet bij deze info komen. Screenshot zal ik morgenvroeg even plaatsen naast alle andere info. Ik vind het in ieder geval erg fijn om te horen dat er al zoveel reacties met aanvullende vragen komen. Alvast heel erg bedankt, morgenvroeg meer info, 😁

[chaoscontrol]

Ik snap het probleem niet. Je linux servers hebben samba shares maar je vraagt je af waarom er smb verkeer is?

[TBK001]

Ik zie in Wireshark SMB verkeer tussen 2 systemen vanaf mijn werkstations die allemaal op een switch zijn aangesloten. Ik post morgenvroeg een screenshot.

[martinr]

Op niet-managed switches (dus simpeler dan de apparatuur die jij gebruikt) is mijn ervaring dat het in promiscuous mode zetten van de netwerkadapter door Wireshark er ook voor zorgt dat verkeer tussen andere poorten gecaptured kan worden. Verkeer dat anders niet op die poort aan zou komen (zonder promiscuous mode zie je op de switch weinig of geen data over die poort gaan, met die optie aan krijgt die poort van de wireshark-PC het ineens drukker). Dat geeft bij mij de indruk dat er meer gebeurd dan dat de NIC alleen maar op andere MAC-adressen gaat luisteren.

[TBK001]

Ik moet even kijken hoe ik de printscreen kan uploaden, die volgt zo nog.
@Kees, jouw uitleg zou een verklaring kunnen zijn waarom ik niet letterlijk al het netwerkverkeer zie, maar b.v. tussen die servers die ik benoemde.

Probleem is dat er zoveel data tussen die servers over de lijn gaat en soms ook clients dat data opnieuw opgebouwd kan worden.
Wanneer iemand hier een laptop in de aansluiting stopt en simpelweg de hele dag door zou luisteren dan zou deze simpelweg opnieuw de data op kunnen bouwen.
Dat is letterlijk de bevinding die in de pentest naar voren is gekomen.
Los van het feit dat het een veiligheidsrisico is wil je niet dat er zoveel data over het netwerk heen gaat.
Zal de prestaties niet ten goede komen dat er zoveel data overheen gaat.

Omzetten naar VLAN's gaat volgende week als het goed is gebeuren, dit om andere risico's verder te beperken, maar dit verschijnsel moet er gewoon uit.

Om de vragen van Muppet99 te beantwoorden:
1. Wat verwacht jij dat er gescheiden is? Dus welk verkeer mag niet welk wel? -> Ik verwacht geen direct verkeer tussen computers onderling te zien.
2. Wat heeft de leverancier hiervoor gedaan? -> Deze zou de switches dermate moeten hebben geconfigureerd dat deze hun werk zouden moeten doen zoals een switch dat behoord te doen, hun vonden het verkeer zelf ook al vreemd.
3. Wat zijn de risico's (in jullie optiek)? -> Mogelijkheden tot een datalek onder extreme omstandigheden.
4. Wat zijn de risico's(uitkomst van de pentest)? -> Zelfde als vorige punt.
5. Zijn dit voor jullie kritieke punten? -> We gaan het ook op andere manieren straks tegen plus dat een apparaat aansluiten op een beschikbare aansluiting een heel gedoe is, maar situatie is zeker niet wenselijk.

Niels1984nl, De CAM tabel, ik heb Google even moeten raadplegen.
Zo'n tabel, kan ik die zelf bijleren in de switch?

Martinr, Wireshark heb ik inderdaad in deze modus gezet, maar juist om al het mogelijke verkeer wat ik te pakken kan krijgen ook daadwerkelijk op te pakken.
Dit is dezelfde methode als die tijdens de pentest is gehanteerd.

Chaoscontrol, Het verkeer dat ik zie is juist niet voor mijn computer bestemd maar dient plaats te vinden tussen de 2 servers zelf, het doel van de switch.

Jvanhambelgium, Het Samba verkeer wat ik opvang is zodanig dat data door te luisteren simpelweg opnieuw opgebouwd kan worden.
De gebruikte Samba versie is: 2:4.3.9.

DukeBox, Ik moet hier even gaan kijken hoe ik bij de switches kan gaan komen zonder ruzie te krijgen.
De webinterface staat hier uit omdat in deze een lek schijnt te zitten, er kan zuiver via SSH ingelogt worden.

Alvast heel erg bedankt iedereen!!!!

[TBK001]

Plaatje Wireshark:

[PerfectPC]

Haha, wft, die switch lijkt inderdaad z'n cam tabel niet te vullen. Ik kan zelfs niet afleiden wat jouw ip adres zou moeten zijn...
Best de netwerkintegrator toch even laten terugkomen om die toestellen te swappen.

[TBK001]

PerfectPC, Begrijp ik jou goed dat je zegt dat dit een defecte switch is?

[Dikke Foaf]

Zie je meer dan enkel het SMB verkeer?
Als de switch z'n CAM tabel niet opvult krijg je een hub werking en zou je dus alle verkeer moeten zien, niet enkel SMB verkeer.

Door in te loggen op de switch kan je waarschijnlijk wel met een show commando kijken of hij MAC adressen leert op poorten.

Als er een probleem zou zijn met het memory in de switch, dan zou zoiets kunnen voorkomen. Kan misschien ook een firmware issue zijn, firmware up-to-date? Geen known issues bij HP? Switch eens uitgebreide selftest laten doen en kijken of daar iets uit komt. Case aanmaken bij HP als er support is. Of netwerkbedrijf laten komen en vragen dat zij dit allemaal nakijken.

Als er van de switch geen speciale features gebruikt worden, wat gebeurd er als er je een domme switch gebruikt?

[ Voor 8% gewijzigd door Dikke Foaf op 06-07-2016 09:20 ]

[TBK001]

Dikke Foaf, We zien veel meer dan alleen SMB verkeer, ik heb hier bewust een filter opgezet omdat ik hier makkelijk data mee naar voren kon halen. Als ik geen filter aanzet dan schiet het scherm letterlijk continue door met de grote hoeveelheid info die voorbij komt.

De firmware zou up-to-date moeten zijn, dit is een eis die opgegeven is bij levering. Dit dient nog getoetst te worden.

Ik heb over het hele probleem geen info kunnen vinden, bewust op het type switch gezocht.

Ik heb zojuist een mail gestuurd naar de leverancier met de opmerking over de CAM tabel. Even kijken wat daar voor een reactie op komt.

We hebben hier nog een paar switches liggen en het er al over gehad om dit te gaan testen, echter zitten we met het punt dat we niet zomaar de stekkers eruit kunnen trekken, dit moet echt gepland worden.

[Dikke Foaf]

Dan wijst dit inderdaad wel rechtstreeks naar een issue met het opvullen/uitlezen van de CAM tabel in de switch.

Beide switches tonen ditzelfde gedrag? Zoja, dan heb je nu gewoon 2 dure hubs in je netwerk staan

Een test met een domme switch zal dit dan bevestigen, als het goed is zal je unicast verkeer tussen 2 andere devices dan niet meer zien.

[TBK001]

Top, dan moet dit het probleem dus wel zijn, wordt ons vermoeden van een probleem met de switch op deze manier bevestigd. Ik wacht het antwoord van de leverancier even af, zodra ik antwoord heb en meer weet ga ik dat hier posten. Zal ooit ongetwijfeld iemand anders ook zijn voordeel mee kunnen doen.

Tot nu toe iedereen bedankt!

[muppet99]

Je mag gerust aan de leverancier vragen wat ze precies gedaan hebben. Dus technische details. Met een beetje geluk kunnen ze een technisch ontwerp oplepelen. Als klant heb je recht om dit soort informatie te krijgen en eigenlijk zonder te vragen Dit ook voor in het geval dat je eventueel door omstandigheden wil overstappen van leverancier. Met deze informatie kun je weer kijken of dit aansluit bij jullie wensen/eisen en zodoende kijken waar nu het probleem zit. De switches zijn voor jullie een black box, waardoor je alleen kan constateren.

[TBK001]

Muppet99, Dat is een goede tip, ik ga tijdens het contact tevens om deze info vragen. Ik heb reeds bevestigd gekregen dat ze erin duiken, dus even wachten op antwoord. Dankjewel!

[PerfectPC]

TBK001 schreef op woensdag 06 juli 2016 @ 09:09:
PerfectPC, Begrijp ik jou goed dat je zegt dat dit een defecte switch is?

Defect, of een firmware issue. DikkeFoaf heeft voor dit type behoorlijk wat bugfixes teruggevonden waaronder hiervoor.

[TBK001]

PerfectPC, Dat is super om te horen. Ergens een link waar ik de leverancier direct heen kan verwijzen om ze hiermee te confronteren?

[Dennism]

TBK001 schreef op woensdag 06 juli 2016 @ 11:09:
PerfectPC, Dat is super om te horen. Ergens een link waar ik de leverancier direct heen kan verwijzen om ze hiermee te confronteren?

Kun je niet zelf een kijken welke firmware versie er draait, en daarna dan even de changelogs van de verschillende versies nalopen. Daar staan meestal de resolved en openstaande issues wel in.

[GEi]

Ik volg deze draad met belangstelling. Maar ik zie niet wat jij ziet in deze screenshot. Kan je mij, en wellicht anderen, meenemen in hoe je kan zien dat de switch zijn cam tabel niet vult? En wellicht andere lering uit de figuur. Alvast bedankt.

PerfectPC schreef op woensdag 06 juli 2016 @ 09:06:
Haha, wft, die switch lijkt inderdaad z'n cam tabel niet te vullen. Ik kan zelfs niet afleiden wat jouw ip adres zou moeten zijn...
Best de netwerkintegrator toch even laten terugkomen om die toestellen te swappen.

[base_]

Allerlei IP adressen op het lokale subnet komen voorbij, normaliter krijg je alleen eigen verkeer voor/van eigen MAC adres op jouw switchpoort (tenzij port mirroring aanstaat).

[GEi]

Bedankt voor de toelichting.

[TBK001]

Ik heb mij net aangemeld bij HP om te kijken welke firmware voor deze switch beschikbaar is.
Huidige gegevens zijn in ieder geval:

HPE Comware Software, Version 7.1.045, Release 3111P02
Copyright (c) 2010-2015 Hewlett Packard Enterprise Development LP

Boot image: flash:/5130ei-cmw710-boot-r3111p02.bin
Boot image version: 7.1.045, Release 3111P02
Compiled Dec 21 2015 16:00:00

[Fidel]

Interessant topic.
Ikzelf heb ditzelfde probleem ook gezien bij een klant en toevallig ook met HP switches.
Volg het topic dus op de voet.

Ook daar was het SMB verkeer op alle poorten zichtbaar tezamen met al het andere verkeer.

[base_]

Broadcast berichten horen wel bij alle clients terecht te komen trouwens (destination x.x.x.255), bijvoorbeeld: https://wiki.wireshark.org/NetBIOS/NBNS

[Fidel]

base_ schreef op woensdag 06 juli 2016 @ 15:22:
Broadcast berichten horen wel bij alle clients terecht te komen trouwens (destination x.x.x.255), bijvoorbeeld: https://wiki.wireshark.org/NetBIOS/NBNS

Klopt. Maar niet de SMB chats en HTTP chats van andere systemen (zoals op wireshark screenshotje te zien is).

[BCC]

Fidel schreef op woensdag 06 juli 2016 @ 15:18:
Interessant topic.
Ikzelf heb ditzelfde probleem ook gezien bij een klant en toevallig ook met HP switches.
Volg het topic dus op de voet.

Ook daar was het SMB verkeer op alle poorten zichtbaar tezamen met al het andere verkeer.

Oh, foute firmware alu hoedjes tijd 😀😀

[TBK001]

Ik heb zojuist een mail verzonden naar HP met de vraag of ze mij kunnen aangeven wat de meest recente firmware is met de release notes. Ik kan geen lijst vinden op de site van HP.

Van de leverancier verder nog niets vernomen.

Zodra ik weer wat weet laat ik het hier horen.

[mhoogendam]

Hier vind je de laatste firmware versie: https://h10145.www1.hpe.c...c=us&prodSeriesId=7399420
Je huidige firmware is van januari 2016, er is dus een nieuwere versie beschikbaar.

Release notes: http://h20564.www2.hpe.co...cDisplay/?docId=c05185372

[ Voor 6% gewijzigd door mhoogendam op 06-07-2016 16:07 ]

[_Hades_]

Hebben jullie een nlb cluster in jullie netwerk? Wellicht hebben ze om dat goed te laten werken arp checking uitgezet (undo arp check enable in de config). Het effect van dat commando is dat mac learning uitgeschakeld word en je switch dus een hub is geworden .

[Yarisken]

_Hades_ schreef op woensdag 06 juli 2016 @ 19:47:
Hebben jullie een nlb cluster in jullie netwerk? Wellicht hebben ze om dat goed te laten werken arp checking uitgezet (undo arp check enable in de config). Het effect van dat commando is dat mac learning uitgeschakeld word en je switch dus een hub is geworden .

Lol waar is de tijd dat er nog "echte" hubs waren en je nog kon spreken van "network congestion" en dat je hele netwerk eruit knalde.
Los je zo'n zaken als nlb cluster niet beter op met een aggregate te maken van enkele poorten ?

[wizl]

Die screenshot zegt niet zo heel veel, behalve dat je VMware gebruikt. Draaien al die servers op VMware? Hoe zijn die (ik denk) ESX servers met die twee switches verbonden?

[Dennism]

Yarisken schreef op woensdag 06 juli 2016 @ 21:37:
[...]


Lol waar is de tijd dat er nog "echte" hubs waren en je nog kon spreken van "network congestion" en dat je hele netwerk eruit knalde.
Los je zo'n zaken als nlb cluster niet beter op met een aggregate te maken van enkele poorten ?

Bepaalde switches kunnen niet goed omgaan met NLB traffic, en gaan dit dan over alle poorten broadcasten. dit betreft vooral de vooral goedkopere series, o.a. Cisco en HP hebben op de duurdere series een commando dat je kan gebruiken om dit te voorkomen.

Ik los het op goedkopere switches meestal op een apart vlan voor de poorten in het NLB netwerk, daarmee los je het ook op.

[TBK001]

Zo even vroeg in de ochtend wat antwoorden vanuit mijn kant.

Mhoogendam, Dankjewel voor de firmware. Ik heb deze gedownload en de releasenotes gelezen, ik zie geen verbetering zo op het eerste oog staan m.b.t. dit probleem. Wel is de policy hier dat alle apparaten laatste firmware draaien, tenzij er een hele goede reden is dit niet te doen. Dit ga ik in ieder geval mee nemen.

Wizl, Wij draaien hier inderdaad VMWare met ESX servers. Dit zat in het project van het migreren van de switches.

_Hades_, Jouw punt m.b.t. NLB kan ik niet bevestigen. Dit was normaal niet het geval, er is echter e.e.a. ingericht zodat in geval van uitval het een en ander automatisch overgenomen wordt. Ik ga dit even achter de hand houden wanneer onze leverancier ons vragen gaat stellen. Vooropgesteld, als dit hiermee ingericht is dan is dit door hunzelf gedaan.

Zodra ik iets meer weet laat ik het hier horen!

[TBK001]

Huidige stand van zaken:

Leverancier geeft het volgende aan:
Een Switch broadcast altijd het verkeer naar alle poorten als dit wordt aangeboden door b.v. de windows server in jullie netwerk. (1 poort op de switch)
Dit wordt bij voorbeeld gebruikt voor het imagen naar alle werkplekken in het totale netwerk. Met andere woorden de switches werken zoals ze moeten werken.

Ik denk dat er momenteel wat ruis op de lijn zit over het betreffende verschijnsel, het betreft namelijk geen echte broadcast, de data wordt simpelweg op alle lijnen aangeboden.

In overleg met de leverancier heb ik zelf contact opgenomen met HP en daar een call aangemaakt. Het is nu even afwachten wat daaruit gaat komen. Uiteindelijk iets waar hopelijk niet alleen wij ons voordeel mee kunnen doen maar ook vele anderen die dit klaarblijkelijk volgen.

Ik kom er weer op terug.

[base_]

TBK001 schreef op vrijdag 08 juli 2016 @ 09:38:
Een Switch broadcast altijd het verkeer naar alle poorten als dit wordt aangeboden door b.v. de windows server in jullie netwerk. (1 poort op de switch)

wtf? een switch broadcast alleen broadcast packets naar alle computers:
"Broadcast packets have no specific destination address"
.255 voor een /24 subnet dus...., je hoort dus geen traffic met een ander bestemmingsadres als jezelf of .255 te zien.

[StevenK]

TBK001 schreef op vrijdag 08 juli 2016 @ 09:38:
Huidige stand van zaken:

Leverancier geeft het volgende aan:
Een Switch broadcast altijd het verkeer naar alle poorten als dit wordt aangeboden door b.v. de windows server in jullie netwerk. (1 poort op de switch)
Dit wordt bij voorbeeld gebruikt voor het imagen naar alle werkplekken in het totale netwerk. Met andere woorden de switches werken zoals ze moeten werken.

Ik denk dat er momenteel wat ruis op de lijn zit over het betreffende verschijnsel, het betreft namelijk geen echte broadcast, de data wordt simpelweg op alle lijnen aangeboden.

In overleg met de leverancier heb ik zelf contact opgenomen met HP en daar een call aangemaakt. Het is nu even afwachten wat daaruit gaat komen. Uiteindelijk iets waar hopelijk niet alleen wij ons voordeel mee kunnen doen maar ook vele anderen die dit klaarblijkelijk volgen.

Ik kom er weer op terug.

Andere leverancier zoeken? Deze snapt er duidelijk geen hout van.

[Spro]

TBK001 schreef op vrijdag 08 juli 2016 @ 09:38:
Huidige stand van zaken:

Leverancier geeft het volgende aan:
Een Switch broadcast altijd het verkeer naar alle poorten als dit wordt aangeboden door b.v. de windows server in jullie netwerk. (1 poort op de switch)
Dit wordt bij voorbeeld gebruikt voor het imagen naar alle werkplekken in het totale netwerk. Met andere woorden de switches werken zoals ze moeten werken.

Ik denk dat er momenteel wat ruis op de lijn zit over het betreffende verschijnsel, het betreft namelijk geen echte broadcast, de data wordt simpelweg op alle lijnen aangeboden.

In overleg met de leverancier heb ik zelf contact opgenomen met HP en daar een call aangemaakt. Het is nu even afwachten wat daaruit gaat komen. Uiteindelijk iets waar hopelijk niet alleen wij ons voordeel mee kunnen doen maar ook vele anderen die dit klaarblijkelijk volgen.

Ik kom er weer op terug.

Packet capture maken, en vragen waarom je verkeer ziet, wat geen broadcast is en niet voor jouw bestemd is.

base_ schreef op vrijdag 08 juli 2016 @ 11:49:
[...]


wtf? een switch broadcast alleen broadcast packets naar alle computers:
"Broadcast packets have no specific destination address"
.255 voor een /24 subnet dus...., je hoort dus geen traffic met een ander bestemmingsadres als jezelf of .255 te zien.

Tenzij je een firmware bug kopt (afgelopen weken nog tegengekomen) waar het mac adres niet geleerd wordt -> flooding all over the place

StevenK schreef op vrijdag 08 juli 2016 @ 11:50:
[...]

Andere leverancier zoeken? Deze snapt er duidelijk geen hout van.

Mee eens. Ik vind het sowieso al raar dat jij een ticket bij HP moet aanmaken, omdat de leverancier een niet (goed) werkende situatie oplevert.

@TS: Wil je geen klant bij ons worden, zo wil ik er wel 10 hebben

[TBK001]

Even een korte update, morgen gaat er hier wat getest worden, daarna hou ik iedereen op de hoogte.
Spro, Ik denk juist dat ik niet de meest makkelijke klant ben, ik blijf wel zeuren totdat het goed is.

[TBK001]

Hallo iedereen.
Zaak ligt bij HP, netwerkleverancier heeft wat gedaan op de switch, heeft helaas niets uitgehaald.
Heb inmiddels een dump van informatie geleverd en ze zijn ermee bezig.

To be continued.

[DukeBox]

Ben benieuwd. De HPE 5130 heb ik zelf nog niet mee gewerkt, vraag me af of dit er een van 3com of hp zelf is.

[Terran]

@ Ts Zitten de switches ook in een irf stack of staan ze stand alone?

[TBK001]

@Terran, hoe kan ik dit zien?
@DukeBox, ik heb iets mee gekregen van de persoon die het hier plaatste dat dit model hetzelfde zou zijn als een ander merk. Lijkt er dus een beetje op dat HP dergelijke spullen rebrand (of omgekeerd) als ik zijn opmerking 100% moet geloven.

Huidige status:
Ik ben info aan het uitwisselen met HP, er zit iemand op.
Zodra ik meer weet laat ik het hier weten.

[ralpje]

Volgens mij zijn dat rebranded Aruba switches. In ieder geval, de laatste HP switches die ik tegenkwam waren dat

[CH4OS]

ralpje schreef op woensdag 20 juli 2016 @ 12:03:
Volgens mij zijn dat rebranded Aruba switches. In ieder geval, de laatste HP switches die ik tegenkwam waren dat

En nu? Is er iets mis met Aruba switches?

[ralpje]

Nee. Er werd alleen gevraagd of dit native HP-switches zijn of rebranded 3Coms.

[Equator]

Volgens mij is de A5130 gewoon de opvolger van de A5120. Beide Comware switches. Of dit oud 3Com is durf ik dan niet te zeggen

De Aruba lijn wordt in de Product Bulletin nog gewoon als Aruba aangegeven. (Aruba 2930F bijvoorbeeld)

TBK001 schreef op woensdag 20 juli 2016 @ 11:55:
@Terran, hoe kan ik dit zien?

Waarschijnlijk zitten er dan 2 modules in de 10Gb aansluiting van de ene switch naar de andere. Maar dat is niet een 'dead giveaway'. Daarvoor zal je in de commandline moeten duiken.

# display irf [configuration]

[ Voor 44% gewijzigd door Equator op 20-07-2016 13:07 ]

[_Hades_]

5130 is comware, OS wat van 3com/H3C is gekomen inderdaad. De switches zijn nooit als 3com te krijgen geweest, dus om nou te spreken van rebranded..

De procurve lijn (wat os van hp is) is nu bij aruba ondergebracht. Dat is wel rebranded naar aruba. Volgens mij willen ze daar wel aruba os op gaan draaien maar dat weet ik dan weer niet zeker. :-)

Overigens wel slecht dat je partner je dit zelf laat uitzoeken. Ik zou als partner ook stervens benieuwd zijn wat hieruit komt (of dit nou een configfout betreft of niet)

[ Voor 20% gewijzigd door _Hades_ op 20-07-2016 19:26 ]

[DukeBox]

Denk niet dat het nu nog speeld maar 3com heeft wel regelmatig problemen gehad met standaarden. Net als IBM, "we love standards, lets make our own one".

[Olaf van der Spek]

Je hebt dus een security probleem en een performance probleem. De echte oplossing voor security is encyptie, toch? Doet SMB daar niet aan?
Wat betreft de switches, kun je eens een ping tussen host A en B starten en kijken of je dat verkeer op host C ziet?

Is een configuratie issue trouwens niet veel waarschijnlijker dan een bug in de switches?

[muppet99]

Maar je hebt nog geen antwoord van de leverancier wat ze precies gedaan hebben? We hebben alles gedaan wat we konden kan ook wijzen op onkunde of gebrek aan kennis. Maar zonder ontwerp/configuratie blijft dat gissen. Eventueel zou je zelf de configuratie in kunnen duiken. Show run en dan kun je het een en ander zelf bekijken. Sloopt niks.

[AjDuLion]

en hoe staat het met de stand van zaken firmware bug ? switch defect ? config fout ?

[Olaf van der Spek]

Er is iets misgegaan met het herconfigureren, hele internetverbinding plat dus Sebastiaan kan niet meer reageren.

[Vicarious]

Kan het niet zijn dat er een foute manier van clustering is ingesteld op die SMB server? Als er bijvoorbeeld 1 virtueel MAC-adres wordt gedeeld door dat hele cluster leert die switch niet op welke poort dat MAC-adres leeft en flood hij het uit alle poorten.

[Ghostface9000]

Ben ook benieuwd wat het probleem hier nu was :-)

[kokkel]

Beste TBK001,

Heb even meegelezen in je posts, als ik goed begrepen heb is de switch niet diepgaand geconfigureerd.
De switch dient als een standaard layer 2 defice, dit is een apparaat dat op basis van MAC beslissingen neemt. Dit wordt ondersteund uit de screenshot die je gepost hebt, daaruit haal ik dat de PC's en servers in hetzelfde segment zitten(vermoedelijk 192.168.0.0/24).

Een switch beperkt een collission domein, grootste voordeel ten opzichte van een hub.
Daarnaast kunnen de geavanceerdere switch snel verkeer schakelen dit gebeurd op basis van het source destination MAC adres (Op Cisco apparatuur heet dit meende ik CEF). Welke machine op welke poort zit met welk MAC adres staat in de CAM table.

Je netwerk lijkt plat ingericht, dat houdt in dat ieder systeem bij ieder systeem kan komen.
- De vraag die ik zou stellen is "waarom setten systemen verkeersstromen op naar destinations waar ze niks te zoeken hebben" (Lijkt mij een OS of applicatie issue).
- Wellicht dat een implementatie van isolated private VLAN's op netwerk niveau een oplossing kan bieden.
- Je zou de linux servers ook zo kunnen configureren dat deze alleen communicatie accepteerd van de benodigde machines.

Heb ook het vermoeden dat muppet99, met zijn post wou bereiken om jouw op een iets andere mannier naar je uitdaging te laten kijken.

[base_]

@kokkel: het gaat hier om basic switch functionaliteit, een switch hoort alleen broadcast messages te broadcasten, niet alles (of het nou binnen of buiten subnet valt is niet relevant, we hebben het hier niet over een router....), er komt allerlei zooi van andere ip adressen voorbij, dit zijn geen "gesette verkeerstromen" naar deze poort/pc, zoals al veel eerder vermeld lijkt het erop dat de cam table helemaal niet gevuld/gebruikt wordt.
In feite heeft hij nu dus een hele dure hub.... En nee firewalls, vlans en meer complexiteit zijn geen oplossing maar een omweg, beter een andere switch halen dan....

[Verwijderd]

HPE was tot voor kort 3com. De 5120 in ieder geval wel. Hang eens een cheapo switch tussen de wireshark pc en de 5130, of had je dat al gedaan?

base_ schreef op dinsdag 09 augustus 2016 @ 03:25:
[...]

En nee firewalls, vlans en meer complexiteit zijn geen oplossing maar een omweg, beter een andere switch halen dan....

Dat vind ik een gevaarlijke uitspraak zonder te weten hoe de infra (inclusief VMware) precies in elkaar zit.

Het zou zomaar kunnen dat er een fout gemaakt is in de koppeling van de VMware infra aan de fysieke infra, waardoor de MAC adressen van de VMware fileservers helemaal niet (juist) in de table opgeslagen worden of telkens weer verwijderd worden. Dat kan weer meerdere oorzaken hebben.

Voor ik zou aanraden om maar een andere switch te halen, zou ik toch zeker eerst eens wat configs en logs willen zien van zowel switches als VMware. En ik kan me voorstellen dat de TS die hier niet zomaar op een publiek forum gaat neerzetten.

Globaal gezien is er maar 1 reden voor een switch om L2 verkeer naar alle poorten te flooden: hij weet niet achter welke poort het destination MAC zit. Waarom die dat niet weet, dat wordt alweer een stukje ingewikkelder.

[ Voor 79% gewijzigd door Verwijderd op 09-08-2016 08:41 ]

[TBK001]

Even een update tussendoor.
Vrijdag is er een update uitgerold door onze leverancier op de switches.
Vervolgens zijn de switches gereboot.
Ze hebben samen met de systeembeheerder hier daarna gemeten, probleem leek opgelost.
Gisterenochtend heb ik daarna weer gemeten, probleem deed zich weer voor.
2 mogelijkheden:
- Ze hebben niet goed gemeten.
- Probleem wordt tijdelijk opgelost met een reboot.

Probleem ligt nu bij de leverancier en HP.
Ik ga hier bijna met vacantie.
Zodra ik weer terug ben geef ik een update van de situatie van dat moment.

@BazzH, probleem is momenteel dat ik niet zo de kabels eruit kan trekken, dat moet allemaal in goed overleg omdat er dan bepaalde producties stil gelegd moeten worden. Dit i.v.m. bepaalde hotfolders die steeds in de gaten gehouden worden e.d.

Ik hou iedereen op de hoogte en iedereen bedankt voor de reacties tot nu toe!

[TommyGun]

Anders even een fatsoenlijk bedrijf laten komen?

[dujour]

Vicarious schreef op woensdag 03 augustus 2016 @ 20:09:
Kan het niet zijn dat er een foute manier van clustering is ingesteld op die SMB server? Als er bijvoorbeeld 1 virtueel MAC-adres wordt gedeeld door dat hele cluster leert die switch niet op welke poort dat MAC-adres leeft en flood hij het uit alle poorten.

Dit hebben wij laatst ook gehad, lijkt er wel erg op.

[AjDuLion]

TBK001 schreef op dinsdag 09 augustus 2016 @ 10:00:
Even een update tussendoor.
Vrijdag is er een update uitgerold door onze leverancier op de switches.
Vervolgens zijn de switches gereboot.
Ze hebben samen met de systeembeheerder hier daarna gemeten, probleem leek opgelost.
Gisterenochtend heb ik daarna weer gemeten, probleem deed zich weer voor.
2 mogelijkheden:
- Ze hebben niet goed gemeten.
- Probleem wordt tijdelijk opgelost met een reboot.

Probleem ligt nu bij de leverancier en HP.
Ik ga hier bijna met vacantie.
Zodra ik weer terug ben geef ik een update van de situatie van dat moment.

@BazzH, probleem is momenteel dat ik niet zo de kabels eruit kan trekken, dat moet allemaal in goed overleg omdat er dan bepaalde producties stil gelegd moeten worden. Dit i.v.m. bepaalde hotfolders die steeds in de gaten gehouden worden e.d.

Ik hou iedereen op de hoogte en iedereen bedankt voor de reacties tot nu toe!

Vreemd, zijn jullie bij die test geweest of hebben ze zelf getest en dat geroepen ?

[jvanhambelgium]

dujour schreef op dinsdag 09 augustus 2016 @ 11:11:
[...]


Dit hebben wij laatst ook gehad, lijkt er wel erg op.

Idd, ook al last van gehad van soortgelijks ;-)

[Verwijderd]

http://www.cisco.com/c/en...s-switches/23563-143.html

Deze is wel interessant in deze context. Common causes for unicast flooding. Asymmetric routing ben ik al eens in het wild tegengekomen en STP topology changes ook.

En ach, als we dan toch bezig zijn:
https://www.vcloudnine.de...ing-switches-windows-nlb/

Het NLB verhaal in niet al te ingewikkelde bewoording. Let wel op, de HP switches uit deze blogpost draaien Provision en geen Commware. De commando's zullen dus niet werken op jouw switches.

[ Voor 38% gewijzigd door Verwijderd op 10-08-2016 06:26 ]

[djluc]

TBK001 schreef op dinsdag 09 augustus 2016 @ 10:00:
[...]

@BazzH, probleem is momenteel dat ik niet zo de kabels eruit kan trekken, dat moet allemaal in goed overleg omdat er dan bepaalde producties stil gelegd moeten worden. Dit i.v.m. bepaalde hotfolders die steeds in de gaten gehouden worden e.d.

Wat gebeurt er als je een switch tussen je werkstation en het netwerk hangt? Een normale switch zal dan niet alles naar jou door gaan sturen OF hetzelfde probleem vertonen. Je kan dan dus zien of dit gedrag zich ook voordoet op een normale switch of dat die het probleem oplost.

Dat kan je wellicht wat beter inzicht geven en kan wellicht gebruikt worden om duidelijker je leverancier te informeren. Dan kan je het tenslotte demonstreren.

[MagicTempest]

Er zijn inderdaad een aantal redenen voor unicast flooding.

1. Je CAM tabel loopt vol, of loopt juist heel snel leeg.
Voer de volgende commando's eens uit op de switch:
- display mac-address statistics
- display mac-address aging-time
2. Je hebt last van heel veel TCN berichten (zou vreemd zijn)
Kijk eens of het commando stp edged-port enable is toegepast op de switch

Het asymmetric routing probleem zou alleen op moeten treden bij meerdere vlans.

[Wim-Bart]

TBK001 schreef op vrijdag 08 juli 2016 @ 09:38:
Leverancier geeft het volgende aan:
Een Switch broadcast altijd het verkeer naar alle poorten als dit wordt aangeboden door b.v. de windows server in jullie netwerk. (1 poort op de switch)
Dit wordt bij voorbeeld gebruikt voor het imagen naar alle werkplekken in het totale netwerk. Met andere woorden de switches werken zoals ze moeten werken.

Grotere onzin bestaat er niet. Een switch zet alleen verkeer door naar een andere poort wanneer port monitoring aan staat. Per definitie is verkeer op een goed geconfigureerde switch tussen twee werkstations nooit af te luisteren. Alleen broadcast verkeer moet je op andere poorten kunnen zien.

Moet je voorstellen wat als jij met 1 Gbps een bestand leest, dan zou bij ieder werkstation, volgens jullie leverancier de netwerkkaart met 1Gbps belast moeten worden.

Overigens wat ik in de screenshot zie is een probleem wat op treed met verdwenen MAC adressen. Ik zie namelijk dat een systeem bestanden wil benaderen en de switch weet niet meer waar het MAC adres van de server zich bevindt.

Oorzaken:

• Defecte switch/firmware: MAC adressen worden niet onthouden;
• BDPU filtering tussen twee switches, switches weten niet van elkaar dat er meerdere MAC adressen achter hun link zitten;
• Verkeerd geconfigureerd (Rapid) Spanning Tree;
• Linux LVS achtige oplossing waarbij virtuele MAC adres niet goed geregistreerd wordt op de switch;
• Windows NLB oplossing waarbij virtuele MAC adres niet goed geregistreerd wordt op de switch;
• 1 van bovenstaande op een ESX host;
• Knipperende LAN verbinding onder ESX waardoor MAC adressen van de VM's steeds van poort wisselen.
• Verkeerd geconfigureerde load balancing met meerdere netwerk kaarten op een server, hierbij zweeft het Virtule MAC adres en mag dit adres alleen maar op 1 poort actief zijn.

Kortom, dit mag niet voor komen.

Wanneer je NLB of LVS achtige oplossing hebt, kan je ook de "Cisco methodiek" gebruiken. Registreer de MAC adressen fixed op alle poorten waar het voor kan komen.

[MagicTempest]

Wim-Bart schreef op zaterdag 13 augustus 2016 @ 20:49:
[...]

• BDPU filtering tussen twee switches, switches weten niet van elkaar dat er meerdere MAC adressen achter hun link zitten;

BPDU filtering zou hier geen invloed op moeten hebben. Ook zonder Spanning Tree kunnen switches meerdere MAC adressen op één poort leren. BPDU filtering kan naar mijn mening het probleem niet zijn omdat je dan eerder een loop krijgt, en een loop zorgt er (in theorie) niet voor dat het verkeer geflood wordt, maar eerder dat je netwerk er in zijn geheel mee stopt.

• Verkeerd geconfigureerd (Rapid) Spanning Tree;

Verkeerd geconfigureerde STP bedoel je waarschijnlijk een loop mee. In dat geval zou het netwerk ondertussen al lang volledig op zijn gat liggen.

[kraats]

TBK001 schreef op dinsdag 09 augustus 2016 @ 10:00:
Probleem ligt nu bij de leverancier en HP.
Ik ga hier bijna met vacantie.
Zodra ik weer terug ben geef ik een update van de situatie van dat moment.

Even uit interesse.. Is er nog iets uitgekomen?

[Verwijderd]

MagicTempest schreef op zondag 14 augustus 2016 @ 01:37:
[...]


BPDU filtering zou hier geen invloed op moeten hebben. Ook zonder Spanning Tree kunnen switches meerdere MAC adressen op één poort leren. BPDU filtering kan naar mijn mening het probleem niet zijn omdat je dan eerder een loop krijgt, en een loop zorgt er (in theorie) niet voor dat het verkeer geflood wordt, maar eerder dat je netwerk er in zijn geheel mee stopt.


[...]


Verkeerd geconfigureerde STP bedoel je waarschijnlijk een loop mee. In dat geval zou het netwerk ondertussen al lang volledig op zijn gat liggen.

Met verkeerd geconfigureerd STP bedoelt hij waarschijnlijk de bridge priority op basis waarvan de STP root bridge gekozen wordt. Of access poorten die niet als Edge geconfigureerd zij waardoor een aangesloten device een root bridge election kan aftrappen.

[TBK001]

Het is een tijd geleden, maar het probleem is opgelost!
Uiteindelijke voorstel van HP, alles uit het platte VLAN1 halen en 1:1 onderbrengen in een nieuw opgezet VLAN en oude VLAN1 uitzetten.
Alle IP adressen en alle instellingen verder hetzelfde gelaten.

Afgelopen maandag is alles samen met onze leverancier overgezet.
Vanaf dan is er uitvoerig getest, Wireshark op de achtergrond laten draaien, alles werkt perfect en is blijven werken.

Oplossing is dus voor iedereen die met dit probleem te maken heeft, nieuw VLAN aanmaken en alles overzetten naar het nieuwe VLAN en het oude VLAN uitzetten.
Het heeft lang geduurd, maar alles is naar tevredenheid opgelost, hier is iedereen gelukkig met het resultaat.
Hoe / wat / waarom deze oplossing werkt is niemand duidelijk, maar deze oplossing voorgesteld door HP werkt uiteindelijk wel.
Wat dus ook de indruk wekt dat dit misschien wel ergens een bekend probleem is bij HP.

Wat mij betreft, case closed.
Iedereen heel erg bedankt voor zijn of haar input.
Ik hoop dat er mensen zijn die wat hebben aan deze discussie!

[Brahiewahiewa]

Ik zou zo blij niet zijn. Kennelijk hebben èn je IT-dienstverlener èn je leverancier (HP) geen flauw benul wat er aan de hand was. Je hebt dus geen enkele garantie dat 't morgen niet weer gebeurt

[DiedX]

Brahiewahiewa schreef op woensdag 28 september 2016 @ 23:18:
Ik zou zo blij niet zijn. Kennelijk hebben èn je IT-dienstverlener èn je leverancier (HP) geen flauw benul wat er aan de hand was. Je hebt dus geen enkele garantie dat 't morgen niet weer gebeurt

Eens. Aan de andere kant: KBK001 heeft laten weten dat hij er wél verstand van heeft, en dat hij door kan bijten.

Ik zou alleen wel even nadenken over je dienstverlener

[ik222]

Als je deze suggestie krijg van de leverancier dan zou ik zelf nog steeds vragen naar een verklaring waarom dit een feature is en geen bug. Dit klinkt namelijk gewoon als een bug in de software waarvoor je nu een workarround actief hebt.

Even los van het feit dat VLAN1 niet gebruiken natuurlijk wel een good practice is.

[Olaf van der Spek]

ik222 schreef op donderdag 29 september 2016 @ 17:34:
Even los van het feit dat VLAN1 niet gebruiken natuurlijk wel een good praktice is.

Want?

[ik222]

Meestal is dat het default VLAN op een switch dus als een poort per ongeluk open staat komt hij in dat VLAN. Daarnaast wordt het soms gebruikt voor spanningtree verkeer waardoor je het niet van trunks mag halen of juist niet tagged op een trunk mag zetten. Kan bijvoorbeeld een issue zijn als je (later) spanningtree tussen verschillende vendors implementeert.

Kortom handiger om het niet te gebruiken, ik geloof dat de meeste vendors ook aanraden het niet te gebruiken.

[ Voor 4% gewijzigd door ik222 op 30-09-2016 16:24 ]