Om TCP/IP slår hål på en buffer genom att skicka fler paket än vad den buffrande enhet klarar av att hantera uppstår ibland stora svårigheter i kommunikationen. Samma sak kan lätt ske om överföringen hanteras av en 'hård' shaping någonstans på vägen mellan avsändare och mottagare. Det kan gå så långt att TCP sessionen stannar helt och kopplar ner. Sessionen startar bra, allt flyter på för att sen gå långsammare och långsammare tills den stannar helt.
Tillåter/använder server/klienten dessutom TCP option 3 för att utöka fönsterstorleken (Window scale) utöver de normala max 64KByte, kan problemet bli än värre. Det här har jag sett mellan en Mac OS X 10.5 och en Windows 2008 server som skapade ett TCP fönster på 512KByte.
Så länge kommunikationen med stora block sker över LAN är det normalt inga problem, däremot om det finns långsamma WAN-länkar med enklare typer av moden (= liten buffer) eller icke buffrande shaping (= t.ex. Cisco CAR) kan problemet uppstå.
Det som händer är att TCP's fönsterstorlek ökar allt eftersom överföringen kommer igång. Förr eller senare är den så stor att någon buffer/shaping kastar en stor mängd paket i slutet av fönstret. Det här förutsätter att avsändaren sitter på en snabb LAN access som tillåter all trafik i fönstret att skickas under en mycket kort tid. Den här pulsen av ett stort antal paket är betydligt större än vad en mellanliggande enhet orkar ta emot (= bufferproblem) eller vill ta emot (= 'hård' shaping). I båda fallen kastas alla paket i slutet av 'pulsen'.
TCP kommer att sända om paketen som slängdes när den upptäcker att paketen inte nått fram. Om den här omsändningen är så stor att även den 'pulsen' kommer att tappa ett större antal paket i slutet av pulsen, börjar sessionen närma sig ett farligt läge.
Beroende på konfiguration i avsändaren kommer normalt 3-5 omsändningsförsök ske. Om även sista 'omsändningspulsen' tappar några paket, kommer avsändaren att lägga ner försöken att skicka om paketen. Avsändaren tycker helt enkelt inte det är värt att försöka hur länge som helst.
Om TCP option för Window scale används så att ett datablock kan bli större än standard 64KByte, ökar möjligheten att 'pulsen' blir så stor så att mellanliggande buffrar/shaping aldrig kommer att hinna släppa igenom allt paket innan avsändaren tröttnar.
Det lustiga är att option 3, windows scale, togs fram för att öka kapaciteten mellan två maskiner, inte förvärra situationen. Men tanken med windows scale var för att kunna utnyttja höghastighetslänkar, t.ex. lokala 1Gbit Ethernet. Att funktionen kan ha en klar negativ effekt på samma kommunikation över långsamma länkar, kanske inte är lika känt.
Tittar man på TCP-flödet med en nätverksanalysator och filtrerar fram omsända kontra icke omsända paket kommer sessione starta med ett antal icke omsända paket, därefter blir det i princip bara omsändingar som syns. Dessutom kan man se att det blir tomrum mellan omsändningsförsöken. Dessa tomrum kan bli längre och längre tills dess att sessionen kopplas ner (FIN).
Dessutom kan jag tänka mig att problemet faktiskt är värst där trafiken på något sätt stryps ner till en mycket låg hastighet jämfört med den fysiska länken. T.ex. om en operatör drar fram en 1Gbit fiber som kunden sedan köper 4/8Mbit access ur. Om operatören har en stor 'burst' konfigurerad och en 'hård' shaping (CAR), är det här problemet inte alls orimligt.
Lösningen är 1) att låta avsändaren inte tillåta window scale, vilket ger sämre överföringskapacitet på t.ex. 1GBit LAN eller 2) se till så att långsamma länkar har bra bufferkapacitet och användar buffrande shaping. Alternativ 1 är egentligen bara aktuellt om alternativ 2 inte går att genomföra. En riktig fusklösning som kan hjälpa i viss utsträckning är att sänka avsändarens LAN anslutning till lägre hastighet. Det är enkelt, men absolut inte optimalt i många lägen. Men jag har gärna långsam och fungerande överföring är snabb överföring som stannar halvägs :-)
Vänligen
- Per Håkansson, CCIE 2446
SpeedApp AB
|
|
Efter justering i DHCP servern skickade den ut 'felaktig' Server Identifier i DHCP Offer. Resultatet var att Cisco AP1130 och Mac OS X 10.5 inte accepterade den DHCP Offer som kom från DHCP server efter att de skickat en DHCP Discover. Både AP'n och Mac'en skickade inget mer efter att den 'felaktiga' DHCP Offer'n kom. En Windows XP och Linux Fedora fungerade dock utan problem.
Så här såg DHCP Offer'n ut (Ytterligare Option har tagits bort):
Bootstrap Protocol
Message type: Boot Reply (2)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0x5c6fa656
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 10.10.10.10 (10.10.10.10)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 10.10.10.1 (10.10.10.1)
Client MAC address: 00:10:20:30:40:50 (00:10:20:30:40:50)
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option: (t=53,l=1) DHCP Message Type = DHCP Offer
Option: (53) DHCP Message Type
Length: 1
Value: 02
Option: (t=54,l=4) Server Identifier = 0.0.0.0
Option: (54) Server Identifier
Length: 4
Value: 00000000
Efter att DHCP servern justerats och den skickar ut sin riktiga adress som Option 54, fungarade både AP'n och Mac'en.
Vänligen
- Per Håkansson, CCIE 2446
SpeedApp AB
|
|
Att köra SMB (NetBIOS) över en NAT där många klienter översätts till en adress mot servern är problematiskt. Anledningen är att befintliga SMB sessioner tas ner av Microsoft servern om en klient 'bakom' NAT sätter upp en ny session. D.v.s. om servern ser en ny session från en och samma IP adress kommer andra sessioner att tas ner med en 'hård' reset. Anledningen är att servern tror att en och samma klient har tappat kontakten och vill börja om från början. Alltså rensar servern befintliga sessioner. Numera gäller det här bara för SMB över CIFS (TCP 445), inte över TCP 139. Enklaste åtgärden för att lösa problemet är alltså att spärra TCP port 445 för att på så sätt låta SMB sessionen 'falla tillbaka' på TCP 139. Alternativet är att göra en NAT-pool för antal klienter som skall koppla upp sig mot servern. Vill du läsa mer kan du titta igenom följande artikel: http://www.nynaeve.net/?p=93 Vänligen
- Per Håkansson, CCIE 2446
SpeedApp AB |
|
|
|
|
|
|
