Force10 – Hashkollisioner och hur man undviker dem

Exempel på loggpost:

20 maj 19:12:20: %EX8PB: 2 %MACAGT-2-HASH_COLLISION_LOG: Mac:00:02:e8:d6:58:20/Vlan:203 kunde inte läggas till L2 CAM på portpipe 2 linecard 2 på grund av hashkollision. Totalt antal hashkollisioner: 30211

20 maj 19:12:20: %EX8PB:2 %MACAGT-2-HASH_COLLISION_LOG: Mac:00:02:e8:d6:58:20/Vlan:203 kunde inte läggas till L2 CAM på portpipe 3 linecard 2 på grund av hashkollision. Totalt antal hashkollisioner: 31979

Hur det fungerar:

I Switch CAM-tabellen finns det ett visst antal poster allokerade för ”värdtabell” som innehåller en del för ARP på /32-nätverk och en specifik summa för alla andra poster.

Om det till exempel finns 1 024 indexvärden som pekar på matriser med 8 minnesplatser så kan varje indexvärde innehålla åtta värden. Alla 8 i en matris kan vara ARP: men totalt, på alla platser, kan ARP-poster inte överstiga den del som är dedikerad till den här funktionen. Olika switchar har olika värden.

När du lägger till en ARP-post för en IP-adress till switchens CAM, beräknar switchchipet ett indexvärde (0–1 023) med hjälp av IP-adressen, och ARP-posten sparas på den plats som anges av den här hashalgoritmen.

I vissa fall vill hashalgoritmen lagra indexet på en plats där alla minnesplatser används och en hashkollision påträffas.

När en IP-adress påträffar en hashkollision, läggs dess ARP-post inte till i CAM.  I stället måste processorn läsa in det i sin programvarutabell. När trafiken till den IP-adressen ska skickas vidare kan inte switchen göra det i maskinvaran.  Den trafiken vidarebefordras sedan till processorn och skickas vidare med programvara.  Det här medför en extra belastning på processorn.  Det här tenderar att skapa latens i den angivna sökvägen. I vissa fall kan mängden programvidarebefordringar överstiga processorns förmåga att behandla dessa, vilket kan leda till paketförluster.

Lösningar för hashfel:

Uppgradera till programvara som tillåter DUAL HASHING. Specifika plattformar efter release 9.3 har möjlighet att utföra dual hashing. Det finns dual hashing-stöd för både L2- och L3-tabeller. Den här funktionen är aktiverad som standard på alla plattformar som kör 9.3. Switchen försöker återhasha och beställa tabellerna för att tillgodose nya poster när en hashkollision inträffar.

Lägg till ett routningslager.  För hashfel i kärnswitch.  Det bästa sättet att hantera den här begränsningen är att använda en Top-of Rack (TOR)-design och aktivera routning mellan varje TOR och kärnswitch.  På så sätt kan ARP-tabellstorleken i kärnan minskas.  Lägg till det här routningslagret mellan individuella värdar och kärnan för att avlasta kärnan så att den slipper lära sig alla enskilda värdars ARP-poster.

Minska ARP-timeout. Standard är 4 timmar. Genom att minska tiden som ARP:er behålls, blir det möjligt att introducera nya ARP-poster oftare. Det här tvingar alla poster att växla snabbare och ökar ARP-trafiken för anslutna nätverk.

Distribuera IP-adresser i det anslutna L3-nätverket.  En mappning av ALLA möjliga IP-adresser i viktiga undernät till motsvarande hashvärden kan skapas men är extremt svårt att producera. Sedan kan IP-adresser redistribueras för att undvika hashfel. Det här är den minst effektiva tillgängliga kortsiktiga lösningen.