ICMP, Ping ও Traceroute

এই Lesson শেষে তুমি পারবে

• ICMP কীসের জন্য তা ব্যাখ্যা করতে, এবং এর প্রধান Message Type চিনতে: Echo, Destination Unreachable (ও তার Code), Redirect ও Time Exceeded।
• Ping চালাতে, এর আউটপুটের প্রতিটি সংখ্যা পড়তে (time, ttl, Packet Loss, min/avg/max/mdev), এবং কেন ব্যর্থ Ping মানেই সবসময় সাইট বন্ধ নয় তা বুঝতে।
• Traceroute কীভাবে TTL কৌশল ব্যবহার করে তা ব্যাখ্যা করতে, UDP, ICMP ও TCP সংস্করণের তুলনা করতে, এবং * * * লাইন ও বিভ্রান্তিকর Latency Spike-সহ এর আউটপুট পড়তে।
• Latency, Bandwidth, Jitter ও Packet Loss আলাদা করে চিনতে।
• Path MTU Discovery ব্যাখ্যা করতে, এবং কেন “সব ICMP Block” বড় Transfer ভেঙে দেয় তা বলতে।
• নিজের Computer থেকে Application পর্যন্ত ধাপে ধাপে একটি Troubleshooting Ladder অনুসরণ করতে।
• একটি Service-এর জন্য Layer ধরে ধরে ওপরে উঠতে (Link → IP → Gateway → DNS → Port → TLS → HTTP): প্রতিটি ধাপের ঠিক Command, আর কোন লক্ষণ কোন Layer-এর দিকে ইঙ্গিত করে তা চিনতে।
• Fibre-এ আলোর গতি থেকে দুই জায়গার মধ্যে ন্যূনতম Round Trip হিসাব করতে, আর Server ও CDN কেন ব্যবহারকারীর কাছে বসানো হয় তা ব্যাখ্যা করতে।

#ICMP: Network-এর বার্তাবাহক

ICMP (Internet Control Message Protocol) হলো OSI Model-এর Network Layer-এর (Layer 3) একটি সাপোর্ট প্রোটোকল। এটি সাধারণ ডেটা বা ওয়েব পেজ আদান-প্রদানের জন্য ব্যবহৃত হয় না; বরং এর কাজ সমস্যার খবর দেওয়া ও ডায়াগনস্টিকসে সাহায্য করা: “ওই গন্তব্যে পৌঁছানো যাচ্ছে না”, “এই Packet-এর TTL শেষ”, “তুমি কি আছ? হ্যাঁ, আছি”।

কয়েকটি তথ্য যা এর আচরণের অনেকটাই ব্যাখ্যা করে:

• ICMP বার্তা সরাসরি IP Packet-এর ভেতরে চলে (IP Protocol Number 1)। নিচে কোনো TCP বা UDP নেই, তাই ICMP-এর কোনো Port নেই। বদলে প্রতিটি বার্তার একটি Type ও একটি Code থাকে।
• কিছু ভুল হলে Router ও Host স্বয়ংক্রিয়ভাবে ICMP তৈরি করে। একটি ত্রুটি-বার্তায় যে Packet-এর কারণে ত্রুটি, তার প্রথম কয়েক Byte থাকে, যাতে প্রেরক বুঝতে পারে এটি কোন Connection-এর।
• IPv6-এর নিজস্ব সংস্করণ আছে, ICMPv6, যা আরও বেশি অপরিহার্য: IPv6-এর Neighbour Discovery (ARP-এর বিকল্প) এর ওপরই চলে।

#যে Message Type-গুলো তুমি দেখবে

Type 3-এর সবচেয়ে কাজের Code:

ICMPv6-এ নম্বরগুলো আলাদা: Echo Request 128, Echo Reply 129, Destination Unreachable 1, Packet Too Big 2 এবং Time Exceeded 3।

#Ping: “কেউ কি আছ?”

Ping হলো দুটি ডিভাইসের মধ্যে সংযোগ আছে কিনা এবং Round Trip-এ কত সময় লাগে তা মাপার সবচেয়ে প্রাথমিক কমান্ড।

