সকেট সাইট প্যাকেট ক্ষতির সমস্যা সমাধান

সমস্যা

প্যাকেট ক্ষতির উৎস নির্ধারণ এবং কেন এটি ঘটছে তা সর্বদা সহজ নয়। প্যাকেটগুলি ইন্টারনেটের মাধ্যমে বিভিন্ন আইএসপি এবং সংস্থার মালিকানাধীন একাধিক নেটওয়ার্কের মধ্য দিয়ে যায়, এবং আপনি লিঙ্ক স্টেট এবং সিপিইউ লোডের মতো বিষয়গুলি পরীক্ষা করার জন্য পথের প্রতিটি রাউটার অ্যাক্সেস পাবেন না। অতিরিক্তভাবে, প্যাকেট ক্ষতি নেটওয়ার্ক পথে যেকোনো পয়েন্টে ঘটতে পারে।

সম্ভাব্য কারণগুলি

এরকম অনেক কারণ রয়েছে যার জন্য প্যাকেটগুলি পথে নিক্ষিপ্ত হতে পারে। কয়েকটি সাধারণ কারণ হল:

• আইএসপি পেয়ারিং সমস্যা
• লেন্ক যানজট
• ভুল কনফিগারেশন (ব্যান্ডউইডথ সেটিংস বা এনআইসি গতি এবং ডুপ্লেক্স)
• হার্ডওয়্যার ব্যর্থতা
• নেটওয়ার্ক ডিভাইসে উচ্চ সিপিইউ
• মাইক্রো-বার্স্ট হ্যান্ডলিং

কাটোতে প্যাকেট ক্ষতি বোঝা

কাটোতে প্যাকেট ক্ষতি চিহ্নিত করার একটি ভাল উপায় হলো কাটো ম্যানেজমেন্ট অ্যাপ্লিকেশনে বিশ্লেষণ স্ক্রিন ব্যবহার করা। প্যাকেট ক্ষতি এবং বাতিল গ্রাফগুলি সময়ের সাথে প্যাকেট ক্ষতি দেখায় এবং আপনাকে নির্দিষ্ট সময় ফ্রেমগুলির উপর ফোকাস করতে দেয়। এই গ্রাফগুলি চিহ্নিত করার জন্য দরকারী যে প্যাকেট ক্ষতি ঘটছে এবং এটি অতীতে কখন ঘটেছিল। 

1. প্রদানকারী ক্ষতি

Socket এবং PoP এর মধ্যে ঘটে। যদিও বেশিরভাগ প্রদানকারী প্যাকেট ক্ষতি কাটো-এর নিয়ন্ত্রণের বাইরে শেষ মাইল নেটওয়ার্ক কানেক্টিভিটি সমস্যার কারণে ঘটে, এটি অবশ্যই কাটো সম্পর্কিত কোন সমস্যা বাদ দেয় না।

কাটো কীভাবে প্রদানকারী ক্ষতি মেপে থাকে 

প্রোভাইডার লস Socket এবং PoP এর উপর একটি নির্দিষ্ট লিঙ্কে প্রেরিত এবং গ্রহণিত প্যাকেটের সংখ্যার তুলনা করে মাপা হয়।

• ডাউনস্ট্রিম প্যাকেট লস হল PoP দ্বারা প্রেরিত প্যাকেটের সংখ্যা এবং Socket দ্বারা গ্রহণ করা প্যাকেটের সংখ্যার মধ্যে পার্থক্য, যা শতাংশ হিসাবে প্রকাশ করা হয়।

ফর্মুলা:

• আপস্ট্রিম প্যাকেট লস হল Socket দ্বারা প্রেরিত প্যাকেটের সংখ্যা এবং PoP দ্বারা গ্রহণ করা প্যাকেটের সংখ্যার মধ্যে পার্থক্য, যা শতাংশ হিসাবে প্রকাশ করা হয়।

ফর্মুলা:

Cato প্রোভাইডার প্যাকেট লস গণনা করার উপায় মানে হল যতটা সহজেই সম্ভব, আপনি আরম্ভতেই ISP এর উপর সব দোষ চাপাতে পারেন না। এটা সম্ভব যে আপনার সকেট এবং আইএসপি রাউটারের মধ্যবর্তী সরঞ্জাম প্যাকেট ক্ষতিতে সহায়তা করে, অথবা আইএসপির নিয়ন্ত্রণের বাইরে PoP-এর কাছে নেটওয়ার্কের পথে সমস্যা থাকতে পারে।

2. Cato বর্জিত

যখন Cato QoS ইচ্ছাকৃতভাবে প্যাকেটগুলি বাদ দেয় তখন ঘটে। QoS ইঞ্জিন নিম্ন-অগ্রাধিকার প্যাকেটগুলি বাতিল করা শুরু করে যখন:

