NX-OS EVPN নাল রুট: বর্জন একটি টেন্যান্টের ভিতরেই রাখুন

অনুরোধটি আসে এক লাইনের পরিবর্তন হিসেবে: একটি ঠিকানা ব্ল্যাকহোল করুন। আপনি টেন্যান্ট কনটেক্সটের ভিতরে Null0-এ একটি হোস্ট রুট যোগ করেন, প্রত্যাশিতভাবেই স্থানীয় টেবিল থেকে প্রিফিক্সটি হারিয়ে যায়, তারপর প্রশ্নগুলো শুরু হয়। রুটটি কি বক্স ছেড়ে গেল? দূরের VTEP-গুলো কি বর্জন করল, নাকি শুধু পৌঁছানোর ক্ষমতা হারাল? এখন কি দ্বিতীয় কোনো টেন্যান্ট প্রভাবিত হচ্ছে?

সঠিক স্থানীয় স্ট্যাটিক রুট কেবল প্রথম প্রশ্নটির উত্তর দেয়, তাই একটি ব্ল্যাকহোল পরিবর্তন আসলে একটি কমান্ড নয়, বরং তিনটি পর্যালোচিত ফলাফল।

পরিবর্তনটি আসলে কী উৎপন্ন করতে হবে

তিনটি ফলাফল লিখে শুরু করুন। নির্ধারিত টেন্যান্টকে গন্তব্যটি স্থানীয়ভাবে বর্জন করতে হবে। কেবল অনুমোদিত রুটই এক্সপোর্ট হতে পারবে, সঙ্গে আর কিছুই যাবে না। প্রতিটি গ্রাহক VTEP-কে অন্য পথের বদলে নির্ধারিত বর্জন ক্রিয়াটি বেছে নিতে হবে।

প্রতিটি ফলাফলের নিজস্ব প্রমাণ আছে, এবং কোনোটি অন্যটিকে বোঝায় না। স্থানীয় Null0 রুট স্থানীয় বর্জন তৈরি করে এবং পুনর্বিতরণ ছাড়া কিছুই এক্সপোর্ট করে না। সম্মত community ছাড়া পুনর্বিতরিত রুট একটি সাধারণ প্রিফিক্স হিসেবে আসে এবং ফরোয়ার্ড হয়। গ্রাহক নীতি ছাড়া community সম্পূর্ণ উপেক্ষিত হতে পারে।

ফলাফলগুলো আগে লেখা একটি সাধারণ ব্যর্থতা থেকেও রক্ষা করে: এমন একটি পরিবর্তন যা কাজ করছে বলে মনে হয় কারণ গন্তব্যটি আগেই অসম্পর্কিত কারণে পৌঁছানোর অযোগ্য ছিল। আপনি যদি পার্থক্য কীভাবে বুঝবেন তা বর্ণনা করতে না পারেন, তবে গ্রহণযোগ্যতা পরীক্ষা এখনও নকশা করা হয়নি।

স্থানীয় বিবৃতিটি কেবল প্রথম অংশটুকু করে

10.4(x) ধারার NX-OS-এ নাল রুটটি টেন্যান্টের VRF কনটেক্সটের ভিতরে থাকে, VRF-এর নাম বলা একটি একক কমান্ডে নয়। অংশটি ছোট, এবং এটি নিশ্চিতভাবেই সম্পূর্ণ EVPN কনফিগারেশন নয়।

vrf context TENANT_A
  ip route 192.0.2.10/32 Null0

ঠিকানাটি একটি ডকুমেন্টেশন প্রিফিক্স, লক্ষ্য নয়। IOS-এর সঙ্গে সিনট্যাক্সের পার্থক্য লক্ষ্য করুন, যেখানে VRF-এর নাম রুট কমান্ডের ভিতরেই আসে, এবং কিছু পেস্ট করার আগে আপনি যে রিলিজটি সত্যিই চালান তার সমর্থিত রূপটি নিশ্চিত করুন।

একা এই লাইনটি TENANT_A-এর ভিতরে ওই হোস্টের ট্রাফিক বর্জন করে এবং আর কিছুই করে না। এটি রুটে ট্যাগ দেয় না, BGP-এর জন্য বেছে নেয় না, এবং community সেট করে না। এগুলো আলাদা কনফিগারেশন সিদ্ধান্ত, এবং প্রত্যেকটিই এমন জায়গা যেখানে পরিবর্তনটি কাজ করার জন্য খুব সংকীর্ণ বা নিরাপদ হওয়ার জন্য খুব প্রশস্ত হতে পারে।

