MPLS L3VPN ল্যাব পিং করছে না? এই পাঁচটি হপ পরীক্ষা করুন

গ্রাহকের দুই রাউটার, এক জোড়া provider edge ডিভাইস এবং একটি পিং যা কোনো ত্রুটি বার্তা ছাড়াই মরে যায়। ছোট MPLS L3VPN ল্যাবে ত্রুটি প্রায় সবসময় পাঁচটি চেকপয়েন্টের একটিতে বসে, এবং প্রতিটির এমন কমান্ড আছে যা দেখায় নির্ভরতা কাজ করছে নাকি অনুপস্থিত। ভুল হলো প্রতিবার পিং ব্যর্থ হলে BGP পুনরায় চালু করা, নির্ভরতাগুলো ক্রমে পরীক্ষা করার বদলে। যদি আপনি সোজা VRF কনফিগারেশনে ঝাঁপ দেন, তাহলে দুই ডিভাইস দূরে অমীমাংসিত পরের হপ থেকে শুরু হওয়া সমস্যায় এক ঘণ্টা নষ্ট করতে পারেন।

তালিকাটি নিচ থেকে উপরে কাজ করুন। যে চেকপয়েন্ট পাস হয় তা পাস থাকে, এবং প্রথম ব্যর্থতাই ডিবাগ করার যোগ্য।

প্রথম চেকপয়েন্ট: PE-গুলো একে অপরকে পৌঁছায়

প্রতিটি PE-এর অন্য PE-র loopback-এ রুট দরকার, এবং সেই রুটকে বাস্তব কোনো কিছুর মাধ্যমে সমাধান হতে হবে। interior gateway protocol সেখানে যাওয়ার স্বাভাবিক পথ, তবে স্থির রুটও কাজ করে যতক্ষণ পুনরাবৃত্ত অনুসন্ধান কোনো জীবন্ত adjacency-তে নামে। IOS ধাঁচের ডিভাইসে, show ip route 10.0.0.2 এবং তারপর show ip cef 10.0.0.2 দেখায় prefix আছে কি না এবং তার পেছনে সমাধান করা adjacency আছে কি না। টেবিলে থাকা রুট, যার পেছনে adjacency নেই, তা পৌঁছানোযোগ্যতা নয়।

দুই দিকই পরীক্ষা করুন। অসমমিত IGP খরচ, ভুল পাশের passive interface বা loopback ফিল্টার করা distribute list প্রতিটি কেবল এক দিক ভাঙে, এবং এক দিকই সেশন মারতে যথেষ্ট। যদি loopback পিং করে কিন্তু BGP সেশন Active-এ দাঁড়িয়ে থাকে, তবে অন্য কিছু স্পর্শ করার আগে update source দেখুন।

দ্বিতীয় চেকপয়েন্ট: লেবেলের পথ আছে

দূরের loopback-এ IP রুট প্রমাণ করে না যে ট্রান্সপোর্ট লেবেল বসাবে। LDP ডিজাইনে নিশ্চিত করুন যে দূরের loopback-এর স্থানীয় ও দূরের বাইন্ডিং দুটোই আছে এবং বেরিয়ে যাওয়া লেবেল forwarding টেবিলে দেখা যায়। show mpls ldp bindings 10.0.0.2 32 লেবেলের জোড়া দেখায়, এবং show mpls forwarding-table 10.0.0.2 দেখায় line card আসলে কী বসাবে। যখন দ্বিতীয় কমান্ড কোনো লেবেল দেখায় না বা IP-তে ফিরে যায়, তখন ট্রান্সপোর্ট VPN ট্র্যাফিক ডিজাইন যেভাবে ধরে নেয় সেভাবে বহন করছে না।

এই পার্থক্য আসে কীভাবে MPLS forwarding state-কে গন্তব্য prefix থেকে আলাদা করে তা থেকে, যে মডেলটি RFC 3031-এ বর্ণিত। যদি আপনার ল্যাব LDP-র বদলে RSVP-TE বা BGP-সংলগ্ন লেবেল ব্যবহার করে, তবে সেই প্রক্রিয়ার নিজস্ব অবস্থা পরীক্ষা করুন; ধরে নেওয়া যে LDP প্রতিটি আন্ডারলে লেবেল বিতরণ করে, ভূতুড়ে বাগের পিছনে দৌড়ানোর সাধারণ উপায়। ভাঙা লেবেল পথ সাধারণত পরে এমন VPN রুট হিসেবে দেখা যায় যা আছে কিন্তু অকেজো।

