এক VTEP-এ ECMP: VXLAN এনট্রপি কোথা থেকে আসে

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

রুট নিয়ন্ত্রণ করে পৌঁছানোযোগ্যতা; হ্যাশ নিয়ন্ত্রণ করে বিতরণ।

কিংবদন্তি: /32 মানে একটাই পথ

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

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

এনট্রপি কোথা থেকে আসতে হবে

দুই VTEP-এর মধ্যে বাইরের সোর্স ও গন্তব্য ঠিকানা স্থির থাকে, আর প্রচলিত স্থাপনায় UDP গন্তব্য পোর্ট 4789। কেবল ওই মানগুলো পড়া হ্যাশ স্থির ইনপুট দেখে এবং স্থির পথ ফিরিয়ে দেয়। বাইরের হেডারের কিছু একটা বদলাতে হবে, আর VTEP-ই সেই ডিভাইস যা তা বদলাতে পারে।

RFC 7348 এনক্যাপসুলেটেড ফ্রেমের ভেতরের ফিল্ড থেকে UDP সোর্স পোর্ট তৈরি করার পরামর্শ দেয়। তখন ভিন্ন ভিন্ন ভেতরের কথোপকথন ভিন্ন ভিন্ন বাইরের টুপল তৈরি করে, যা সাধারণ ট্রান্সপোর্ট হ্যাশকে কাজ করার মতো কিছু দেয়।

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

আসলে যে হ্যাশ পাচ্ছেন তা যাচাই করুন

অনুমান না করে মাপুন। এনক্যাপসুলেটেড ট্রাফিকের একটি নমুনা ধরুন এবং বাইরের সোর্স পোর্টগুলো দেখুন, তারপর ফলাফলটি ফরওয়ার্ডিং এন্ট্রি ও প্রতি-লিঙ্ক কাউন্টারের সঙ্গে মিলিয়ে দেখুন।

show ip route 10.255.0.5/32
show ip cef 10.255.0.5 internal
ip route show 10.255.0.5
tcpdump -ni eth0 -c 200 'udp port 4789' -vv

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

নমুনার আগে ও পরে কাউন্টার লিখে রাখুন, এবং আপলিঙ্ক ভাগ করে নেওয়া অসম্পর্কিত ট্রাফিক লক্ষ্য করুন, নইলে সংখ্যাগুলো হ্যাশের প্রাপ্যের চেয়ে খারাপ দেখাবে।

সমান বিতরণ কী বোঝায় না

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

একাধিক ফ্লোও দৈবক্রমে একই পরবর্তী হপে সংঘর্ষ করতে পারে। একটি ছোট নমুনা মারাত্মক বাঁকা দেখাতে পারে, অথচ হ্যাশ ঠিক তা-ই করছে যার জন্য তাকে কনফিগার করা হয়েছিল, আর লিঙ্ক ব্যর্থতা বা পথ-সেট পরিবর্তন প্রতিষ্ঠিত ফ্লোগুলোকে ট্রান্সফারের মাঝপথে সরিয়ে দিতে পারে।

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