VPN গেটওয়ে পোর্টে ডুপ্লেক্স মিসম্যাচ: দুই প্রান্তই পড়ুন

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

পোর্ট থেকে নয়, বিরতি থেকেই শুরু করুন

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

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

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

দুই প্রান্তের অপারেশনাল মোড পড়ুন

সংরক্ষিত কনফিগারেশন অপারেশনাল অবস্থা নয়। একটি পোর্ট অটোনেগোশিয়েশনের জন্য কনফিগার হয়ে শেষ পর্যন্ত হাফ ডুপ্লেক্সে পৌঁছাতে পারে, অথবা এমন একটি নির্দিষ্ট গতিতে কনফিগার হতে পারে যা অন্য প্রান্ত কখনো মেনে নেয়নি। লিংকটি এখন দুই দিকে কী করছে তা পড়ুন।

ethtool eth0
ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0

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

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

10/100 হাফ ডুপ্লেক্স অবস্থাটি কেমন দেখায়

10/100 কপার লিংকে, অটোনেগোশিয়েটিং প্রান্ত একটি জোরপূর্বক দেওয়া সহকর্মীর গতি শনাক্ত করতে পারে কিন্তু তার ডুপ্লেক্স সেটিং জানতে পারে না। প্যারালেল ডিটেকশন সিগন্যাল থেকে গতি নির্ধারণ করে, আর ডুপ্লেক্স সমঝোতা না করে ধরে নেওয়া হয়, ফলে এক দিক হাফ ডুপ্লেক্সে থেকে যেতে পারে, আর অন্যটি ফুল ডুপ্লেক্সে চলে।

Cisco-র অটোনেগোশিয়েশন নির্দেশিকা ঠিক সেই ঘটনাটিই ব্যাখ্যা করে। এটি সর্বত্র নেগোশিয়েশন বন্ধ করার পক্ষে যুক্তি নয়, আর গিগাবিট কপার সম্পর্কে এটি কিছুই কাজের কথা বলে না, যেখানে ডুপ্লেক্স নির্দিষ্ট এবং লিংক আদৌ চালু হতে অটোনেগোশিয়েশন বাধ্যতামূলক।

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

দুই প্রান্ত একসাথে বদলান, ফেরার পথ রেখে

ডুপ্লেক্স সংশোধন একটি সমন্বিত পরিবর্তন, স্থানীয় নয়। দূর প্রান্তের সম্মতি ছাড়া নিজের দিক জোর করা হলো একটি সচল লিংককে ভাঙা লিংকে পরিণত করার উপায়, আর CLI কমান্ডটি গ্রহণ করা কেবল প্রমাণ করে সিনট্যাক্স বৈধ ছিল।

sudo ethtool -s eth0 speed 100 duplex full autoneg off
ethtool eth0

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

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

নিশ্চিত করুন কাউন্টারগুলো ভালোর দিকে সরেছে

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

ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0
ping -f -c 200 10.90.0.1

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

টিকিটে টাইমস্ট্যাম্পসহ আগের ও পরের সংখ্যাগুলো লিখুন। সেই রেকর্ডই «VPN ভালো লাগছে» কথাটিকে এমন কিছুতে বদলে দেয় যার উপর পরের ইঞ্জিনিয়ার দাঁড়াতে পারেন।