কীভাবে কাজ করে:

1. Client নির্দিষ্ট IP-তে একটি ICMP Echo Request (Type 8) Packet পাঠায়।
2. গন্তব্য ডিভাইস সচল থাকলে এবং উত্তর দেওয়ার অনুমতি থাকলে সেটি জবাবে একটি ICMP Echo Reply (Type 0) পাঠায়, Identifier, Sequence Number ও Data হুবহু ফেরত দিয়ে।

যে তথ্য দেয়:

• RTT (Round Trip Time): মিলিসেকেন্ডে (ms) হিসাব, Packet গিয়ে ফেরত আসতে কত সময় লাগল।
• Packet Loss: কত শতাংশ Request-এর কোনো উত্তর আসেনি।

# কমান্ড ফরম্যাট
ping google.com

#Ping-এর আউটপুট পড়া

Linux ও macOS প্রতি সেকেন্ডে একবার করে Ping করতে থাকে, যতক্ষণ না তুমি Ctrl+C চাপো:

$ ping -c 4 google.com
PING google.com (142.250.190.46) 56(84) bytes of data.
64 bytes from 142.250.190.46: icmp_seq=1 ttl=117 time=23.1 ms
64 bytes from 142.250.190.46: icmp_seq=2 ttl=117 time=22.8 ms
64 bytes from 142.250.190.46: icmp_seq=3 ttl=117 time=23.3 ms
64 bytes from 142.250.190.46: icmp_seq=4 ttl=117 time=22.9 ms

--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 22.8/23.0/23.3/0.2 ms

Windows ডিফল্টভাবে ৪টি Request পাঠায় এবং ভিন্নভাবে লেখে:

> ping google.com
Reply from 142.250.190.46: bytes=32 time=23ms TTL=117
Request timed out.
Reply from 142.250.190.46: bytes=32 time=24ms TTL=117
Reply from 142.250.190.46: bytes=32 time=22ms TTL=117

Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Minimum = 22ms, Maximum = 24ms, Average = 23ms

#কাজের Ping Option

#Latency, Bandwidth, Jitter ও Loss আলাদা জিনিস

একটি Link-এর বিশাল Bandwidth কিন্তু ভয়াবহ Latency থাকতে পারে (Satellite Link), অথবা কম Latency কিন্তু অল্প Bandwidth। Ping শুধু Latency, Jitter ও Loss মাপে, কখনো Bandwidth নয়।

#যখন Ping ব্যর্থ কিন্তু সাইট চলে

ব্যর্থ Ping একটি ইঙ্গিত, রায় নয়:

• ICMP Block করা। অনেক Firewall ও Cloud Security Group (AWS ডিফল্টভাবে Block করে) Echo Request Drop করে অথচ TCP 443 অনুমতি দেয়। Ping দেখায় ১০০% Loss আর Website দিব্যি Load হয়।
• নাম Resolve হয়নি। “could not find host” বা “Name or service not known” মানে DNS ব্যর্থ; Ping কোনো Packet পাঠায়ইনি।
• ICMP Rate-limit বা কম অগ্রাধিকার পায়। Router ICMP-এর উত্তর দেয় কম অগ্রাধিকারে, তাই কোনো Router-এ Ping-এর সময় তার মধ্য দিয়ে যাওয়া আসল Traffic-এর চেয়ে খারাপ দেখাতে পারে।

আসল Service পরীক্ষা করতে আসল Protocol পরীক্ষা করো: curl -I https://example.com, অথবা Windows-এ Test-NetConnection example.com -Port 443।

#Traceroute: পথের মানচিত্র

Traceroute (Windows-এ tracert) দেখায় একটি Packet তোমার Computer থেকে বের হয়ে গন্তব্যে পৌঁছানো পর্যন্ত মাঝে কোন কোন Router (Hop) অতিক্রম করছে, এবং কোথায় দেরি জমছে।

  [My computer] ──(TTL=1)──► [Router 1] ──► (Time Exceeded)
  [My computer] ──(TTL=2)──► [Router 1] ──► [Router 2] ──► (Time Exceeded)
  [My computer] ──(TTL=3)──► [Router 1] ──► [Router 2] ──► [Server] ──► (Echo Reply / Port Unreachable)

