Paket kayiplarindan kaynaklanan ag baglanti sorunlarinin network trace’lerden tespit edilmesi
Tekrar merhaba,
Bugunku yazimizda size kisaca paket kayiplarinin es zamanli toplanan network trace’ler icinde nasil bulunabilecegi konusunda bilgiler vermeye calisacagim.
Zaman zaman musterilerimiz degisik baglanti sorunlari nedeniyle Microsoft destek hattina problem acmaktadirlar. Bu tur sorunlarin kaynagini tespit etmek her zaman kolay olmamakla birlikte, ozellikle network trace’lerden de faydalanarak problemin izolasyonu saglanabilmektedir. Bu sayede incelenmesi gereken alan daraltilmaktadir. Genel olarak bu tur senaryolarda problemin uc farkli noktadan kaynaklandigini soyleyebiliriz:
a) Kaynak sistem tarafinda bir sorun
b) Ag cihazlari (firewall, Proxy, WAN accelarator, WAN compression vs. gibi cihazlar) ya da ag baglantilarindan kaynaklanan bir sorun
c) Hedef sistem tarafinda bir sorun
Bu tur senaryolarin cozumlenmesinde en onemli log, problem repro edilirken hem kaynak hem de hedef sistem tarafinda es zamanli olarak network trace’ler toplanmasidir. Asagida bu tur durumlarda, es zamanli toplanmis trace’lerin ne sekilde analiz edilebilecegine dair bir ornek bulacaksiniz.
PROBLEM:
==========
Uzak lokasyonlarda calisan bazi SCCM agent’lar, SCCM server’dan policy degisikliklerini alamamaktadir.
ANALIZ:
========
Bir analiz yaparken, oncelikli olarak arastirilan senaryoda normal sartlar altinda nasil bir isleyis oldugunu da bilmek gerekmektedir. Bizim buradaki ornegimizde, SCCM agent SCCM server’a bir TCP baglanti yapip, HTTP POST request ile policy isteginde bulunmaktadir. Bu bilgiler isiginda SCCM agent ve SCCM server tarafinda toplanmis trace’lere ayri ayri baktigimizda, problemin paket kaybindan kaynaklandigini gorebiliyoruz:
a) SCCM agent (10.1.1.1) tarafta toplanmis network trace’in analizi:
Not: Asagidaki paketler, SCCM agent ve SCCM server IP adresleri ve kullanilan source/target TCP port numaralarina gore network trace’in filtrelenmis seklidir:
No. Time Source Destination Protocol Info
1917 104.968750 10.1.1.1 172.16.1.1 TCP rmiactivation > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460
1918 105.000000 172.16.1.1 10.1.1.1 TCP http > rmiactivation [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460
1919 105.000000 10.1.1.1 172.16.1.1 TCP rmiactivation > http [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
1920 105.000000 10.1.1.1 172.16.1.1 HTTP CCM_POST /ccm_system/request HTTP/1.1 1921 105.000000 10.1.1.1 172.16.1.1 HTTP Continuation or non-HTTP traffic
1922 105.000000 10.1.1.1 172.16.1.1 HTTP Continuation or non-HTTP traffic
1925 105.140625 172.16.1.1 10.1.1.1 TCP http > rmiactivation [ACK] Seq=1 Ack=282 Win=65254 Len=0 SLE=1742 SRE=2328 1975 107.750000 10.1.1.1 172.16.1.1 HTTP [TCP Retransmission] Continuation or non-HTTP traffic
2071 112.890625 10.1.1.1 172.16.1.1 HTTP [TCP Retransmission] Continuation or non-HTTP traffic
2264 123.281250 10.1.1.1 172.16.1.1 HTTP [TCP Retransmission] Continuation or non-HTTP traffic
2651 144.171875 10.1.1.1 172.16.1.1 HTTP [TCP Retransmission] Continuation or non-HTTP traffic
3475 185.843750 10.1.1.1 172.16.1.1 HTTP [TCP Retransmission] Continuation or non-HTTP traffic 4392 234.937500 172.16.1.1 10.1.1.1 TCP http > rmiactivation [RST, ACK] Seq=1 Ack=282 Win=0 Len=0
b) SCCM Server (172.16.1.1) tarafta toplanmis network trace:
Not: Asagidaki paketler, SCCM agent ve SCCM server IP adresleri ve kullanilan source/target TCP port numaralarina gore network trace’in filtrelenmis seklidir:
No. Time Source Destination Protocol Info
13587 100.765625 10.1.1.1 172.16.1.1 TCP rmiactivation > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460
13588 0.000000 172.16.1.1 10.1.1.1 TCP http > rmiactivation [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460
13591 0.031250 10.1.1.1 172.16.1.1 TCP rmiactivation > http [ACK] Seq=1 Ack=1 Win=65535 Len=0
13598 0.031250 10.1.1.1 172.16.1.1 HTTP CCM_POST /ccm_system/request HTTP/1.1
13611 0.078125 10.1.1.1 172.16.1.1 HTTP [TCP Previous segment lost] Continuation or non-HTTP traffic
13612 0.000000 172.16.1.1 10.1.1.1 TCP http > rmiactivation [ACK] Seq=1 Ack=282 Win=65254 [TCP CHECKSUM INCORRECT] Len=0 SLE=1742 SRE=2328
30509 129.812500 172.16.1.1 10.1.1.1 TCP http > rmiactivation [RST, ACK] Seq=1 Ack=282 Win=0 Len=0
=> Yukaridaki renklendirmeleri aciklamak gerekirse:
a) MAVI ile isaretlenmis olan alanlar hem client hem de server side trace’de gozuken paketler. Yani client’in server’a gonderdigi ve server’in sorunsuz aldigi ya da server’in gonderdigi ve client’in sorunsuz aldigi paketler
b) KIRMIZI olan paketler ise, client’in gonderdigi ama server’in alamadigi paketler. Daha ayrintili bakmak gerekirse:
- Client taraftaki trace’deki 1921 numarali paket (ki bu HTTP CCM_POST request’in data’sini tasiyan bir paket), server’a gelmiyor. Bunu server side trace’e bakarak anliyoruz
- Client side trace’deki 1975, 2071, 2264, 2651 ve 3475 numarali paketler ise 1921 numarali paketin bir tekrar gonderimi (retransmission) aslinda. Ve 5 kere tekrarlandigi halde bunlarin da hic birisi server’a ulasmiyor bunu da server taraftaki trace’e bakarak soyleyebiliyoruz.
Yaklasik 2 dakika boyunca bekledikten sonra da server oturumu resetliyor. (Client taraftaki paket numarasi 4392, ayni paketin server taraftaki paket numarasi 30509)
SONUC:
=======
1) Burada yasanan bir paket drop problemidir ve bu acidan bakildiginda problemin SCCM agent ya da SCCM server ile bir baglantisi gozukmemektedir.
2) Gene bu paket drop probleminin Windows network stack ile de bir baglantisi gozukmemektedir ve problem asagidaki noktalardan birisinde olusmaktadir:
a) Workstation (SCCM agent) tarafinda NIC seviyesinde veya altinda bir problem
b) Network’te (veya uzerinde calisan herhangi bir network device’da) yasanan bir problem
c) Hedef server (SCCM server) tarafinda NIC level veya altinda bir problem
3) Kaynak sistem tarafinda (bu senaryoda SCCM agent) NIC level veya altinda olusabilecek muhtemelen sorunlar icin sunlar kontrol edilebilir:
- NIC/Teaming driver
- 3rd party Firewall’lar (ozellikle NDIS seviyesinde filter driver olarak implemente edilenler)
- HIPS (Host based intrusion detection systems)
Sorun gidermenin bir parcasi olarak bu komponentlerin son surumleri yuklenebilir, ya da test amacli olarak sistemden tamamen kaldirilabilirler
4) Network tarafindan kaynaklanabilecek muhtemel sorunlar icin sunlar kontrol edilebilir:
- Kablo/NIC kontrol
- Switch port
- Speed/duplex setting’lerin manuel 100/FD ya da 10/FD'ye cekilmesi (hem client/server hem de switchport tarafinda)
- Router/Switch/firewall/proxy cihazlar uzerinde logging acilarak, paket drop olusup olusmadigini konrol etmek (bunun icin client ile server arasindaki yol uzerinde degisik ara noktalarda da network trace’ler toplanabilir)
5) Hedef sistem tarafinda (bu senaryoda SCCM server) NIC level veya altinda olusabilecek muhtemelen sorunlar icin sunlar kontrol edilebilir:
- NIC/Teaming driver
- 3rd party Firewall’lar (ozellikle NDIS seviyesinde filter driver olarak implemente edilenler)
- HIPS (Host based intrusion detection systems)
Not: Yukarida detaylarini verdigim senaryodaki problem, client ile server arasindaki bir router’dan kaynaklaniyordu.
Umuyorum burada verilmis olan bilgiler, benzer sorunlarin (paket kayiplari) cozumlenmesinde isinize yarar.
Gorusmek uzere
Tesekkurler,
Murat