অসুবিধা
প্যাকেট ক্ষতির উৎস নির্ধারণ এবং কেন এটি ঘটছে তা সর্বদা সহজ নয়। প্যাকেটগুলি ইন্টারনেটের মাধ্যমে বিভিন্ন আইএসপি এবং সংস্থার মালিকানাধীন একাধিক নেটওয়ার্কের মধ্য দিয়ে যায়, এবং আপনি লিঙ্ক স্টেট এবং সিপিইউ লোডের মতো বিষয়গুলি পরীক্ষা করার জন্য পথের প্রতিটি রাউটার অ্যাক্সেস পাবেন না। অতিরিক্তভাবে, প্যাকেট ক্ষতি নেটওয়ার্ক পথে যেকোনো পয়েন্টে ঘটতে পারে।
গ্রাহকের নতুন সেটআপ জন্য ব্যবহারকারী সচেতনতা এবং ডিসি সিঙ্ক ত্রুটির প্রাপ্তি।
এরকম অনেক কারণ রয়েছে যার জন্য প্যাকেটগুলি পথে নিক্ষিপ্ত হতে পারে। কয়েকটি সাধারণ কারণ হল:
আইএসপি পেয়ারিং সমস্যা
লেন্ক যানজট
ভুল কনফিগারেশন (ব্যান্ডউইডথ সেটিংস বা এনআইসি গতি এবং ডুপ্লেক্স)
হার্ডওয়্যার ব্যর্থতা
নেটওয়ার্ক ডিভাইসে উচ্চ সিপিইউ
মাইক্রো-বার্স্ট হ্যান্ডলিং
কাটোতে প্যাকেট ক্ষতি বোঝা
Cato-তে প্যাকেট লস চিহ্নিত করার একটি ভাল উপায় হল কাটো ম্যানেজমেন্ট অ্যাপ্লিকেশনে অ্যানালিটিক্স স্ক্রিন ব্যবহার করুন। প্যাকেট ক্ষতি এবং বাতিল গ্রাফগুলি সময়ের সাথে প্যাকেট ক্ষতি দেখায় এবং আপনাকে নির্দিষ্ট সময় ফ্রেমগুলির উপর ফোকাস করতে দেয়। এই গ্রাফগুলি চিহ্নিত করতে সহায়ক যে প্যাকেট ক্ষতি ঘটছে এবং এটি পূর্বে কখন ঘটেছিল।
দ্রষ্টব্য:
বিশ্লেষণ গ্রাফগুলিতে সবচেয়ে ক্ষুদ্র ডেটা বাকেট নমুনার আকার 5 সেকেন্ড। ফলস্বরূপ, একটি মাইক্রো-বার্স্ট 5 মিলিসেকেন্ডের মধ্যে গড়ার মধ্যে স্বাভাবিক অবস্থায় ফিরে আসে এবং বিশ্লেষণ গ্রাফে শিখর হিসেবে দেখানো হয় না।
1. প্রদানকারী ক্ষতি
Socket এবং PoP এর মধ্যে ঘটে। যদিও বেশিরভাগ প্রদানকারী প্যাকেট ক্ষতি কাটো-এর নিয়ন্ত্রণের বাইরে শেষ মাইল নেটওয়ার্ক কানেক্টিভিটি সমস্যার কারণে ঘটে, এটি অবশ্যই কাটো সম্পর্কিত কোন সমস্যা বাদ দেয় না।
কাটো কীভাবে প্রদানকারী ক্ষতি মেপে থাকে
প্রোভাইডার লস Socket এবং PoP এর উপর একটি নির্দিষ্ট লিঙ্কে প্রেরিত এবং গ্রহণিত প্যাকেটের সংখ্যার তুলনা করে মাপা হয়।
ডাউনস্ট্রিম প্যাকেট লস হল PoP দ্বারা প্রেরিত প্যাকেটের সংখ্যা এবং Socket দ্বারা গ্রহণ করা প্যাকেটের সংখ্যার মধ্যে পার্থক্য, যা শতাংশ হিসাবে প্রকাশ করা হয়।
ফর্মুলা:
আপস্ট্রিম প্যাকেট লস হল Socket দ্বারা প্রেরিত প্যাকেটের সংখ্যা এবং PoP দ্বারা গ্রহণ করা প্যাকেটের সংখ্যার মধ্যে পার্থক্য, যা শতাংশ হিসাবে প্রকাশ করা হয়।
ফর্মুলা:
Cato প্রোভাইডার প্যাকেট লস গণনা করার উপায় মানে হল যতটা সহজেই সম্ভব, আপনি আরম্ভতেই ISP এর উপর সব দোষ চাপাতে পারেন না। এটা সম্ভব যে আপনার সকেট এবং আইএসপি রাউটারের মধ্যবর্তী সরঞ্জাম প্যাকেট ক্ষতিতে সহায়তা করে, অথবা আইএসপির নিয়ন্ত্রণের বাইরে PoP-এর কাছে নেটওয়ার্কের পথে সমস্যা থাকতে পারে।
2. Cato বর্জিত
যখন ঘটে, তখন Cato QoS ইচ্ছাকৃতভাবে প্যাকেটগুলি বাদ দেয়। যখন QoS ইঞ্জিন নিম্ন-অগ্রাধিকার প্যাকেটগুলি বাতিল করা শুরু করে:
যানজট ঘটে যখন একটি লিঙ্কের উপরে মোট থ্রুপুট লিঙ্কের জন্য কনফিগার করা ব্যান্ডউইথের সাথে মেলে।
Cato প্যাকেটগুলি বাতিল করে যদি একটি BW ব্যবস্থাপনা অগ্রাধিকার একটি কঠিন থ্রুপুট সীমা দিয়ে কনফিগার করা হয় এবং অগ্রাধিকার মেলানো ট্রাফিক সীমায় পৌঁছে যায়।
বিস্ফোরণের সময় (এমনকি উচ্চ-অগ্রাধিকার সারিও প্যাকেট হতে পারে)।
Cato বাতিল প্যাকেট লস আশা করা যায় এবং এটি প্রয়োজনীয়ভাবে কোনো সমস্যার লক্ষণ নয়।
কাটো প্যাকেট লস বাতিল সম্পর্কিত যে কোনো সমস্যা সম্ভবত একটি ভুল কনফিগারেশনের কারণে ঘটে। সংকটাপন্ন অ্যাপ্লিকেশনগুলি, যেমন VoIP, সর্বোচ্চ ব্যান্ডউইথ পরিচালনা অগ্রাধিকার দেওয়া উচিত। যদি ভিড় হয়, Cato নিম্ন-অগ্রাধিকার ট্রাফিক বাদ দেয়, কিন্তু এটি উচ্চ-অগ্রাধিকার ট্রাফিক বাদ দেয় না। সর্বদা নিশ্চিত করুন যে যথাযথ ব্যান্ডউইথ ব্যবস্থাপনা অগ্রাধিকারের সাথে ট্রাফিক বরাদ্দ করা হয়েছে।
বিশ্লেষণ প্যাকেট ক্ষতির ব্যাপক দেখুন প্রদান করে। তবে, যদি আপনি Cato এর বাতিল প্যাকেট লসের পরিস্থিতে নেই, তাহলে শুধুমাত্র অ্যানালিটিক্সের মাধ্যমে জানতে পারবেন না কী কারণে প্যাকেট লস হচ্ছে বা কোথায় প্যাকেট লস ঘটছে।
কিভাবে প্যাকেট ক্ষতি নির্ণয় করা যায়
1. প্যাকেট ক্ষতির পরিসর নির্ধারণ করা
যখন আপনি শুরু করেন, এটা সত্যিই গুরুত্বপূর্ণ যে কে বা কী প্যাকেট লসের সম্মুখীন হচ্ছে তা খুঁজে বের করা।
যে সাইটে প্রতিটি ব্যবহারকারী প্যাকেট লসের সম্মুখীন হচ্ছে, নাকি এটি একটি একক এন্ডপয়েন্টে সীমিত রয়েছে?
প্যাকেট লস ইন্টারনেটের উপর নাকি WAN এর উপর ঘটে?
বহু সাইট প্যাকেট লস দ্বারা প্রভাবিত হচ্ছে, নাকি শুধু একটি?
সমস্ত ট্রাফিক প্রভাবিত হচ্ছে, নাকি শুধু একটি নির্দিষ্ট অ্যাপ্লিকেশন?
প্যাকেট লস কি স্থায়ী, নাকি এটা শুধু মাঝে মাঝে ঘটে?
উপরোল্লেখিত প্রশ্নগুলির উত্তর জানা আপনাকে সম্পর্কিত CMA ইভেন্টগুলি চিহ্নিত করতে সহায়তা করে এবং সমস্যার সমাধান করার প্রক্রিয়ায় আপনার সময় বাঁচায়। আপনার যত বেশি তথ্য জানা থাকবে, তত ভালো সমাধান দেওয়া আপনার পক্ষে সম্ভব হবে।
2. সাইট বিশ্লেষণ পরীক্ষা করা - প্যাকেট ক্ষতি গ্রাফ
সাইটের বিশ্লেষণ প্যাকেট ক্ষতি গ্রাফে প্যাকেট ক্ষতি দেখাচ্ছে? প্যাকেট ক্ষতি এবং বাতিল করা প্যাকেটগুলি দেখাতে পারে এমন বিশ্লেষণ গ্রাফের উপর ভিত্তি করে আমাদের বিভিন্ন সুপারিশ রয়েছে।
প্যাকেট ক্ষতি নেই
বিশ্লেষণ স্ক্রীনে কোন প্যাকেট ক্ষতি প্রদর্শিত ছাড়াই প্যাকেট ক্ষতি বিদ্যমান থাকতে পারে। স্থানীয় নেটওয়ার্কে একটি সমস্যা থাকতে পারে, অথবা এটি একটি PoP সম্পর্কিত সমস্যা হতে পারে। সকেট থেকে একটি ল্যান পাশে আইপি পিং করার জন্য ইউআই নেটওয়ার্ক টুল ব্যবহার করা একটি ভাল উপায় হতে পারে মূল কারণ সনাক্ত করার জন্য।
প্যাকেট ক্ষতি
যদি গ্রাফে প্যাকেট লস প্রদর্শিত হয়, তবে এটি একটি ভুল বিডাব্লিউ কনফিগারেশনের কারণে হতে পারে। নীচে কিভাবে ব্যান্ডউইথ কনফিগার করা হয় তা দেখে নিন ব্যান্ডউইথ কনফিগারেশন যাচাই।
প্রদানকারী প্যাকেট ক্ষতির জন্য, নিশ্চিত করুন যে ড্রপগুলি কেবল তখনই উপস্থিত হয় যখন ট্রাফিকের স্পাইক (বিস্ফোরণ) ঘটে। যদি তা হয়, তাহলে অ্যাপ্লিকেশন বিশ্লেষণ পৃষ্ঠা ব্যবহার করে বিস্ফোরণ সৃষ্টি করা ট্রাফিক চিহ্নিত করুন। আপনি অ্যাপ্লিকেশন ট্রাফিক একটি সীমিত বিডাব্লিউ ব্যবস্থাপনা প্রোফাইল এ অর্পণ করে সীমাবদ্ধ করতে পারেন।
প্রায়ই, আমরা এমন কিছু ঘটনা দেখতে পাব যেখানে থ্রুপুট সাধারণত কম থাকে, কিন্তু বিস্ফোরণ স্পাইকগুলি প্যাকেট ক্ষতির কারণ হয়। আমাদের বিবেচনায় রাখতে হবে যে আইএসপির নিজস্ব ট্রাফিক আকারের নীতি রয়েছে, এবং সেই ক্ষেত্রে, সম্ভবত আইএসপি নীতি এবং ক্যাটো ট্রাফিক আকারের নীতির ভিন্ন উন্নয়ন নীতি রয়েছে। বিস্ফোরণের বিষয়ে আরও তথ্যের জন্য, নীচে দেখুন মাইক্রো-বিস্ফোরণ যাচাই করুন
3. সাইট এনালিটিক্স যাচাই করুন - বাতিল প্যাকেটস গ্রাফ
কাটো বাতিল প্যাকেটগুলির জন্য, ব্যান্ডউইথ অগ্রাধিকারগুলিও পরীক্ষা করুন। অগ্রাধিকার বিশ্লেষক দেখুন সাইটের বিশ্লেষণ স্ক্রিনের নিচে কোন অগ্রাধিকার বাদ দেওয়া হয়েছে তা জানতে। আপনি অগ্রাধিকার সেকশন বিস্তৃত করে সেই অগ্রাধিকারের শীর্ষ অ্যাপ্লিকেশনগুলি দেখতে পারেন। যদি একটি নির্দিষ্ট অ্যাপ্লিকেশন প্যাকেট ক্ষতির প্রভাবে হয়, তাহলে নেটওয়ার্ক নিয়মের মধ্যে সেই অ্যাপ্লিকেশনের অগ্রাধিকার বৃদ্ধি করতে হতে পারে। মনে রাখবেন, Cato QoS ডিজাইন করা হয়েছে কম অগ্রাধিকার প্যাকেট বাদ দেওয়া যায় যখন যানজট হয়, তাই কাটো বাতিল প্যাকেট লস সর্বদা সমস্যা নয়।
ক্যাটো QoS যে কোনো প্যাকেট, অগ্রাধিকার নির্বিশেষে বাতিল করতে পারে, সেই কিউতে বিস্ফোরণ থাকার কারণে। বিস্ফোরণ ব্যবস্থাপনার প্রকৃতির কারণে এই আচরণেরও আশা করা হয়। অগ্রাধিকার বিশ্লেষক পেজটি কাজ দ্বারা নির্ধারণ করতে পারে কি ট্রাফিক বিস্ফোরণগুলি প্যাকেট বাতিল হওয়ার সময় ঘটে। আরও তথ্যের জন্য, দেখুন সকেট ট্রাফিক অগ্রাধিকার এবং QoS।
বিশ্লেষণ স্ক্রিনের অগ্রাধিকার বিশ্লেষক প্রতিটি QoS অগ্রাধিকার জন্য উপারি ও অধোগামী দিকের প্যাকেট ক্ষতি প্রদর্শন করে।
4. সাইট বিশ্লেষণ যাচাই করা হচ্ছে - শেষ মাইল প্যাকেট ক্ষতি
ISP সমস্যা সম্মুখীন হচ্ছে কিনা মূল্যায়ন করতে, শেষ মাইল ট্যাব ব্যবহার করুন শেষ মাইল মনিটরিং স্ক্রীনে WAN লিঙ্কের বিলম্ব পরিবর্তন বা প্যাকেট লসের জন্য পরীক্ষা করুন। প্রদানকারী প্যাকেট ক্ষতির সাথে অমিল রেখে, শেষ মাইল তথ্য পপুলার ওয়েবসাইটের ICMP পরীক্ষার উপর ভিত্তি করে। একটি পরামর্শ হিসেবে, পিং করা যায় এমন অতিরিক্ত সার্ভিস IPগুলি শেষ মাইল মনিটরিং পাতায় যোগ করা যেতে পারে। উদাহরণস্বরূপ, যদি VoIP সম্পর্কিত সমস্যা থাকে, তাহলে SIP সার্ভার IP একটিভ IP হিসেবে সেট করা যেতে পারে।
যদি আপনি সন্দেহ করেন যে আইএসপি সংক্রান্ত প্যাকেট হারানো হচ্ছে, আপনার আইএসপিকে নিম্নলিখিত প্রশ্নগুলি জিজ্ঞাসা করুন:
আপনি কি UDP/443 বা UDP/1337 (DTLS) ট্রাফিকে QoS প্রয়োগ করছেন?
আপনি কি UDP ট্রাফিকে কোনো DoS সুরক্ষা প্রয়োগ করছেন যা PoP IP-তে প্যাকেট ক্ষতি করতে পারে?
আপনার রাউটার(গুলি) এর পথে PoP IP এর দিকে যানজট বা উচ্চ CPU আছে কি?
আপনি কি সাবস্ক্রাইব করা লাইন রেটের উপরে বুর্স্টিং অনুমতি দিচ্ছেন?
5. (ঐচ্ছিক) শেষ মাইল অভিজ্ঞতা পর্যবেক্ষণ
অভিজ্ঞতা পর্যবেক্ষণ লাইসেন্স সহ গ্রাহকরা শেষ মাইল এবং অ্যাপ্লিকেশন পারফরমেন্স ট্যাবগুলি প্যাকেট হ্রাস এবং প্যাকেট বাতিলের সম্ভাবনার জন্য পরীক্ষা করতে পারেন। সমস্যার সূচনা স্থান ভালোভাবে বোঝার জন্য সাইটের নেটওয়ার্ক বিশ্লেষণ পাতায় পাওয়া ফলাফলগুলোর সাথে ডেটার মিল করা যেতে পারে।
6. DTLS পোর্ট UDP/443 পরিবর্তন করুন
কিছু ISP সম্ভবত UDP/443-এ ট্র্যাফিক শেপিং অথবা QoS প্রয়োগ করতে পারে। এটি এমনকি যখন লিংক অন্যথায় স্থিতিশীল থাকে তখনও প্যাকেট লস আনতে পারে।
Socket কনফিগারেশনে, DTLS টানেল পোর্ট পরিবর্তন করুন 443 থেকে 1337।
পরিবর্তন প্রয়োগের পরে, অ্যানালিটিক্স স্ক্রিনে প্যাকেট লস এবং লেটেন্সি নিরীক্ষণ করুন।
যদি প্যাকেট লস উন্নত হয়, এটি নিশ্চিত করে যে ISP UDP/443 ট্র্যাফিককে শেপ করছে। সে ক্ষেত্রে, টানেলটি 1337 এ রাখুন অথবা ISP এর সাথে বিষয়টি উথাপন করুন।
7. ব্যান্ডউইথ কনফিগারেশন পরীক্ষা করা হচ্ছে
লিঙ্ক যানজট দ্বারা প্যাকেট লস হতে পারে, এবং এটি গুরুত্বপূর্ণ যে প্রতিটি WAN লিঙ্কের জন্য Cato ম্যানেজমেন্ট অ্যাপ্লিকেশনে সঠিকভাবে ব্যান্ডউইথ কনফিগার করা হয়েছে। সাইট কনফিগারেশনে কনফিগার করা ব্যান্ডউইথ আইএসপি দ্বারা প্রদত্ত ব্যান্ডউইথের সাথে মিলিয়ে নিশ্চিত করুন। Cato সাইট লাইসেন্সের শর্ত অনুযায়ী সকেট ওয়ান ইন্টারফেসের ব্যান্ডউইথ সেটিং কনফিগার করুন।
Azure/AWS পরিবেশগুলোর কোনো ঐতিহ্যগত ব্যান্ডউইথ সীমাবদ্ধতা নেই। পরিবর্তে, কনফিগার করা সাইটের ব্যান্ডউইথ কখনও vSocket এর জন্য সমর্থিত ব্যান্ডউইথের বেশি হওয়া উচিত নয়। Azure এর সংস্করণ ২১ থেকে, Standard_D8ls_v5 VM আকার ২Gbps পর্যন্ত সমর্থন করে। AWS এ, c5n.xlarge ইন্সটেন্স সাইজ ২Gbps এর বেশি ব্যান্ডউইথ প্রদান করে। শ্রেষ্ঠ পারফরম্যান্স নিশ্চিত করার জন্য সাইটের কনফিগার করা ব্যান্ডউইথ সমর্থিত সীমার মধ্যে থাকতে হবে।
যদি কনফিগার করা ব্যান্ডউইথ আইএসপি যা প্রদান করে তার কম হয়, তবে Cato-এর QoS ইঞ্জিন কনফিগার করা ব্যান্ডউইথ সীমা অতিক্রম হলে প্যাকেটস ড্রপ করা শুরু করতে পারে। যদি এটি ঘটে, তবে একটি সাইটের বিশ্লেষণ থ্রুপুট গ্রাফে একটি সমতল রেখা লক্ষ্যনীয় হয় যা সাইটের কনফিগার করা ব্যান্ডউইথের সমান হয় এবং Cato বাতিল প্যাকেটস সহ।
যদি ব্যান্ডউইথ সঠিকভাবে কনফিগার করা থাকে তবেও, ISP সংযোগ যানজটপূর্ণ হলে একই আচরণটি হতে পারে। যদিও এই আচরণ সমস্যার নিশ্চয়তা দেয় না, এটি একটি ভাল অনুশীলন যে এই পরিস্থিতিতে ব্যান্ডউইডথ সঠিকভাবে কনফিগার করা হয়েছে তা নিশ্চিত করার।.
যদি কনফিগার করা ব্যান্ডউইডথ আইএসপি প্রদানকারীর থেকে বেশি হয়, তাহলে আইএসপি-এর ব্যান্ডউইডথ সীমা অতিক্রম করলে ক্যাটোের QoS ইঞ্জিন কাজ করবে না এবং সুতরাং, আইএসপি র্যান্ডমভাবে প্যাকেট ড্রপ করতে শুরু করতে পারে।. এই ক্ষেত্রে, আপনি সাইট বিশ্লেষণ থ্রুপুট গ্রাফে একটি ফ্ল্যাটলাইন দেখতে পাবেন যা কনফিগার করা ব্যান্ডউইডথ স্তরের নীচে এবং প্রদানকারীর প্যাকেট ক্ষতি সহ।.
প্রতিটি সকেট মডেলের জন্য সকেট থ্রুপুট এবং ক্ষমতা তথ্য সকেট ডেটাশিটে উপলব্ধ, এই তথ্যটি দেখুন: X1700, X1600 & X1500 সকেট গাইডস।
8. সকেট সিপিইউ পারফরম্যান্স চেক করুন
CMA-তে নেটওয়ার্ক বিশ্লেষণ থেকে, হার্ডওয়্যার ট্যাব নির্বাচন করুন। এই সেকশনটি প্রতিটি কোরের ঐতিহাসিক সিপিইউ ব্যবহার শতাংশ প্রদর্শন করে।
সতত, 90% এর উপরে ধারাবাহিক CPU ব্যবহার সকেট পারফরম্যান্সে নেতিবাচক প্রভাব ফেলতে পারে এবং প্যাকেট ক্ষতি এবং বেশি বিলম্ব সৃষ্টি করতে পারে। যদি ক্রমাগত উচ্চ CPU ব্যবহার পর্যবেক্ষণ করা হয়, সম্ভাব্য হার্ডওয়্যার প্রতিস্থাপনের জন্য আপনার অ্যাকাউন্ট প্রতিনিধির সাথে যোগাযোগ করুন (যেমন, X1500 থেকে X1600 পর্যন্ত)।
অতিরিক্ত ত্রুটিমুক্ত করার জন্য, সাপোর্টের সাথে যোগাযোগ করুন।
রিয়েল-টাইম সকেট সিপিইউ ব্যবহার সকেট ওয়েবইউআই এর হার্ডওয়্যার অবস্থা ট্যাব থেকে দেখা যেতে পারে। পারফরম্যান্সের ধারা নির্ধারণ করতে সক্রিয় ব্যবহারকে ঐতিহাসিক তথ্যের সাথে তুলনা করুন।
9. সাইট পুনরায় সংযোগ বাতিল করা
ক্যাটো ক্লাউড সাইট পুনরায় সংযোগগুলি প্যাকেট ক্ষতির একটি উৎস।. গৃহ > ইভেন্ট চেক করুন যদি প্যাকেট ক্ষতি পুনরায় সংযোগ ইভেন্টগুলির সাথে সংযুক্ত হয়ে থাকে।. ইভেন্টগুলিকে সাব-টাইপ = 'পুনরায় সংযুক্ত' হিসেবে ফিল্টার করুন।.
পুনরায় সংযুক্ত ইভেন্টগুলি একটি বার্তা দেখাবে যা বিচ্ছেদের কারণ ব্যাখ্যা করবে।. দেখুন পুনরায় সংযুক্ত ইভেন্টগুলি বুঝুন
10. ক্যাটো বাইপাস করা
ইন্টারনেটে প্যাকেট লসের জন্য, দ্রুত Cato ক্লাউডের সমস্যাগুলি বাদ দিন এবং একটি উৎস বা গন্তব্য বাইপাস সেট আপ করুন। এটি করার সবচেয়ে সহজ উপায় হল সাইট কনফিগারেশনে একটি একক ব্যবহারকারীর আইপি ঠিকানার জন্য একটি উৎস বাইপাস সেট আপ করা এবং পরীক্ষা করা যে প্যাকেট ক্ষতি অব্যাহত থাকে কিনা।. যদি প্যাকেট ক্ষতি অব্যাহত থাকে, তাহলে সমস্যা ল্যান, সকেট বা আইএসপি হতে পারে, তবে সমস্যাটি একটি PoP এর সাথে সম্পর্কিত নেই।.
11. পিং টেস্ট চালানো হচ্ছে
প্যাকেট ক্ষতিগ্রস্ত উৎস এবং গন্তব্য আইপি ঠিকানার মধ্যে একটি নিরবিচ্ছিন্ন পিং শুরু করুন।. পিং-গুলি ট্রেস করা সহজ এবং প্যাকেট ক্যাপচারগুলিতে বিশ্লেষণ করা যায়।. যখন কিছু পিং অনুরোধ তাদের গন্তব্যে পৌঁছায় না, তখন সাধারণত আপনি প্যাকেট ক্ষতির সম্মুখীন হন এবং এটি অনুরোধ টাইম আউট হিসাবে প্রদর্শিত হবে।
নোট: প্যাকেট ক্যাপচারগুলি সিপিইউ বোঝাই এবং কর্মক্ষমতা হ্রাস করতে পারে। দয়া করে নিশ্চিত করুন প্যাকেট ক্যাপচারগুলি অক্ষম করা হয় যদি না সক্রিয়ভাবে সমস্যার সমাধান করা হয়।
সকেট UI আপনাকে হোস্টনেম অথবা IP দ্বারা পিং করার জন্য পিং টুল ব্যবহার করার সুযোগ দেয়। আপনি যে ইন্টারফেসটি পিংয়ের জন্য পাঠাতে চান তা নির্বাচন করতে পারেন, এটি Cato এর মাধ্যমে বা সরাসরি WAN লিঙ্কের মাধ্যমে। পিং ফলাফলে কোনো অমিল আছে কিনা দেখুন, যেমন প্যাকেট ক্ষতি বা উচ্চ বিলম্ব। যদি Cato সহ এবং ছাড়া প্যাকেট ক্ষতি উপস্থিত থাকে, তাহলে এটি একটি ISP সমস্যা নির্দেশ করতে পারে। যদি কোনো লিঙ্ক 4G/LTE হয়, তবে মনে রাখুন যে এই লিঙ্কগুলি প্যাকেট ক্ষতির প্রতি বেশি সংবেদনশীল।
UI শুধুমাত্র 10 পিং অনুরোধ পাঠায়, তাই যদি আপনার আরও পিং প্রয়োজন হয় তবে আপনাকে পিং বাটনটি আবার ক্লিক করতে হবে।
নোট: পিং পরীক্ষাগুলি নেটওয়ার্কের মৌলিক স্বাস্থ্য যাচাই করতে ভালো, কিন্তু কোন পিং ড্রপ না থাকলে তা অপরিহার্যভাবে একটি নির্মল লাইন নির্দেশ করে না।
12. ট্রেসরুট টেস্ট চালানো হচ্ছে
ট্রেসরুট একটি উৎস এবং গন্তব্যের মধ্যে রাউটারগুলিকে (হপ) শনাক্ত করতে ব্যবহৃত হয়। এটি প্রতিটি হপের জন্য প্যাকেট ক্ষতি এবং বিলম্ব দেখাবে।
ট্রেসরাউট টুল দিয়ে সকেট UI থেকে চালানো যেতে পারে। টু হপগু লিংক নেটওয়ার্ক রাউট ট্রেস রান করুন কাছ প্যাকেটের কোন খয় বা অনাকাঙিত উচ্চ বিলম্ব খুঁজতে সকেট এবং গন্তব্য ডোমেইন মধ্যে। পরীক্ষা চালানোর সময় প্যাকেট হারোনো যাচাই করতে সর্বোচ্চ কাউন্ট (২০০) সর্বনিম্ন সময়ান্তর (০.১) সেট করুন।
ট্রেসরাউট ফলাফল বিশ্লেষণ
অবগত থাকুন যে যে কোন একক হপের প্যাকেট ক্ষতি দেখানো হচ্ছে, তা অপরিহার্যভাবে কোন সমস্যার ইঙ্গিত নয়। একটি একক হপ 100% প্যাকেট ক্ষতি দেখাতে পারে কেবলমাত্র এর ICMP রাউটারে সক্রিয় না থাকার কারণে। ICMP হার সীমাবদ্ধতার কারণে কোন সমস্যার উপস্থিতি ছাড়া একটি হপ 100% এর কম প্যাকেট ক্ষতি দেখাতে পারে। যদি আপনি একটি হপে কিছু প্যাকেট ক্ষতি দেখতে পান এবং পরবর্তী হপে 0% প্যাকেট ক্ষতি, তাহলে আপনি সম্ভবত ICMP হার সীমাবদ্ধতা দেখছেন।
যদি প্যাকেট হারানোর সমস্যা সত্যি থাকে, এটি এক হপ থেকে শুরু হবে এবং একাধিক হপের জন্য চলতে থাকবে, প্রতিটি হপ প্যাকেট হারানো দেখাবে। এটিও সম্ভব যে পাথের একাধিক রাউটার প্যাকেট ক্ষতিতে অবদান রাখছে, তাই প্রতি হপে প্যাকেট ক্ষতির পরিমাণ বিভিন্ন হতে পারে। উদাহরণস্বরূপ, রুটে আটটি হপ আছে, এবং ট্রেসরাউট হপ ৩-৭ এর জন্য প্যাকেট হারানো দেখায়।
13. Speedtest দিয়ে লিংক পরীক্ষা করা হচ্ছে
রিয়েল টাইম স্ক্রিনটি বর্তমান থ্রুপুট পরিবর্তনগুলি সনাক্ত করতে সাহায্য করতে পারে এবং অবিলম্বে প্যাকেট ক্ষতি এবং বাতিল প্যাকেটগুলি চিহ্নিত করে। সমস্যা সমাধানের সময়, উচ্চ চাহিদার কারণে প্যাকেট ক্ষতি পুনরায় তৈরি করার জন্য সকেটের স্পিডটেস্ট টুল ব্যবহার করুন।
সকেট Sপিডটেস্ট ফলাফলগুলি Cato দ্বারা প্রদত্ত লিঙ্কের জন্য কনফিগার করা ব্যান্ডউইথের কাছাকাছি হওয়ার প্রত্যাশা করা যায়। তবে, DTLS টানেল ওভারহেড (117 বাইট) সামান্য ডিগ্রির জন্য থ্রুপুট হ্রাস করতে পারে।
পরীক্ষায় লিঙ্ক স্যাচুরেট করা হবে এবং নেটওয়ার্ক বিশ্লেষণ স্ক্রীনে কোনও ISP সম্পর্কিত প্যাকেট ক্ষতি প্রদর্শন করবে। যদি কনফিগার করা লিঙ্কের ব্যান্ডউইথ ISP-দ্বারা প্রদত্ত ব্যান্ডউইথ থেকে কম হয়, পরীক্ষা চালানোর সময় বাতিল প্যাকেটগুলি প্রত্যাশিত।
সরাসরি স্পিডটেস্ট
যখন WAN পোর্টের মাধ্যমে সরাসরি স্পিডটেস্ট চালানো হয়, তখন আপস্ট্রিম ফলাফলটি Cato ম্যানেজমেন্ট অ্যাপ্লিকেশনে কনফিগার করা ব্যান্ডউইথ লাইসেন্সের কাছাকাছি হওয়া উচিত। সকেট এখনও সাইটের ব্যান্ডউইথ লাইসেন্স অনুযায়ী আপস্ট্রিম সরাসরি স্পিডটেস্টের জন্য QoS ব্যবহার করবে। অন্যদিকে, ডাউনস্ট্রিম ফলাফলটি স্থানীয় ISP এর পূর্ণ ক্ষমতা প্রদর্শিত করবে।
14. iPerf দিয়ে লিংক পরীক্ষা করা হচ্ছে
সকেট ওয়েবইউআই আপনাকে iPerf টুল ব্যবহারের অনুমতি দেয় শেষ মাইল পারফরম্যান্স সমস্যাগুলি সমস্যা সমাধানের জন্য সকেট এবং সংযুক্ত PoP এর মধ্যে Cato ক্লাউডে। Socket যা iPerf ক্লায়েন্ট চালাচ্ছে তা সংযুক্ত PoP এ চলমান iPerf সার্ভারের বিপরীতে পরীক্ষা করে।
Cato এর মাধ্যমে এবং সকেট UI এর টুলস পেজ থেকে WAN এর মাধ্যমে সরাসরি iPerf পরীক্ষা চালান। প্রোটোকল হিসাবে UDP বেছে নিন (TCP ফ্লো কন্ট্রোল বাদ দিতে), দিক (আপস্ট্রীম বা ডাউনস্ট্রীম) স্থাপন করুন এবং লক্ষ্য হার কনফিগার করা ব্যান্ডউইথ হিসেবে সেট করুন। এই সরঞ্জামটি ভালোভাবে নিশ্চিত করতে পারে যে Cato এবং WAN এর মাধ্যমে থ্রুপুট প্রত্যাশা অনুযায়ী আছে। DTLS টানেল ওভারহেড (117 বাইট) সামান্য থ্রুপুট হ্রাস করতে পারে।
নিচের উদাহরণে আমরা লক্ষ্য হার 45Mbps (যেটি Cato ম্যানেজমেন্ট অ্যাপ্লিকেশন এ কনফিগার করা ব্যান্ডউইথের সমান) স্থাপন করেছি এবং প্রাপ্ত হার প্রত্যাশার থেকে কম, প্যাকেট হারানো 3.7%।
15. লিঙ্ক একত্রীকরণ (LAG) লিঙ্কগুলি পরীক্ষা করা হচ্ছে
প্যাকেট ক্ষতি এবং উচ্চ বিলম্ব সময় সকেট এবং অভ্যন্তরীণ সুইচের মধ্যে লিঙ্ক একত্রীকরণ (LAG) ভুল কনফিগারেশনের কারণে হতে পারে। এই বিশেষ সমস্যা নেটওয়ার্ক বিশ্লেষণে সনাক্ত করা যায় না, বরং এটি LAN এর মধ্যে সমস্যা সমাধান করতে হয়। Cato শুধুমাত্র স্ট্যাটিক LAG সাপোর্ট করে এবং LAG পিয়ার অবশ্যই একই মোড সাপোর্ট করতে হবে। LAG কনফিগারেশনের মিল না হলে প্যাকেট ক্ষতি হবে।
আরও ট্রাবলশুটিং তথ্যের জন্য দেখুন উচ্চ বিলম্ব এবং প্যাকেট ক্ষতি অভিজ্ঞ লিঙ্ক একত্রীকরণ (LAG) লিঙ্ক।
16. সকেটের লিঙ্ক স্পিড পরীক্ষা করা হচ্ছে
প্রোভাইডার লসের একটি সম্ভাব্য কারণ হল একটি Socket লিংক অর্ধ-ডুপ্লেক্সে চলছে। এর মানে হল যে প্যাকেটগুলি একটি সময়ে কেবলমাত্র একটি দিক (আউটবাউন্ড বা ইনবাউন্ড) ব্যতীত যেতে পারে, যা কঠিনভাবে কার্যকারিতা কমিয়ে দেয় এবং প্যাকেট লসে পরিণত হয়। সব সকেট লিঙ্ক অবশ্যই কোন ব্যতিক্রম ছাড়াই সর্বদা ফুল-ডুপ্লেক্সে হতে হবে।
এছাড়াও, নিশ্চিত করুন যে উভয় WAN এবং LAN লিঙ্ক স্পিড একটি সাইটের জন্য কনফিগার করা ব্যান্ডউইথের সমান বা তার উপরে। লিঙ্ক স্পিড থ্রুপুটের জন্য সীমাবদ্ধ কারণ হতে পারে। উদাহরণস্বরূপ, একটি সাইটের কনফিগার করা ব্যান্ডউইথ 200 Mbps হলে কিন্তু LAN লিঙ্ক শুধুমাত্র 100 Mbps ফুল-ডুপ্লেক্স নিয়ে সমঝোতা করে, তবে সকেটে সংযুক্ত কম্পিউটার 100 Mbps এর উপরে থ্রুপুট অর্জন করতে পারে না।
লিঙ্ক স্থিতি পরীক্ষা করতে, সকেট UI তে লগ ইন করুন এবং মনিটর পৃষ্ঠায় লিঙ্ক স্ট্যাটাস দেখুন। নিচের উদাহরণটি 100 Mbps হাফ-ডুপ্লেক্সে WAN1 সংযোগ দেখায়।
যদি আপনি একটি লিঙ্ক হাফ-ডুপ্লেক্সে বা ভুল স্পিডে সেট করা দেখে থাকেন, তাহলে যার ডিভাইস সকেটের লিঙ্ক সংযুক্ত তার পোর্ট সেটিংস চেক করুন। নিশ্চিত করুন এটি অটো-নেগোশিয়েট এ সেট করা আছে বা এটি সকেটের স্পিড সেটিংসের সাথে মেলে। সব সকেট লিঙ্ক ডিফল্টভাবে অটো-নেগোশিয়েট এ সেট করা থাকে, কিন্তু আপনি নেটওয়ার্ক সেটিংস পৃষ্ঠায় স্পিড জোরপূর্বক করতে পারেন।
অন্য ডিভাইসে পোর্ট সেটিংস সঠিক হলে, ইথারনেট কেবলটি নষ্ট হতে পারে। কেবলটি একটি জানা ভাল কেবল দিয়ে পরিবর্তন করুন এবং দেখুন ডুপ্লেক্স বা স্পিড পরিবর্তন হয় কি না। যদি তাও কাজ না করে, ল্যাপটপ কম্পিউটার বা অন্যান্য ডিভাইসকে সকেটের পোর্টে সংযুক্ত করুন এবং লিঙ্ক স্ট্যাটাস পরীক্ষা করুন। অন্য ডিভাইসে একই কাজ করুন। যদি সকেটের লিঙ্ক প্রত্যাশিত স্পিড এবং ফুল-ডুপ্লেক্সে ওঠে কিন্তু অন্য ডিভাইসের লিঙ্ক না ওঠে, তাহলে আপনি জানতে পারবেন সমস্যা অন্য ডিভাইসেই রয়েছে।
17. ডুপ্লিকেট আইপি পরীক্ষা করা হচ্ছে
নেটওয়ার্ক স্তরে প্যাকেট ক্ষতি হতে পারে এমন আরেকটি সমস্যা হল ডুপ্লিকেট আইপি। সকেট সাধারণত এর কনফিগার করা ইন্টারফেসের IP ঠিকানা দিয়ে IP কনফ্লিক্ট সনাক্ত করতে পারে। একটি IP সংঘাত অস্তিত্বশীল যখন একই নেটওয়ার্কে দুটি ডিভাইসকে একই IP ঠিকানা বরাদ্দ করা হয়। যদি এটি ঘটে, আপনি Socket UI এর মনিটর পৃষ্ঠায় নিম্নলিখিত ত্রুটি দেখতে পাবেন।
যখন WAN ইন্টারফেসে একটি স্থিতিশীল আইপি ঠিকানা কনফিগার করা হয়, তখন ডুপ্লিকেট IP সনাক্ত হতে ব্যর্থ হতে পারে, কারণ সকেট শুধুমাত্র প্যাসিভভাবে একটি IP কনফ্লিক্টের জন্য মনিটর করে। এটি শুধুমাত্র একটি আইপি অ্যাড্রেস দ্বন্দ্ব শনাক্ত করবে যদি সকেট দ্বন্দ্বপূর্ণ আইপি অ্যাড্রেস সহ ডিভাইস থেকে একটি ARP প্রাপ্ত করে।
একবার। দ্বন্দ্বপূর্ণ আইপি অ্যাড্রেস সমস্যার সমাধান হয়ে গেলে, সতর্কতা WebUI থেকে অদৃশ্য হতে ২৪ ঘণ্টা পর্যন্ত সময় নিতে পারে। দেখুন IP ঠিকানা দ্বন্দ্ব রিপোর্ট করা হয়েছে Socket UI তে এটি সমাধান হওয়ার পরেও।
18. মাইক্রো-বুর্স্ট পরীক্ষা করা হচ্ছে
প্যাকেট হারানোর আরেকটি সম্ভাব্য কারণ হলো মাইক্রো-বার্স্ট (ফেটে যাওয়া)। মাইক্রো-বার্স্ট প্যাকেট বা ডেটা ফ্রেমের হঠাৎ বৃদ্ধি দ্বারা চিহ্নিত করা হয়, যা একটি খুব স্বল্প সময়ের মধ্যে ঘটে, সাধারণত কেবল কয়েক মাইক্রোসেকেন্ড থেকে কয়েক মিলিসেকেন্ডের মধ্যে স্থায়ী হয়। যেসব পরিস্থিতিতে মাইক্রো-বার্স্ট ঘটে এবং লিঙ্কের সীমা ছাড়িয়ে যায়, সেখানে প্রদানকারী (ISP) অতিরিক্ত ট্রাফিক বাদ দিতে পারে, যার ফলে প্যাকেট হারানো হয়।
নীচের গ্রাফে, আপনি মাইক্রো-বার্স্ট দ্বারা সৃষ্ট একটি সাধারণ প্যাকেট ক্ষতির উদাহরণ দেখতে পারেন এবং বার্স্টনেস মান সেটিংস সামঞ্জস্য করার পর উন্নতি পেতে পারেন।
উপরের উদাহরণে, বার্স্টনেস স্তরের মানটি পরিবর্তন করা হয় 0.2 থেকে 0.01 এ, যার মানে সকেট এবং PoP ট্রাফিকের উপর আরও আক্রমণাত্মক আকার প্রয়োগ করেছে, ফলে প্যাকেট ক্ষতির সমস্যা সমাধান হয়েছে।
প্যাকেট হারানো কমানোর জন্য বার্স্টনিস স্তরের সেটিংস সামঞ্জস্য করা
আপস্ট্রিম এবং ডাউনস্ট্রিম দিকগুলির জন্য প্রয়োগের ডিফল্ট বার্স্টনিস মান 0.2। এই মান সহ, সকেট এবং PoP প্যাকেটগুলি মিডিয়াতে যত তাড়াতাড়ি সম্ভব সিরিয়ালাইজ করে, যা সময়ের প্রথম মাইক্রোসেকেন্ডে অধিক বাইটি পাঠানোর অনুমতি দেয়। এই সেটিং সিরিয়ালাইজেশন বিলম্ব এবং সামগ্রিক বিলম্ব কমিয়ে পারফরম্যান্স অপটিমাইজ করে।
এই সমস্যার নিবারণ পদক্ষেপের অংশ হিসেবে, আপনাকে ধীরে ধীরে বার্স্টনিস স্তর কমাতে হবে যতক্ষণ না প্যাকেট হারানো কমে। যখন আপনি বার্স্টনিস স্তরের মান কমাবেন, সকেট এবং PoP ট্রাফিকের উপর আরও আক্রমণাত্মক আকার প্রয়োগ করে, ফলে মাইক্রো-বার্স্টকে মসৃণ করে। সবচেয়ে কম মান যা আপনি কনফিগার করতে পারেন তা হল 0.001।
বার্স্টনেস স্তর সামঞ্জস্য করার সর্বোত্তম পদ্ধতি হল ধীরে ধীরে মান কমানো (যেমন, 0.2 থেকে 0.18)। মান হ্রাসের পর, প্রভাব পর্যবেক্ষণ করতে সাইট মনিটরিং রিয়েল টাইম বা নেটওয়ার্ক বিশ্লেষণ স্ক্রীনগুলিতে প্যাকেট ক্ষতি বিশ্লেষণ করুন। মনে রাখবেন যে সাইটের মেট্রিক সাধারণত আপডেট হতে কয়েক মিনিট সময় লাগে। প্যাকেট হারানো সমস্যাকে মিটিয়ে ফেলার জন্য বর্স্টিনেস মান কমিয়ে চালিয়ে যান।
যদি এই প্রক্রিয়াটি প্যাকেট লস সমাধান না করে, এর মানে এটি মাইক্রো-বার্স্ট নয় বরং অন্যান্য কারণে সৃষ্ট। এই অবস্থায়, ডিফল্ট বার্স্টনেস মান ০.২ পুনরায় সেট করুন এবং আরও সহায়তার জন্য সাপোর্টের সাথে যোগাযোগ করুন।
বর্স্টিনেস লেভেল পরিবর্তন
উপস্ট্রীম এবং ডাউনস্ট্রিম দিকের জন্য বর্স্টিনেস স্তর সমন্বয় করা যেতে পারে। এই সেটিংটি সাইটের সমস্ত WAN লিঙ্কে প্রভাব ফেলে।
কনফিগারেশন সাইট স্তর বা অ্যাকাউন্ট স্তরে প্রয়োগ করা হয়। সাইট স্তরের কনফিগারেশন অ্যাকাউন্ট স্তরের উপর অগ্রাধিকার পায়।
বর্স্টিনেস লেভেল কনফিগার করার জন্য:
নেভিগেশন মেনু থেকে, অ্যাকাউন্ট স্তরের জন্য সম্পদ > উন্নত কনফিগারেশন অথবা সাইট স্তর সেটিংয়ের জন্য সাইট কনফিগারেশন > উন্নত কনফিগারেশন নির্বাচন করুন।
ডাউনস্ট্রিম মানের বর্স্টিনেস অথবা আপস্ট্রীম মানের বর্স্টিনেস নির্বাচন করুন।
সেটিংস সক্রিয় করুন এবং মানটি 0.001 - 0.2 এর মধ্যে সামঞ্জস্য করুন।
প্রয়োগ করুন এ ক্লিক করুন
সংরক্ষণ করুন ক্লিক করুন
নোট
যদি বর্স্টিনেস আগে Cato সাপোর্ট দ্বারা সমঞ্জসিত হয়েছিল, তাহলে ডিফল্ট 0.2 মানের পরিবর্তে সমঞ্জসিত মান প্রদর্শিত হবে।
বর্স্টিনেস মানগুলি শুধুমাত্র সকেট সাইটগুলির জন্য সমন্বয় করা যেতে পারে।
Cato ম্যানেজমেন্ট অ্যাপ্লিকেশনে সবচেয়ে ছোট ডেটা বালতি 5 সেকেন্ডের, মাইক্রো-বার্স্টগুলি সবচেয়ে ছোট ডেটা বালতিতে স্বাভাবিক করা হয় এবং সাধারণত চিহ্নিত করা কঠিন হয়।
যে সাইটগুলির ব্যান্ডউইথ 10 Mbps এবং নীচে রয়েছে তাদের জন্য বারস্টনেস মান 0.001 এ সেট করা সুপারিশ করা হয় না, কারণ এটি সাইটটির জন্য সংযোগ সমস্যা সৃষ্টি করতে পারে।