কেন একটি AWS VGW সাবনেট রুট একটি VPN টানেল বেছে নিতে পারে না

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

দুটি স্তর এখানে জড়িত: VPC রুট যা বলে কোন গেটওয়ে, এবং গেটওয়ের নিজের টানেল বাছাই। এ দুটিকে গুলিয়ে ফেললে এমন সম্পাদনা তৈরি হয় যা রুট টেবিলে সঠিক দেখায় কিন্তু একটি প্যাকেটও সরায় না।

একটির মতো দেখতে দুটি স্তর

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

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

VGW আসলে কী তুলনা করে

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

একই প্রিফিক্সের যোগ্য পথগুলির মধ্যে AWS ছোট AS_PATH পছন্দ করে। দুটি পথ দৈর্ঘ্যে সমান হলে এটি MED তুলনা করে, পথের প্রথম AS সম্পর্কে নথিভুক্ত শর্ত সাপেক্ষে। প্রচলিত গল্পের সংস্করণ নয়, প্রকাশিত ক্রমটিই পড়ুন, কারণ প্রচলিত গল্প সাধারণত স্বাস্থ্য ধাপটি এবং স্ট্যাটিক রুটের ব্যতিক্রমটি বাদ দেয়। একটি ফলাফল: ব্যাকআপ সংযোগে তিনটি প্রিপেন্ড প্রাইমারিকে কঠোরভাবে ছোট করে তোলে, আর অগ্রাধিকার প্রকাশের স্বাভাবিক উপায় সেটিই।

প্রিপেন্ডিং, আর কখন তা কিছুই করে না

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

পরিবর্তনের পরে AWS-এর দিকে পাওয়া পথটি যাচাই করুন। যে প্রিপেন্ড কদায়ই কাস্টমার ডিভাইস ছাড়ে যায়নি, তা AWS যে উপেক্ষা করেছে তার মতোই দেখায়।

স্ট্যাটিক রুট পুরো যুক্তটিই উপেক্ষা করে

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

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

কেন ট্রানজিট গেটওয়ে ভিন্ন উত্তর

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

পদ্ধতির আগে মডেল বেছে নিন: নির্দিষ্ট অগ্রাধিকারসহ অ্যাক্টিভ ও স্ট্যান্ডবাই, অথবা ECMP-সহ অ্যাক্টিভ ও অ্যাক্টিভ।

সেট করার পরে কী যাচাই করবেন

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

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