• যানজট ঘটে যখন একটি লিঙ্কের উপরে মোট থ্রুপুট লিঙ্কের জন্য কনফিগার করা ব্যান্ডউইথের সাথে মেলে।
• Cato প্যাকেটগুলি বাতিল করে যদি একটি BW ব্যবস্থাপনা অগ্রাধিকার একটি কঠিন থ্রুপুট সীমা দিয়ে কনফিগার করা হয় এবং অগ্রাধিকার মেলানো ট্রাফিক সীমায় পৌঁছে যায়।
• বিস্ফোরণের সময় (এমনকি উচ্চ-অগ্রাধিকার সারিও প্যাকেট হতে পারে)।

Cato বাতিল প্যাকেট লস আশা করা যায় এবং এটি প্রয়োজনীয়ভাবে কোনো সমস্যার লক্ষণ নয়।

Cato প্যাকেট ক্ষতি বাতিল সম্পর্কিত যেকোনো সমস্যা সম্ভবত ভুল কনফিগারেশনের কারণে ঘটে। সংকটাপন্ন অ্যাপ্লিকেশনগুলি, যেমন VoIP, সর্বোচ্চ ব্যান্ডউইথ পরিচালনা অগ্রাধিকার দেওয়া উচিত। যদি ভিড় হয়, Cato নিম্ন-অগ্রাধিকার ট্রাফিক বাদ দেয়, কিন্তু এটি উচ্চ-অগ্রাধিকার ট্রাফিক বাদ দেয় না। সর্বদা নিশ্চিত করুন যে যথাযথ ব্যান্ডউইথ পরিচালনা অগ্রাধিকারগুলি ট্রাফিকের জন্য নিয়োগ করা হয়েছে।

বিশ্লেষণ প্যাকেট ক্ষতির ব্যাপক দেখুন প্রদান করে। তবে, যদি আপনি Cato এর বাতিল প্যাকেট লসের সাথে ডিল না করেন, শুধু অ্যানালিটিক্স আপনাকে জানাতে পারবে না কী কারণে প্যাকেট লস ঘটছে বা প্যাকেট লস কোথায় ঘটছে। 

কিভাবে প্যাকেট ক্ষতি নির্ণয় করা যায়

1. প্যাকেট ক্ষতির পরিসর নির্ধারণ করা

যখন আপনি শুরু করেন, এটা সত্যিই গুরুত্বপূর্ণ যে কে বা কী প্যাকেট লসের সম্মুখীন হচ্ছে তা খুঁজে বের করা।

• যে সাইটে প্রতিটি ব্যবহারকারী প্যাকেট লসের সম্মুখীন হচ্ছে, নাকি এটি একটি একক এন্ডপয়েন্টে সীমিত রয়েছে?
• প্যাকেট লস ইন্টারনেটের উপর নাকি WAN এর উপর ঘটে?
• বহু সাইট প্যাকেট লস দ্বারা প্রভাবিত হচ্ছে, নাকি শুধু একটি?
• সমস্ত ট্রাফিক প্রভাবিত হচ্ছে, নাকি শুধু একটি নির্দিষ্ট অ্যাপ্লিকেশন?
• প্যাকেট লস কি স্থায়ী, নাকি এটা শুধু মাঝে মাঝে ঘটে?

উপরের প্রশ্নগুলির উত্তর জানা আপনাকে সম্পর্কিত CMA ইভেন্টগুলি সনাক্ত করতে সহায়তা করতে পারে এবং সমাধান প্রক্রিয়ার সময় আপনাকে সময় বাঁচায়। অগ্রিম আপনার জানা যত বেশি বিস্তারিত, আপনার সমস্যা সমাধানটি তত বেশি কেন্দ্রীভূত হতে পারে।

2. সাইট বিশ্লেষণ পরীক্ষা করা - প্যাকেট ক্ষতি গ্রাফ

সাইটের বিশ্লেষণ প্যাকেট ক্ষতি গ্রাফে প্যাকেট ক্ষতি দেখাচ্ছে? প্যাকেট ক্ষতি এবং বাতিল করা প্যাকেটগুলি দেখাতে পারে এমন বিশ্লেষণ গ্রাফের উপর ভিত্তি করে আমাদের বিভিন্ন সুপারিশ রয়েছে।

প্যাকেট ক্ষতি নেই

বিশ্লেষণ স্ক্রীনে কোন প্যাকেট ক্ষতি প্রদর্শিত ছাড়াই প্যাকেট ক্ষতি বিদ্যমান থাকতে পারে। স্থানীয় নেটওয়ার্কে একটি সমস্যা থাকতে পারে, অথবা এটি একটি PoP সম্পর্কিত সমস্যা হতে পারে। সকেট থেকে একটি ল্যান পাশে আইপি পিং করার জন্য ইউআই নেটওয়ার্ক টুল ব্যবহার করা একটি ভাল উপায় হতে পারে মূল কারণ সনাক্ত করার জন্য।

প্যাকেট ক্ষতি

যদি গ্রাফে প্যাকেট ক্ষতি প্রদর্শিত হয়, এটি ভুল বিডাব্লিউ কনফিগারেশনের কারণে হতে পারে। নীচে যা বর্ণিত হয়েছে তা হিসাবে কনফিগার করা ব্যান্ডউইথ দেখুন ব্যান্ডউইথ কনফিগারেশন যাচাই।