তৃতীয় চেকপয়েন্ট: VPN রুট অক্ষত পৌঁছেছে

ঠিক গ্রাহক prefix-এর VPNv4 বা VPNv6 রুট দেখুন, সেশনের সারসংক্ষেপ নয়। show bgp vpnv4 unicast all 10.10.1.0/24 route distinguisher, দূরের PE-র loopback-এ সেট করা next hop এবং একটি লেবেল দেখানো উচিত। যদি prefix অনুপস্থিত থাকে, প্রথম সন্দেহভাজন হলো উৎস PE-তে export নীতি বা গ্রহণকারী PE-তে import নীতি, এবং route target-ই সাধারণ অপরাধী।

route target যাচাই BGP গ্রহণ থেকে আলাদা পড়ুন। রুট সঠিক next hop নিয়ে আসতে পারে এবং তবুও VRF-এ না নামতে পারে কারণ importtarget মেলে না। গ্রহণকারী PE-তে show ip route vrf CUSTOMER 10.10.1.0 সেই পরীক্ষা যা গুরুত্বপূর্ণ; BGP টেবিল কেবল প্রমাণ করে রুট নিয়ন্ত্রণ তল অতিক্রম করেছে।

চতুর্থ চেকপয়েন্ট: interface VRF-এর ভেতরে

route distinguisher ও route target সহ VRF সংজ্ঞা কোনো interface সেখানে স্থানান্তর করে না। CE-র দিকে থাকা interface-এর VRF বরাদ্দ দরকার, এবং show ip vrf interfaces বা show ip interface brief সেটি সঠিক instance-এর অধীনে তালিকাভুক্ত করা উচিত। এটিই সেই চেকপয়েন্ট যেখানে অনুলিপি করা কনফিগারেশন সবচেয়ে বেশি ভুল করে, কারণ VRF ব্লক সম্পূর্ণ দেখায় অথচ interface এখনো বিশ্বব্যাপী টেবিলে বসে আছে।

তারপর নিশ্চিত করুন যে PE স্থানীয় গ্রাহক prefix সেই VRF-এ শিখেছে এবং CE-র সংযোগের মাধ্যমে ফেরার রুট আছে। CE-তে PE-র দিকে নির্দেশ করা স্থির default ল্যাবের জন্য যথেষ্ট, যদি PE-র VRF-এ CE-র LAN পর্যন্ত রুট থাকে। যদি দুই ভাগের যেকোনো একটি অনুপস্থিত থাকে, পিং কোনো লেবেল বসার আগেই ব্যর্থ হয়।

পঞ্চম চেকপয়েন্ট: উত্তর ঘরে ফেরার পথ খুঁজে পায়

সামনের দিকে যাওয়া প্যাকেট এবং তারপর ফেরত আসা প্যাকেট অনুসরণ করুন, কারণ তারা আলাদা টেবিল ব্যবহার করে। প্রবেশ PE-তে গ্রাহক উৎস VRF-এর ভেতরে দূরের prefix-এ দূরের লেবেল নিয়ে সমাধান হওয়া উচিত। নির্গমন PE-তে গন্তব্য একই VRF-এর ভেতরে CE-র দিকে থাকা interface-এ সমাধান হওয়া উচিত। PE থেকে নিজেই পাঠানো পিং প্রমাণ নয়: এটি বিশ্বব্যাপী টেবিল বা অন্য উৎস ঠিকানা দিয়ে বেরোতে পারে, তাই ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 সেই পরীক্ষা যা চালানো উচিত।

হোস্টের ফায়ারওয়াল, reverse-path filtering এবং CE-র access তালিকা এখনো প্রযোজ্য। যদি সামনের পথ কাজ করে এবং উত্তর মরে যায়, সমস্যা ফেরার দিকের রুট বা ফিল্টারে, MPLS ট্রান্সপোর্টে নয়।

প্রতিটি চেকপয়েন্টের জন্য একটি লাইন রাখুন যা প্রথম ব্যর্থ নির্ভরতার নাম দেয়। সেই লাইন গ্রাহকের পিং করতে না পারার অভিযোগকে পৌঁছানোযোগ্যতা, লেবেলের অবস্থা, রুট আমদানি, interface-এর সদস্যতা বা ফেরার পথ নিয়ে সুনির্দিষ্ট প্রশ্নে বদলে দেয় এবং পরের ডিবাগ সেশনকে একই পাঁচ কমান্ড একই ক্রমে পুনরাবৃত্তি করা থেকে বিরত রাখে।