#TTL কৌশল

Traceroute ইচ্ছে করে IP Header-এর TTL Field-এর সুযোগ নেয়:

1. TTL = 1: প্রথম Probe-এর TTL দেওয়া হয় ১। প্রথম Router-এ পৌঁছাতেই TTL 0 হয়ে যায়। ফলে প্রথম Router Packet-টি ফেলে দেয় এবং ICMP Time Exceeded (Type 11) ফেরত পাঠায়। বার্তাটি আসে Router-এর নিজের IP Address থেকে, তাই তোমার Computer প্রথম Hop জেনে যায়।
2. TTL = 2: দ্বিতীয় Probe প্রথম Router পার হয়ে দ্বিতীয় Router-এ গিয়ে মারা যায়, যে একইভাবে নিজের পরিচয় জানায়।
3. এভাবে প্রতিবার TTL ১ করে বাড়ানো হয় যতক্ষণ না একটি Probe মূল গন্তব্যে পৌঁছায়, যে ভিন্নভাবে উত্তর দেয় (Echo Reply বা Port Unreachable)। তখন Traceroute থামে।

ডিফল্টভাবে এটি প্রতি Hop-এ তিনটি Probe পাঠায়, তাই প্রতিটি লাইনে তিনটি সময় দেখা যায়, এবং ৩০ Hop পর হাল ছেড়ে দেয়।

#UDP, ICMP ও TCP Traceroute

TTL কৌশল সব জায়গায় একই; পার্থক্য শুধু Probe-এর ধরনে:

গন্তব্যের কাছের Firewall UDP ও ICMP Probe Block করলে Port 443-এ TCP সংস্করণ সাধারণত পৌঁছে যায়, কারণ Service-কে ওই Port তো অনুমতি দিতেই হয়।

#Traceroute-এর আউটপুট পড়া

$ traceroute example.com
traceroute to example.com (198.51.100.20), 30 hops max, 60 byte packets
 1  192.168.1.1     1.2 ms   1.0 ms   1.1 ms
 2  203.0.113.1     6.8 ms   7.1 ms   6.9 ms
 3  * * *
 4  192.0.2.17     22.5 ms  22.1 ms  22.8 ms
 5  198.51.100.20  23.0 ms  22.9 ms  23.2 ms

• Hop 1 তোমার নিজের Router, এক-দুই মিলিসেকেন্ড দূরে। Hop 2 সাধারণত তোমার ISP।
• * * * মানে তিনটি Probe-এর কোনোটিরই Timeout-এর মধ্যে উত্তর আসেনি। মাঝখানে একটিমাত্র নীরব Hop (এখানে Hop 3) ক্ষতিকর নয়: ওই Router শুধু Time Exceeded পাঠায় না, বা Rate-limit করে। Packet যে তাকে পেরিয়ে যাচ্ছে তা পরিষ্কার, কারণ Hop 4 ও 5 উত্তর দেয়। শুধু শেষ পর্যন্ত চলতে থাকা * ইঙ্গিত দেয় যে গন্তব্য বা তার সামনের Firewall Probe Filter করছে।
• একটি Hop-এ Latency Spike যা পরের Hop-এ মিলিয়ে যায় কোনো সমস্যা নয়। Router Traffic Forward করে দ্রুত Hardware-এ, কিন্তু ICMP উত্তর তৈরি করে ধীর, কম-অগ্রাধিকারের Control Plane-এ। শুধু যে Latency (বা Loss) শেষ Hop পর্যন্ত থাকে সেটাই আসল।
• দুই Hop-এর মধ্যে বড় লাফ যা থেকে যায়, তা সাধারণত দীর্ঘ ভৌগোলিক দূরত্ব বোঝায়, যেমন Traffic বাংলাদেশ ছেড়ে Singapore বা Europe-এ গেলে, অথবা ওই Link-এ জ্যাম।
• Traceroute শুধু যাওয়ার পথ দেখায়। উত্তরগুলো অন্য পথে ফিরতে পারে (Asymmetric Routing), তাই ধীর একটি Hop আসলে ধীর ফেরার পথও হতে পারে।
• Reverse DNS Lookup বাদ দিয়ে দ্রুত ফল পেতে -n (Linux) বা -d (Windows) যোগ করো।

