কেন QFX-এর MAC EVPN-এ দেখা যায় কিন্তু ফরওয়ার্ডিং টেবিলে দেখা যায় না

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

দুটি টেবিল, দুটি ভিন্ন প্রশ্নের উত্তর

Junos EVPN-এ ডেটাবেসটি প্রতি ইনস্ট্যান্সে MAC ঠিকানা তালিকাভুক্ত করে এবং প্রতিটি কীভাবে এসেছে তাও দেখায়: অ্যাক্সেস পোর্ট থেকে শেখা, Type 2 রুটে গৃহীত, বা মাল্টিহোমিং গ্রুপের অংশ হিসেবে চিহ্নিত। Juniper-এর show evpn database রেফারেন্স দেখাটিকে পাঠযোগ্য করে তোলা প্রতি-MAC ও প্রতি-ইনস্ট্যান্স ফিল্টারগুলো কভার করে। এটি ইনস্ট্যান্স ও MAC দিয়ে চাবিকৃত একটি কন্ট্রোল-প্লেন সারাংশ, হার্ডওয়্যার যে টেবিল দিয়ে ফ্রেম সুইচ করে সেটি নয়।

সুইচিং টেবিল হলো সেই ফরওয়ার্ডিং স্টেট। উভয় আউটপুটই MAC-এর পাশে VLAN বা VNI প্রসঙ্গ তালিকাভুক্ত করে, ঠিক এ কারণেই সেগুলো লাইন ধরে ধরে তুলনা করা হয়, আর ঠিক এ কারণেই তুলনাটি বিভ্রান্তিকর। ডেটাবেসের একটি এন্ট্রি বলে রুটটি আছে এবং ইনস্ট্যান্সে গৃহীত হয়েছে; প্ল্যাটফর্ম সেটি ফরওয়ার্ডিংয়ের জন্য ইনস্টল করেছে কি না, সে সম্পর্কে এটি কিছুই বলে না।

একটি Type 2 রুট MAC, একটি ঐচ্ছিক IP, একটি লেবেল বা VNI, একটি রুট ডিস্টিংগুইশার এবং দূরের VTEP-এর নাম বলা একটি নেক্সট হপ বহন করে। তার থেকে সেই রুট পর্যন্ত চারটি জিনিস ভাঙতে পারে: হোস্ট কখনো শেখা হয় না, রুট কখনো বিজ্ঞাপিত হয় না, ইমপোর্টে এটি প্রত্যাখ্যাত হয়, অথবা এর নেক্সট হপ মীমাংসা হয় না। প্রতিটি ব্যর্থতা ভিন্ন একটি টেবিল-সমষ্টি ভরা রেখে যায়, আর এ কারণেই ক্রমটি আদৌ নির্ণয় করা সম্ভব।

স্থানীয় শিক্ষণ এখনো আগে ঘটে

সাধারণ ধারণা হলো EVPN MAC শিক্ষণ নিজে নেয়, তাই খালি ডেটাবেস মানে ওভারলে সমস্যা। স্থানীয় শিক্ষণ এখনো অ্যাক্সেসের দিকে চলে, VXLAN-এর আগেও যেমন চলত: সুইচটি একটি অনুমোদিত ফ্রেমের সোর্স MAC সঠিক VLAN ও সার্ভিসে শেখে, এবং কেবল তারপরই তার জন্য একটি Type 2 তৈরি করে। যে হোস্ট প্রাসঙ্গিক কোনো ফ্রেম পাঠায়নি, তার বিজ্ঞাপন দেওয়ার কিছু নেই। যে হোস্টের ফ্রেম VLAN সদস্যতা, ফিল্টার বা অ্যাগ্রিগেটের একটি ডাউন সদস্য দ্বারা বাদ পড়ে, ওভারলের দৃষ্টিতে সে একই রকম দেখায়।

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

show interfaces ge-0/0/1.0
show ethernet-switching interface ge-0/0/1.0
show lacp interfaces ae0

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

দূরের MAC কোথায় হারায়

