Willekeurige netwerkhikjes

[cyberstalker]

In ons serverpark hebben wij onverklaarbare, willekeurige, kortdurende hikjes in onze netwerkverbinding. Om te debuggen draaien wij een script dat elke minuut vanaf alle servers een traceroute doet naar alle andere servers.

In bijna alle gevallen gaat dit goed, maar af en toe rapporteert dit script naar een andere server niet te kunnen tracerouten. Op het moment dat je dan op die server inlogt en het handmatig doet is het probleem alweer weg.

De servers zijn verdeeld over drie racks welke met elkaar in contact staan via juniper switches met een glasvezelkabel ertussen. Vanwege een recentelijke uitbreiding zijn er twee losse /24 subnets welke nog gemerged moeten worden. Alle servers hebben dus een extra route toegevoegd om dit subnet te kunnen bereiken.

De problemen zijn volkomen random. Server X kan niet tracerouten naar server G. De volgende keer is het server B die server H niet kan vinden. Het kan optreden bij servers in andere racks, of in hetzelfde rack, tussen servers in hetzelfde subnet of in het andere subnet.

De servers zijn een combinatie van
- M610's
- M620's
- R310's

De meeste servers zijn uitgerust met een broadcom NetXtreme II uit de BCM serie. Alle servers gebruiken twee netwerkpoorten, die via bonding (balance-tlb) zijn geconfigureerd.

Wat het voor mij lastig te traceren maakt is het feit dat het probleem net zo snel verdwijnt als het verschijnt en ik dus niet verschillende instellingen kan proberen om te zien of dat het probleem oplost.

Wat kan ik nog meer doen om de oorzaak te vinden en dit op te lossen?

[JMW761]

Wat zeggen de logs van de Junipers?

[Rolfie]

arp issue?

[cyberstalker]

Heb je een specifieke log die relevant is? Ik heb de meeste bekeken en de enige die ik regelmatig zie terugkomen is

code:

mib2d[950]: SNMP_TRAP_LINK_DOWN: ifIndex 561, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-0/0/30
chassism[932]: IFCM: no handler for command subtype 238
chassism[932]: IFCM: no handler for command subtype 238

Arp issue zou natuurlijk kunnen, hoewel ik meen dat dat enkel zou kunnen optreden door een ander onderliggend probleem. Hoe kan ik dit uitsluiten? Op het moment dat ik ga kijken werkt alles, en staat de arp entry er natuurlijk gewoon netjes in. arp -n toont voor alle adressen gewoon netjes een macadres.

[Brahiewahiewa]

cyberstalker schreef op woensdag 28 november 2012 @ 14:11:
...In bijna alle gevallen gaat dit goed, maar af en toe rapporteert dit script naar een andere server niet te kunnen tracerouten...

Hoe rapporteert dat script?
Maw: een foutmelding à la "winsock error 12345" of "Name or service not known" zou handig zijn

Terzijde: de laatste keer dat ik de bonding software van BMC gebruikte, was die nogal braque.
Maar dat is alweer 5 jaar geleden.

Enneh, welke OSen draaien die servers?

[josvane]

Kun je geen monitorport aan maken en dan met wireshark traces zien of daar wat zinnigs te zien is. Als je wireshark laat loggen met circulair logging dan loopt de pc waar wireshark op staat niet vol.

Als je dan de traceroute ook laat lopen, kun je daarop zoeken in wireshark

[cyberstalker]

Het script is nu heel simpel. Het start 'traceroute -4 -N 1 <server> | tail -n +2 | awk '{print $2}' grep -v '^*&' op en kijkt of de output gelijk is aan de servernaam.

De servers waar het om gaat draaien allemaal op Ubuntu, de meeste op 12.04, sommige op 10.04.

Wireshark is inderdaad een goede optie. Ik zal dit installeren op een PC met de minste netwerkactiviteit en de logfile bekijken.

[Remco]

cyberstalker schreef op donderdag 29 november 2012 @ 21:10:
Wireshark is inderdaad een goede optie. Ik zal dit installeren op een PC met de minste netwerkactiviteit en de logfile bekijken.

Ik zou dan wel port mirroring aanzetten. Anders zie je nog niet veel.

[Brahiewahiewa]

cyberstalker schreef op donderdag 29 november 2012 @ 21:10:
Het script is nu heel simpel. Het start 'traceroute -4 -N 1 <server> | tail -n +2 | awk '{print $2}' grep -v '^*&' op en kijkt of de output gelijk is aan de servernaam...

Je zou ook