#mtr ও pathping: থেমে না থাকা Traceroute

একটি Traceroute শুধু এক মুহূর্তের ছবি। mtr (Linux/macOS, আর Windows-এ WinMTR) Ping ও Traceroute একসঙ্গে করে এবং প্রতিটি Hop-এ Probe করতেই থাকে, Loss ও Latency-এর পরিসংখ্যান সরাসরি হালনাগাদ করে। Windows-এর pathping একবারেই একই কাজ করে: Route খুঁজে বের করে, তারপর প্রতিটি Hop-এ ১০০ বার Ping করে (প্রতি Hop-এ মোটামুটি ২৫ সেকেন্ড) এবং প্রতি Hop-এর Loss জানায়।

mtr example.com               # সরাসরি দেখা
mtr -rwc 100 example.com      # ১০০ দফা পর Report (Ticket-এ পেস্ট করার জন্য ভালো)
pathping example.com          # Windows

mtr-ও একইভাবে পড়ো: মাঝের একটি Hop-এ Loss দেখা গেল কিন্তু পরের Hop-এ নেই মানে ওই Router ICMP Rate-limit করছে; যে Loss কোনো Hop থেকে শুরু হয়ে গন্তব্য পর্যন্ত চলে তা আসল।

#Path MTU Discovery: যখন ICMP Block করা চলবে না

প্রতিটি Link-এর একটি MTU (Maximum Transmission Unit) আছে, Ethernet-এ সাধারণত ১৫০০ Byte, কিন্তু Tunnel ও VPN-এ কম। আধুনিক TCP Stack DF (Don’t Fragment) Bit সেট করে, তাই Router বড় Packet ভাগ করতে পারে না। বদলে:

1. যে Router-এর পরের Link খুব ছোট, সে Packet ফেলে দেয়।
2. সে পাঠায় ICMP Destination Unreachable, Code 4 (Fragmentation Needed), সঙ্গে পরের Hop-এর MTU।
3. প্রেরক ওই গন্তব্যের জন্য Packet-এর আকার কমিয়ে আবার পাঠায়।

এটাই Path MTU Discovery (PMTUD)। IPv6-এ Router কখনোই Fragment করে না, এবং পাঠায় ICMPv6 Packet Too Big (Type 2)।

কোনো Firewall “নিরাপত্তার জন্য সব ICMP Block” করলে প্রেরক কখনো জানতে পারে না তার Packet বেশি বড়। ফলাফল একটি PMTUD Black Hole: TCP Handshake আর ছোট Request কাজ করে, কিন্তু বড় Page, Download ও Upload Timeout না হওয়া পর্যন্ত আটকে থাকে। Networking-এর সবচেয়ে বিভ্রান্তিকর ত্রুটিগুলোর একটি এটি। সমাধান হলো ICMP Type 3 (এবং ICMPv6 Type 2) অনুমতি দেওয়া, অথবা Router দিয়ে TCP Handshake-এ MSS কমিয়ে দেওয়া (MSS Clamping), যা VPN ও Home Router প্রায়ই করে।

তুমি নিজেও পথের MTU খুঁজে বের করতে পারো: Linux-এ ping -M do -s 1472 example.com (১৪৭২ Byte Data + ২৮ Byte Header = ১৫০০) বা Windows-এ ping -f -l 1472 example.com। “message too long” বা “Packet needs to be fragmented but DF set” পেলে আকার কমাতে থাকো যতক্ষণ না পার হয়।

#একটি Troubleshooting Ladder

