Verdwijnende frames

[MagicTempest]

Ik zit met een probleem waar ik ondertussen zelf echt niet meer uitkom. Wellicht dat jullie wat ideeën hebben om mij in de juiste richting te duwen.

Ik zal eerst de situatie even uitleggen:

We hebben een aantal servers die via pxe en tftp moeten booten om op die manier van een OS te worden voorzien. Deze servers zijn allemaal virtueel en draaien in VMware op UCS. De TFTP server die ze moeten benaderen draait op de zelfde virtuele infrastructuur, maar in een ander vlan.

Voor de tftp client om de tftp server te bereiken moet het achtereenvolgens door de volgende (virtuele) apparaten heen:

VM --> Nexus 1000v --> Interconnect switch --> Nexus 5K -->Nexus 7K --> Nexus 5K --> Interconnect switch --> Nexus 1000v --> TFTP server

De nexus 5K's en 7K's zijn redundant. De 7K's draaien hsrp waardoor altijd dezelfde switch routeert. De 5K's zijn L2 switches en doen dus niets met L3.

Het probleem zit hem in de communicatie tussen de 7K en de 5K. Nadat er gerouteerd is naar het andere vlan verdwijnt het verkeer. Het is gewoon echt weg. Op de weg naar de 7K gaat alles goed, maar de weg terug lukt dus niet.

We kunnen het verkeer met sniffers volgen tot in de 7k waar we het gerouteerd zien worden van vlan 251 naar vlan 650. We zien het verkeer vlan interface 650 verlaten waarna het de trunk op zou moeten naar de 5K. Daar komt het echter nooit aan.

Alle interfaces zijn errorvrij.

Iets wat het nog 'leuker' maakt is dat het soms wel werkt. Wanneer er 10 servers uitgerold worden (tegelijk) dan kunnen we er op rekenen dat er 5 mislukken omdat ze geen tftp kunnen doen. Daarnaast werkt pingen zonder problemen, evenals DHCP.

Passen we het mac adres van de client aan dan doet het het soms wel. Gebruiken we een bootcd met een andere tftp client dan doet het ook soms wel.

Kijk ik in de mac adres tabellen dan klopt de egress interface op de 7K, de switch heeft dus in ieder geval de correcte informatie om het frame door te sturen.

[WhizzCat]

TFTP is sowieso een ontzettend gevoelig protocol. Het verbaast me niet heel veel dat dat niet erg goed werkt in een moderne infra zoals jullie die hebben liggen. Ik vermoed toch dat je probleem op L2 zit, ondanks dat je arp/mac tabellen in orde lijken te zijn.

Ik zou kijken of je iets kan meten met bij hoeveel servers het mis gaat. Lukt het nog wel met 7 tegelijk? 1tje d'r bij etc. Dat is nogal een tijdrovende klus, maar ik vermoed dat je hoeveelheid tegelijkertijd uitrollende (prachtig Nederlands ) een bottleneck is voor het archaïsche TFTP protocol.

Wat voor TFTP server hebben we het over trouwens? Dat maakt ook nog wel eens verschil. Heb je het al met een andere geprobeerd?

[MagicTempest]

Ik weet dat TFTP een ***protocol is, maar ik krijg helaas ook alleen maar de opdracht dit te fixen . Helaas gaat het ook met 1 server tegelijk fout.

Ik vermoed niet dat het aan de TFTP server zelf ligt aangezien het verkeer daar nooit aankomt. Ik vermoed zelf ook een probleem op L2 (of misschien zelfs op L1), maar ik ben een beetje uit de mogelijkheden gelopen om dit te testen, vandaar de vraag

[WhizzCat]

Dus als ik het goed begrijp heb je de 5K's op (R)STP draaien en de 7K op HSRP?

Zou je dit eens nader kunnen/willen beschrijven want volgens mij mis ik iets...

[MagicTempest]

Wat mis je precies?

De 7K's zijn de core die L3 doen. De 5k's zijn op beide 7k's aangesloten. Hiervoor worden vpc's gebruikt (virtual port channels) waardoor tussen deze devices geen stp nodig is. De links naar de core worden door de 5k's namelijk als enkele links gezien, ook al zijn ze dubbel uitgevoerd.

De 7k's hebben onderling een vpc peer link waar ze informatie over uitwisselen zodat er geen loop ontstaat. Je zou het kunnen vergelijken met VSS, alleen dan zonder dat je twee switches als één maakt.

[ Voor 9% gewijzigd door MagicTempest op 15-06-2012 15:50 ]

[WhizzCat]

En daar draait niet stiekum iets van een loadbalance-achtig iets op waardoor je L2 sessies in de war schieten?

[MagicTempest]

Dat is hetzelfde systeem als een normale portchannel. Het gaat echter om de route terug. Op elke 7k is maar 1 link aanwezig naar een 5k, en dus ook maar 1 route om te bewandelen. Los daarvan heb ik natuurlijk wel op beide 5k's gekeken of er verkeer binnenkomt vanaf de 7k.

code:

  -----          -----
  | 7k | ------ | 7k |
  -----          -----
    |\            /|
    |  \        /  |
    |    \    /    |
    |      \/      |
    |     /  \     |
    |   /      \   |
   -----       -----
   | 5k |      | 5k |
   -----       -----

[DavidK]

Je spreekt over een inter-connect switch tussen de N5K en de 1000v switches. Waarom zitten de 1000v's niet rechtstreeks op de N5K's als zijnde fabric extenders? Dit maakt het troubleshooting een stuk makkelijker. Of was hier een speciale reden voor?