প্রদানকারী প্যাকেট ক্ষতির জন্য, চেক করুন যে ড্রপগুলি শুধুমাত্র তখনই থাকে যখন ট্রাফিক স্পাইক (বিস্ফোরণ) ঘটে। ইতিমধ্যে যদি হয়, তাহলে অ্যাপ্লিকেশন এনালিটিক্স পেজ ব্যবহার করে ট্রাফিক নির্ধারণ করুন যা বিস্ফোরণ সৃষ্টি করে। বিশেষভাবে সীমিত বিডাব্লিউ ব্যবস্থাপনা প্রোফাইল এ এপ্লিকেশন ট্রাফিক বাঁধা রাখুন।

প্রায়ই, আমরা এমন কিছু ঘটনা দেখতে পাব যেখানে থ্রুপুট সাধারণত কম থাকে, কিন্তু বিস্ফোরণ স্পাইকগুলি প্যাকেট ক্ষতির কারণ হয়। আমাদের বিবেচনায় রাখতে হবে যে আইএসপির নিজস্ব ট্রাফিক আকারের নীতি রয়েছে, এবং সেই ক্ষেত্রে, সম্ভবত আইএসপি নীতি এবং ক্যাটো ট্রাফিক আকারের নীতির ভিন্ন উন্নয়ন নীতি রয়েছে। বিস্ফোরণের বিষয়ে আরও তথ্যের জন্য, নীচে দেখুন মাইক্রো-বিস্ফোরণ যাচাই করুন

3. সাইট এনালিটিক্স যাচাই করুন - বাতিল প্যাকেটস গ্রাফ

কাঠের বাতিল প্যাকেটের জন্য, আপনার ব্যান্ডউইথ অগ্রাধিকারগুলিও তদন্ত করা উচিত। অগ্রাধিকার বিশ্লেষক সাইটের বিশ্লেষণ স্ক্রিনের নিচে দেখুন যে কোন অগ্রাধিকার বাদ দেওয়া হয়েছে। আপনি অগ্রাধিকার সেকশন বিস্তৃত করে সেই অগ্রাধিকারের শীর্ষ অ্যাপ্লিকেশনগুলি দেখতে পারেন। যদি কোনো বিশেষ অ্যাপের প্যাকেট ক্ষতি দ্বারা প্রভাবিত হয়, তাহলে নেটওয়ার্ক নিয়ম এ সেই অ্যাপ্লিকেশনের অগ্রাধিকার বাড়ানো প্রয়োজন হতে পারে। মনে রাখবেন, ক্যাটো QoS বাধ্যতা সময়ে কম অগ্রাধিকার প্যাকেট বাতিল করার জন্য ডিজাইন করা হয়েছে, তাই ক্যাটো বাতিল প্যাকেট ক্ষতি সর্বদা সমস্যা নয়।

ক্যাটো QoS যে কোনো প্যাকেট, অগ্রাধিকার নির্বিশেষে বাতিল করতে পারে, সেই কিউতে বিস্ফোরণ থাকার কারণে। বিস্ফোরণ ব্যবস্থাপনার প্রকৃতির কারণে এই আচরণেরও আশা করা হয়। অগ্রাধিকার বিশ্লেষক পেজটি কাজ দ্বারা নির্ধারণ করতে পারে কি ট্রাফিক বিস্ফোরণগুলি প্যাকেট বাতিল হওয়ার সময় ঘটে। আরও তথ্যের জন্য দেখুন সকেট ট্রাফিক প্রাধান্য এবং QoS।

বিশ্লেষণ স্ক্রিনের অগ্রাধিকার বিশ্লেষক প্রতিটি QoS অগ্রাধিকার জন্য উপারি ও অধোগামী দিকের প্যাকেট ক্ষতি প্রদর্শন করে।

4. সাইট বিশ্লেষণ যাচাই করা হচ্ছে - শেষ মাইল প্যাকেট ক্ষতি

ISP সমস্যা সম্মুখীন হচ্ছে কিনা মূল্যায়নে, বিশ্লেষণ স্ক্রিনের শেষ মাইল ট্যাব ব্যবহার করে WAN লিঙ্কের বিলম্ব পরিবর্তন বা প্যাকেট ক্ষতির জন্য পরীক্ষা করুন। প্রদানকারী প্যাকেট ক্ষতির সাথে অমিল রেখে, শেষ মাইল তথ্য পপুলার ওয়েবসাইটের ICMP পরীক্ষার উপর ভিত্তি করে। একটি পরামর্শ হিসেবে, পিং করা যায় এমন অতিরিক্ত সার্ভিস IPগুলি শেষ মাইল মনিটরিং পাতায় যোগ করা যেতে পারে। উদাহরণস্বরূপ, যদি VoIP সম্পর্কিত সমস্যা থাকে, তাহলে SIP সার্ভার IP একটিভ IP হিসেবে সেট করা যেতে পারে।