কেউ যখন বলে “Internet নেই”, একবারে একটি স্তর পরীক্ষা করো, তোমার সবচেয়ে কাছেরটা দিয়ে শুরু করে। প্রথম যে ধাপ ব্যর্থ হয়, সেটিই বলে দেয় কোথায় খুঁজতে হবে।

1. ১. আমার কি Address আছে?

   ipconfig (Windows) বা ip addr (Linux/macOS)। তুমি 192.168.1.10-এর মতো একটি Address আর একটি Default Gateway দেখতে পাবে। 169.254.x.x Address মানে DHCP ব্যর্থ: সমস্যা তোমার আর Router-এর মাঝে।

2. ২. আমি কি Gateway-তে পৌঁছাতে পারি?

   ping 192.168.1.1 (তোমার Gateway)। Reply ১–৫ ms-এ আসা উচিত। এটি ব্যর্থ হলে সমস্যা স্থানীয়: Wi-Fi Signal, ভুল Network, Cable, বা Router নিজেই।

3. ৩. IP দিয়ে কি Internet-এ পৌঁছাতে পারি?

   ping 8.8.8.8 (বা 1.1.1.1)। IP Address ব্যবহার করলে DNS বাদ পড়ে, তাই এটি শুধু তোমার ISP হয়ে Routing পরীক্ষা করে। Gateway উত্তর দিলেও এটি ব্যর্থ হলে ISP-এর Link বিকল।

4. ৪. DNS কি কাজ করছে?

   nslookup example.com। IP-তে Ping কাজ করে কিন্তু নাম ব্যর্থ হলে সমস্যা DNS-এ। সরাসরি অন্য Resolver চেষ্টা করো (nslookup example.com 1.1.1.1), তারপর DNS Server বদলাও বা Cache Flush করো।

5. ৫. Service নিজে কি কাজ করছে?

   curl -I https://example.com বা Test-NetConnection example.com -Port 443। কীভাবে ব্যর্থ হয় সেটাই সূত্র: “Connection refused” মানে Host চালু কিন্তু ওই Port-এ কেউ শুনছে না; Timeout মানে Firewall বা বন্ধ Host; HTTP 502/503 মানে Server উত্তর দিয়েছে কিন্তু তার Backend ভাঙা; Certificate ত্রুটি TLS-এর দিকে ইঙ্গিত করে। এ পর্যন্ত সব কাজ করলে তোমার Network ঠিক আছে এবং সমস্যা Service-এ, তাই নিশ্চিত হতে অন্য Network থেকে চেষ্টা করো।

#Layer ধরে ধরে, Application পর্যন্ত

ওপরের Ladder উত্তর দেয় “আমার Internet কি চলছে?”। কিন্তু Internet চলছে, অথচ একটি নির্দিষ্ট Service চলছে না, তখন আরও ওপরে ওঠো, এক Layer করে, যতক্ষণ না কোথাও আটকায়। প্রতিটি Layer-এর নিজস্ব Command আছে, আর প্রতিটির ব্যর্থতা দেখতেও আলাদা:

Session Layer-এর সমস্যার (Login বারবার মেয়াদ হারায়, WebSocket বারবার নতুন করে Connect হয়) নিজস্ব কোনো Network Command নেই: এগুলো ধরা পড়ে Application Log-এ। আর সবসময় Refused আর Timed out-এর তফাত খেয়াল করো: Refused মানে চালু একটি Host উত্তর দিয়েছে, Timeout মানে পুরো নিস্তব্ধতা। দুটোর সমাধান সম্পূর্ণ আলাদা।

শুধু curl -v একাই ওপরের বেশিরভাগ Layer একবারে পার হয়, আর বলে দেয় কতদূর গেল:

$ curl -v https://shop.example.com/
*   Trying 203.0.113.10:443...                              ← DNS worked
* Connected to shop.example.com (203.0.113.10) port 443     ← TCP handshake worked
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384     ← TLS handshake worked
*  expire date: Jan 15 23:59:59 2027 GMT
*  SSL certificate verify ok.
> GET / HTTP/2
< HTTP/2 503                                                ← the application answered, with an error

