একজন গেস্ট হয়তো একটি সাইট ব্রাউজ করতে পারছেন কিন্তু অন্যটি পারছেন না। স্টাফরা বলছেন রিসেপশনের কাছে WiFi "ধীরগতির"। একটি হোটেল PMS টার্মিনাল প্রতি কয়েক মিনিটে নেটওয়ার্ক থেকে বিচ্ছিন্ন হয়ে যাচ্ছে, অথচ কন্ট্রোলার ড্যাশবোর্ডটি দেখতে একেবারেই ঠিকঠাক লাগছে। সেই মুহূর্তে, আপনি থিওরি দিয়ে শুরু করেন না। আপনি একটি শেল ওপেন করেন এবং ping রান করেন।
এই কারণেই check ping cmd এখনও গুরুত্বপূর্ণ। এটি দ্রুত, লোকাল এবং অত্যন্ত নির্ভুল। এটি আপনাকে সবকিছু বলবে না, তবে অনুমান করা বন্ধ করতে আপনাকে কোথায় থামতে হবে তা জানিয়ে দেবে।
অধিকাংশ মৌলিক গাইডগুলো "ping google.com টাইপ করুন" পর্যন্ত এসে থমকে যায়। এটি কার্যকর, তবে আধুনিক এন্টারপ্রাইজ WiFi-এর গভীর জটিলতাগুলো এতে এড়িয়ে যাওয়া হয়। হসপিটালিটি, রিটেইল, হেলথকেয়ার এবং মাল্টি-টেন্যান্ট সাইটগুলোতে, কানেক্টিভিটির সমস্যাগুলো প্রায়শই অথেন্টিকেশন, রোমিং, কন্ট্রোলার রিচিবিলিটি, MTU মিসম্যাচ বা আইডেন্টিটি ওয়ার্কফ্লোর ভেতরে লুকিয়ে থাকে। একটি পাবলিক হোস্টের সফল পিং প্রমাণ করে না যে গেস্টের কানেকশন জার্নিটি ঠিকঠাক চলছে। আবার একটি ব্যর্থ পিংও সবসময় প্রমাণ করে না যে নেটওয়ার্কটি সম্পূর্ণ ভেঙে পড়েছে।
সঠিকভাবে ব্যবহার করলে, ping কেবল একটি একক কমান্ড নয়, বরং এটি একটি ডায়াগনস্টিক অভ্যাস। আপনি প্রথমে ডিভাইসের সবচেয়ে কাছাকাছি টেস্ট করেন। তারপর বাইরের দিকে অগ্রসর হন। আপনি টার্গেটগুলোর তুলনা করেন। আপনি প্যাকেটের সাইজ পরিবর্তন করেন। আপনি সময়ের সাথে সাথে লস এবং জিটার পর্যবেক্ষণ করেন। এবং যখন ping আর যথেষ্ট মনে হয় না, তখন অন্ধভাবে খোঁজার পরিবর্তে একটি স্পষ্ট হাইপোথিসিস নিয়ে আপনি tracert, pathping, লগ এবং প্যাকেট ক্যাপচারে চলে যান।
কেন নেটওয়ার্কের সমস্যার ক্ষেত্রে পিং এখনও আপনার প্রথম রেসপন্ডার
একজন গেস্ট হয়তো বলতে পারেন WiFi কাজ করছে না, কিন্তু মূল সমস্যাটি হয়তো DNS, Captive Portal রিডাইরেক্ট, আপস্ট্রিম রিচিবিলিটি, অথবা SSID-এর পেছনে থাকা অথেন্টিকেশন পাথে থাকতে পারে। Ping এখনও রান করার মতো প্রথম কমান্ড, কারণ এটি সেই সম্ভাবনাগুলোকে দ্রুত আলাদা করে এবং ড্যাশবোর্ড, কন্ট্রোলার লগ বা প্যাকেট ক্যাপচার খোলার আগেই আপনাকে একটি ফল্ট বাউন্ডারি প্রদান করে।
নিকটতম সত্য দিয়ে শুরু করুন
ভালো ট্রাবলশুটিং সবসময় ডিভাইসের কাছাকাছি জায়গা থেকে শুরু হয়।
লোকাল স্ট্যাক, ডিফল্ট গেটওয়ে এবং একটি পরিচিত আপস্ট্রিম টার্গেটে পাঠানো কয়েকটি ইকো রিকোয়েস্ট আপনাকে বলে দিতে পারে যে আপনি কোনও ক্লায়েন্ট সমস্যা, লোকাল RF বা সাবনেট সমস্যা, নাকি পাথের আরও দূরের কোনও সমস্যার মুখোমুখি হচ্ছেন। একটি Purple-ম্যানেজড পরিবেশে এটি অত্যন্ত গুরুত্বপূর্ণ, কারণ রেডিও লিঙ্ক ঠিক থাকা সত্ত্বেও এবং মূল বিলম্বটি অনবোর্ডিং, পলিসি এনফোর্সমেন্ট বা ইন্টারনেট ব্রেকআউটে থাকা সত্ত্বেও অভিযোগটি প্রায়শই "WiFi ধীরগতির" হিসেবে আসে।
Ping আপনাকে নিয়মের মধ্যে কাজ করতেও সাহায্য করে। যদি গেটওয়ে স্থিতিশীল থাকে এবং পাবলিক টার্গেটটি স্থিতিশীল না হয়, তবে প্রথম বিশ মিনিট অ্যাক্সেস পয়েন্ট সেটিংসে ব্যয় করা সাধারণত সময়ের অপচয়। যদি গেটওয়ে নিজেই রিপ্লাই ড্রপ করে বা অনিয়মিত ল্যাটেন্সি দেখায়, তবে ক্লাউড-সাইডের অনুমান নিয়ে কাজ শুরু করার কোনও কারণ নেই।
কেন বেসিক গাইডগুলো যথেষ্ট নয়
অনেক নতুনদের জন্য তৈরি গাইড ping-কে কেবল হ্যাঁ বা না-এর পরীক্ষা হিসেবে দেখে। বাস্তব নেটওয়ার্কগুলো এতটা সহজ হয় না।
Enterprise WiFi, বিশেষ করে পরিচয়-ভিত্তিক গেস্ট এবং স্টাফ অ্যাক্সেস, এমন কিছু নির্ভরতা যোগ করে যা পুরোনো ট্রাবলশুটিং প্লেবুকে খুব কমই উল্লেখ করা হয়। একটি ডিভাইস SSID-এর সাথে যুক্ত হতে পারে, একটি IP অ্যাড্রেস পেতে পারে এবং তবুও একটি খারাপ ব্যবহারকারীর অভিজ্ঞতা থাকতে পারে কারণ captive portal হ্যান্ডলিং ধীরগতির, একটি RADIUS লেনদেনে বিলম্ব হচ্ছে, অথবা একটি পলিসি সিদ্ধান্তের কারণে প্রথম ব্যবহারযোগ্য কানেকশনটি স্থবির হয়ে পড়েছে। আগে যেমন উল্লেখ করা হয়েছে, CMD দিয়ে পিং চেক করার কিছু পাবলিক নির্দেশিকায় নির্দেশ করা হয়েছে যে সাধারণ হোস্ট টেস্টগুলি আধুনিক অ্যাক্সেস ওয়ার্কফ্লোতে সেই সেশন-শুরু বিলম্বগুলি মিস করে।
সেজন্য আমি একটি পাবলিক সাইটে সফল পিংকে পরিষেবাটি সুস্থ থাকার প্রমাণ হিসাবে বিবেচনা করি না। এটি কেবল প্রমাণ করে যে সেই মুহূর্তে দুটি পয়েন্টের মধ্যে ICMP কাজ করেছে। একটি Purple স্থাপনায়, ব্যবহারকারীর যাত্রা এখনও সেই স্তরের উপরে ভেঙে যেতে পারে।
ব্যবহারিক নিয়ম:
pingএকটি নির্দিষ্ট পথের জন্য পৌঁছানোর যোগ্যতা এবং টাইমিং যাচাই করে। এটি captive portal লজিক, অ্যাপ্লিকেশনের স্বাস্থ্য, বা এন্ড-টু-এন্ড আইডেন্টিটি ওয়ার্কফ্লো যাচাই করে না।
পিং আরও ভাল নেটওয়ার্ক বিচার শেখায়
অভিজ্ঞ প্রকৌশলীরা অন্য একটি কারণে ping ব্যবহার চালিয়ে যান। এটি একবারে একটি সীমানা পরীক্ষা করার অভ্যাস তৈরি করে।
স্থানীয়ভাবে শুরু করুন। গেটওয়ে পরীক্ষা করুন। আপনার কাছে থাকলে একটি নিয়ন্ত্রিত অভ্যন্তরীণ লক্ষ্য পরীক্ষা করুন। তারপর একটি বাহ্যিক গন্তব্য পরীক্ষা করুন। একটি একক উত্তরের দিকে তাকিয়ে এবং এটিকে ভালো বলে মনে করার পরিবর্তে লেটেন্সি, লস এবং ধারাবাহিকতা তুলনা করুন। ব্যস্ত WiFi পরিবেশে, সেই দৃষ্টিভঙ্গি প্রায়শই প্রকাশ করে যে সমস্যাটি ক্লায়েন্ট, VLAN, সাইট আপলিঙ্ক নাকি ওয়্যারলেস নেটওয়ার্কের বাইরের কোনো পরিষেবা নির্ভরতা অনুসরণ করছে।
আপনি যদি সেই সহজাত প্রবৃত্তিগুলি তৈরি করছেন, তবে শক্ত রাউটিং এবং সুইচিংয়ের মৌলিক বিষয়গুলি এখনও গুরুত্বপূর্ণ। এই CCNA Practice Exam -এর মতো রিসোর্সগুলি একটি সহজ কমান্ডের মতো দেখায় এমন বিষয়ের পিছনের ট্রাবলশুটিং লজিককে শক্তিশালী করতে সহায়তা করে।
Ping প্রতিটি সমস্যার সমাধান করে না। এটি আপনাকে একটি পরিষ্কার প্রথম রিড দেয় এবং নেটওয়ার্ক অপারেশনে, এটি সাধারণত সবচেয়ে বেশি সময় বাঁচায়।
CMD এবং PowerShell-এ পিং কমান্ড আয়ত্ত করা
মূল সিনট্যাক্সটি সহজ:
- বেসিক হোস্ট টেস্ট:
ping hostname - বেসিক IP টেস্ট:
ping target-ip
কমান্ড প্রম্পট এবং PowerShell-এ, Windows-এ ping একটি পরিচিত উপায়ে কাজ করে। আপনি যে সমস্যাটি আলাদা করার চেষ্টা করছেন তার জন্য সঠিক ফ্ল্যাগগুলি বেছে নেওয়ার মাধ্যমে এর আসল মূল্য পাওয়া যায়।
ফ্ল্যাগগুলি যা আসলেই গুরুত্বপূর্ণ
Windows-এ একটি সঠিক check ping cmd ওয়ার্কফ্লো করার সময় আমি প্রায়শই যে অপশনগুলি ব্যবহার করি তা এখানে রয়েছে।
| ফ্ল্যাগ | এটি কী করে | কখন এটি ব্যবহার করবেন |
|---|---|---|
-t |
বন্ধ না করা পর্যন্ত একটানা চলতে থাকে | সাময়িক ড্রপ, roaming সমস্যা, অস্থিতিশীল WAN |
-n |
নির্দিষ্ট সংখ্যক echo অনুরোধ পাঠায় | টিকিট নোটের জন্য দ্রুত পুনরাবৃত্তিযোগ্য পরীক্ষা |
-l |
প্যাকেটের সাইজ নির্ধারণ করে | MTU এবং ফ্র্যাগমেন্টেশন পরীক্ষা |
-w |
মিলিসেকেন্ডে টাইমআউট নির্ধারণ করে | উচ্চ-লেটেন্সি বা দূরবর্তী সাইট পরীক্ষা |
CMD-তে প্রয়োজনীয় উদাহরণ
কয়েকটি ব্যবহারিক প্যাটার্ন:
- দ্রুত অ্যাক্সেসযোগ্যতার পরীক্ষা:
ping target-host - একটানা মনিটরিং:
ping -t target-host - সংক্ষিপ্ত নমুনা পরীক্ষা:
ping -n target-count target-host - বড় প্যাকেটের পরীক্ষা:
ping -l target-size target-host - টাইমআউটের আগে দীর্ঘ প্রতীক্ষা:
ping -w target-timeout target-host
একটি চলমান ping থামাতে এবং সারাংশ পরিসংখ্যান প্রদর্শন করতে Ctrl+C ব্যবহার করুন।
PowerShell-এ একই অভ্যাস
Windows PowerShell-এ, আপনি এখনও সরাসরি স্ট্যান্ডার্ড ping কমান্ডটি চালাতে পারেন। অনেক অ্যাডমিনের জন্য এটাই যথেষ্ট। PowerShell-এর সুবিধা হলো আপনি এর চারপাশে কী করতে পারেন।
আপনি ping-কে স্ক্রিপ্টে অন্তর্ভুক্ত করতে পারেন, আউটপুটে টাইমস্ট্যাম্প দিতে পারেন, টার্গেট তালিকার মধ্য দিয়ে লুপ চালাতে পারেন, অথবা একটি roaming পরীক্ষার সময় ব্যর্থতাগুলো লগ করতে পারেন। কোনো সমস্যা যখন সাথে সাথে দেখা যায় না, তখন এটি বেশ কার্যকর।
একটি সহজ উদাহরণ হলো একটি টেস্ট ডিভাইস নিয়ে কোনো ভেন্যুতে ঘুরে বেড়ানোর সময় একটি উইন্ডোতে একটানা ping চালানো। অন্য একটি উদাহরণ হলো কনফিগারেশন পরিবর্তনের আগে এবং পরে একটি নির্দিষ্ট সংখ্যক ping পাঠানো যাতে আপনার কাছে পরিবর্তনের আগের ও পরের স্পষ্ট রেকর্ড থাকে।
সঠিক ফ্ল্যাগ কীভাবে নির্বাচন করবেন
প্রতিবার সব অপশন ব্যবহার করবেন না। লক্ষণের সাথে মিলিয়ে পরীক্ষাটি নির্বাচন করুন।
- ব্যবহারকারী বলছেন সমস্যাটি ক্রমাগত হচ্ছে: একটি সাধারণ ping দিয়ে শুরু করুন, তারপর নির্দিষ্ট সংখ্যক
-nব্যবহার করুন। - ব্যবহারকারী বলছেন এটি "মাঝে মাঝে" ঘটে:
-tব্যবহার করুন। - পোর্টাল লগইন বা ডিভাইস অনবোর্ডিং অসংগত মনে হচ্ছে:
-lদিয়ে প্যাকেটের সাইজ পরীক্ষা করুন। - দূরবর্তী প্রোপার্টি বা ধীর ব্যাকহল:
-wদিয়ে টাইমআউট বাড়ান।
সুবিধাকে প্রমাণের সাথে গুলিয়ে ফেলবেন না। একটি চার-প্যাকেট সফল হওয়ার অর্থ কেবল এটাই যে সেই চারটি প্যাকেট সফলভাবে পার হয়েছে।
যেখানে প্যাকেটের সাইজ গুরুত্বপূর্ণ হয়ে ওঠে
অনেক অ্যাডমিন কখনোই -l ব্যবহার করেন না, যা একটি ভুল। সাধারণ ছোট ping-গুলো সফল দেখাতে পারে, যেখানে বড় বাস্তব ট্র্যাফিক বাধাগ্রস্ত হয়। এন্টারপ্রাইজ WiFi-এ, এটি প্রায়শই MTU অমিল, ফ্র্যাগমেন্টেশন, অথবা টানেল এবং সিকিউরিটি লেয়ার জুড়ে ত্রুটিপূর্ণ হ্যান্ড-অফ নির্দেশ করে।
ব্যবহারিক পদক্ষেপ হলো একটি সাধারণ পিং-এর সাথে একটি বৃহত্তর-পেলোড টেস্টের তুলনা করা। যদি ছোট প্যাকেটগুলো ঠিক থাকে এবং বড়গুলো ঠিকমতো কাজ না করে, তবে আপনি প্যাকেট অ্যানালাইজার স্পর্শ না করেই একটি গুরুত্বপূর্ণ তথ্য জেনে গেছেন।
সেখানেই ping একটি সাধারণ কমান্ডের পরিবর্তে একটি নিখুঁত টুলের মতো আচরণ শুরু করে।
কীভাবে একজন পেশাদারের মতো পিং স্ট্যাটিস্টিকস বিশ্লেষণ করবেন
একটি নিখুঁত ping উত্তর আসার পরেও ব্যবহারকারীর অভিজ্ঞতা খারাপ হতে পারে। এন্টারপ্রাইজ WiFi-এ এটি সবসময় ঘটে। একটি ডিভাইস গেটওয়েতে পৌঁছায়, কিন্তু Captive Portal লগইন আটকে যায়, পলিসি অ্যাসাইনমেন্টে বিলম্ব হয়, অথবা রোমিং সেশনকে কয়েক সেকেন্ডের জন্য ব্যাহত করে। ping আউটপুট সঠিকভাবে পড়ার অর্থ হলো এটিকে একটি বড় চেইনের একটি একক সংকেত হিসেবে বিবেচনা করা।
সারাংশ দিয়ে শুরু করুন, তারপর প্যাটার্নটি পড়ুন
যেকোনো একক উত্তরের চেয়ে নিচের সারাংশটি বেশি গুরুত্বপূর্ণ। প্যাকেট লস, রাউন্ড-ট্রিপ টাইম এবং সর্বনিম্ন ও সর্বোচ্চ রেসপন্স টাইমের পার্থক্যের দিকে মনোযোগ দিন।
আমি যখন একটি Purple-পরিচালিত ভেন্যু পরীক্ষা করি, তখন আমি প্রতিটি টার্গেটকে একইভাবে মূল্যায়ন করি না। একটি ক্লায়েন্ট-টু-গেটওয়ে পিং সাধারণত স্থিতিশীল এবং কম-লেটেন্সি হওয়া উচিত। একটি পাবলিক SaaS এন্ডপয়েন্টে পিং করতে স্বাভাবিকভাবেই বেশি সময় লাগবে। গুরুত্বপূর্ণ বিষয় হলো ফলাফলটি আপনি যে পাথটি পরীক্ষা করছেন তার সাথে সামঞ্জস্যপূর্ণ কিনা।
আউটপুটের একটি অনুচ্ছেদ তিনটি দরকারী প্রশ্নের উত্তর দিতে পারে। পাথটি কি প্যাকেট ড্রপ করছে? বিলম্ব কি ক্রমাগত বেশি? বিলম্ব কি প্রতিটি উত্তরের সাথে ওঠানামা করছে?
টার্গেটের সাপেক্ষে ফলাফল বিচার করুন
একটি গেটওয়ে, DNS রিজলভার, RADIUS সার্ভার, কন্ট্রোলার এবং পাবলিক ওয়েবসাইট প্রতিটি আপনাকে আলাদা তথ্য দেয়।
স্থানীয় অবকাঠামোতে কোনো সমস্যা থাকা উচিত নয়। উত্তরগুলো স্থিতিশীল হওয়া উচিত। যদি তা না হয়, তবে ক্লায়েন্ট এজ থেকে শুরু করুন: RF কোয়ালিটি, ক্লায়েন্ট ড্রাইভারের আচরণ, AP লোড, VLAN অ্যাসাইনমেন্ট, সুইচ আপলিঙ্ক বা স্থানীয় ফায়ারওয়াল পলিসি। প্রথম ধাপটি ইতিমধ্যেই অস্থির থাকলে সরাসরি Microsoft 365, Google বা কোনো Captive Portal প্রদানকারীকে দোষারোপ করতে যাবেন না।
দূরবর্তী টার্গেটগুলোর জন্য আরও সূক্ষ্ম বিচার প্রয়োজন। WAN লিঙ্ক, ইন্টারনেট ব্রেকআউট পয়েন্ট এবং ক্লাউড সিকিউরিটি লেয়ার জুড়ে বেশি লেটেন্সি হওয়া স্বাভাবিক। শুধুমাত্র উচ্চ গড় লেটেন্সির চেয়ে ব্যাপক ওঠানামা বেশি উদ্বেগজনক, বিশেষ করে আইডেন্টিটি-ভিত্তিক WiFi-এ যেখানে ব্যবহারকারীরা অনবোর্ডিং, সার্টিফিকেট চেক, পলিসি লুকআপ এবং পোস্ট-অথ রিডাইরেক্টের সময় বিলম্ব অনুভব করেন।
নেটওয়ার্ক ট্রাবলশুটিং এবং মনিটরিংয়ে পিং নিয়ে Kentik-এর ওভারভিউতে আগেই যেমন উল্লেখ করা হয়েছে, প্যাকেট লস এবং অসঙ্গতিপূর্ণ রাউন্ড-ট্রিপ টাইম হলো সেই সংকেত যা সবার আগে মনোযোগ পাওয়ার যোগ্য।
ওঠানামাই প্রায়শই অভিযোগের কারণ ব্যাখ্যা করে
ব্যবহারকারীরা খুব কমই "উচ্চ লেটেন্সি"-র রিপোর্ট করেন। তারা রিপোর্ট করেন ঘুরতে থাকা লগইন স্ক্রিন, অস্পষ্ট কল, আটকে থাকা স্প্ল্যাশ পেজ এবং এমন অ্যাপ যা দ্বিতীয় চেষ্টায় কাজ করে।
এটি প্রায়শই ওঠানামাজনিত সমস্যা।
গড় হিসেব এটিকে আড়াল করে। উত্তর যদি ৮ মিলি-সেকেন্ড, ৯ মিলি-সেকেন্ড, ১১ মিলি-সেকেন্ড এবং তারপর ১৮০ মিলি-সেকেন্ডে আসে, তবে প্রথম নজরে গড়টি গ্রহণযোগ্য মনে হতে পারে। তবে ব্যবহারকারী ঠিকই গতি হ্রাসের এই ধাক্কাটি টের পাবেন। WiFi-এর ক্ষেত্রে, এটি পুনরায় ট্রান্সমিশন, এয়ারটাইম দ্বন্দ্ব, ক্লায়েন্ট ডিভাইসে পাওয়ার-সেভ আচরণ, রোমিং বাধা, বা আপস্ট্রিম কিউয়িং-এর ইঙ্গিত হতে পারে।
| প্যাটার্ন | সম্ভাব্য অর্থ | পরবর্তী পদক্ষেপ |
|---|---|---|
| কম গড়, সংকীর্ণ পরিসীমা | সুস্থ পাথ | চেইনের পরবর্তী ডিপেন্ডেন্সি পরীক্ষা করুন |
| কম গড়, বিস্তৃত পরিসীমা | সাময়িক অস্থিরতা, কিউয়িং, বা RF সমস্যা | দীর্ঘ সময়ের জন্য পরীক্ষা চালান এবং লোকাল বনাম রিমোট টার্গেট তুলনা করুন |
| প্যাকেট লস বিদ্যমান | কনজেশন, RF সমস্যা, ফিল্টারিং, বা আপস্ট্রিম লস | প্রথমে গেটওয়ে পরীক্ষা করুন, তারপর একটি পরিচিত ইন্টারনেট হোস্ট |
| লোকাল ভালো, রিমোট খারাপ | WAN, ISP, ক্লাউড পাথ, বা বাহ্যিক সার্ভিস সমস্যা | রুট-ভিত্তিক টুলস এবং সার্ভিস চেকের মাধ্যমে যাচাই করুন |
TTL সাহায্য করে, কিন্তু সামান্যই
TTL একটি সূত্র হিসেবে দরকারী। এটি ইঙ্গিত করতে পারে যে আপনি প্রত্যাশার চেয়ে ভিন্ন একটি হোস্টে পৌঁছাচ্ছেন, ভিন্ন কোনো পথ অতিক্রম করছেন, অথবা ভিন্ন ডিফল্ট সেটিংস সহ সিস্টেমের তুলনা করছেন।
এটি নিজে থেকে কোনো জোরালো প্রমাণ নয়।
অনেক অ্যাডমিন TTL-এর পার্থক্য ব্যাখ্যা করতে সময় নষ্ট করেন, অথচ সবচেয়ে গুরুত্বপূর্ণ ফলাফলটি উপেক্ষা করেন: কোনো ক্ষতি ছাড়াই স্থিতিশীল লোকাল ল্যাটেন্সি, নাকি স্পষ্ট স্পাইক সহ অস্থিতিশীল লোকাল ল্যাটেন্সি। TTL রোগ নির্ণয়ে সহায়তা করে। এটি নিজেই রোগ নির্ণয় করে না।
WiFi-এর ক্ষেত্রে, সুস্থ পিং পুরো সার্ভিস পাথকে ত্রুটিমুক্ত প্রমাণ করে না
আধুনিক গেস্ট এবং এন্টারপ্রাইজ অ্যাক্সেস নেটওয়ার্কের ক্ষেত্রে এটি অত্যন্ত গুরুত্বপূর্ণ। Purple পরিবেশে, একজন ব্যবহারকারীর সম্পূর্ণ নিখুঁত ICMP রিচিবিলিটি থাকতে পারে এবং তবুও DHCP রিনিউয়াল, DNS রেজোলিউশন, Captive Portal রিডাইরেকশন, বা আইডেন্টিটি এনফোর্সমেন্টে ব্যর্থ হতে পারে। এই কারণেই গেটওয়েতে একটি সফল ping সমস্যার কেবল একটি অংশকেই দূর করে।
যদি লোকাল ICMP সুস্থ দেখায় কিন্তু সেশনটি এখনও ত্রুটিপূর্ণ মনে হয়, তবে আশেপাশের সার্ভিসগুলো পর্যালোচনা করুন। DHCP এবং DNS WiFi ফান্ডামেন্টাল সম্পর্কিত Purple-এর গাইডটি DHCP and DNS WiFi fundamentals একটি ভালো রেফারেন্স, কারণ অনেক সমস্যা যা দেখতে RF সমস্যা মনে হয়, তা আসলে অ্যাড্রেস অ্যাসাইনমেন্ট বা নেম রেজোলিউশন থেকে শুরু হয়।
পেশাদার প্রশ্নটি সহজ: এই ফলাফলটি কোন সমস্যাটিকে বাদ দিল, এবং এর পর আপনাকে কী পরীক্ষা করতে বাধ্য করছে?
Tracert এবং Pathping এর সাহায্যে আপনার টুলকিট সম্প্রসারণ করা
একজন ব্যবহারকারী WiFi-এ সংযুক্ত হন, অ্যাসোসিয়েশন পার করেন, মাঝে মাঝে ইন্টারনেটে প্রবেশ করতে পারেন, এবং জোর দিয়ে বলেন যে সমস্যাটি কেবল ভবনের একটি নির্দিষ্ট অংশেই ঘটে। Ping লক্ষণটি নিশ্চিত করে। Tracert এবং pathping এটি কোথায় ঘটছে তা সনাক্ত করতে সাহায্য করে।
বাস্তব ক্ষেত্রে, যখন আমি বুঝতে পারি যে কেবল প্রাথমিক সংযোগ যাচাই করাই যথেষ্ট নয়, তখন আমি এই টুলগুলো ব্যবহার করি। এগুলো আলাদা আলাদা প্রশ্নের উত্তর দেয়। Tracert দেখায় যে একটি প্যাকেট কোন পথ দিয়ে যাচ্ছে। অন্যদিকে, Pathping সেই পুরো পথ জুড়ে প্যাকেট লস এবং বিলম্ব পরিমাপ করতে বেশি সময় নেয়। একটি Purple-পরিচালিত পরিবেশে এই পার্থক্যটি অত্যন্ত গুরুত্বপূর্ণ, কারণ কোনো ত্রুটির উৎস ভেন্যু LAN, WAN পাথ, অথবা অথেন্টিকেশন, পলিসি বা গেস্ট অ্যাক্সেসের সাথে যুক্ত কোনো ক্লাউড ডিপেনডেন্সির ভেতরেও থাকতে পারে।
tracert আপনাকে কী সুবিধা দেয়
কোথায় পরিস্থিতি পরিবর্তিত হচ্ছে তা দ্রুত জানার একটি সহজ উপায় হলো Tracert।
যদি কোনো ক্লায়েন্ট সফলভাবে লোকাল গেটওয়েকে পিং করতে পারে কিন্তু একটি SaaS প্ল্যাটফর্ম ধীরগতির মনে হয়, তবে সার্ভিস এন্ডপয়েন্ট বা কোনো নির্ভরযোগ্য পাবলিক টার্গেটে একটি ট্রেস রান করুন। ল্যাটেন্সি বা বিলম্ব ঠিক কোন ধাপে প্রথম বাড়ছে এবং বিভিন্ন সাইটের মধ্যে রুট বা পথে কোনো অমিল আছে কিনা তা খেয়াল করুন। এটি আপনাকে সমস্যা সমাধানের সঠিক দিকনির্দেশনা দেবে। যদি দ্বিতীয় ধাপে সমস্যা দেখা দেয়, তবে বুঝতে হবে ত্রুটিটি লোকাল এজ, ফায়ারওয়াল বা ISP হ্যান্ডঅফের দিকে রয়েছে। আর যদি সমস্যাটি অনেক পরে দেখা দেয়, তবে সাধারণত এটি প্রোভাইডার পাথ বা ডেস্টিনেশন নেটওয়ার্কের দিকে ইঙ্গিত করে।
এখানে মূল বিষয় হলো গতি বনাম নির্ভুলতার আপস। Tracert হলো তাৎক্ষণিক একটি চিত্র, এবং কিছু রাউটার ICMP রিপ্লাই সীমিত করে দেয় বা উপেক্ষা করে। মাঝখানের কোনো ধাপে গতি ধীর হওয়া বা কোনো রেসপন্স না পাওয়ার মানেই এই নয় যে সেখানে ফরওয়ার্ডিং পুরোপুরি বন্ধ হয়ে গেছে। আপনাকে লক্ষ্য করতে হবে পরবর্তী ধাপগুলোর সামগ্রিক প্যাটার্ন কেমন।
কেন pathping এত কার্যকর
Pathping তুলনামূলকভাবে ধীরগতির, তবে সংযোগের ওঠানামার অভিযোগগুলোর ক্ষেত্রে এটি অত্যন্ত কার্যকর। এটি প্রথমে রুট ট্রেস করে এবং তারপর পুরো পথের প্যাকেট লস অনুমান করার জন্য প্রতিটি ধাপে সময়ের ব্যবধানে স্যাম্পল সংগ্রহ করে।
এটি তখন খুবই কাজে দেয় যখন ব্যবহারকারীরা অভিযোগ করেন যে WiFi "মোটামুটি ঠিক আছে" কিন্তু ভয়েস কল আটকে যাচ্ছে, পোর্টাল লোড হতে সময় শেষ হয়ে যাচ্ছে, অথবা ক্লাউড অ্যাপগুলো কয়েক সেকেন্ডের জন্য হ্যাং হয়ে আবার ঠিক হয়ে যাচ্ছে। একটি সাধারণ ping দিয়ে এই ধরণের সমস্যা সবসময় ধরা নাও পড়তে পারে। ক্লায়েন্ট সাইডে, WAN এজে, নাকি আরও উপরের দিকে প্যাকেট লস হচ্ছে, তা Pathping আরও নির্ভুলভাবে দেখাতে পারে।
ভুল জায়গায় সমস্যার দায় চাপানো বন্ধ করতেও এটি সাহায্য করে। আমি অনেক টিমকে দেখেছি কোনো একটি এক্সটার্নাল সার্ভিসে সমস্যা হওয়ার কারণে সরাসরি ISP-কে দায়ী করতে, কিন্তু পরে দেখা গেছে সমস্যাটি ট্রাফিক সাইট থেকে বের হওয়ার আগেই শুরু হয়েছিল।
কোন টুলটি কখন ব্যবহার করবেন
আপনার প্রয়োজনের সাথে সামঞ্জস্যপূর্ণ টুলটি বেছে নিন।
- সংযোগ নিশ্চিত করতে এবং ল্যাটেন্সি ও প্যাকেট লসের প্রাথমিক ধারণা পেতে
pingব্যবহার করুন। - রুট বা পথ কোথায় পরিবর্তিত হচ্ছে বা বিলম্ব কোথায় শুরু হচ্ছে তা শনাক্ত করতে
tracertব্যবহার করুন। - প্যাকেট লস স্থায়ী কিনা এবং তা আনুমানিক কোথায় ঘটছে তা পরিমাপ করতে
pathpingব্যবহার করুন।
একটি মাত্র কমান্ডের বাইরে "ভালো" পারফরম্যান্স বলতে কী বোঝায় সে সম্পর্কে আরও জানতে, Purple-এর measuring WiFi network performance নির্দেশিকাটি একটি দরকারী রেফারেন্স।
একটি ব্যবহারিক এস্কেলেশন প্যাটার্ন
একটি সাধারণ সিকোয়েন্স ভালো কাজ করে:
- একটি লোকাল গেটওয়ে এবং একটি আপস্ট্রিম টার্গেটে
pingদিয়ে শুরু করুন। - লোকাল ফলাফল ঠিক থাকলে কিন্তু দূরবর্তী অভিজ্ঞতা খারাপ হলে
tracertচালান। - রুটটি স্বাভাবিক মনে হলেও ব্যবহারকারীরা মাঝে মাঝে বিঘ্নিত হওয়ার কথা জানালে
pathpingচালান। - আপনি যদি MTU বা ফ্র্যাগমেন্টেশন সন্দেহ করেন তবে প্যাকেটের আকার আলাদাভাবে পরীক্ষা করুন।
Tracertএবংpathpingনিজে থেকে এই সমস্যার সমাধান করবে না।
মূল সতর্কতা প্রতিটি এন্টারপ্রাইজ নেটওয়ার্কে একই থাকে। ডিজাইন অনুসারেই ICMP ভিজিবিলিটি অসম্পূর্ণ থাকে। কিছু হপ নীরব থাকবে, কিছু ধীরে উত্তর দেবে এবং কিছু ক্লাউড পাথ বাস্তবের চেয়ে আরও অদ্ভুত দেখাবে। এই টুলগুলিকে রায় হিসেবে না দেখে সূচক হিসেবে বিবেচনা করুন। জটিল WiFi এস্টেটে, বিশেষ করে যেগুলিতে আইডেন্টিটি, পলিসি এবং গেস্ট ওয়ার্কফ্লো লেয়ার রয়েছে, সেগুলি ত্রুটির ক্ষেত্রটিকে সংকুচিত করতে সাহায্য করে যাতে পরবর্তী পরীক্ষাটি আগেরটির চেয়ে আরও নিখুঁত হয়।
Ping দিয়ে জটিল WiFi সমস্যা নির্ণয় করা
একজন ব্যবহারকারী লবি দিয়ে হেঁটে যাচ্ছেন, তার ফোন ফুল WiFi সিগন্যাল দেখাচ্ছে, তবুও গেস্ট সাইন-অন বা সিকিউর রোমিং-এর মাঝামাঝি সময়ে সেশনটি বন্ধ হয়ে যাচ্ছে। এই ধরণের ত্রুটিগুলিই ping দ্রুত সনাক্ত করতে সাহায্য করে। একটি Purple দ্বারা পরিচালিত পরিবেশে, প্রশ্নটি খুব কমই কেবল "এই ডিভাইসটি কি ইন্টারনেট অ্যাক্সেস করতে পারছে?" হয়। আরও ভালো প্রশ্ন হলো "ব্যবহারকারীর যাত্রাপথের কোন ডিপেন্ডেন্সিটি ভেঙে যাচ্ছে এবং ঠিক কোন পয়েন্টে?"
রোমিং এবং মাঝে মাঝে ড্রপআউট
রোমিং সংক্রান্ত অভিযোগের জন্য, আমি একটি লোকাল, স্থিতিশীল টার্গেটে একটি অবিচ্ছিন্ন পিং দিয়ে শুরু করি। ডিফল্ট গেটওয়েতে ping -t চালানো সাধারণত প্রথম পরীক্ষা হিসেবে সবচেয়ে স্পষ্ট হয় কারণ এটি ইন্টারনেটের পথের গোলমালের চেয়ে WLAN ধারাবাহিকতার ওপর বেশি ফোকাস রাখে।
ব্যবহারকারী সমস্যাযুক্ত এলাকার মধ্য দিয়ে যাওয়ার সময় পরীক্ষাটি চালান। টাইমআউট, লেটেন্সি স্পাইক বা সাময়িক বিরতির পর আবার স্বাভাবিক হচ্ছে কিনা তা লক্ষ্য করুন। রোমিংয়ের সময় একটি ছোট বাধা কিছু হ্যান্ডসেট এবং AP কম্বিনেশনে গ্রহণযোগ্য হতে পারে। একই দরজা, সিঁড়ি বা কভারেজ প্রান্তে বারবার সংযোগ বিচ্ছিন্ন হওয়া সাধারণত RF ডিজাইন, স্টিকি ক্লায়েন্ট আচরণ বা AP হ্যান্ডঅফ টাইমিংকে নির্দেশ করে।
টার্গেট নির্বাচন করা গুরুত্বপূর্ণ। একটি গেটওয়ে পরীক্ষা করে যে ক্লায়েন্টটি লোকাল নেটওয়ার্কের সাথে যুক্ত আছে কিনা। একটি রিমোট হোস্ট WAN ভ্যারিয়েশন, DNS পলিসি এবং আপস্ট্রিম কনজেশন মিশ্রিত করে, যা আসল সমস্যাটিকে লুকিয়ে রাখতে পারে।
Captive Portal এবং গেস্ট জার্নি চেক
গেস্ট WiFi আরেকটি লেয়ার যোগ করে। একটি ডিভাইস SSID-এর সাথে যুক্ত হতে পারে এবং তবুও প্রকৃত ব্যবহারকারীর যাত্রাপথে ব্যর্থ হতে পারে।
পলিসি থেকে ট্রান্সপোর্টকে আলাদা করতে ping ব্যবহার করুন। ক্লায়েন্ট যদি গেটওয়েতে পৌঁছাতে পারে কিন্তু কোনও এক্সটার্নাল IP-তে না পারে, তবে সমস্যাটি ফায়ারওয়াল রুলস, আপস্ট্রিম রাউটিং বা ওয়াল্ড-গার্ডেন পলিসিতে থাকতে পারে। যদি উভয়ই সাড়া দেয় কিন্তু গেস্ট এখনও অ্যাক্সেস সম্পূর্ণ করতে না পারে, তবে অনবোর্ডিং ফ্লোর ভিতরে পোর্টাল লজিক, DNS ইন্টারসেপশন, সেশন স্টেট বা টাইমআউট হ্যান্ডলিংয়ের দিকে নজর দিন।
এখানেই ভালো নিয়মানুবর্তিতা গুরুত্বপূর্ণ। Ping পোর্টালটি নিজে যাচাই করে না। এটি আপনাকে কেবল জানায় যে তার নিচের পথটি ঠিকঠাক কাজ করছে কিনা।
Passpoint, OpenRoaming, এবং আইডেন্টিটি-ব্যাকড অ্যাক্সেস
আইডেন্টিটি-ভিত্তিক WiFi ট্রাবলশুটিং মডেলকে পরিবর্তন করে। Passpoint বা OpenRoaming -এর ক্ষেত্রে, কোনও ব্রাউজার প্রম্পট আসার আগেই ব্যবহারকারীরা ব্যর্থ হতে পারে, তাই "ইন্টারনেট চালু আছে" এটি পরীক্ষা করা নিজেই কোনো কার্যকর পরীক্ষা নয়।
সেশনটি যে ইনফ্রাস্ট্রাকচারের উপর নির্ভর করে তাকে ping করুন। এর অর্থ প্রায়শই লোকাল কন্ট্রোলার বা গেটওয়ে, তারপর ICMP অনুমোদিত হলে অথেন্টিকেশন পাথ। ping -l 1472 এর মতো একটি বড় প্যাকেট পরীক্ষা ক্লায়েন্ট সেগমেন্ট এবং কন্ট্রোলার বা আপস্ট্রিম সার্ভিসের মধ্যে MTU বা ফ্র্যাগমেন্টেশন সমস্যাগুলি প্রকাশ করতে সাহায্য করতে পারে, বিশেষ করে যখন স্ট্যান্ডার্ড-সাইজের ping ঠিকঠাক দেখায় কিন্তু অনবোর্ডিং বা রি-অথেন্টিকেশন এখনও আটকে থাকে।
RADIUS-এর বিশেষ মনোযোগ প্রয়োজন। ব্যবহারকারীরা যদি ধীরগতির জয়েনিং, বারবার ক্রেডেন্সিয়াল প্রম্পট বা অসামঞ্জস্যপূর্ণ সিকিউর অনবোর্ডিংয়ের রিপোর্ট করে, তবে যেখানে সম্ভব অথেন্টিকেশন নেটওয়ার্ক সেগমেন্টের রিচিবিলিটি এবং স্ট্যাবিলিটি পরীক্ষা করুন। সেই পাথে উচ্চ লেটেন্সি বা মাঝে মাঝে ড্রপ হওয়া, কেউ ড্যাশবোর্ড খোলার অনেক আগেই লগইন অভিজ্ঞতাকে ব্যাহত করতে পারে।
ব্যবহারকারী আসলে যে পথটি ব্যবহার করেন তা পরিমাপ করুন
এন্টারপ্রাইজ WiFi-তে, টার্গেটগুলো সেশন ফ্লোর সাথে মিললে ping সবচেয়ে ভালো কাজ করে।
- WLAN কন্টিনিউইটির জন্য লোকাল গেটওয়ে
- ইনফ্রাস্ট্রাকচার হেলথ-এর জন্য কন্ট্রোলার বা লোকাল সার্ভিস এজ
- আইডেন্টিটি-ভিত্তিক অ্যাক্সেসের জন্য অথেন্টিকেশন ডিপেনডেন্সি
- সাধারণ আপস্ট্রিম রিচিবিলিটির জন্য এক্সটার্নাল হোস্ট
এই সিকোয়েন্সটি অপারেশনালভাবে দরকারী কারণ গেস্ট অ্যাক্সেস, পলিসি এনফোর্সমেন্ট এবং সেগমেন্টেড ট্রাফিক থাকা ভেন্যুগুলোতে ব্যবহারকারীরা কীভাবে অনলাইন হয় তার সাথে এটি মিলে যায়। যে দলগুলোর আরও ব্যাপক সার্ভিস এবং RF কন্টেক্সট প্রয়োজন, তাদের কমান্ড-লাইন চেকের সাথে WiFi নেটওয়ার্ক পারফরম্যান্স পরিমাপের গাইড ব্যবহার করা উচিত।
একটি শেষ সতর্কতা। ICMP একটি ট্রাবলশুটিং টুল, পুরো সার্ভিসটি সুস্থ থাকার প্রমাণ নয়। একটি ক্লিন ping পোর্টাল রেন্ডারিং, পলিসি অ্যাসাইনমেন্ট, সার্টিফিকেট ট্রাস্ট বা অ্যাপ্লিকেশন রিচিবিলিটি নিশ্চিত করে না। এটি আপনাকে ফল্ট ডোমেনটি দ্রুত সংকুচিত করার একটি উপায় দেয়, যা জটিল WiFi এবং নেটওয়ার্ক সিকিউরিটি পরিবেশে আপনার ঠিক প্রয়োজন যেখানে একাধিক সিস্টেম একই সময়ে বিভিন্ন উপায়ে ব্যর্থ হতে পারে।
Purple অ্যাডমিনদের জন্য একটি বাস্তবসম্মত ট্রাবলশুটিং ওয়ার্কফ্লো
সবচেয়ে ভালো ওয়ার্কফ্লো হলো সেটি যা আপনার টিম চাপের মুখেও বারবার সঠিকভাবে সম্পন্ন করতে পারে। আমার পদ্ধতিটি সহজ। ডিভাইস থেকে শুরু করুন, তারপর একটি নির্দিষ্ট ক্রমানুসারে বাইরের দিকে যান। ড্যাশবোর্ড দেখে বিশ্বাসযোগ্য মনে হলেও কোনো ধাপ বাদ দিয়ে এগিয়ে যাবেন না।
আউটওয়ার্ড-ইন পদ্ধতি
প্রথমে এন্ডপয়েন্টটি যাচাই করুন নিশ্চিত করুন যে ডিভাইসটি সংযুক্ত রয়েছে এবং প্রত্যাশিত নেটওয়ার্ক অবস্থায় আছে। WiFi আইকন দেখাচ্ছে মানেই একটি ব্যবহারযোগ্য সেশন সচল আছে, এমনটা ধরে নেবেন না।
লুপব্যাক অ্যাড্রেস পিং (Ping) করুন
এটি লোকাল TCP/IP স্ট্যাক পরীক্ষা করে। যদি এটি ব্যর্থ হয়, তবে এটি কোনো নেটওয়ার্ক সমস্যা নয়। এটি আপনার হোস্টেরই সমস্যা।ডিফল্ট গেটওয়ে পিং করুন
এটি লোকাল ক্লায়েন্ট ও WLAN-এর সমস্যাগুলোকে আপস্ট্রিম সমস্যা থেকে দ্রুত আলাদা করে।পরবর্তী গুরুত্বপূর্ণ ডিপেন্ডেন্সি পিং করুন
এটি একটি কন্ট্রোলার, কোনো অথেন্টিকেশন টার্গেট বা অন্য কোনো ইন্টারনাল সার্ভিস হতে পারে। লক্ষণের সাথে মিলিয়ে টার্গেট নির্ধারণ করুন।একটি এক্সটারনাল হোস্ট পিং করুন
এর মাধ্যমে নিশ্চিত হওয়া যায় যে সমস্যাটি ভেন্যুর সীমানার বাইরে চলে গেছে কিনা।প্রয়োজন হলে
tracertবাpathpingব্যবহার করুন
কোন সেগমেন্টটি খতিয়ে দেখা দরকার তা নিশ্চিত হওয়ার পরেই কেবল এগুলো ব্যবহার করুন।ড্যাশবোর্ড এবং পলিসি সিস্টেমগুলো সবশেষে পরীক্ষা করুন, সাথে একটি ধারণা তৈরি রাখুন
এখন আপনার লগগুলোর গুরুত্ব আরও বেশি, কারণ আপনার কমান্ড-লাইন টেস্টগুলো ইতিমধ্যেই সমস্যার ক্ষেত্রটিকে সংকুচিত করে এনেছে।
কোনটি কাজ করে এবং কোনটি করে না
যা কাজ করে তা হলো ধারাবাহিকতা। টিমের প্রতিটি ইঞ্জিনিয়ারের একই ক্রম অনুসরণ করা উচিত, একই আউটপুট রেকর্ড করা উচিত এবং কোনো কিছু পরিবর্তন করার আগে লোকাল বনাম আপস্ট্রিমের আচরণ তুলনা করা উচিত।
যা কাজ করে না তা হলো সঠিক পথ বিশ্লেষণ না করেই সরাসরি রিসেট করা, ফায়ারওয়ালকে দোষ দেওয়া বা ভেন্ডর টিকিট ওপেন করা। এতে সময় নষ্ট হয় এবং প্রায়শই আপনার প্রয়োজনীয় প্রমাণগুলো নষ্ট হয়ে যায়।
এই শৃঙ্খলার অনেক কিছুই বৃহত্তর নেটওয়ার্ক সিকিউরিটি চিন্তাভাবনার সাথে মিলে যায়। আইডেন্টিটি, সেগমেন্টেশন, ফিল্টারিং এবং পলিসি - এই সব কিছুই ICMP অনুমোদিত, অগ্রাধিকারপ্রাপ্ত বা প্রতিনিধিত্বশীল হবে কিনা তা প্রভাবিত করতে পারে। ভালো ট্রাবলশুটিং একে সম্মান করে, কিন্তু এর কারণে থমকে যায় না।
প্রতিটি ব্যর্থ পিংকে একটি নিয়ন্ত্রিত সিকোয়েন্সের অংশ হিসেবে একটি ডেটাপয়েন্ট হিসেবে বিবেচনা করুন, সম্পূর্ণ নেটওয়ার্কের চূড়ান্ত রায় হিসেবে নয়।
OS পরিবর্তনের পর যদি আপনি এন্ডপয়েন্ট-সাইডের কোনো অদ্ভুত সমস্যার সম্মুখীন হন, তবে উইন্ডোজ আপগ্রেডের পর ইন্টারনেট কানেক্টিভিটি সংক্রান্ত সমস্যা সমাধানের জন্য এই troubleshooting Windows 11 internet connectivity issues after upgrade গাইডটি একটি ব্যবহারিক রেফারেন্স হতে পারে। আশ্চর্যজনকভাবে অনেক "নেটওয়ার্ক ইনসিডেন্ট" শুরু হয় মূলত ক্লায়েন্ট স্ট্যাক পরিবর্তনের কারণে, যা ব্যবহারকারীর অজান্তেই ঘটে থাকে।
মূল বিষয়টি ping-কে পূজা করা নয়। মূল বিষয়টি হল এটিকে এমনভাবে ব্যবহার করা যাতে দ্রুত স্পষ্টতা পাওয়া যায়। এটি এখনও একজন নেটওয়ার্ক অ্যাডমিন গড়ে তুলতে পারেন এমন অন্যতম সেরা অভ্যাসগুলির একটি।
আপনি যদি গেস্ট, স্টাফ বা মাল্টি-টেন্যান্ট WiFi পরিচালনা করেন এবং অথেন্টিকেশনে কম জটিলতা, আইডি-ভিত্তিক অ্যাক্সেসে আরও ভালো দৃশ্যমানতা এবং শেয়ারড পাসওয়ার্ড ও দুর্বল Captive Portal-এর চেয়ে আরও পরিচ্ছন্ন অপারেশনাল মডেল চান, তাহলে Purple দেখতে পারেন।