যদি আপনি সন্দেহ করেন যে আইএসপি সংক্রান্ত প্যাকেট হারানো হচ্ছে, আপনার আইএসপিকে নিম্নলিখিত প্রশ্নগুলি জিজ্ঞাসা করুন:

1. আপনি কি UDP/443 বা UDP/1337 (DTLS) ট্রাফিকে QoS প্রয়োগ করছেন?
2. আপনি কি UDP ট্রাফিকে কোনো DoS সুরক্ষা প্রয়োগ করছেন যা PoP IP-তে প্যাকেট ক্ষতি করতে পারে?
3. আপনার রাউটার(গুলি) এর পথে PoP IP এর দিকে যানজট বা উচ্চ CPU আছে কি?
4. আপনি কি সাবস্ক্রাইব করা লাইন রেটের উপরে বুর্স্টিং অনুমতি দিচ্ছেন?

5. (ঐচ্ছিক) শেষ মাইল অভিজ্ঞতা পর্যবেক্ষণ

অভিজ্ঞতা মনিটরিং লাইসেন্স সহ গ্রাহকরা প্যাকেট হারানো এবং প্যাকেট বাতিলের সম্ভাবনার জন্য শেষ মাইল এবং অ্যাপ্লিকেশন পারফরম্যান্স ট্যাবগুলি পরীক্ষা করতে পারেন। সমস্যার সূচনা স্থান ভালোভাবে বোঝার জন্য সাইটের নেটওয়ার্ক বিশ্লেষণ পাতায় পাওয়া ফলাফলগুলোর সাথে ডেটার মিল করা যেতে পারে।

6. DTLS পোর্ট UDP/443 পরিবর্তন করুন

কিছু ISP সম্ভবত UDP/443-এ ট্র্যাফিক শেপিং অথবা QoS প্রয়োগ করতে পারে। এটি এমনকি যখন লিংক অন্যথায় স্থিতিশীল থাকে তখনও প্যাকেট লস আনতে পারে।

• Socket কনফিগারেশনে, DTLS টানেল পোর্ট পরিবর্তন করুন 443 থেকে 1337।

• পরিবর্তন প্রয়োগের পরে, অ্যানালিটিক্স স্ক্রিনে প্যাকেট লস এবং লেটেন্সি নিরীক্ষণ করুন।

• যদি প্যাকেট লস উন্নত হয়, এটি নিশ্চিত করে যে ISP UDP/443 ট্র্যাফিককে শেপ করছে। সে ক্ষেত্রে, টানেলটি 1337 এ রাখুন অথবা ISP এর সাথে বিষয়টি উথাপন করুন।

7. ব্যান্ডউইথ কনফিগারেশন পরীক্ষা করা হচ্ছে

লিঙ্ক যানজট দ্বারা প্যাকেট ক্ষতি হতে পারে, এবং এটি গুরুত্বপূর্ণ যে প্রতিটি WAN সংযোগের জন্য ব্যান্ডউইথ Cato ম্যানেজমেন্ট অ্যাপ্লিকেশন-এ সঠিকভাবে কনফিগার করা হয়। নিশ্চিত করুন যে কনফিগার করা ব্যান্ডউইথ সাইট কনফিগারেশন এ আইএসপি যা সরবরাহ করে তা সাথে মিলে যায়। Cato সাইট লাইসেন্সের শর্তাবলী অনুসারে সকেট WAN ইন্টারফেস ব্যান্ডউইথ সেটিংস কনফিগার করুন।

Azure/AWS পরিবেশগুলোর কোনো ঐতিহ্যগত ব্যান্ডউইথ সীমাবদ্ধতা নেই। পরিবর্তে, কনফিগার করা সাইটের ব্যান্ডউইথ কখনও vSocket এর জন্য সমর্থিত ব্যান্ডউইথের বেশি হওয়া উচিত নয়। Azure এর সংস্করণ ২১ থেকে, Standard_D8ls_v5 VM আকার ২Gbps পর্যন্ত সমর্থন করে। AWS এ, c5n.xlarge ইন্সটেন্স সাইজ ২Gbps এর বেশি ব্যান্ডউইথ প্রদান করে। শ্রেষ্ঠ পারফরম্যান্স নিশ্চিত করার জন্য সাইটের কনফিগার করা ব্যান্ডউইথ সমর্থিত সীমার মধ্যে থাকতে হবে।

যদি কনফিগার করা ব্যান্ডউইথ আইএসপি যা প্রদান করে তার কম হয়, তবে Cato-এর QoS ইঞ্জিন কনফিগার করা ব্যান্ডউইথ সীমা অতিক্রম হলে প্যাকেটস ড্রপ করা শুরু করতে পারে। যদি এটি ঘটে, তবে একটি সাইটের বিশ্লেষণ থ্রুপুট গ্রাফে একটি সমতল রেখা লক্ষ্যনীয় হয় যা সাইটের কনফিগার করা ব্যান্ডউইথের সমান হয় এবং Cato বাতিল প্যাকেটস সহ।