পরিস্থিতিগুলো চালিয়ে দেখো, কোন ত্রুটি কোন ধাপে হাঁটা থামিয়ে দেয়:

#দূরত্বের দাম সময়: আলোর গতি

Ping-এর সময় এলোমেলো নয়। প্রতিটি Round Trip-এর বড় একটা অংশ নিছক দূরত্ব, আর দূরত্বের একটা শক্ত নিচের সীমা আছে, যা ঠিক করে দেয় পদার্থবিদ্যা।

• শূন্যস্থানে আলো চলে সেকেন্ডে প্রায় ৩,০০,০০০ কিমি। কাচের Fibre-এ কাচ তাকে ধীর করে দেয়, গতি দাঁড়ায় প্রায় ২,০০,০০০ কিমি/সেকেন্ড, মানে মোটামুটি তিন ভাগের দুই ভাগ।
• অর্থাৎ একদিকে প্রতি কিলোমিটারে ৫ µs, বা Cable-এর প্রতি ১০০ কিমিতে প্রায় ১ ms Round Trip।
• তাই ন্যূনতম Round Trip: RTT ≥ ২ × দূরত্ব ÷ ২,০০,০০০ কিমি/সেকেন্ড।

একটা হিসাব করে দেখি। ঢাকা থেকে সিঙ্গাপুর সরলরেখায় প্রায় ২,৯০০ কিমি। একদিকে: ২,৯০০ ÷ ২,০০,০০০ = ০.০১৪৫ সেকেন্ড ≈ ১৪.৫ ms। আসা-যাওয়া মিলিয়ে ≈ ২৯ ms। পদার্থবিদ্যা এর চেয়ে ভালো হতে দেয় না। বাস্তবে Ping আসে প্রায় ৪০–৬০ ms, কারণ Cable সরলরেখায় যায় না, উপকূল আর সমুদ্রতল ধরে যায়; Traffic Landing Station আর Exchange হয়ে যায়; আর প্রতিটি Router একটু করে Queue-এর সময় যোগ করে।

মনে রাখার মতো একটা নিয়ম: বাস্তব RTT ≈ সরলরেখার ন্যূনতমের ১.৫–২ গুণ। মাপা RTT এর চেয়ে অনেক বেশি হলে খোঁজো কোনো ঘুরপথ আছে কি না (কাছের দেশের Traffic ইউরোপ ঘুরে যাচ্ছে), কোথাও জ্যাম আছে কি না, বা শেষ ধাপটা ধীর কি না (যেমন Wi-Fi)।

System Design-এ এর গুরুত্ব কোথায়:

• Round Trip দূরত্বকে গুণ করে। প্রথমবার একটি HTTPS Page-এ প্রথম Byte আসার আগেই প্রায় ৪টি Round Trip লাগে (DNS, TCP, TLS, Request)। ঢাকা থেকে ভার্জিনিয়া হলে প্রায় ৪ × ২৫০ ms = ১ সেকেন্ড শুধু অপেক্ষা; সিঙ্গাপুর হলে ৪ × ৫০ ms = ২০০ ms; ঢাকার একটি CDN Edge হলে প্রায় ৪ × ৫ ms = ২০ ms।
• Bandwidth Round Trip ছোট করে না। দ্রুত লাইন বড় Download আগে শেষ করে, কিন্তু প্রতিটি Request–Response-কে তবুও আলোর যাওয়া-আসার অপেক্ষা করতে হয়।
• তাই Server সরাও, বা Round Trip কমাও। ব্যবহারকারীর সবচেয়ে কাছের Region-এ Server রাখো, Static Content CDN-এ দাও, কাছের Edge-এ TLS Terminate করো, Connection আবার ব্যবহার করো, আর কম Handshake-এর জন্য HTTP/3 নাও। Lesson 1.11-এ Cloud-এর ভেতরেও একই সংখ্যা দেখেছ: এক Zone-এ ~০.১–০.৫ ms, ভিন্ন Zone-এ ~১–২ ms, ভিন্ন Region-এ কয়েক দশ থেকে কয়েকশো ms।