traceroute -4 -N 1 <server> >> logfile.log

een dagje kunnen laten draaien, dan zie je misschien meteen waar het misgaat.
Merk je die netwerkhikjes ook in andere situaties op, of alleen maar in dit script?
Voor je het weet zit je je de pleuris te zoeken in netwerktraces, voor iets wat een probleem met je tempfolder of een bug in cron blijkt te zijn.

[WhizzCat]

Dit zou echt van alles kunnen zijn. Helaas geef je eigenlijk te weinig informatie om iets zinnigs te kunnen zeggen. Die toegevoegde route bv. gaat dat naar een router of l3 switch of wat? Hoe zijn de Junipers verbonden? Proprietary stack of bv. LACP? Zijn je servers per Bond op 1 server aangesloten of verdeeld over 2 switches? (soms kan dit issues opleveren) Welk merk zijn de servers zelf?

[decramy]

Zit er een CPU of een interface van een switch vol? Dit kun je met SNMP uitlezen en vervolgens in tools als munin/cacti weergeven.

Komt het probleem overal voor? Kun je je switches allemaal een IP geven en vervolgens met smokeping data verzamelen? Probeer het probleem te localiseren tot een bepaalde switch

[wagenveld]

Even ervan uitgaande dat het Windows is, probeer eens op een testserver de offloading features uit te zetten: Information about the TCP Chimney Offload, Receive Side Scaling, and Network Direct Memory Access features in Windows Server 2008
Broadcom drivers up to date? Verder de teaming software van BC is niet geweldig, als bovenstaand niks uithaald dan zou ik eens een testserver met een enkele NIC uitproberen.

[decramy]

wagenveld schreef op vrijdag 30 november 2012 @ 20:11:
Even ervan uitgaande dat het Windows is,

cyberstalker schreef op donderdag 29 november 2012 @ 21:10:
De servers waar het om gaat draaien allemaal op Ubuntu, de meeste op 12.04, sommige op 10.04.

[joopv]

Over je logfile:
Wat is hier: ifName ge-0/0/30 op aangesloten en waarom gaat die regelmatig up en down?

Is er een correlatie tussen die log entry's en je hiks?

Kan het zijn dat er een loop in je netwerk zit? Dat kan kortstondige broadcast storms veroorzaken die hele netwerk doen vollopen. Dat zul je wel terug kunnen zien op een wireshark machine, ook zonder het aanmaken van een monitor poort.

En als laatste: de servers die elkaar soms niet kunnen bereiken, zitten die in hetzelfde subnet of loopt dat via een router?

[ Voor 13% gewijzigd door joopv op 30-11-2012 22:03 ]

[cyberstalker]

WhizzCat schreef op vrijdag 30 november 2012 @ 19:38:
Dit zou echt van alles kunnen zijn. Helaas geef je eigenlijk te weinig informatie om iets zinnigs te kunnen zeggen. Die toegevoegde route bv. gaat dat naar een router of l3 switch of wat? Hoe zijn de Junipers verbonden? Proprietary stack of bv. LACP? Zijn je servers per Bond op 1 server aangesloten of verdeeld over 2 switches? (soms kan dit issues opleveren) Welk merk zijn de servers zelf?

Alle servers zijn verbonden via de Juniper switches. Hoewel ze dus in een ander subnet zitten zit er geen router tussen. Om die reden heb ik dus een extra route toegevoegd om te voorkomen dat dit via de default gateway wordt gerouteerd.

De precieze configuratie van de communicatie tussen de junipers weet ik niet, aangezien dat voor ons is opgeleverd door leaseweb (wij huren de junipers van hen). Wel weet ik dat LACP nog niet is ingesteld. Dit willen wij wel heel graag, maar hiervoor moet éérst het virtual chassis geconfigureerd worden, wat enige downtime tot gevolg heeft (die we eerst moeten inplannen, etc...). Om die reden zijn de beide aansluitingen die samen de bond0 interface bieden steeds op één switch aangesloten (waarbij ik weet dat dat niet de optimale configuratie is).

Alle servers zijn van het merk Dell.

decramy schreef op vrijdag 30 november 2012 @ 19:40:
Zit er een CPU of een interface van een switch vol? Dit kun je met SNMP uitlezen en vervolgens in tools als munin/cacti weergeven.

Komt het probleem overal voor? Kun je je switches allemaal een IP geven en vervolgens met smokeping data verzamelen? Probeer het probleem te localiseren tot een bepaalde switch

