TCP problemen

[BasXcore]

De opzet/configuratie: Wij hebben Extended Ethernet verbinding van 4mbit (synchroom). Dit wordt verzorgt door een Cisco router in beheer door onze ISP. De Cisco zit aan een switch aangesloten die de verbinding verdeeld naar 2 in cluster geconfigureerde Juniper SSG140 firewalls. De LAN zeide van de firewalls zit in een HP Procurve 5412zl core switch. De switch waar het gros van de PC's en servers op aangesloten zitten. Wij gebruiken Websense in combinatie met de Juniper SSG's om de content van het browse verkeer in controle te houden.

Probleem: Ik weet niet wanneer dit precies is ontstaan, maar het zou goed kunnen dat dit probleem al vanaf start (1 jaar terug met door plaatsting SSG's met Websense) er zit. Het probleem is dat er regelmatig door gebruikers wordt geklaagd over vertraagd internet browsen. Op dat soort momenten meet ik dat de verbinding niet zijn volledige capaciteit heeft verbruikt. In tegendeel. En we zien ook dat alleen sommige site's vertraagd aanvoelen. Ook krijgen we klachten van de thuisgebruikers dat terminal sessie wegvallen, of stroperig aanvoelen.

Wat gedaan: Eerst hadden we een vermoeden dat het aan Websense in combinatie met Juniper te maken had. Na veel troubleshooting, logs mailen, packet captures en alles zijn we erachter gekomen dat er te vaak RST, ACK's en TCP Retransmissions voorbij komen. Beide partijen schuiven het nu af op de ISP provider. Ik heb daar reeds een call aangemaakt, en zij zijn aan het kijken of het iets is waar zij wat aan kunnen doen.

Zelf kan ik niet een conclusie uit de packet logs trekken. En daar wil ik jullie vragen onafhankelijk te willen kijken naar de packet logs die ik van/naar de Cisco (ISP router) heb gecaptured. Of jullie daar iets over te zeggen hebben?

Packet capture: Download
Wachtwoord: tweakers

Alvast bedankt.

[jvanhambelgium]

Tja, dan mag je hier ook al eventueel een net tekeningetje neerzetten hé. Zomaar een rauwe packet capture zonder enige IP-plan, positie van end-users in het verhaal etc,etc.

Je weet wel, de standaard zaken die men nodig heeft om te troubleshooten...

[FatalError]

Misschien n hele stomme vraag, maar heb je alle interfaces al op errors gecontroleerd?

[wowi]

check bestemmings adress 217.17.135.162 eens daar naar toe als bestemming zit wat verkeerd zou ik zeggen zo. Kabel niet goed ??

[ Voor 8% gewijzigd door wowi op 25-06-2009 22:51 ]

[Guru Evi]

te vaak RST, ACK's en TCP Retransmissions voorbij komen

Hoe bedoel je te vaak?

1) RST en (SYN/)ACK wordt gebruikt om TCP verbindingen op te zetten (waarschijnlijk weet je dat wel). RST wil meestal zeggen dat een bepaalde verbinding niet beschikbaar is en kan gebruikt worden door een firewall of een content inspector (zoals een intrusion detection/prevention system) om bepaalde dingen te blokkeren of te limiteren.

2) TCP Retransmissions: Slechte lijn, slechte verbinding, slechte hardware, slechte MTU. Als je ISP een kleinere MTU hebt dan jij denkt en de ISP's (of jouw) hardware kan het niet zo snel aan (iets oudere of slecht geconfigureerde hardware) krijg je snel veel RST pakketjes en retransmissions (buffers vol). Er zijn veel settings in dat geval waar jij soms denkt dat het 'normaalgezien' zou moeten verbeteren (zoals Path MTU Discovery en nieuwere zaken zoals NewReno) die bij jouw ISP misschien niet goed zitten. Als je TCP Window daarentegen echter te klein en de latency te groot dan kan je lijn het fysiek niet aan om zo'n kleine pakketjes op zo'n korte tijd te versturen dan krijg je ook problemen (VoIP heeft kleinere pakketjes - als je onlangs VoIP hebt geimplementeerd of iemand gebruikt regelmatig Skype of een SIP provider kan dit het probleem zijn)

3) (D)DoS - crackers, hackers en script kiddie tools maken regelmatig gebruik van de kleinere ongemerkte pakketjes (zoals ACK en RST) om je lijn vol te zetten. De meeste tools kunnen dit wel loggen als je de juiste instellingen gebruikt maar eenmaal de lijn vol is kun je nog weinig doen.

4) In het slechtste geval: De RST techniek wordt tegenwoordig door minder scrupuleuze ISP's gebruikt om bandbreedte in te perken van vb. BitTorrent of andere traffiek die ze niet graag zien (zoals VoIP bij een GSM provider). Als je een fysieke 10Mbit lijn hebt en 4Mbit aankoopt kan het zijn dat hun bandbreedte inperking het via RST pakketjes forceert (slechte instelling, goedkope hardware of slechte sysadmin aan hun kant).