#System Design-এ Diagnostics

• সব ICMP Block কোরো না। অন্তত Destination Unreachable (বিশেষ করে “Fragmentation Needed”), Time Exceeded ও ICMPv6 Packet Too Big অনুমতি দাও; Echo Block করা একটি পছন্দ, বাকিগুলো Block করলে জিনিস ভাঙে।
• Health Check Service পরীক্ষা করবে, Ping নয়। যে Load Balancer শুধু Server-কে Ping করে, সে এমন Machine-এ Traffic পাঠাতে থাকবে যার Application Crash করেছে। /health-এর মতো একটি HTTP Endpoint দেখো, বা অন্তত একটি TCP Connection খোলো।
• ব্যবহারকারীর দিক থেকে মাপো। তোমার Laptop থেকে একটি Ping খুব কম কথা বলে। কয়েকটি Region থেকে Synthetic Monitoring, এবং গড়ের বদলে Latency Percentile (p50, p95, p99) দেখায় ব্যবহারকারী আসলে কী অনুভব করছে।
• Escalate করার আগে প্রমাণ জোগাড় করো। আক্রান্ত Network থেকে একটি mtr -rwc 100 Report, সঙ্গে সময় ও দুই প্রান্তের IP Address, এটাই একটি ISP বা Cloud Provider-এর Routing সমস্যায় পদক্ষেপ নিতে দরকার।
• ফেরার পথ মনে রাখো। Traceroute শুধু একদিক দেখায়। সমস্যা শুধু কিছু ব্যবহারকারীর ক্ষেত্রে হলে দুই প্রান্ত থেকেই Traceroute চালাও।
• ভূগোল থেকে Latency-র বাজেট করো। Region বাছার আগে ব্যবহারকারী পর্যন্ত ন্যূনতম RTT হিসাব করো (দূরত্ব × ২ ÷ ২,০০,০০০ কিমি/সেকেন্ড), তারপর একটি Request-এ কয়টি Round Trip লাগে তা দিয়ে গুণ করো। উত্তর বেশি ধীর হলে Server যতই Tune করো, লাভ নেই: কাছে Deploy করো, বা Edge-এ Cache করো।
• Certificate মেয়াদ ফুরানোর আগেই Alert নাও, আর প্রতিটি Service-কে তার Log ও Metric-এ জানাতে দাও কোন Layer ব্যর্থ হলো (DNS Error, Connection Refused, Timeout, TLS Error, HTTP Status)। তাহলে রাতে ডাক পড়লে Layer ধরে খোঁজার কাজটা আগেই অর্ধেক হয়ে থাকবে।

#নিজে করে দেখো

# Ping: ৫টি Request, তারপর সারাংশ
ping -c 5 example.com          # Linux / macOS
ping -n 5 example.com          # Windows

# Don't Fragment সেট করে বড় Packet (পথের MTU খোঁজা)
ping -M do -s 1472 example.com # Linux
ping -f -l 1472 example.com    # Windows

# Traceroute-এর তিন রূপ
traceroute -n example.com           # UDP Probe, Reverse DNS ছাড়া
traceroute -I example.com           # ICMP Probe
sudo traceroute -T -p 443 example.com   # Port 443-এ TCP SYN Probe
tracert -d example.com              # Windows

# প্রতি Hop-এর চলমান পরিসংখ্যান
mtr example.com
pathping example.com           # Windows

# Troubleshooting Ladder
ip addr; ip route              # অথবা: ipconfig
ping -c 3 192.168.1.1
ping -c 3 8.8.8.8
nslookup example.com
curl -I https://example.com

# Layer ধরে ধরে, Application পর্যন্ত
ip link                                        # link state (Linux)
dig example.com                                # DNS through your resolver
dig @1.1.1.1 example.com                       # DNS through another resolver
nc -vz example.com 443                         # TCP port test (Linux / macOS)
Test-NetConnection example.com -Port 443       # TCP port test (Windows PowerShell)
ss -tlnp                                       # on a server: who listens on which port
openssl s_client -connect example.com:443 -servername example.com </dev/null | grep -E "subject|issuer|Verify"
curl -v https://example.com/ -o /dev/null      # DNS, TCP, TLS and HTTP in one go