যদি ব্যান্ডউইথ সঠিকভাবে কনফিগার করা থাকে তবেও, ISP সংযোগ যানজটপূর্ণ হলে একই আচরণটি হতে পারে। যদিও এই আচরণ সমস্যার নিশ্চয়তা দেয় না, এটি একটি ভাল অনুশীলন যে এই পরিস্থিতিতে ব্যান্ডউইডথ সঠিকভাবে কনফিগার করা হয়েছে তা নিশ্চিত করার।.

যদি কনফিগার করা ব্যান্ডউইডথ আইএসপি প্রদানকারীর থেকে বেশি হয়, তাহলে আইএসপি-এর ব্যান্ডউইডথ সীমা অতিক্রম করলে ক্যাটোের QoS ইঞ্জিন কাজ করবে না এবং সুতরাং, আইএসপি র্যান্ডমভাবে প্যাকেট ড্রপ করতে শুরু করতে পারে।. এই ক্ষেত্রে, আপনি সাইট বিশ্লেষণ থ্রুপুট গ্রাফে একটি ফ্ল্যাটলাইন দেখতে পাবেন যা কনফিগার করা ব্যান্ডউইডথ স্তরের নীচে এবং প্রদানকারীর প্যাকেট ক্ষতি সহ।.

প্রতিটি সকেট মডেলের জন্য সকেট থ্রুপুট এবং ক্ষমতা তথ্য সকেট ডেটাশিট-এ উপলব্ধ, এই প্রবন্ধটি দেখুন: X1700, X1600 & X1500 সকেট গাইডস।.

8. সকেট সিপিইউ পারফরম্যান্স চেক করুন

CMA এর নেটওয়ার্ক অ্যানালিটিকস থেকে, হার্ডওয়্যার ট্যাব নির্বাচন করুন। এই সেকশনটি প্রতিটি কোরের ঐতিহাসিক সিপিইউ ব্যবহার শতাংশ প্রদর্শন করে।

স্থায়ী সিপিইউ ব্যবহার 90% এর উপরে সকেট পারফরম্যান্সের উপর নেতিবাচক প্রভাব ফেলতে পারে এবং প্যাকেট ক্ষতি এবং উচ্চ বিলম্ব তৈরি করতে পারে। যদি স্থায়ী উচ্চ সিপিইউ ব্যবহার লক্ষ্য করা যায়, তবে আপনার অ্যাকাউন্ট প্রতিনিধি সঙ্গে যোগাযোগ করুন সম্ভাব্য হার্ডওয়্যার পরিবর্তন মূল্যায়ন করার জন্য (যেমন, X1500 থেকে X1600)।

অতিরিক্ত ত্রুটিমুক্ত করার জন্য, সাপোর্টের সাথে যোগাযোগ করুন

রিয়েল-টাইম সকেট সিপিইউ ব্যবহার সকেট ওয়েবইউআই এর হার্ডওয়্যার অবস্থা ট্যাব থেকে দেখা যেতে পারে। পারফরম্যান্সের ধারা নির্ধারণ করতে সক্রিয় ব্যবহারকে ঐতিহাসিক তথ্যের সাথে তুলনা করুন।

9. সাইট পুনরায় সংযোগ বাতিল করা

ক্যাটো ক্লাউড সাইট পুনরায় সংযোগগুলি প্যাকেট ক্ষতির একটি উৎস।. গৃহ > ইভেন্ট চেক করুন যদি প্যাকেট ক্ষতি পুনরায় সংযোগ ইভেন্টগুলির সাথে সংযুক্ত হয়ে থাকে।. ইভেন্টগুলিকে সাব-টাইপ = 'পুনরায় সংযুক্ত' হিসেবে ফিল্টার করুন।.

পুনরায় সংযুক্ত ইভেন্টগুলি একটি বার্তা দেখাবে যা বিচ্ছেদের কারণ ব্যাখ্যা করবে।. দেখুন পুনরায় সংযুক্ত ইভেন্টগুলি বুঝুন

10. ক্যাটো বাইপাস করা

ইন্টারনেটের উপর প্যাকেট ক্ষতির জন্য, দ্রুত ক্যাটো ক্লাউডের সমস্যাটি বাদ দিতে একটি উৎস বা গন্তব্য বাইপাস সেট আপ করুন।. এটি করার সবচেয়ে সহজ উপায় হল সাইট কনফিগারেশনে একটি একক ব্যবহারকারীর আইপি ঠিকানার জন্য একটি উৎস বাইপাস সেট আপ করা এবং পরীক্ষা করা যে প্যাকেট ক্ষতি অব্যাহত থাকে কিনা।. যদি প্যাকেট ক্ষতি অব্যাহত থাকে, সমস্যাটি ল্যান, সকেট অথবা আইএসপি হতে পারে, কিন্তু সমস্যাটি পপ-এর সাথে সম্পর্কিত হবে না।.