দূরের MAC উল্টো দিকে ব্যর্থ হয়, আর নীরবে। Type 2 রুটটি আসে, কিন্তু এটি একটি ইনস্ট্যান্সে ঢোকে কেবল তখনই যখন তার রুট টার্গেট ও VNI স্থানীয় কনফিগারেশনের সঙ্গে মেলে, এবং ব্যবহারযোগ্য হয় কেবল তখনই যখন নেক্সট হপ একটি পৌঁছানোযোগ্য VTEP-এ মীমাংসা হয়। রুট টার্গেটের অমিল BGP টেবিলে একটি বৈধ রুট রেখে যায়, যা কোনো ইনস্ট্যান্স কখনো চায় না।

তিনটি দৃশ্য ক্রমানুসারে পড়ুন: রুটের উপস্থিতি, ডেটাবেস এন্ট্রি, ফরওয়ার্ডিং এন্ট্রি। নিচের কমান্ডগুলো প্রতিটি ধাপে একই MAC জিজ্ঞাসা করে, আর নমুনা ঠিকানাটি আউটপুটগুলো তুলনাযোগ্য রাখে।

show evpn database instance blue mac-address 02:00:00:00:00:5c extensive
show route table bgp.evpn.0 | match 02:00:00:00:00:5c
show route table bgp.evpn.0 | match 02:00:00:00:00:5c extensive

সেই আউটপুটগুলো তিনটি আলাদা প্রশ্নের উত্তর দেয়। bgp.evpn.0-এ একটি রুট থাকলেও ডেটাবেস এন্ট্রি না থাকলে তা ইমপোর্ট পলিসি, রুট টার্গেট বা ইনস্ট্যান্স কনফিগারেশনের দিকে ইঙ্গিত করে। ডেটাবেস এন্ট্রি থাকলেও ফরওয়ার্ডিং এন্ট্রি না থাকলে তা প্ল্যাটফর্ম প্রোগ্রামিংয়ের দিকে ইঙ্গিত করে, যা ভিন্ন একটি এস্কেলেশন পথের অন্তর্গত। যে সক্রিয় রুটের নেক্সট হপ মীমাংসা হয় না, সেটি পরিবহন বা লেবেল সমস্যা, এবং MAC ডিবাগিংয়ের কোনো পরিমাণই তা সারায় না।

যে রিবুট এটি ঠিক করেছে, তা খুব কমই প্রমাণ করে

যখন একটি রিস্টার্ট লক্ষণটিকে মিলিয়ে দেয়, তখন লোভনীয় সিদ্ধান্ত হলো কনফিগারেশন নিশ্চয়ই ঠিক আছে। একটি রিবুট প্রতিটি টেবিল শূন্য থেকে পুনঃপ্রোগ্রাম করে, তাই এটি সেই ক্ষেত্রটিও ঢেকে দেয় যেখানে একটি পুরোনো এন্ট্রি পলিসি ত্রুটিকে ছায়া দিচ্ছিল; ত্রুটিটি সাধারণত পরের পরিবর্তন, লিঙ্ক ফ্ল্যাপ বা রুট প্রত্যাহারে ফিরে আসে।

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

show evpn database instance blue
show route table bgp.evpn.0
show version

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

চারটি পর্যবেক্ষণ, যা বেশিরভাগ ক্ষেত্রেই নিষ্পত্তি করে

চারটি পর্যবেক্ষণ প্রায় প্রতিটি ক্ষেত্রেই কাজে লাগে: অ্যাটাচমেন্ট ও তার সার্ভিস, নমুনা মান হিসেবে MAC, রুট ও ডেটাবেসের অবস্থা, এবং ব্যবহৃত বিল্ড। এমন একটি MAC বেছে নিন যা স্পষ্টতই নমুনা, যাতে কেউ এটিকে প্রোডাকশন ঠিকানা ভুল না করে: প্রথম অক্টেট 02 স্থানীয়ভাবে পরিচালিত ইউনিকাস্ট ঠিকানা বোঝায়, বাকি অক্টেটগুলো মুক্ত, তাই 02:00:00:00:00:5c একটি নিরাপদ প্লেসহোল্ডার।

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