কয়েকটি লক্ষ্যে Ping করে তুলনা করো: তোমার Router (প্রায় ১ ms), বাংলাদেশের একটি Server, Singapore-এর একটি, আর Europe-এর একটি। দেখবে দূরত্ব সরাসরি মিলিসেকেন্ডে রূপ নিচ্ছে। তারপর পদার্থবিদ্যার সঙ্গে মিলিয়ে দেখো: সরলরেখার দূরত্ব খুঁজে বের করো, প্রতি Millisecond Round Trip-এ ১০০ কিমি ধরে ভাগ করো, আর দেখো বাস্তব Routing এর কত কাছাকাছি যায়।

#সারসংক্ষেপ

মূল কথা

• ICMP হলো ত্রুটি ও Diagnostics-এর জন্য Network Layer-এর বার্তা Protocol। এটি IP-এর ভেতরে চলে, এর Type ও Code আছে, Port নেই।
• প্রধান Type: 8/0 Echo Request/Reply (Ping), 3 Destination Unreachable (Code 0 Network, 1 Host, 3 Port, 4 Fragmentation Needed, 13 Prohibited), 5 Redirect, 11 Time Exceeded (Traceroute)।
• Ping মাপে পৌঁছানো যায় কি না, RTT, Packet Loss এবং mdev দিয়ে Jitter। এটি কখনো Bandwidth মাপে না। নামটি Sonar থেকে; “Packet Internet Groper” একটি Backronym।
• ব্যর্থ Ping মানে হতে পারে ICMP Filter করা বা DNS ব্যর্থ, Service বন্ধ নয়। আসল Service পরীক্ষা করো curl বা একটি TCP Connection দিয়ে।
• Traceroute TTL 1, 2, 3… দিয়ে Probe পাঠায় এবং যে Router-গুলো Time Exceeded ফেরত দেয় তাদের তালিকা করে। Linux UDP ব্যবহার করে (Port 33434+), Windows ICMP, আর TCP Mode Firewall পেরিয়ে যায়।
• Traceroute-এ একাকী * * * বা এক Hop-এর Spike সাধারণত ক্ষতিকর নয়; শুধু যে Loss বা Latency গন্তব্য পর্যন্ত থাকে তা গুরুত্বপূর্ণ। mtr ও pathping সময়ের সঙ্গে প্রতি Hop-এর পরিসংখ্যান দেয়।
• Path MTU Discovery ICMP “Fragmentation Needed” / “Packet Too Big”-এর ওপর নির্ভর করে; এগুলো Block করলে বড় Transfer আটকে যায়।
• নিচ থেকে ওপরে Troubleshoot করো: নিজের IP → Gateway → 8.8.8.8 → DNS → Service। একটি নির্দিষ্ট Service ব্যর্থ হলে আরও ওপরে ওঠো: Link → IP → Gateway → DNS (dig) → Port (nc, ss) → TLS (openssl s_client) → HTTP (curl -v)। Refused মানে চালু Host-এ কেউ শুনছে না; Timeout মানে কেউ Packet ফেলে দিচ্ছে।
• Fibre-এ আলো যায় প্রতি Millisecond-এ প্রায় ২০০ কিমি (একদিকে কিলোমিটারপ্রতি ৫ µs): RTT ≥ ২ × দূরত্ব ÷ ২,০০,০০০ কিমি/সেকেন্ড, আর বাস্তব পথে লাগে তার ১.৫–২ গুণ। ঢাকা–সিঙ্গাপুর ≈ ৪০–৬০ ms, ঢাকা–US East ≥ ~২০০ ms। একে হারানোর উপায় শুধু Server বা Cache কাছে আনা, অথবা Round Trip কমানো।

নিজেকে যাচাই করো: ICMP, Ping, Traceroute আর Troubleshooting২৯টি প্রশ্ন