5) Heb je al eens geprobeerd om direct aan de router van je ISP een computer te hangen en te zien wat je krijgt. Meet op verschillende punten (voor en achter de firewalls en de verschillende andere apparaten) in je eigen netwerk en probeer iemand te vinden die je lijn kan voltrekken van buitenaf om te zien wat je bandbreedte daadwerkelijk is (4Mbit piek met 1Mbit garantie misschien? - lees je contract door) of als er bepaalde dingen zijn die gelimiteerd worden.

[ Voor 27% gewijzigd door Guru Evi op 26-06-2009 06:26 ]

[BasXcore]

Ik ben nog bezig jullie reacties door te lezen. Alvast dank daarvoor.

Hierbij een tekening: Download

[BasXcore]

FatalError schreef op donderdag 25 juni 2009 @ 22:37:
Misschien n hele stomme vraag, maar heb je alle interfaces al op errors gecontroleerd?

Flow counters? Ja die zijn uitvoerig gecontroleerd. Volledige tech-supports zijn naar Juniper toegegaan.

Beneden een dump van de UNTRUST interface van de actieve SSG naar de switch (UNTRUST VLAN).

FW-SSG01(M)-> get counter flow interface ethernet0/0
Flow counters for interface ethernet0/0:
in bytes 139776005 | out bytes 2388159205 | tcp proxy 0
in packets 44973528 | out packets 36966991 | tear drop 0
in vlan 0 | out vlan 0 | in permit 3830633512
out permit 3975487305 | src route 0 | no g-parent 0
ping of death 0 | no gate sess 0 | address spoof 0
in icmp 11315 | no nat vector 0 | land attack 0
in self 0 | no map 0 | icmp flood 0
in un-auth 0 | no conn 0 | no arp entry 0
udp flood 0 | in unk prot 0 | no dip 0
winnuke 0 | in vpn 3427696 | no gate 0
port scan 0 | in other 0 | no xmit vpnf 0
ip sweep 0 | no mac 0 | no route 0
tcp out of seq 1197 | mac relearn 0 | no frag sess 0
wrong intf 0 | slow mac 0 | no frag netpak 0
wrong slot 0 | trmng queue 0 | no sa 0
icmp broadcast 0 | trmng drop 0 | no sa policy 0
illegal pak 18923 | tiny frag 0 | sa inactive 0
url block 0 | syn frag 0 | sa policy deny 0
encrypt fail 0 | connections 359007 | policy deny 34912
mp fail 0 | misc prot 0 | auth deny 0
auth fail 0 | loopback drop 1601 | big bkstr 0
proc sess 0 | mal url 0 | sessn thresh 0
invalid zone 0 | null zone 0 | no nsp-tunnel 0
IP cls failure 0 | first pak frag 0 | unknown pak 312668
multiauth drop 0 | multi-DIP drop 0 | tcp sweep 0
udp sweep 0 |
Policing drop 0 | Tra-Shap drop 486857 |

[BasXcore]

wowi schreef op donderdag 25 juni 2009 @ 22:50:
check bestemmings adress 217.17.135.162 eens daar naar toe als bestemming zit wat verkeerd zou ik zeggen zo. Kabel niet goed ??

Dat IP adres is de UNTRUST zijde van het SSG cluster. Dus het IP waarmee alles naar buiten gaat. Er gaat vanaf elke SSG één kabel van 1 meter naar de switch. Kabels zijn al eens vervangen, daar is niets mis mee.

Overigens staan zijn de UNTRUST interfaces van de SSG's 10/100/1000 auto, en Duplex auto. De switch idem. En de interface van de switch naar de cisco 100mb fixed, FD fixed. En de cisco natuurlijk ook 100mb fixed, FD fixed.

Ik krijg wel steeds meer het vermoeden dat de tussenkomst v/d switch tussen het SSG cluster en de EE router het probleem veroorzaakt. Maar zelf kan ik dat niet hard maken omdat ik niet afdoende kennis heb van de onderste layers van het OSI model.

[BasXcore]

Guru Evi schreef op vrijdag 26 juni 2009 @ 06:11:
te vaak RST, ACK's en TCP Retransmissions voorbij komen

Hoe bedoel je te vaak?

Dit is wat Juniper tech support ons vertelt heeft. Zelf heb ik niet genoeg kennis om hierover een conclusie te trekken.

1) RST en (SYN/)ACK wordt gebruikt om TCP verbindingen op te zetten (waarschijnlijk weet je dat wel). RST wil meestal zeggen dat een bepaalde verbinding niet beschikbaar is en kan gebruikt worden door een firewall of een content inspector (zoals een intrusion detection/prevention system) om bepaalde dingen te blokkeren of te limiteren.

Wij gebruiken Websense, deze gebruikt ook deze techniek om protocollen te blokkeren. Maar dat wordt intern toegepast. Uitschakelen van Websense brengt geen verschil.

