pseudowire প্রান্তবিন্দুতে VLAN ট্যাগ স্বাভাবিক করা: একটি রানবুক
প্রতিটি গ্রাহক প্রান্ত কী ফ্রেম পাবে তা ঠিক করুন, তারপর pop, push বা swap স্থানীয়ভাবে প্রয়োগ করুন। MTU বাজেটে MPLS স্ট্যাক ও control word অন্তর্ভুক্ত করুন।
pseudowire স্পর্শ করার আগে প্রতিটি গ্রাহক প্রান্ত কী ফ্রেম পাবে তা নির্ধারণ করুন। সরল ক্ষেত্রে CE A সেবা-সীমায়ক একটি ট্যাগ পাঠায় এবং CE B ট্যাগবিহীন ফ্রেম প্রত্যাশা করে, আর এই পার্থক্য প্রোভাইডার প্রান্তেই সমাধান হয়। ট্যাগ স্থানীয় নীতি, গ্রাহকের Ethernet চুক্তির অংশ নয়, এবং pseudowire মূল ফ্রেমের বদলে সম্মত ফ্রেম বহন করে। যেকোনো কনফিগারেশনের আগে দুই দিকই লিখে রাখুন।
আগে ফ্রেম চুক্তি লিখুন
সামনের দিক একটি ট্যাগ সরায় এবং ফিরতি দিক তা আবার যোগ করে। যদি আপনি এর মধ্যে কেবল একটি লেখেন, তবে আপনি এক দিকে কাজ করা পথ পরীক্ষা করবেন এবং সার্কিটকে সুস্থ ঘোষণা করবেন।
চুক্তিটি এত ছোট রাখুন যে পরিবর্তন টিকিটে পেস্ট করা যায়: কোন প্রান্ত ট্যাগসহ পাঠায়, কোনটি ট্যাগবিহীন প্রত্যাশা করে এবং কোন ট্যাগ মান সেবা-সীমায়ক।
pseudowire মোডে একমত হোন
RFC 4448 raw ও tagged pseudowire মোডের মধ্যে পার্থক্য করে এবং সেবা-সীমায়ক ট্যাগ কীভাবে হ্যান্ডেল হয় তা বর্ণনা করে। raw মোড এখনও গ্রাহক ফ্রেমের অন্তর্গত ট্যাগ বহন করতে পারে, তাই পার্থক্যটি ট্যাগের সেবা-ভূমিকা নিয়ে, শুধু 802.1Q হেডারের উপস্থিতি নিয়ে নয়। মোডকে tagged বনাম untagged পড়া এই কাজের পরিধি ভুলভাবে নির্ধারণের সবচেয়ে সাধারণ উপায়। কোন অপারেশন দরকার তা ঠিক করার আগে সঙ্গীর সঙ্গে মোডে একমত হোন।
তারপর প্রকৃত pseudowire ধরন ও সঙ্গীর প্যারামিটার যাচাই করুন। স্থানীয় VLAN অ্যাটাচমেন্ট এবং দূরবর্তী পোর্ট অ্যাটাচমেন্টের জন্য সমর্থিত interworking ব্যবস্থা প্রয়োজন, আর দুটি স্থানীয় রিরাইট বিবৃতি প্রমাণ করে না যে ঘোষিত সার্কিট ধরন মিলে যায়।
যদি control word ও MTU-এর প্রত্যাশা ভিন্ন হয়, তবে আপনার কাছে আলোচনার সমস্যা আছে যা কোনো রিরাইট ঠিক করবে না। দুটিরই নিশ্চিতকরণ ডিজাইন নথির বদলে সঙ্গীর চলমান কনফিগারেশন থেকে করুন।
স্থানীয় ট্যাগ অপারেশন প্রয়োগ করুন
Juniper-এর VLAN CCC রিরাইট গাইড pop, push ও swap অপারেশন প্ল্যাটফর্ম-নির্দিষ্ট সীমাবদ্ধতাসহ নথিভুক্ত করে। আগে থেকেই কনফিগার করা সামঞ্জস্যপূর্ণ tagged ইউনিটের জন্য উদাহরণ দিক ingress-এ input-vlan-map pop এবং egress-এ output-vlan-map push। ওই লাইনগুলি অপারেশন দেখায়, সম্পূর্ণ ইন্টারফেস বা সার্কিট কনফিগারেশন নয়। একই ডিভাইস পরিবারের উদাহরণ সর্বত্র প্রয়োগ করার বদলে সঠিক প্ল্যাটফর্ম ও রিলিজ নিশ্চিত করুন।
ইউনিটের সমর্থিত VLAN ও encapsulation সেটিংসকে এখনও অভীষ্ট ট্যাগ ও শ্রেণিবিন্যাস সংজ্ঞায়িত করতে হবে। ভুল ফ্রেম শ্রেণিবদ্ধ করা ইউনিটে রিরাইট বিবৃতি সমস্যাটি সমাধান করে না, স্থানান্তর করে।
সেবার জন্য প্রয়োজনীয় যেকোনো অভ্যন্তরীণ গ্রাহক ট্যাগ সংরক্ষণ করুন। স্ট্যাক করা ট্যাগে, কিছু সরানোর আগে নির্ধারণ করুন আপনি কোন বহিঃস্থ ট্যাগ পরিবর্তন করছেন।
আকারের বাজেট করুন, কেবল ট্যাগের নয়
আকার বাজেটে রাখা ট্যাগ, প্রকৃত MPLS স্ট্যাক ও control word অন্তর্ভুক্ত করুন। RFC 8469 Ethernet pseudowire-এর জন্য control word সুপারিশ করে, এবং এই সুপারিশ ফ্রেম বাজেট বদলে দেয়, আপনার প্ল্যাটফর্ম এটি ডিফল্টভাবে সক্ষম করুক বা না করুক। MTU অমিল মিটমাট করুন, এর সতর্কতা মেরামত হিসেবে দমিয়ে দেওয়ার বদলে। দমিয়ে দেওয়া সতর্কতা হলো তারিখ মুছে ফেলা পরিকল্পিত বিভ্রাট।
উভয় প্রোভাইডার প্রান্তে একই বাজেট যাচাই করুন, কারণ এক পক্ষের ট্যাগ ও অপরটির control word যোগ করা আগে ঠিক থাকা পেলোড ভাঙার জন্য যথেষ্ট।
যদি সংখ্যাগুলি না মেলে, পরিকল্পনা বদলান, লগিং স্তর নয়।
এটি ফ্রেম ধরে ধরে গ্রহণ করুন
স্বীকৃতির জন্য, প্রতিটি গ্রাহক অ্যাটাচমেন্টে প্রত্যাশিত ফ্রেম দুই দিকেই পরীক্ষা করুন। তারপর সেবার সত্যিই প্রয়োজনীয় অ্যাপ্লিকেশন ও নিয়ন্ত্রণ ট্রাফিক অনুমোদিত পরীক্ষা পরিকল্পনা অনুযায়ী চালান, কারণ ping অক্ষতভাবে পৌঁছানো tagged ফ্রেমের চেয়ে অনেক কম প্রমাণ করে। ingress ও egress-এর ফ্রেম চুক্তি সার্কিটের কনফিগারেশনের সঙ্গে নথিভুক্ত করুন। এই রেকর্ডই পরবর্তী পরিবর্তনকে পর্যালোচনাযোগ্য করে।
মোড, ট্যাগ অপারেশন, MTU বাজেট ও পরীক্ষার ফলাফল এক জায়গায় রাখুন, কারণ এদের অর্থ কেবল একসঙ্গেই। এগুলি তিনটি টিকিটে ভাগ করা নিশ্চিত করে যে পরবর্তী প্রকৌশলী একই সীমাবদ্ধতা আবার আবিষ্কার করবেন।
সার্কিট তখন সম্পূর্ণ হয় যখন দুই দিকই আপনি শুরুতে লেখা চুক্তির সঙ্গে মেলে, তখন নয় যখন প্রথম দিক পাস করে।