Hoe zijn de inter-connect switches geconfigureerd richting de N5k's? Zijn dit LACP's?
Het kan zo zijn dat een (deel) van het verkeer wegvalt als gevolg niet correct geconfigureerde LACP''s of VPC connecties (al dan niet icm mogelijke vlan trunk configuratie issue's op deze connecties)...

Het is even lastig om zo 1-2-3 met een mogelijk oplossing te komen. Er zijn ietwat te veel factoren in het spel; de configuraties van de N7K's op de zowel layer 2 als 3 als de configuraties op de N5K's. Controleer ook (o.a. aan de hand van mac-tabellen) hoe de communicatie paden lopen, via welke fysieke Nexus, welk fysiek pad etc etc. Welke default gateway wordt er gebruikt vanuit vlan 6xx (en op welke fysieke N7K draait deze) en welke default gateway wordt er gebruikt voor vlan 251 (en waar draait deze....)...

Er is vanalles mogelijk...ik zou bijna zeggen, post de configs even...maar dat gaat denk ik net iets te ver

[ Voor 73% gewijzigd door DavidK op 20-06-2012 15:58 . Reden: **Ik praatte even po*p (thnx to post hieronder)** ]

[Bl@ckbird]

TS bedoelt hiermee de UCS6100 / UCS6200.
Je hebt dit nodig, anders is de blade-omgeving dood ijzer.



Een UCS6200 is eigenlijk Nexus5k hardware met extra software. (UCS Manager)

UCS6200 is gekoppeld aan de N5k welke gekoppeld is aan de N7k.
Op het blade draait VMware met de virtuele N1k.

[MagicTempest]

Dat is inderdaad wat ik bedoel.

Ondertussen zijn we misschien een klein stukje verder gekomen. Het probleem is ontstaan na ons vorige onderhoudsweekend. In dat weekend is toen de ESX omgeving geüpgraded naar versie 5 met hardwareversie 8. Daarnaast zijn de 7K's geüpgraded.

We hebben gezien dat de VM's twee gateways krijgen, namelijk het IP adres van de DHCP helper en de daadwerkelijke gateway. Volgens de RFC mag een client echter geen gebruik maken van het adres van de dhcp helper (tenzij dat toevallig hetzelfde is als de gateway). Deze VMs gebruiken echter wel dat adres als gateway. Naar mijn mening is dat een bug en dus gaan we dat ook als zodanig aanmelden bij VMware.

Dat verhaal haalt echter nog niet weg dat de frames die naar de DHCP helper worden gestuurd (wat een van de realip's van de routers is) soms lijken te verdwijnen. Mijn vermoeden is dat dat met het pad te maken heeft dat een frame volgt om bij de core te komen (en weer terug). We gaan voor dat probleem navraag doen bij Cisco of dit normaal is.

[Bl@ckbird]

Als je denkt dat het probleem bij VMware ligt, kan je hier een support case loggen. Als je denk dat het probleem bij Cisco ligt kan je hier een case loggen. Engineers van beide fabrikanten kunnen onderling bij problemen overleggen. Je hebt zo een single point of contact. (De support centers werken onderling dus samen.)
Dit hebben ze gedaan om support issues beter af te handelen met het verhaal rond UCS en NetApp FlexPod en VMware.

[MagicTempest]

Dat is wel een mooie. Ik heb al een call geopend bij VMware en ben nu bezig om een call te openen bij Cisco. (Maar het nadeel daar is dat we geen direct contact met Cisco hebben, dus we moeten door een derde partij).

Maar ik kan inderdaad wel aangeven dat die dingen mogelijk met elkaar te maken hebben.

[bigfoot1942]

zonder heel diep erin te duiken, heb je el gedacht aan de mogelijkheid dat je DHCP reply groter is dan de Max MTU size (black hole routing) of iets in die geest?

[MagicTempest]

Het probleem is gevonden. Het heeft te maken met een bug van VMware in combinatie met de vpc's. Wat er namelijk gebeurt is het volgende:

VMware gebruikt bij tftp de verkeerde gateway (dat is de bug) waardoor het verkeer naar de verkeerde router wordt gestuurd. Door de loadbalancing in het netwerk kan het gebeuren dat het verkeer op de andere router terecht komt. Deze stuurt het verkeer naar de juiste router. Die heeft echter door dat hij zelf niet mag routeren, dus hij stuurt het terug naar de router waar het vandaan kwam. Op dat moment heeft de vpc software door dat er een loop is en dropt het dit verkeer.

De workaround is op alle routers vpc peer-gateway functie aan te zetten. Overigens is dat niet de oplossing, want VMware moet het probleem bij hun oplossen.

[PcDealer]

Met vSphere 5 kun je toch de (image) booten via vCenter tegenwoordig?

Waarom heb je geen direct contact met Cisco, geen SmartNet?

[ Voor 31% gewijzigd door PcDealer op 09-07-2012 11:10 ]

[bigfoot1942]

als t een vmware bug is, wat zou Cisco daaraan kunnen doen?
Tijd voor vSphere 5.0 update2

[MagicTempest]

@PcDealer: Ik weet zelf heel weinig van VMware zelf. Wat ik weet is dat ze hier voor nieuwe linux servers graag gebruik maken van PXE en tftp. Of dat in vSphere 5 ook anders kan geloof ik wel, maar dat wordt hier dus niet gebruikt. De reden dat wij geen direct contact hebben met Cisco is omdat wij geen klant van ze zijn. We kopen onze Cisco apparatuur via een reseller.

@bigfoot1942: Cisco zal weinig aan die bug kunnen doen, maar ze hebben ons wel de workaround gegeven.