2) TCP Retransmissions: Slechte lijn, slechte verbinding, slechte hardware, slechte MTU. Als je ISP een kleinere MTU hebt dan jij denkt en de ISP's (of jouw) hardware kan het niet zo snel aan (iets oudere of slecht geconfigureerde hardware) krijg je snel veel RST pakketjes en retransmissions (buffers vol). Er zijn veel settings in dat geval waar jij soms denkt dat het 'normaalgezien' zou moeten verbeteren (zoals Path MTU Discovery en nieuwere zaken zoals NewReno) die bij jouw ISP misschien niet goed zitten. Als je TCP Window daarentegen echter te klein en de latency te groot dan kan je lijn het fysiek niet aan om zo'n kleine pakketjes op zo'n korte tijd te versturen dan krijg je ook problemen (VoIP heeft kleinere pakketjes - als je onlangs VoIP hebt geimplementeerd of iemand gebruikt regelmatig Skype of een SIP provider kan dit het probleem zijn)

Wij hebben een Extended Ethernet verbinding. Deze kent een MTU van 1500. Dit is ook zo ingesteld op de apparatuur. Van SIP en Skype is geen sprake. Ik ben nog in afwachting van onze ISP gaat melden. Die zou antwoord moeten geven op "Slechte lijn, slechte verbinding, slechte hardware, slechte MTU".

3) (D)DoS - crackers, hackers en script kiddie tools maken regelmatig gebruik van de kleinere ongemerkte pakketjes (zoals ACK en RST) om je lijn vol te zetten. De meeste tools kunnen dit wel loggen als je de juiste instellingen gebruikt maar eenmaal de lijn vol is kun je nog weinig doen.

Ok, duidelijk.

4) In het slechtste geval: De RST techniek wordt tegenwoordig door minder scrupuleuze ISP's gebruikt om bandbreedte in te perken van vb. BitTorrent of andere traffiek die ze niet graag zien (zoals VoIP bij een GSM provider). Als je een fysieke 10Mbit lijn hebt en 4Mbit aankoopt kan het zijn dat hun bandbreedte inperking het via RST pakketjes forceert (slechte instelling, goedkope hardware of slechte sysadmin aan hun kant).

Intressant, wist ik niet. ISP moet hierop antwoord geven.

5) Heb je al eens geprobeerd om direct aan de router van je ISP een computer te hangen en te zien wat je krijgt. Meet op verschillende punten (voor en achter de firewalls en de verschillende andere apparaten) in je eigen netwerk en probeer iemand te vinden die je lijn kan voltrekken van buitenaf om te zien wat je bandbreedte daadwerkelijk is (4Mbit piek met 1Mbit garantie misschien? - lees je contract door) of als er bepaalde dingen zijn die gelimiteerd worden.

Ja, wij hebben een test PC direct op de lijn gehad. Het leek hiermee beter te gaan. Maar ja, je zit dan als enige op een schone lijn. Wij hebben helaas daarvan geen packet capture gemaakt. Dus of daar de TCP problemen niet in voor kwamen, kan ik dus niet zeggen.

Er is geen overboeking actief. Dus wij hebben 1:1. Wij monitoren het internet gebruik, aan beide zijde van de firewalls. Er is geen sprake van volledige bellasting.

Ik waardeer je meedenken! Maar kunnen we stellen dat er daadwerkelijk problemen in de capture te vinden is, of zijn het aantal "fouten" niet van die mate dat de performance van de verbinding in geding is?

[CaPuT]

Vraag je ISP is of ze errors zien op de FA0/1 van de Cisco (je lan kant)
Wanneer ze hier errors zien, controleer je bekabeling en of je interface op 10mb FD staat.
Bij het extended ethernet platform, moet je je interface vast instellen.

Wanneer je die dip in je dataverkeer hebt, haal je je download dan nog wel en is het puur je upload die inzakt?

Het is toevallig ook niet zo dat je een rood lampje hebt op je Siemens STU? (wanneer je die geleverd gekregen hebt)

[Saab]

Soortgelijk probleem hier gehad met een 10mbit leased line. Fixeren van de speed van de upload van de HP switch naar de Cisco op 10Mbit FD ipv 100Mbit lostte het probleem op.

Ook hier geen duidelijk toename van netwerk verkeer oid maar op advies van de ISP gedaan en het hielp.

[DGTL_Magician]

Waarschijnlijk is het idd een autonegotiation probleem. Volgens de tekening staat de switch op 100mb Full duplex fixed, staat de Cisco router hier ook op?
Zelfde geldt voor de Junipers, staan die fixed en de switch ook?

Autonegotiation zorgt vaak voor dit soort problemen.

[BasXcore]

Inderdaad zojuist bericht terug van de ISP. De interface v/d Cisco stond inderdaad op 100mbit HD ipv aan mijn kant 100FDx. Terwijl dit tijdens implentatie met de betrokken engineer was afgesproken beide zeide op 100mbit FDx te zetten.

Ze hebben het aangepast, en de retransmissions behoren tot het verleden. En daarme constateren we ook dat allemaal een stuk soepeler aanvoelt.

Dank jullie voor de berichten!

[ Voor 19% gewijzigd door BasXcore op 30-06-2009 16:17 ]