11. পিং টেস্ট চালানো হচ্ছে

প্যাকেট ক্ষতিগ্রস্ত উৎস এবং গন্তব্য আইপি ঠিকানার মধ্যে একটি নিরবিচ্ছিন্ন পিং শুরু করুন।. পিং-গুলি ট্রেস করা সহজ এবং প্যাকেট ক্যাপচারগুলিতে বিশ্লেষণ করা যায়।. যখন কিছু পিং অনুরোধ তাদের গন্তব্যে পৌঁছায় না, তখন সাধারণত আপনি প্যাকেট ক্ষতির সম্মুখীন হন এবং এটি অনুরোধ টাইম আউট হিসাবে প্রদর্শিত হবে।

সকেট UI আপনাকে হোস্টনেম বা IP দ্বারা পিং টুল এর মাধ্যমে পিং করার সুযোগ দেয়। আপনি যে ইন্টারফেসটি পিংয়ের জন্য পাঠাতে চান তা নির্বাচন করতে পারেন, এটি Cato এর মাধ্যমে বা সরাসরি WAN লিঙ্কের মাধ্যমে। পিং ফলাফলে কোন অমিল আছে কিনা দেখুন, যেমন প্যাকেট ক্ষতি বা উচ্চ বিলম্ব। যদি Cato সহ এবং ছাড়া প্যাকেট ক্ষতি উপস্থিত থাকে, তাহলে এটি একটি ISP সমস্যা নির্দেশ করতে পারে। এছাড়াও, যদি লিঙ্কগুলির মধ্যে একটি 4G/LTE হয়, তাহলে আপনাকে মনে রাখতে হবে যে এই লিঙ্কগুলি প্যাকেট ক্ষতির প্রতি আরও সংবেদনশীল।

UI শুধুমাত্র 10 পিং অনুরোধ পাঠায়, তাই যদি আপনার আরও পিং প্রয়োজন হয় তবে আপনাকে পিং বাটনটি আবার ক্লিক করতে হবে। 

নোট: পিং পরীক্ষাগুলি নেটওয়ার্কের মৌলিক স্বাস্থ্য যাচাই করতে ভালো, কিন্তু কোন পিং ড্রপ না থাকলে তা অপরিহার্যভাবে একটি নির্মল লাইন নির্দেশ করে না।

12. ট্রেসরুট টেস্ট চালানো হচ্ছে

ট্রেসরাউট একটি উৎস এবং গন্তব্যের মধ্যে রাউটার (হপ) সনাক্ত করার জন্য ব্যবহৃত হয়। এটি প্রতিটি হপের জন্য প্যাকেট ক্ষতি এবং বিলম্ব দেখাবে।

ট্রেসরাউট ট্রেসরাউট টুল এর মাধ্যমে সকেট UI থেকে চালানো যেতে পারে। টু হপগু লিংক নেটওয়ার্ক রাউট ট্রেস রান করুন কাছ প্যাকেটের কোন খয় বা অনাকাঙিত উচ্চ বিলম্ব খুঁজতে সকেট এবং গন্তব্য ডোমেইন মধ্যে। পরীক্ষা চালানোর সময় প্যাকেট হারোনো যাচাই করতে সর্বোচ্চ কাউন্ট (২০০) সর্বনিম্ন সময়ান্তর (০.১) সেট করুন।

ট্রেসরাউট ফলাফল বিশ্লেষণ

অবগত থাকুন যে যে কোন একক হপের প্যাকেট ক্ষতি দেখানো হচ্ছে, তা অপরিহার্যভাবে কোন সমস্যার ইঙ্গিত নয়। একটি একক হপ 100% প্যাকেট ক্ষতি দেখাতে পারে কেবলমাত্র এর ICMP রাউটারে সক্রিয় না থাকার কারণে। ICMP হার সীমাবদ্ধতার কারণে কোন সমস্যার উপস্থিতি ছাড়া একটি হপ 100% এর কম প্যাকেট ক্ষতি দেখাতে পারে। যদি আপনি একটি হপে কিছু প্যাকেট ক্ষতি দেখতে পান এবং পরবর্তী হপে 0% প্যাকেট ক্ষতি, তাহলে আপনি সম্ভবত ICMP হার সীমাবদ্ধতা দেখছেন।

যদি প্যাকেট হারানোর সমস্যা সত্যি থাকে, এটি এক হপ থেকে শুরু হবে এবং একাধিক হপের জন্য চলতে থাকবে, প্রতিটি হপ প্যাকেট হারানো দেখাবে। এটিও সম্ভব যে পাথের একাধিক রাউটার প্যাকেট ক্ষতিতে অবদান রাখছে, তাই প্রতি হপে প্যাকেট ক্ষতির পরিমাণ বিভিন্ন হতে পারে। উদাহরণস্বরূপ, রুটে আটটি হপ আছে, এবং ট্রেসরাউট হপ ৩-৭ এর জন্য প্যাকেট হারানো দেখায়।

