Bekijk Volledige Versie : Geen netwerk na reboot
Het volgende probleem heb ik al jaren in ons datacenter. We hebben weinig Windows dozen, dus het is vooral vervelend en niet meteen een enorm issue, maar zie het toch graag opgelost:
Op Windows systemen die rebooten na (meestal) Windows Update komt van tijd tot tijd de netwerk verbinding niet tot stand. Als je lokaal of via IPMI kijkt in in Control Panel zijn de kaarten wel up, maar ze geven dan aan "No Connectivity". De machines hebben een statisch IP. De kaart disablen/enablen lost het probleem op. Op machines zonder IPMI geven we de server een trap met de APC MasterSwitch. Dat werkt ook _altijd_.
Collega ISP heeft dit zelfde issue ook met VM's, dus het is ook niet gebonden aan ons model netwerkkaart (e1000).
Het vreemde is wel dat ik dit probleem thuis nog nooit ben tegengekomen. Ik vermoed dan ook dat het iets in ons netwerk is. Misschien een protocol als STP dat draait of andere packets waar Windows van op hol slaat.
Ik heb dit probleem op MS fora gegooid, maar dan krijg je vooral antwoorden waar je niets mee kan als probeer een nadere kabel, misschien is je DHCP server stuk (die we niet gebruiken) en meer van dat soort andere onzin.
Omdat we dit op _al_ onze Wnidows dozen hebben (het zijn er niet zoveel) moet iemand anders dit probleem toch ook herkennen. Anyone? :)
Ik heb de ervaring dat de e1000 soms wel eens lastig wil doen in combinatie met bepaalde switches. Als je de autonegotiation op de kaart uit zet (en bij voorkeur ook op de switch) door de netwerk snelheid en duplex te forceren gaat het meestal wel goed.
Als je collega e1000 emulators gebruikt voor zijn vm's, dan zou je wel dezelfde network card gebruiken. Ik neem aan dat je dat hebt gevraagd? Wat mind zegt kan zeker helpen mocht het network gerelateerd zijn. Wij zelf gebruiken heel veel e1000 emulators voor onze vm's, ook vaste servers hebben e1000 of andere intel varianten. Gelukkig komen zulke rare problemen niet bij ons voor.
Nouja, wij draaien primair Linux en die draaien ook op de e1000 kaarten. Daar heb ik dit probleem nog nooit gezien. Maar, het is inderdaad het proberen waard. Zal het zodirect meteen eens doen.
Overigens, de VMmetjes gebruiken die VMWare driver. vmxnet uit me hoofd dacht ik.
Bij VMware hangt er vanaf wat je gekozen hebt als emulator, als dit vmxnet is dan gebruik je deze. Standaard word de e1000 emulator gekozen bij een VMware setup.
Er zijn hier vrij veel Windows systemen in beheer en herken het probleem niet dus je zou toch eens naar de overlappende factor tussen jullie setup en je concullega kunnen zoeken.
Misschien ook wel handig te vermelden op welke Windows smaak de machines draaien, driver versies van de netwerkkaart, staat er bepaalde antivirus/firewall software geïnstalleerd en meer van dit soort nuttige informatie.
Versie van WIndows maakt niet uit. w2k3 en w2k8 doen het allebei. Het moet inderdaad iets in ons netwerk zijn, want thuis heb ik het probleem niet. Terwijl ik daar wel het zelfde merk (Cisco) switches gebruik. Het zal dus een specifiek protocol zijn in 't DC wel draait en elders niet. Verder gewoon de standaard windows firewall, geen anti virus.
Drivers is ook het probleem niet (nouja, of wel, aangezien Linux het niet heeft) maar in ieder geval de WIndows drivers als de echte Intel.com drivers hebben hetzelfde probleem. In alle eerlijkheid zou ik niet weten waar ik moet zoeken.
Versie van WIndows maakt niet uit. w2k3 en w2k8 doen het allebei. Het moet inderdaad iets in ons netwerk zijn, want thuis heb ik het probleem niet. Terwijl ik daar wel het zelfde merk (Cisco) switches gebruik. Het zal dus een specifiek protocol zijn in 't DC wel draait en elders niet. Verder gewoon de standaard windows firewall, geen anti virus.
Drivers is ook het probleem niet (nouja, of wel, aangezien Linux het niet heeft) maar in ieder geval de WIndows drivers als de echte Intel.com drivers hebben hetzelfde probleem. In alle eerlijkheid zou ik niet weten waar ik moet zoeken.
Heel wilde gok :
Kijk of op je switch 'spanning-tree portfast' (Cisco IOS syntax) wel aanstaat op die poorten.
Zonder dat zal een switchpoort wel opkomen, maar de eerste 30 seconden geen verkeer doorlaten.
Als de server in die eerste periode 'iets' doet met het netwerk om te kijken of er verbinding is, zou je misschien dit probleem kunnen krijgen.
Jij gebruikt geen DHCP, maar dit probleem heb je dan vaak ook met apparaten die in die eerste 30 seconden DHCP proberen en dan stoppen met retryen voordat het netwerk op is.
Het probleem is niet zo specifiek. Als ik de server namelijk reboot middels de APC op het moment dat ie geen netwerk heeft, dan werkt het na de reboot _altijd_. Als het probleem STP zou zijn dan zou 't soms wel na een update moeten werken, en soms ook niet tijdens een APC boot.
Het probleem zit 'm ergens in Windows. Het is namelijk raar dat na een "vrijwillige" reboot (dus, start -> reset of windows update) het probleem zich vrijwel altijd voordoet, maar na een cold reset niet (APC powerswitch).
't is net of Windows ergens een vlaggetje zet bij het afsluiten waardoor het mis gaat.
dreamhost_nl
18/07/12, 15:45
Dan kun je net zo goed altijd via APC booten indien dit later alsnog moet. Het verschil zal hem zitten in de soft reboot en hard reboot functionaliteit waardoor dit optreed.
Tuurlijk kan dat, maar het is natuurlijk geen oplossing :)
Het probleem is niet zo specifiek. Als ik de server namelijk reboot middels de APC op het moment dat ie geen netwerk heeft, dan werkt het na de reboot _altijd_. Als het probleem STP zou zijn dan zou 't soms wel na een update moeten werken, en soms ook niet tijdens een APC boot.
Dat verschil is wel gek, maar het hoeft niet deze verklaring uit te sluiten :
Als Windows bij een soft-reboot altijd snel na het opkomen van de netwerk kaart iets eenmalig test, en na een cold reboot of niet, of met meer retries zou je dit symptoom krijgen.
De STP blocking/listening/learning tijd is constant (staat in de spec), en de opstart tijd van een bepaalde server, in elk geval het kernel/netwerk stack deel ervan, is dat in principe ook, dus om die reden zul je geen "af en toe" gedrag krijgen.
Een "soft reboot" is voor WIndows gezien ook een reboot. Zowel bij stroom uit/aan als bij een reguliere reboot reset de BIOS de NICs en gaat de link down. Dan begint het STP feest dus opnieuw. Maar ik heb even gekeken, portfast staat al aan op alle poorten. STP is dus het probleem niet.
Overigens, alleen de kaart disablen/enablen werkt (of rebooten). De UTP eruit en er weer in helpt niet. Als het een STP iets zou zijn zou dat ook moeten helpen.
Bij een APC reboot gaat de stroom van het moederbord, bij een soft reboot niet dus dan zou je eerder aan een hardware iets denken. Verschillende server types of (nagenoeg) allemaal dezelfde (of zelfde merk)?
Maar een reboot via console helpt meestal ook. Het is echt dat een reboot op welke manier dan ook uiteindelijk altijd werkt. Ik ben meer nieuwsgiering waarom het soms _niet_ werkt :-). Een collega ISP heeft exact hetzelfde probleem bij zijn servers (Ook SuperMicro) maar ook bij virtuele machines.
Maar is er dan helemaal niemand die dit probleem herkent? :)
Een "soft reboot" is voor WIndows gezien ook een reboot. Zowel bij stroom uit/aan als bij een reguliere reboot reset de BIOS de NICs en gaat de link down. Dan begint het STP feest dus opnieuw. Maar ik heb even gekeken, portfast staat al aan op alle poorten. STP is dus het probleem niet.
Het punt is niet (speciaal) STP, maar of windows verwacht binnen een paar seconden na link up ook verkeer door de switch te krijgen. STP is alleen de oorzaak dat het zonder portfast tot 30 seconden na link up verkeer in een zwart gat gooit.
Als windows dat in het ene geval wel, en andere geval niet verwacht zou dat het probleem zijn.
Maar goed, dat heb je uitgesloten nu portfast overal aan staat.
Ik herken het probleem, paar keer voorbij zien komen. Als ik het mij goed herinner, _altijd_ na een Windows update. Nooit de oorzaak kunnen achterhalen.
Ik heb het zelf nog niet eerder voorbij zien komen. Zal het eens in de gaten houden.
Staat er in het eventlog toevallig iets zinnig?
Ik heb ook wel eens soortgelijke problemen gezien in combinatie met NAC, waar de authenticatie om de een of andere reden soms mislukte en de server daardoor in een andere VLAN terecht kwam. Moest je dus NAC gebruiken op de switch, misschien eens in die richting kijken.
In eventlog staat voor zover ik weet niets, maar zal het de volgende keer eens bekijken. We gebruiken geen NAC of andere authenticatiesystemen op onze switches.
Nitroserve
06/08/12, 12:26
Hier ook weleens gehad, niet bij elke reboot of update.
Gebeurt misschien 1 keer per maand en wordt direct door onze interne 'checks' opgepakt en opgelost (reboot NIC).
Enige overeenkomst lijkt hier Windows OS op Supermicro servers.
Met 2003 was het probleem erger, met 2008 R2 komt het (hier) nauwelijks meer voor.