গ্রাহক জানালে VPN বন্ধ এবং পরিবহন দল জানালে টানেল ঠিক আছে—দুই দলই ঠিক হতে পারে। ট্রাফিক-ইঞ্জিনিয়ারড LSP আর MPLS L3VPN ভিন্ন প্রশ্নের উত্তর দেয়: একটি কোরের মধ্য দিয়ে লেবেলযুক্ত প্যাকেট সরায়, অন্যটি ঠিক করে প্যাকেটটি কার রাউটিং কনটেক্সটের। দুটোকে গুলিয়ে ফেললে বিতর্ক বৃত্তে ঘোরে, কারণ প্রতিটি পক্ষ ভিন্ন বস্তু মাপে আর দুটি মাপই বৈধ।

পরিবহন চালু আর সেবা বন্ধ হওয়া স্বাভাবিক অবস্থা

একটি LSP প্রতিষ্ঠিত থাকতে পারে, ট্রাফিক বহন করতে পারে এবং প্রতিটি মনিটরিং সিস্টেমে দেখা যেতে পারে, অথচ গ্রাহক সেবা অচল থাকে। এই সমন্বয়ে কোনো দ্বন্দ্ব নেই, কারণ দূরবর্তী প্রিফিক্স আছে কি না, ইমপোর্ট নীতি সেটি গ্রহণ করেছে কি না, বা সংযুক্তি সার্কিট ফ্রেম পার করছে কি না—এসব নিয়ে টানেলের কোনো মত নেই।

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

স্ট্যাককে দুটি দায়িত্ব হিসেবে পড়ুন

নিচের লেবেল সেবার আর উপরের লেবেল পথের। RFC 4364 ক্রমটি স্পষ্টভাবে বর্ণনা করে: প্রথমে VPN রুট লেবেল আরোপিত হয়, তারপর সেই লেবেলযুক্ত প্যাকেট BGP নেক্সট হপের দিকে টানেল করা হয়, আর সেখানেই ট্রাফিক-ইঞ্জিনিয়ারিং টানেল নিজের লেবেল উপরে চাপায়।

ObjectDecision it encodesWho owns it
Attachment and VRFWhich customer context receives the arriving packetEdge configuration
VPN route and service labelWhich remote forwarding context handles the destinationBGP VPN signalling
Transport LSP and tunnel labelHow the core carries the packet to the BGP next hopRSVP-TE or another tunnel mechanism

দূরের PE-তে সেবা লেবেল প্রক্রিয়াকরণ বেছে নেয়, যা VRF লুকআপ বা সংযুক্তি সিদ্ধান্ত হতে পারে। সেই লেবেলকে শুধু কোর পার করা লেবেল দিয়ে বদলানো যায় না, এবং দুটো বিনিময়যোগ্য নয়—একই ইন্টারফেসে একই স্ট্যাকে দুটোই দেখা গেলেও।

RSVP সফলতা কী প্রমাণ করে আর কী করে না

RSVP-TE সম্পদ সংরক্ষণসহ বা ছাড়া স্পষ্টভাবে রাউটকৃত LSP প্রতিষ্ঠা করে, যা কোরের মধ্য দিয়ে প্যাকেটের পথ সম্পর্কে একটি নির্দিষ্ট ও উপকারী নিশ্চয়তা। এটি গ্রাহক রুট সম্পর্কে কোনো বিবৃতি নয়, আর কনফিগার করা টানেল নাম আদৌ কোনো রুট নয়।

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

ক্রমানুসারে যাচাই করুন, তারপর থামুন

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

show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMER

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

একটি অনুমোদিত অনুরোধ অনুসরণ করুন এবং ভালো প্রমাণ রাখুন

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

পরে কোনো ধাপ ব্যর্থ হলে পরিবহন নতুন করে না বানিয়ে সফল LSP পর্যবেক্ষণটি সংরক্ষণ করুন। কার্যকর টানেল নতুন করে বানালে অনুপস্থিত দূরবর্তী প্রিফিক্স, ভুল VRF সংযুক্তি বা গন্তব্য অ্যাক্সেস নিয়ম মেরামত হয় না, বরং যে প্রমাণ প্রথমে বলেছিল পরিবহন সুস্থ, তা নষ্ট হয়।

সম্পর্কিত নিবন্ধ