13. Speedtest দিয়ে লিংক পরীক্ষা করা হচ্ছে

রিয়েল টাইম স্ক্রীনটি বর্তমান থ্রুপুট পরিবর্তনগুলি সনাক্ত করে অবিলম্বে প্যাকেট হারানো এবং বাতিল প্যাকেটগুলি সনাক্ত করতে সাহায্য করতে পারে। সমস্যা সমাধানের সময়, উচ্চ চাহিদার কারণে প্যাকেট লস প্রতিলিপি বানানোর জন্য Socket এর speedtest টুল ব্যবহার করুন।

সকেট Sপিেডটেস্ট ফলাফলসমূহ কাটো দ্বারা প্রদত্ত লিঙ্কের জন্য কনফিগার করা ব্যান্ডউইথের কাছাকাছি হওয়ার আশা করা যায়। তবে, DTLS টানেল ওভারহেড (117 বাইট) সামান্য দ্বারার তার কার্যকারিতা কমতে পারে। 

পরীক্ষাটি লিঙ্কটি সম্পূর্ণ করবে এবং নেটওয়ার্ক বিশ্লেষণ স্ক্রীনে কোনও ISP-সম্পর্কিত প্যাকেট হারানো প্রদর্শন করবে। যদি কনফিগার করা লিঙ্কের ব্যান্ডউইথ ISP-দ্বারা প্রদত্ত ব্যান্ডউইথ থেকে কম হয়, পরীক্ষা চালানোর সময় বাতিল প্যাকেটগুলি প্রত্যাশিত।

সরাসরি স্পিডটেস্ট 

WAN পোর্টের মাধ্যমে সরাসরি স্পিডটেস্ট চালানোর সময়, আপস্ট্রীম ফলাফলটি Cato ম্যানেজমেন্ট অ্যাপ্লিকেশন এ কনফিগার করা ব্যান্ডউইথ লাইসেন্সের কাছাকাছি হওয়া উচিত। সকেট এখনও সাইটের ব্যান্ডউইথ লাইসেন্স অনুযায়ী আপস্ট্রীম সরাসরি স্পিডটেস্টের জন্য QoS ব্যবহার করবে। অন্যদিকে, ডাউনস্ট্রিম ফলাফলটি স্থানীয় ISP-এর সম্পূর্ণ ক্ষমতা প্রদর্শন করবে।

14. iPerf দিয়ে লিংক পরীক্ষা করা হচ্ছে

সকেট ওয়েবইউআই আপনাকে iPerf টুল ব্যবহার করতে দেয় সমস্যা সমাধানের জন্য শেষ-মাইল পারফরম্যান্স সমস্যা সকেট এবং সংযুক্ত PoP এর মধ্যে কাটো ক্লাউড এ। 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 থেকে অদৃশ্য হতে ২৪ ঘণ্টা পর্যন্ত সময় নিতে পারে। দেখুন সমাধান হওয়ার পরেও সকেট UI তে রিপোর্ট করা IP ঠিকানা দ্বন্দ্ব

18. মাইক্রো-বুর্স্ট পরীক্ষা করা হচ্ছে

প্যাকেট হারানোর আরেকটি সম্ভাব্য কারণ হলো মাইক্রো-বার্স্ট (ফেটে যাওয়া)। মাইক্রো-বার্স্ট স্বল্প সময়ের মধ্যে প্যাকেট বা ডেটা ফ্রেমের হঠাৎ বৃদ্ধি দ্বারা চিহ্নিত করা হয়, যা সাধারণত কেবল কয়েক মাইক্রোসেকেন্ড থেকে কয়েক মিলিসেকেন্ডের জন্য স্থায়ী হয়। যেসব পরিস্থিতিতে মাইক্রো-বার্স্ট ঘটে এবং লিঙ্কের সীমা ছাড়িয়ে যায়, সেখানে প্রদানকারী (ISP) অতিরিক্ত ট্রাফিক বাদ দিতে পারে, যার ফলে প্যাকেট হারানো হয়।

নীচের গ্রাফে, আপনি মাইক্রো-বার্স্টের কারণে প্যাকেট হারানোর একটি সাধারণ উদাহরণ দেখতে পারেন এবং বার্স্টনিস মান সেটিংস সমন্বয় করার পর উন্নতি দেখতে পারেন। 

উপরে উল্লেখিত উদাহরণে বিস্ফোরণ স্তরের মান ডিফল্ট মান 0.2 থেকে 0.01 এ পরিবর্তন করা হয়েছিল যা মানে Socket এবং PoP ট্রাফিকের উপর আরও আক্রমণাত্মক শেপিং প্রয়োগ করে, এইভাবে প্যাকেট লস সমস্যার সমাধান করে।  

প্যাকেট হারানো কমানোর জন্য বার্স্টনিস স্তরের সেটিংস সামঞ্জস্য করা

