কোর-এ VPNv4-এর কি MPLS দরকার? জরুরি নয়
BGP VPNv4 একটি রুট-বিতরণ প্রসঙ্গ নিয়ে আলোচনা করে, ফরওয়ার্ডিং পথ নয়। ইমপোর্ট, নেক্সট-হপ রিজলিউশন এবং আপনি যে এনক্যাপসুলেশন চালাতে পারেন তা আলাদা করুন।
দুটি রাউটারের মধ্যে VPNv4 অ্যাড্রেস ফ্যামিলি চালু করা কেবল একটি রুট-বিতরণ প্রসঙ্গ তৈরি করে, এর বেশি কিছু নয়। এটি কোনো ফরওয়ার্ডিং পথ ইনস্টল করে না, এবং কোন এনক্যাপসুলেশন গ্রাহক প্যাকেটকে দূরবর্তী এন্ডপয়েন্টে নিয়ে যাবে তা বলে না। এই দুই তথ্য আলাদা হয়ে গেলে, «কোর-এ কি MPLS দরকার» প্রশ্নটি প্ল্যাটফর্মের সমর্থিত ডেটা প্লেন সম্পর্কে সংকীর্ণ ও উত্তরযোগ্য প্রশ্নে পরিণত হয়।
অ্যাড্রেস ফ্যামিলি আসলে কী নিয়ে আলোচনা করে
মাল্টিপ্রোটোকল BGP, AFI 1 এবং SAFI 128-এর অধীনে VPNv4 নেটওয়ার্ক লেয়ার রিচেবিলিটি তথ্য বহন করে, এবং প্রতিটি এন্ট্রি একটি রুট ডিস্টিংগুইশারকে একটি প্রিফিক্স ও একটি লেবেলের সঙ্গে জোড়া দেয়। সেশনটি এই বিষয়ে সম্মত হয় যে উভয় পক্ষ সেই তথ্য এনকোড ও ডিকোড করতে পারে। যা নিয়ে এটি সম্মত হয় না তা হলো ডেটা প্লেন। এই অনুচ্ছেদের পরে সবকিছু ফরওয়ার্ডিং নিয়ে, এবং এর কোনোটিই সেশন চালু হওয়ার মাধ্যমে নির্ধারিত হয় না।
তাই একটি সফল সেশন নিয়ন্ত্রণ-প্লেন সক্ষমতার প্রমাণ, ফরওয়ার্ডিংয়ের নয়। একটি রাউটার হাজার হাজার VPNv4 এন্ট্রি ধরে রাখতে পারে এবং তবুও প্রতিটি গ্রাহক প্যাকেট ফেলে দিতে পারে; প্রথম থেকেই দুই ধরনের ব্যর্থতা গুলিয়ে ফেলার কারণ এটাই।
NLRI-তে লেবেলটি লক্ষ করুন। এটি একটি সার্ভিস লেবেল, VRF-এর ভিতরে একটি প্রিফিক্সের সঙ্গে বাঁধা, এবং প্যাকেটটি ইগ্রেস এন্ডপয়েন্টে পৌঁছালে এটির ফরওয়ার্ডিং ভূমিকা থাকে। কোনো ট্রানজিট ডিভাইস এটি পড়ে কি না, তা আলাদা নকশা সিদ্ধান্ত।
প্রাপ্তি, ইমপোর্ট ও ফরওয়ার্ডিং তিনটি ধাপ
একটি রুট পাওয়া, সেটি ব্যবহারের অনুমতি থাকা এবং সেটি দিয়ে ফরওয়ার্ড করতে পারা ডিভাইসের ভিন্ন ভিন্ন অংশ সম্পাদন করে। BGP যা শোনে তা সংরক্ষণ করে; ইমপোর্ট পলিসি ও রুট-টার্গেট মিল নির্ধারণ করে কোন VRF এটি বিবেচনা করতে পারে; এরপর ফরওয়ার্ডিং প্লেনকে বিজ্ঞাপিত নেক্সট হপকে এমন কিছুতে রিজলভ করতে হয় যা এটি সত্যিই তারে পাঠাতে পারে।
| Step in the chain | What has to be true | How it fails quietly |
|---|---|---|
| NLRI exchange | Both speakers negotiate the VPNv4 capability | Session stays up while the family is never activated |
| Import eligibility | A route target on the received route matches the VRF import policy | The route exists in the table but never enters the VRF |
| Next-hop resolution | The advertised next hop resolves to a usable tunnel or label path | Best path is selected, then marked unreachable or unusable |
| Encapsulation | The egress endpoint can decapsulate what the ingress produced | Packets arrive and are discarded for a format mismatch |
এই মধ্যম ধাপেই সবচেয়ে আশ্চর্যকর ব্যর্থতাগুলো বাস করে। একটি রুট BGP টেবিলে উপস্থিত, বৈধ এবং এমনকি সেরা হতে পারে, অথচ VRF রুট টেবিল খালি থাকে কারণ কোনো রুট টার্গেট ইমপোর্ট তালিকার সঙ্গে মেলেনি। কিছুই প্রোটোকল ত্রুটি লগ করে না, কারণ কোনো প্রোটোকল ত্রুটিই ঘটেনি।
শেষ ধাপেই প্ল্যাটফর্ম সমর্থন দেখা যায়। আন্ডারলে-এ পৌঁছানো একটি নেক্সট হপ স্বয়ংক্রিয়ভাবে VPN সার্ভিস ট্রান্সপোর্ট হিসেবে রিজলভ হয় না, এবং ডিভাইসটির একটি নির্দিষ্ট টানেল ধরন, একটি নির্দিষ্ট লেবেল অপারেশন বা উভয়ই প্রয়োজন হতে পারে। রিজলিউশন অবস্থা পড়া রুট সংখ্যা পড়ার চেয়ে বেশি তথ্যবহ।
একটি IP কোর এমন স্ট্যাক বহন করতে পারে যা এটি কখনো সুইচ করে না
যে পার্থক্যটি ধরে রাখা উচিত তা হলো «কোর MPLS চালায় না» এবং «সার্ভিসে কোথাও কোনো লেবেল নেই»-এর মধ্যে। এগুলো ভিন্ন দাবি, এবং কেবল প্রথমটি ট্রানজিট ডিভাইস সম্পর্কে বক্তব্য। RFC 4023 IP বা GRE টানেলের মাধ্যমে MPLS বহনকে সংজ্ঞায়িত করে, এবং এই প্রক্রিয়াই সম্পূর্ণ IP কোরে দ্বিতীয় দাবিটিকে সম্ভব করে।
customer packet + service label
encapsulated in GRE, addressed to the egress tunnel endpoint
forwarded by ordinary IP routers on the outer header
decapsulated at the endpoint, label still meaningfulট্রানজিট রাউটারগুলো বাইরের IP গন্তব্যে ফরওয়ার্ড করে এবং গ্রাহক প্রিফিক্স বা নেটিভ লেবেল সুইচিং কোনোটিই দরকার হয় না। দূর প্রান্তে বাইরের টানেল সরানো হয় এবং সার্ভিস লেবেল তার কাজ পুনরায় শুরু করে। কোরটি একটি অস্বচ্ছ পেলোড সরিয়েছে, যা ঠিক সেই কাজ যেখানে IP নেটওয়ার্ক দক্ষ।
এই নকশা আপনাকে যা দেয় না তা হলো একটি সর্বজনীন নিশ্চয়তা। এটি প্রমাণ নয় যে প্রতিটি রাউটার যেকোনো GRE ইন্টারফেসের উপর প্রতিটি VPNv4 নেক্সট হপ রিজলভ করে, এবং এটি কোনো কার্যকর নেটিভ MPLS কনফিগারেশন মুছে ফেলার কারণও নয়। এটি সর্বজনীন দাবির একটি প্রতিউদাহরণ, এবং ব্যবহারিক প্রশ্নটি প্ল্যাটফর্মের মধ্যেই সীমিত থাকে। সেই প্রশ্নটি প্রোটোকল নিয়ম নয়, প্ল্যাটফর্ম সীমাবদ্ধতা হিসেবে লিখে রাখুন।
বক্সে শিকলটি ভাঙা পর্যন্ত হাঁটুন
প্রাপ্ত রুট থেকে শুরু করুন এবং যে প্রথম ধাপটি ব্যর্থ হয় সেখানে থামুন, কারণ আগের ধাপ ভাঙা থাকলে পরের ধাপগুলো নির্ণয় করা যায় না। সাধারণ বাস্তবায়নে চারটি কমান্ড এর বেশিরভাগটাই কভার করে।
show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_Aসেগুলো চারটি স্বতন্ত্র পরীক্ষা নয়, একটি ক্রম হিসেবে পড়ুন। প্রথমটি নিশ্চিত করে ফ্যামিলিটি সক্রিয় এবং পিয়ার রুট বিনিময় করছে; দ্বিতীয়টি দেখায় প্রিফিক্সটি ব্যবহারযোগ্য নেক্সট হপ নিয়ে এসেছে কি না; তৃতীয়টি ইমপোর্ট যোগ্যতা প্রমাণ করে; চতুর্থটি দেখায় ফরওয়ার্ডিং প্লেন এটির সঙ্গে লেবেল বা টানেল বেঁধেছে কি না।
তারপর ওয়ার্কলোড পথটি দুই দিকেই পরীক্ষা করুন, এমন MTU দিয়ে যা এনক্যাপসুলেশন সহ্য করে। GRE হেডার বাইট যোগ করে, এবং ছোট প্রোব পেরোয় এমন পথ শুধু এক দিকেই পূর্ণ আকারের প্যাকেটে ব্যর্থ হতে পারে, যা ট্রান্সপোর্ট সমস্যার বদলে অ্যাপ্লিকেশন সমস্যার মতো দেখায়।
দুটি পরিচালনাগত নোট চক্রটি বন্ধ করে। GRE হলো এনক্যাপসুলেশন, গোপনীয়তা নয়, তাই অবিশ্বস্ত ট্রানজিট নেটওয়ার্কের অনুমানের বদলে উপরে একটি সমর্থিত নিরাপত্তা ব্যবস্থা দরকার। এবং নকশা পর্যালোচনার আগে প্ল্যাটফর্মটি আসলে কোন এনক্যাপসুলেশন সমর্থন করে তা লিখে রাখুন, কারণ সেই একক উত্তরই ঠিক করে শুধু-IP কোর বৈধ পছন্দ, নাকি ফরওয়ার্ড করতে অক্ষম পরিকল্পনা।