দুই গ্রাহকের জন্য একই /24? VPNv4-এর জন্য RD ও লেবেল দরকার
দুই টেন্যান্ট একই /24 ঘোষণা করতে পারে কেবল এই কারণে যে RD প্রতিটি রুটকে নিজস্ব পরিচয় দেয়। লেবেল অন্য প্রশ্নের উত্তর দেয়: কীভাবে ফরওয়ার্ড করতে হবে।
দুই টেন্যান্ট তাদের শাখা 10.50.0.0/24 দিয়ে নম্বর দেয়, এবং একটি পরিবর্তনের পর একজনের রুট প্রোভাইডার এজ থেকে হারিয়ে যায়, অন্যজন কাজ করতে থাকে। ওই টিকিটের পেছনের সরলীকরণটি সাধারণত রুট ডিস্টিংগুইশার (RD) বাদ দেওয়া, কারণ "লেবেলই ইতিমধ্যে গ্রাহককে চিহ্নিত করে"। তা করে না। RD ও লেবেল দুটি আলাদা প্রশ্নের উত্তর দেয়, এবং এই ফাঁক কেবল তখনই দৃশ্যমান হয় যখন ওভারল্যাপিং ঠিকানা তা বাধ্য করে।
যেখানে দুটি থাকা উচিত সেখানে একটি রুট
সাধারণ IPv4 ইউনিকাস্ট একই প্রিফিক্সের দুটি পথ তুলনা করে এবং ভালোটি ইনস্টল করে। টেন্যান্ট A থেকে 10.50.0.0/24 এবং টেন্যান্ট B থেকে 10.50.0.0/24 একই কী, তাই একটি জেতে আর অন্যটি কেবল ব্যাকআপ পথ হিসেবে টিকে থাকে। প্রোটোকল যা বলা হয়েছিল তাই করেছে; কন্ট্রোল প্লেনকে একই শনাক্তকারীর অধীনে দুটি ভিন্ন রুট সংরক্ষণ করতে বলা হয়েছিল।
ফলাফলটি ত্রুটির বদলে হারানো রুটের মতো দেখায়: যে PE প্রতিযোগিতায় হেরেছে সে এখনও নিজের টেন্যান্টকে লোকালি ফরওয়ার্ড করে, তাই সাইটের ভেতরের পিং সফল হয় আর সাইটের মধ্যে পরীক্ষাটি ব্যর্থ হয়। কোনো পলিসিতে হাত দেওয়ার আগে VPNv4 টেবিলে ওই প্রিফিক্সের এন্ট্রিগুলো গুনুন।
RD একটি কী-কে দুইয়ে পরিণত করে
আট বাইটের রুট ডিস্টিংগুইশার IPv4 প্রিফিক্সের সামনে যোগ হয়, এবং BGP যে অবজেক্ট বহন করে তা IPv4 প্রিফিক্সের বদলে VPN-IPv4 ঠিকানা হয়ে যায়। দুই টেন্যান্ট একই 32 বিট রাখতে পারে কারণ সামনের 64 বিট আলাদা। AS-ভিত্তিক RD এবং ঠিকানা-ভিত্তিক RD-এর জন্য ফরম্যাট টাইপ আছে, এবং পছন্দটি উৎস PE-এর। PE-গুলো একই AS ভাগ করলে AS-ভিত্তিক RD সাধারণ, না ভাগ করলে ঠিকানা-ভিত্তিক RD।
RD-কে সদস্যপদের ট্যাগ হিসেবে পড়বেন না. রুট টার্গেট আমদানি ও রপ্তানি নিয়ন্ত্রণ করে এবং কোন VRF রুটটি ইনস্টল করতে পারবে তা নির্ধারণ করে; RD শুধু নিশ্চিত করে যে রুটটির নিজস্ব পরিচয় আছে। প্রতিটি VRF-কে নিজস্ব RD দেওয়া সাধারণ রীতি, কারণ এটি ওই ম্যাপিংকে রুট টেবিলে সহজে পড়ার যোগ্য রাখে।
লেবেল হলো স্থানীয় ফরওয়ার্ডিং নির্দেশ
প্রতিটি ঘোষণা একটি MPLS লেবেলও বহন করে, আর তার অর্থ সেই রাউটারের মধ্যে সীমাবদ্ধ যা সেটি বরাদ্দ করেছে। অন্য একটি PE অসংশ্লিষ্ট গন্তব্যের জন্য একই নম্বর দিতে পারে। এ কারণেই লেবেল গ্রাহকের পরিচয়ের বিকল্প হতে পারে না: নম্বরটি কেবল পরবর্তী হপ ও যে ফরওয়ার্ডিং অবস্থা এটি ইনস্টল করেছে তার পাশেই সঠিক।
বরাদ্দের দানাগ্রিকতা বাস্তবায়ন ও নকশা অনুযায়ী বদলায়: কিছু প্ল্যাটফর্ম প্রতি VRF-এ একটি লেবেল দেয়, অন্যরা প্রতি প্রিফিক্সে, এবং লেবেল গ্রাহককে নয় বরং একটি ফরওয়ার্ডিং ক্রিয়া চিহ্নিত করতে পারে। একই গন্তব্যে পৌঁছানো দুটি ভিন্ন লেবেল কোনো বিরোধ নয়, এবং দুটি PE-তে একই লেবেল নম্বরও নয়।
| Field | Where it lives | Scope | If you remove it |
|---|---|---|---|
| RD | VPNv4 NLRI | Per advertised route | Overlapping prefixes collide |
| Route target | Extended community | Import and export policy | Route lands in the wrong VRF |
| Label | Labeled NLRI and forwarding state | Per allocating router | No instruction for the data plane |
| Next hop | Path attribute | Per path | The label cannot be resolved |
কেন একটি অন্যটির বিকল্প হতে পারে না
একটি ঘোষণা পড়া মানে চারটি জিনিস একসাথে দেখা: RD-যোগ্য প্রিফিক্স, রুট টার্গেট, পরবর্তী হপ এবং লেবেল। ব্যবহারকারীর প্যাকেট পড়া মানে ওই তথ্য থেকে ইনস্টল করা স্ট্যাকটি দেখা। সুস্থ নকশায় দুই পক্ষ মিলে যায়, আর নষ্ট নকশায় সাধারণত এক পক্ষ সঠিক ও অন্য পক্ষ পুরনো থাকে। এই তুলনাই পরিচয়ের সমস্যাকে ফরওয়ার্ডিং সমস্যা থেকে আলাদা করে।
কন্ট্রোল প্লেন ও ডেটা প্লেনের মধ্যে পরিচ্ছন্ন বৈপরীত্য একটি শিক্ষণ কৌশল, এনকোডিংয়ের বর্ণনা নয়। RFC 8277 লেবেলটিকে লেবেলযুক্ত NLRI-এর ভেতরে রাখে, তাই ঘোষণাটি নিজেই বাইন্ডিংটি বহন করে; এটিকে ফরওয়ার্ডিংয়ে ব্যবহার করা পরের, আলাদা ধাপ।
কোনো টেন্যান্টের রুট হারালে এই ক্রমে যাচাই করুন: প্রিফিক্সের জন্য দুটি VPNv4 এন্ট্রি, প্রতিটিতে সঠিক রুট টার্গেট, সমাধানযোগ্য পরবর্তী হপ, এবং এমন লেবেল যার জন্য গ্রহণকারী PE-এর অবস্থা আছে। পরিচয় ঠিক করা ফরওয়ার্ডিং মান দিয়ে, বা তার বিপরীত, একটি পরীক্ষায় পাশ করবে আর পরেরটিতে ব্যর্থ হবে।