আপস্ট্রিম এবং ডাউনস্ট্রিম দিকগুলির জন্য প্রয়োগের ডিফল্ট বার্স্টনিস মান 0.2। এই মান সহ, সকেট এবং PoP প্যাকেটগুলি মিডিয়াতে যত তাড়াতাড়ি সম্ভব সিরিয়ালাইজ করে, যা সময়ের প্রথম মাইক্রোসেকেন্ডে অধিক বাইটি পাঠানোর অনুমতি দেয়। এই সেটিংস সিরিয়ালাইজেশন বিলম্ব এবং সামগ্রিক বিলম্ব কমিয়ে পারফরম্যান্স অপটিমাইজ করে। 

এই সমস্যার নিবারণ পদক্ষেপের অংশ হিসেবে, আপনাকে ধীরে ধীরে বার্স্টনিস স্তর কমাতে হবে যতক্ষণ না প্যাকেট হারানো কমে। যখন আপনি বার্স্টনিস স্তরের মান কমাবেন, সকেট এবং PoP ট্রাফিকের উপর আরও আক্রমণাত্মক আকার প্রয়োগ করে, ফলে মাইক্রো-বার্স্টকে মসৃণ করে। সবচেয়ে কম মান যা আপনি কনফিগার করতে পারেন তা হল 0.001।

বার্স্টনিস স্তর সামঞ্জস্য করার সর্বোত্তম অনুশীলন হল মান ধীরে ধীরে কমানো (যেমন, 0.2 থেকে 0.18)।  মান কমানোর পরে, সাইট নিরীক্ষণ রিয়েল টাইম বা নেটওয়ার্ক বিশ্লেষণ স্ক্রীনগুলিতে প্যাকেট হারানো বিশ্লেষণ করে প্রভাব নিরীক্ষণ করুন। মনে রাখবেন যে সাইটের মেট্রিক সাধারণত আপডেট হতে কয়েক মিনিট সময় লাগে। প্যাকেট হারানো সমস্যাকে মিটিয়ে ফেলার জন্য বর্স্টিনেস মান কমিয়ে চালিয়ে যান। 

যদি এই প্রক্রিয়া দ্বারা প্যাকেট হারানোর সমস্যা সমাধান না হয়, তাহলে এর কারণ মাইক্রো-বার্স্ট ছাড়া অন্যান্য কিছু।  এই ক্ষেত্রে, ডিফল্ট বর্স্টিনেস মান 0.2 এ পুনরুদ্ধার করুন এবং আরো সহায়তার জন্য সাপোর্টের সাথে যোগাযোগ করুন। 

বর্স্টিনেস লেভেল পরিবর্তন

উপস্ট্রীম এবং ডাউনস্ট্রিম দিকের জন্য বর্স্টিনেস স্তর সমন্বয় করা যেতে পারে। এই সেটিংস সাইটের সকল WAN লিঙ্ককে প্রভাবিত করে। 

কনফিগারেশন সাইট স্তর বা অ্যাকাউন্ট স্তরে প্রয়োগ করা হয়। সাইট স্তরের কনফিগারেশন অ্যাকাউন্ট স্তরের উপর অগ্রাধিকার পায়।

বর্স্টিনেস লেভেল কনফিগার করার জন্য:

1. নেভিগেশন মেনু থেকে, অ্যাকাউন্ট স্তরের জন্য সম্পদ > উন্নত কনফিগারেশন অথবা সাইট স্তর সেটিংয়ের জন্য সাইট কনফিগারেশন > উন্নত কনফিগারেশন নির্বাচন করুন।
   
2. ডাউনস্ট্রিম মানের বর্স্টিনেস অথবা আপস্ট্রীম মানের বর্স্টিনেস নির্বাচন করুন।
3. সেটিংস সক্রিয় করুন এবং মানটি 0.001 - 0.2 এর মধ্যে সামঞ্জস্য করুন।
   
4. প্রয়োগ করুন ক্লিক করুন
5. সংরক্ষণ করুন ক্লিক করুন

নোট: 

• যদি বর্স্টিনেস আগে Cato সাপোর্ট দ্বারা সমঞ্জসিত হয়েছিল, তাহলে ডিফল্ট 0.2 মানের পরিবর্তে সমঞ্জসিত মান প্রদর্শিত হবে।
• বর্স্টিনেস মানগুলি শুধুমাত্র সকেট সাইটগুলির জন্য সমন্বয় করা যেতে পারে।
• Cato ম্যানেজমেন্ট অ্যাপ্লিকেশনে সবচেয়ে ছোট ডেটা বালতি 5 সেকেন্ডের, মাইক্রো-বার্স্টগুলি সবচেয়ে ছোট ডেটা বালতিতে স্বাভাবিক করা হয় এবং সাধারণত চিহ্নিত করা কঠিন হয়।

• যে সাইটগুলির ব্যান্ডউইথ 10 Mbps এবং নীচে রয়েছে তাদের জন্য বারস্টনেস মান 0.001 এ সেট করা সুপারিশ করা হয় না, কারণ এটি সাইটটির জন্য সংযোগ সমস্যা সৃষ্টি করতে পারে।