Force10 – Hash-konflikter og hvordan du kan unngå dem

Eksempel på loggoppføring:

20. mai 19:12:20: %EX8PB:2 %MACAGT-2-HASH_COLLISION_LOG: Mac:00:02:e8:d6:58:20/Vlan:203 kunne ikke legges til i L2 CAM på portkanal 2 linjekort 2 på grunn av hash-konflikt. Totalt antall hash-konflikter: 30 211

20. mai 19:12:20: %EX8PB:2 %MACAGT-2-HASH_COLLISION_LOG: Mac:00:02:e8:d6:58:20/Vlan:203 kunne ikke legges til i L2 CAM på portkanal 3 linjekort 2 på grunn av hash-konflikt. Totalt antall hash-konflikter: 31 979

Slik fungerer det:

I Switch CAM-tabellen er det et spesifikt antall oppføringer tildelt «Vertstabellen» som inneholder en del for ARP på /32-nettverk, og et spesifikt antall for alle andre oppføringer.

Hvis det for eksempel er 1024 indeksverdier som peker mot arrayer på åtte minneplasseringer, kan hver indeksverdi inneholde åtte verdier. Alle åtte i et array kan være ARP-er, men det totale antallet ARP-oppføringer på tvers av alle plasseringer kan ikke overskride delen som er dedikert til denne funksjonen. Ulike svitsjer har ulike verdier.

Når du legger til en ARP-oppføring for en IP-adresse til svitsjens CAM, beregner svitsjebrikken en indeksverdi (0–1023) ved hjelp av IP-adressen, og ARP-oppføringen blir lagret på området som denne hash-algoritmen peker mot.

I visse tilfeller vil hash-algoritmen lagre indeksen på et område hvor alle minneområdene brukes, og det oppstår en hash-kollisjon.

Når en IP-adresse møter en hash-kollisjon, blir ikke IP-adressens ARP-oppføring lagt til i CAM-en.  CPU-en må i stedet laste den inn i programvaretabellen. Når trafikken til denne IP-adressen må videresendes, kan ikke svitsjen gjøre dette i maskinvaren.  Denne trafikken blir videresendt til CPU-en med myk videresending.  Dette øker belastningen på CPU-en.  Dette forårsaker ofte ventetid for den angitte banen. I visse tilfeller kan mengden av myk videresending overskride CPU-ens behandlingskapasitet og føre til pakketap.

Løsninger på hash-feil:

Oppgrader til programvare som tillater DOBBEL HASHING. Utvalgte plattformer etter utgivelsen av 9.3 kan utføre dobbel hashing. Støtte for dobbel hashing for L2- og L3-tabeller er tilgjengelig. Denne funksjonen er aktivert som standard på alle plattformer som kjører 9.3. Svitsjen prøver å endre hashing og rekkefølgen på tabeller for å imøtekomme nye oppføringer hver gang det oppstår en hash-konflikt.

Legg til et rutinglag.  For hash-feil på kjernesvitsj.  Den beste måten å takle denne begrensningen på er å bruke et TOR-design (Top-of Rack) og aktivere ruting mellom TOR-er og kjernesvitsjer.  På den måten kan vi redusere størrelsen på ARP-tabellen på kjernen.  Legg til dette rutinglaget mellom individuelle verter og kjernen, slik at kjernen slipper å lære alle ARP-oppføringene til de individuelle vertene.

Reduser ARP-tidsavbrudd. Standarden er fire timer. Hvis ARP-ene beholdes i kortere tid, kan nye ARP-oppføringer introduseres oftere. Dette vil selvfølgelig også tvinge alle oppføringer til å kretse gjennom raskere, og vil øke ARP-trafikken for tilkoblede nettverk.

Distribuer IP-adresser i det tilkoblede L3-nettverket.  Du kan opprette en tilordning av alle mulige IP-adresser i viktige delnett til de tilsvarende hash-verdiene, men det er ekstremt tungvint å produsere. IP-adresser kan deretter distribueres på nytt for å unngå hash-feil. Dette er den minst effektive løsningen på kort sikt.