স্থানীয় বর্জন একই গন্তব্যে বৈধ ট্রাফিককেও প্রভাবিত করে। উদ্দেশ্য যদি হয় একটি অপব্যবহারকারী উৎস থামানো যখন প্রকৃত ব্যবহারকারীদের এখনও ঠিকানাটি দরকার, তবে নাল রুট ভুল হাতিয়ার এবং প্রথম সাপোর্ট কলেই তা জানতে পারবেন।

এক্সপোর্ট ও ইমপোর্ট আলাদা চুক্তি

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

BLACKHOLE community হলো একটি সুপরিচিত মান নিয়ে চুক্তি, কোনো প্রতিবেশীকে যেকোনো ঠিকানা বর্জনের অনুমতি নয়। RFC 7999 এটিকে ঠিক সেই ভাষায় বর্ণনা করে, এবং কে এটি ঘোষণা করতে পারবে তা নিয়ে বিশ্বাসের সীমা নকশার অংশ, বাস্তবায়নের খুঁটিনাটি নয়।

গ্রাহক পক্ষের নিজস্ব কনফিগারেশন দরকার। NX-OS-এ টাইপ 5 নাল রুটের ক্ষেত্রে বর্জন আচরণ বাছতে VTEP-এ route-map প্রক্রিয়াকরণ দরকার, যা এক্সপোর্ট ধাপের সঙ্গে নথিভুক্ত। সঠিকভাবে ট্যাগ করা প্রেরক ডিভাইস এবং ট্যাগ উপেক্ষা করা গ্রাহক এমন একটি পরিবর্তন তৈরি করে যা প্রয়োগ হয়েছে বলে মনে হয় কিন্তু ট্রাফিক ফরোয়ার্ড করেই যায়।

সেখানে থেকেই route-map-এ পার্শ্বপ্রতিক্রিয়া খুঁজুন। নতুন সীমাবদ্ধ নীতি অসম্পর্কিত প্রিফিক্সের বৈধ পৌঁছানোর ক্ষমতা দমন করতে পারে, এবং সেই ক্ষতি ব্ল্যাকহোলের পরে দেখা যায় এবং তাকে দায়ী করা কঠিন।

সন্নিবেশের আগে প্রত্যাহার লিখুন

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

এমন একটি স্বতন্ত্র ম্যানেজমেন্ট পথ রাখুন যা আপনি যে রুটটি বদলাচ্ছেন তার উপর নির্ভর করে না। যদি প্রশমনটি এমন একটি ঠিকানাকে ঢেকে দেয় যা আপনি ডিভাইসে পৌঁছাতে ব্যবহার করেন, তবে আপনি অতিরিক্ত ধাপসহ লকআউট তৈরি করেছেন।

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

কমান্ডের আউটপুট দিয়ে নয়, প্রমাণ দিয়ে গ্রহণ করুন

নির্ধারিত VTEP-গুলোতে নির্বাচিত রাউটিং অবস্থা এবং ফরোয়ার্ডিং অবস্থা পরীক্ষা করুন, এবং একটি প্রতিবেশী গন্তব্য পরীক্ষা করুন যা অপরিবর্তিত থাকা উচিত। নিশ্চিত করুন যে অন্য কোনো টেন্যান্ট প্রিফিক্সটি ইমপোর্ট করেনি, কারণ টেন্যান্ট-থেকে-টেন্যান্টে লিকেজই সেই ব্যর্থতার ধরন যা একটি রক্ষণাবেক্ষণ কাজকে দুর্ঘটনায় পরিণত করে।

তারপর প্রত্যাহার করুন এবং যাচাই করুন যে সাধারণ রুট ও সেবা ফিরে এসেছে। NX-OS EVPN নাল রুট নির্দেশিকা 10.4(x) রিলিজের জন্য এখানে বর্ণিত ট্যাগিং, পুনর্বিতরণ ও গ্রাহক নীতি নথিভুক্ত করে, এবং এটি আপনার নিজের রিলিজের সঙ্গে মিলিয়ে দেখার রেফারেন্স।