Force10 - Hash-kollisioner og hvordan de undgås

Eksempel på logpost:

May 20 19:12:20: %EX8PB:2 %MACAGT-2-HASH_COLLISION_LOG: Mac:00:02:e8:d6:58:20/Vlan:203 could not be added to L2 CAM on portpipe 2 linecard 2 due to hash collision. Total number of hash collisions: 30211

May 20 19:12:20: %EX8PB:2 %MACAGT-2-HASH_COLLISION_LOG: Mac:00:02:e8:d6:58:20/Vlan:203 could not be added to L2 CAM on portpipe 3 linecard 2 due to hash collision. Total number of hash collisions: 31979

Sådan fungerer det:

I switchens CAM-tabel er der tildelt et bestemt antal poster til "Host Table", som indeholder en delmængde til ARP på /32-netværk og en specifik mængde til alle andre poster.

Hvis der f.eks. er 1024 indeksværdier, der peger i retning af matricer med 8 hukommelsesplaceringer, så kan hver indeksværdi indeholde otte værdier. Alle 8 i en matrix kan være ARP'er, men samlet set på tværs af alle placeringer kan ARP-poster ikke overstige den delmængde, der er dedikeret til denne funktion. Forskellige switche har forskellige værdier.

Når du tilføjer en ARP-post for en IP-adresse til switchens CAM, beregner switching-chippen en indeksværdi (0-1023) vha. IP-adressen, og ARP-posten gemmes på den placering, der er udpeget af denne hash-algoritme.

I visse tilfælde vil hashing-algoritmen gerne gemme indekset på en placering, hvor alle hukommelsesplaceringer er i brug, hvorved der opstår en hash-kollision.

Når en IP-adresse støder på en hash-kollision, bliver dens ARP-post ikke føjet til CAM'en.  I stedet er CPU'en nødt til at indlæse den i sin softwaretabel. Når trafik til denne IP skal videresendes, kan switchen ikke gøre det i hardware.  Trafikken videresendes derefter til CPU'en med en "blød videresendelse" (soft forwarding).  Dette medfører en yderligere belastning af CPU'en.  Dette har tendens til at medføre ventetid for den angivne sti. I visse tilfælde kan mængden af bløde videresendelser overstige CPU'ens evne til at behandle dem og føre til pakketab.

Omgåelser af hash-fejl:

Opgradering til software, der tillader DOBBELT HASHING. Bestemte platforme efter version 9.3 har kapacitet til at udføre dobbelt hashing. Understøttelse af dobbelt hashing for både L2- og L3-tabeller er tilgængeligt. Denne funktion er som standard aktiveret på alle platforme, der kører 9.3. Switchen forsøger at gen-hashe og omarrangere tabellerne for at få plads til nye poster, når der opstår en hash-kollision.

Tilføj et routing-lag.  Ved hash-fejl i kerneswitche.  Den bedste måde at overvinde denne begrænsning på er at bruge et TOR-design (Top-of Rack) og tillade routing mellem TOR'erne og kerneswitchene.  På den måde kan vi reducere ARP-tabelstørrelsen på kernen.  Tilføjelse af dette routing-lag mellem individuelle værter og kernen fritager kernen fra at skulle lære alle de individuelle værters ARP-poster.

Reducer ARP-timeout. Standarden er 4 timer. Ved at mindske det tidsrum, hvor ARP'er opretholdes, bliver der mulighed for en mere hyppig indlæsning af nye ARP-poster. Dette vil naturligvis også tvinge alle poster til et hurtigere gennemløb og øge ARP-trafikken for de tilknyttede netværk.

Fordel IP-adresser i det tilknyttede L3-netværk.  En kortlægning af ALLE mulige IP-adresser i vigtige undernet efter deres tilsvarende hash-værdier kan oprettes, men er ekstremt krævende at udføre. IP-adresser kan derefter omfordeles for at undgå hash-fejl. Dette er den mindst effektive kortsigtede løsning, der er tilgængelig.