Ik ga me hier in verdiepen. De switches hebben sowieso allemaal een IP adres en SSH geconfigureerd zodat ik erop kan inloggen. Zoals gezegd, het probleem is volkomen random en treedt dus op alle switches op. Dit kan tussen servers zijn die aangesloten zitten op verschillende switches (via de fiber kabel) of op servers die op dezelfde switch zijn aangesloten. Hier heb ik geen patroon in kunnen ontdekken. Ik vermoed dus dat het probleem niet in één specifieke switch zit.

joopv schreef op vrijdag 30 november 2012 @ 20:39:
Over je logfile:
Wat is hier: ifName ge-0/0/30 op aangesloten en waarom gaat die regelmatig up en down?

Is er een correlatie tussen die log entry's en je hiks?

Kan het zijn dat er een loop in je netwerk zit? Dat kan kortstondige broadcast storms veroorzaken die hele netwerk doen vollopen. Dat zul je wel terug kunnen zien op een wireshark machine, ook zonder het aanmaken van een monitor poort.

En als laatste: de servers die elkaar soms niet kunnen bereiken, zitten die in hetzelfde subnet of loopt dat via een router?

Dit zal ik moeten uitzoeken.

Ik weet wel dat de fiber kabels in een loop zijn aangesloten. Switch 1 zit met een kabel naar switch 2, switch 2 zit met de andere poort naar switch 3, switch met de andere poort naar 4 en 4 met de andere poort weer naar 1. Dit is ons zo aangeraden door leaseweb.

De servers die elkaar soms niet kunnen bereiken zitten soms wel en soms niet in hetzelfde subnet, maar lopen nooit via een router.

[joopv]

Spanning-tree zal er voor moeten zorgen dat van die 4 switches met glaspoorten er 1 poort in blocking staat.

Die laatste opmerking klopt niet. 2 systemen die niet in hetzelfde subnet zitten kunnen elkaar alleen via een router bereiken.

[WhizzCat]

joopv schreef op zaterdag 01 december 2012 @ 20:44:
Spanning-tree zal er voor moeten zorgen dat van die 4 switches met glaspoorten er 1 poort in blocking staat.

Die laatste opmerking klopt niet. 2 systemen die niet in hetzelfde subnet zitten kunnen elkaar alleen via een router bereiken.

Ja, maar wel als de Juniper ook L3 doet, wat denk ik het geval is. Ergens zit er dus wel een "router"-engine tussen. Maar goed, dat is nog steeds een aanname.

Poorten die staan te klapperen kan idd een spanning tree issue zijn. Dat zou verklaren waarom het op alle switches mis gaat. Ik zou eens kijken naar topology changes en of de root bridge en/of priorities goed staan, blocking poorten etc. Het lijk iig een L2 issue

[JMW761]

Denk dat wij verder alleen kunnen assisteren als we de daadwerkelijke (anoniem gemaakte) configs van de junipers onder ogen krijgen.

Zou het niet zoeken in de servers, maar in de config van je netwerklaag, zoals de rest van de reageerders ook al aangeeft.

[Kabouterplop01]

En de log messages van die switches met de timestamps erbij...Op het moment dat het fout gaat!

[skai21]

Brahiewahiewa schreef op donderdag 29 november 2012 @ 17:05:
[...]

Hoe rapporteert dat script?
Maw: een foutmelding à la "winsock error 12345" of "Name or service not known" zou handig zijn

Terzijde: de laatste keer dat ik de bonding software van BMC gebruikte, was die nogal braque.
Maar dat is alweer 5 jaar geleden.

Enneh, welke OSen draaien die servers?

Jup ook de recente BMC doet het niet goed, vind hem altijd bagger.
In het begin lijkt alles goed te gaan maar na een tijdje krijg je heel vreemde verschijnselen net als je nu hebt.

Server wel pingbaar, maar inloggen lukt niet.
Of wel DB connectie maar ODBC niet goed dat soort gevalletjes.

Wat dus vaak ook wijst op een brakke Trunking/load balancing software / netwerkkaart.

Wat je zou kunnnen proberen is om op een Rack gewoon je load balancing uit te zetten.
En gewoon via 1GB gaan werken.. als dit performance technisch gezien mogelijk is.

als je dan na een lange tijd geen errors hebt op dat rack weet je dat het in de load balancing is.

Anders zit het ergens anders.

[bigfoot1942]

Ik zou voorstellen Intel nics te gaan gebruiken. Broadcom heb ik de afgelopen 3 jaar een 10 tal keren kunnen aanwijzen als veroorzaker van iSCSI problemen (en dat Idd gewoon gevoelig IP verkeer)