Junos L2VPN: আগে গ্রাহকের সংযুক্তি চুক্তিটি ঠিক করুন

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

ফ্রেম চুক্তিটি লিখে রাখুন

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

এটি পরিষেবা নোটে লিখুন, টিকিটের মন্তব্যে নয়। ছয় মাস পরে এটি ডিবাগ করবে যে ব্যক্তি নোটটি পড়বে। টিকিট সে পড়বে না।

এনক্যাপসুলেশন চুক্তির সাথে মিলিয়ে নিন

এক ট্যাগের পরিষেবা সাধারণত VLAN সার্কিট এনক্যাপসুলেশন ব্যবহার করে, যেমন vlan-ccc, অন্যদিকে ট্যাগবিহীন ফ্রেমের জন্য সাধারণ Ethernet সার্কিট রূপ দরকার এবং স্ট্যাকের জন্য দুটি ট্যাগ বোঝে এমন বর্ধিত রূপ দরকার। যে প্ল্যাটফর্ম প্রতি-ইউনিট পরিষেবা এনক্যাপসুলেশন সমর্থন করে, সেখানে একটি ফিজিক্যাল ইন্টারফেস একসাথে কয়েকটিকে হোস্ট করতে পারে, যা সুবিধাজনক এবং ফ্রেমটি ভুল ইউনিটে পৌঁছানোর পথও সেটাই। যেখানে আপনার প্ল্যাটফর্মের গাইড family ccc, এটিকে সম্পূর্ণ সংযুক্তির অংশ হিসেবে কনফিগার করুন, রাউটেড ইন্টারফেসে আটকাবেন না। এনক্যাপসুলেশন গাইড কোন সংযুক্তি ধরন কোন প্রয়োজনীয়তা আরোপ করে তা তালিকাভুক্ত করে।

সতর্কতামূলকভাবে প্রতিটি ইন্টারফেসে family বিবৃতি যোগ করবেন না। যে কনফিগারেশন একটি সার্কিট চালায় তা পরেরটিকে এমন ফ্রেম গ্রহণ করতে বাধ্য করতে পারে যা তার গ্রাহক কখনো পাঠায় না।

সংযুক্তিকে সঠিক পরিষেবার সাথে বাঁধুন

BGP দিয়ে সিগন্যাল করা লেয়ার 2 VPN, LDP দিয়ে সিগন্যাল করা সার্কিট এবং অন্যান্য সমর্থিত পরিষেবার প্রতিটির নিজস্ব ইন্টারফেস বাইন্ডিং ও সিগন্যালিং কনফিগারেশন আছে, এবং সেগুলো একে অপরের বিকল্প নয়। একটির সংযুক্তি শৈলী অন্যটির সিগন্যালিংয়ের সাথে মেশালে এমন সার্কিট তৈরি হয় যা পিয়ারের রিপোর্ট দেয় এবং কখনো ফ্রেম বহন করে না।

দূরের প্রান্তকে কাছের প্রান্তের সাথে তুলনা করুন, কোনোটিকেই আলাদা করে দেখবেন না: পিয়ার ঠিকানা, পরিষেবা শনাক্তকারী, এনক্যাপসুলেশন সম্মতি, control word প্রত্যাশা এবং আকার বাজেট। নিচের MPLS স্তর পুরোপুরি সুস্থ থাকতে পারে যখন সংযুক্তি অনুপস্থিত বা অন্যত্র শ্রেণিবদ্ধ, তাই কেবল নিচের স্তর দেখে এমন পরীক্ষা এখানে কিছুই প্রমাণ করে না।

ফ্রেম দিয়ে যাচাই করুন, অবস্থা দিয়ে নয়

গ্রাহক ট্রাফিক পাঠানোর সময় স্থানীয় ইন্টারফেসের কাউন্টার পড়ুন, তারপর পরিষেবার অবস্থা, এবং তারপর নিশ্চিত করুন যে আসা ফ্রেমটি সেই সম্মত ফ্রেম, তার ট্যাগসহ। মেরামত করা সংযুক্তি সেই ফ্রেম পৌঁছায়; কেবল অবস্থার পরিবর্তন কিছুই প্রমাণ করে না।

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

তারপর এটি লিখে রাখুন

পরিষেবা নোটে চারটি মান নথিভুক্ত করুন: চুক্তি, এনক্যাপসুলেশন, ইউনিট এবং পরিষেবা বাইন্ডিং। এই চারটিই নতুন ইঞ্জিনিয়ারের প্রয়োজন এবং কনফিগারেশন পর্যালোচনা যা খুব কমই স্পষ্ট করে বলে।

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