EVPN-এর নীরব হোস্ট কখনও সমাধান হয় না: ARP ধরে বাইন্ডিং পর্যন্ত যান

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

পরবর্তী ARP বা ND বিনিময় অনুসরণ করুন

IPv4-এর জন্য অনুরোধকারী হোস্টের ARP বিনিময় লক্ষ্য করুন; IPv6-এর জন্য Neighbor Solicitation ও Advertisement অনুসরণ করুন। নিশ্চিত করুন যে অনুরোধটি অভীষ্ট লোকাল সেগমেন্ট ও অভীষ্ট VNI-তে প্রবেশ করছে, কারণ যে অনুরোধ কখনও সঠিক bridge domain-এ পৌঁছায় না, কোনো প্রক্সি তার উত্তর দিতে পারে না।

তারপর দেখুন fabric লক্ষ্য সম্পর্কে কী জানে। শুধু MAC-ভিত্তিক রুট একটি Layer 2 গন্তব্য শনাক্ত করতে পারে, অথচ প্রক্সির এখনও তার জন্য কোনো IP-to-MAC বাইন্ডিং নেই। এগুলো আলাদা রেকর্ড, এবং একটি পরীক্ষা করলে অন্যটি সম্পর্কে কিছুই জানা যায় না।

যদি বৈধ বাইন্ডিং থাকে, প্রক্সি তার নীতি অনুযায়ী উত্তর দিতে পারে, কিন্তু সেই বাইন্ডিংয়ের MAC-এর এখনও একটি সক্রিয় ফরওয়ার্ডিং পথ প্রয়োজন। যদি বাইন্ডিং না থাকে, তবে উত্তর থেকে কিছু শেখার আগে অনুরোধটিকে flooding বা replication পথ দিয়ে এন্ডপয়েন্টের সংযুক্তিতে পৌঁছাতে হবে।

দুটি রেকর্ড যা মিলতেই হবে

MAC রুট উত্তর দেয় Ethernet ঠিকানাটি কোথায় থাকে। প্রক্সি টেবিল উত্তর দেয় কোন IP কোন MAC-এ ম্যাপ হয়। যে হোস্ট সম্প্রতি কথা বলেনি, তার পুরোপুরি ভালো MAC রুট থাকতে পারে এবং কোনো ব্যবহারযোগ্য প্রক্সি এন্ট্রি না-ও থাকতে পারে, আর এটিই ঠিক সেই অবস্থা যা সুস্থ সংযুক্তিতে রেজলিউশন ব্যর্থতা তৈরি করে।

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

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

স্ট্যান্ডার্ডটি আসলে কী ধরে নেয়

RFC 9161 ডায়নামিক প্রক্সি লার্নিং এবং অজানা ARP ও ND অনুরোধের ডিফল্ট flooding বর্ণনা করে। সেই flooding-এর সম্পূর্ণ দমন কেবল এমন ডিপ্লয়মেন্টে সীমিত যাদের লার্নিং বা প্রভিশনিং অনুমান এটিকে নিরাপদ করে, যা বেশিরভাগ কনফিগারেশন গাইড যে শর্ত বোঝায় তার চেয়ে সংকীর্ণ।

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

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

রিফ্রেশ, এজিং ও স্ট্যাটিক বিকল্প

স্ট্যান্ডার্ডটি ডায়নামিক এন্ট্রি পুরোনো হওয়ার আগে সমর্থিত রিফ্রেশ প্রোব বর্ণনা করে। উত্তর সংশ্লিষ্ট bridge ও প্রক্সি অবস্থা রিফ্রেশ করে; উত্তর না এলে বৈধভাবেই অপসারণ ও রুট প্রত্যাহার হতে পারে। এটি কোনো বাগ নয় যা প্রতিটি টাইমার টেনে দমন করতে হবে।

এজিং টাইমার অনির্দিষ্টকাল বাড়ানো একটি দৃশ্যমান ব্যর্থতার বদলে একটি পুরোনো ব্যর্থতা কিনে দেয়: fabric এমন একটি অবস্থান বিজ্ঞাপন করে চলতে থাকে যা হোস্ট ছেড়ে গেছে। ইমপ্লিমেন্টেশনের নথিভুক্ত নিয়ন্ত্রণ ব্যবহার করুন এবং এমন আয়ু বাছুন যা এন্ডপয়েন্টের যুক্তিসঙ্গতভাবে কথা বলার প্রত্যাশিত হারের সঙ্গে মেলে।

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

পরবর্তী টিকিটের আগে কী রেকর্ড করবেন

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

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