BGP — ইন্টার-ডোমেইন রাউটিং
এই পাঠে যা শিখবেন
- Interior বনাম Exterior গেটওয়ে প্রোটোকলের পার্থক্য
- BGP কীভাবে Autonomous System-দের মধ্যে সংযোগ তৈরি করে
- কেন BGP নীতি-ভিত্তিক, শুধু শর্টেস্ট-পাথ নয় — বাস্তব উদাহরণসহ
- BGP হাইজ্যাকিং কী ও কেন এটি সম্ভব (সংক্ষেপে)
- Python দিয়ে local_pref-ভিত্তিক BGP রুট নির্বাচন বাস্তবায়ন
১ · Interior বনাম Exterior গেটওয়ে প্রোটোকল
L18 (RIP) ও L19 (OSPF) — দুটোই Interior Gateway Protocol (IGP) — একটি একক প্রতিষ্ঠানের নিজস্ব নেটওয়ার্কের (একে বলা হয় Autonomous System (AS)Autonomous Systemএকটি একক প্রতিষ্ঠান (যেমন একটি ISP বা বড় কোম্পানি) দ্বারা পরিচালিত নেটওয়ার্কের সমষ্টি, যার একটি অনন্য AS নম্বর থাকে।) ভেতরে রাউটিং টেবিল তৈরির জন্য ডিজাইন করা। কিন্তু ইন্টারনেট তো একটি একক প্রতিষ্ঠানের নয় — এটি লক্ষ লক্ষ স্বতন্ত্র AS-এর সমষ্টি (L01-এর "নেটওয়ার্কদের নেটওয়ার্ক" ধারণার সরাসরি ধারাবাহিকতা)। এই ভিন্ন প্রতিষ্ঠানগুলোর AS-কে একসাথে সংযুক্ত করার জন্য দরকার একটি সম্পূর্ণ ভিন্ন প্রোটোকল — BGP (Border Gateway Protocol), আজকের দিনে ব্যাপকভাবে ব্যবহৃত একমাত্র Exterior Gateway Protocol।
এক প্রতিষ্ঠানের ভেতরে, প্রযুক্তিগত সর্বনিম্ন-খরচের পথ খোঁজে।
বিভিন্ন প্রতিষ্ঠানের মধ্যে, বাণিজ্যিক নীতি অনুযায়ী পথ বেছে নেয়।
২ · BGP নীতি-ভিত্তিক — শুধু শর্টেস্ট পাথ নয়
OSPF (L19) সবসময় গাণিতিকভাবে সবচেয়ে কম-খরচের পথ খোঁজে। কিন্তু BGP ভিন্ন — একটি AS ঘোষণা করে সে কোন ডেস্টিনেশন প্রিফিক্স পৌঁছাতে পারে, আর প্রতিটি AS নিজের বাণিজ্যিক সম্পর্ক ও নীতি অনুযায়ী রুট বেছে নেয় বা ফিল্টার করে (যেমন — একজন টাকা-প্রদানকারী গ্রাহকের মাধ্যমে যাওয়া রুটকে একজন সমান-অবস্থানের পিয়ারের মাধ্যমে যাওয়া রুটের চেয়ে অগ্রাধিকার দেওয়া, অথবা একজন প্রতিদ্বন্দ্বী প্রতিষ্ঠানের মধ্য দিয়ে রাউটিং এড়ানো) — নিছক "কারিগরিভাবে সবচেয়ে ছোট পথ" নয়, কারণ বাস্তব-বিশ্বের ইন্টারনেট রাউটিং স্বাধীনভাবে-পরিচালিত নেটওয়ার্কের মধ্যে বাণিজ্যিক চুক্তির উপর নির্ভর করে।
BGP-এ একটি রাউটের local preference (local_pref) মান — একটি প্রশাসনিকভাবে নির্ধারিত নীতি স্কোর — সবসময় AS-পাথের দৈর্ঘ্যের চেয়ে অগ্রাধিকার পায়। মানে একটি ৫-হপ পাথ যদি বেশি local_pref পায়, সেটি একটি ২-হপ পাথের চেয়ে জিতবে, যদি সেই ২-হপ পাথের local_pref কম হয়। এটাই BGP-কে OSPF/RIP থেকে দার্শনিকভাবে আলাদা করে।
# সরলীকৃত BGP পাথ নির্বাচন — local_pref আগে, তারপর শর্টেস্ট AS-পাথ
def select_best_route(routes):
"""routes: প্রতিটি dict-এ 'as_path' (AS নম্বরের তালিকা) ও 'local_pref' থাকে।
সর্বোচ্চ local_pref আগে জেতে; টাই হলে সবচেয়ে ছোট as_path জেতে।"""
return max(routes, key=lambda r: (r["local_pref"], -len(r["as_path"])))
# একই ডেস্টিনেশন প্রিফিক্সে পৌঁছানোর দুটি প্রার্থী রুট
routes_to_prefix = [
{
"label": "Peer-A হয়ে (কারিগরিভাবে ছোট পথ)",
"as_path": [65010, 65020],
"local_pref": 100,
},
{
"label": "Customer-B হয়ে (দীর্ঘ পথ, কিন্তু নীতিগতভাবে অগ্রাধিকারপ্রাপ্ত)",
"as_path": [65010, 65030, 65040],
"local_pref": 200,
},
]
winner = select_best_route(routes_to_prefix)
print("প্রার্থী রুটগুলো —")
for r in routes_to_prefix:
print(f" {r['label']}: AS-path length={len(r['as_path'])}, local_pref={r['local_pref']}")
print(f"\nবিজয়ী: {winner['label']}")
# --- স্ব-যাচাই: দীর্ঘ পথ কিন্তু বেশি local_pref-ওয়ালা রুটটিই জেতা উচিত ---
assert winner["as_path"] == [65010, 65030, 65040], "উচ্চতর local_pref-ওয়ালা রুটের জেতা উচিত ছিল, পাথ ছোট হলেও নয়!"
print("স্ব-যাচাই পাস — নীতি (local_pref) কারিগরি পাথ-দৈর্ঘ্যকে হারিয়েছে।")
# --- টাই-ব্রেক ডেমো: local_pref সমান হলে ছোট পাথ জেতে ---
tie_routes = [
{"label": "৩-হপ পাথ", "as_path": [65010, 65020, 65099], "local_pref": 150},
{"label": "২-হপ পাথ", "as_path": [65010, 65030], "local_pref": 150},
]
tie_winner = select_best_route(tie_routes)
assert tie_winner["label"] == "২-হপ পাথ", "local_pref টাই হলে ছোট AS-পাথের জেতা উচিত ছিল!"
print(f"\nটাই-ব্রেক পরীক্ষা — local_pref সমান হলে বিজয়ী: {tie_winner['label']} (ছোট পাথ)")
৩ · BGP হাইজ্যাকিং — একটি সংক্ষিপ্ত সতর্কতা
BGP ঐতিহাসিকভাবে একটি AS আসলেই একটি নির্দিষ্ট প্রিফিক্স ঘোষণা করার অনুমতিপ্রাপ্ত কি না তা যাচাই করার দুর্বল ব্যবস্থা রাখে — ফলে রুট হাইজ্যাকিং (অন্য কারো ঠিকানা ব্লক ভুয়াভাবে নিজের বলে দাবি করা) একটি বাস্তব, নথিভুক্ত ইন্টারনেট ঘটনার শ্রেণি। এই পাঠে আমরা শুধু এটির অস্তিত্বের কথা উল্লেখ করছি, গভীরে যাচ্ছি না — বিস্তারিত আক্রমণ-প্রতিরক্ষা বিশ্লেষণের জন্য Cybersecurity কোর্স দেখুন।
BGP-ই ইন্টারনেটকে একটি একক, সংযুক্ত সিস্টেমে পরিণত করে — কিন্তু এটি একটি কারিগরি অপ্টিমাইজেশন সমস্যা নয়, এটি হাজার হাজার স্বাধীনভাবে-পরিচালিত নেটওয়ার্কের মধ্যে একটি বিতরণকৃত বাণিজ্যিক আলোচনা। M4-এর শেষ পাঠ, L21-এ, আমরা দেখব কীভাবে NAT ও ICMP প্যাকেটকে বাস্তবে গন্তব্যে পৌঁছানো ও তার পথ নির্ণয় করা নিশ্চিত করে।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ কেন OSPF পুরো ইন্টারনেটে ব্যবহার করা যাবে না — শুধু organization-এর ভেতরে কেন সীমাবদ্ধ?
OSPF ধরে নেয় প্রতিটি রাউটার একটি একক প্রশাসনিক কর্তৃত্বের অধীনে (একই সংস্থা), তাই সবাই সততার সাথে তথ্য শেয়ার করবে এবং একই ধরনের "সর্বনিম্ন খরচ" লক্ষ্য অনুসরণ করবে। কিন্তু পুরো ইন্টারনেটে হাজার হাজার স্বাধীন, একে অপরের প্রতিদ্বন্দ্বী প্রতিষ্ঠান আছে — তারা কখনোই তাদের পুরো অভ্যন্তরীণ টপোলজি একে অপরের সাথে শেয়ার করবে না (বাণিজ্যিক গোপনীয়তা), আর সবাই একই "সর্বনিম্ন খরচ" লক্ষ্যও মানবে না (প্রত্যেকের নিজস্ব ব্যবসায়িক স্বার্থ আছে)। তাই BGP-এর মতো একটি নীতি-ভিত্তিক প্রোটোকল দরকার।
প্র ০২ "একজন টাকা-প্রদানকারী গ্রাহকের মাধ্যমে যাওয়া রুট" অগ্রাধিকার পাওয়ার পেছনে ব্যবসায়িক যুক্তি কী?
ইন্টারনেট সার্ভিস প্রোভাইডাররা একে অপরকে ট্রানজিট সার্ভিসের জন্য টাকা দেয় বা নেয়। যদি একটি ISP-এর একটি গ্রাহক (যে টাকা দিচ্ছে) একটি রুট অফার করে, সেই রুট ব্যবহার করা ISP-এর জন্য রাজস্ব-সহায়ক (গ্রাহকের ট্রাফিক তাদের নেটওয়ার্ক দিয়ে যাচ্ছে, যার জন্য তারা টাকা পাচ্ছে)। অন্যদিকে একজন সমান-অবস্থানের পিয়ারের মাধ্যমে ট্রাফিক পাঠানো সাধারণত বিনামূল্যে বিনিময় চুক্তির অংশ — কম লাভজনক। তাই local_pref-এ গ্রাহকের রুট বেশি স্কোর পায়।
প্র ০৩ BGP হাইজ্যাকিং সম্ভব হওয়ার মূল কারিগরি কারণ কী?
ঐতিহাসিকভাবে BGP-তে কোনো AS একটি প্রিফিক্স ঘোষণা করলে অন্য রাউটাররা ডিফল্টভাবে তা বিশ্বাস করে নিত — এটি যাচাই করার কোনো built-in ক্রিপ্টোগ্রাফিক ব্যবস্থা ছিল না যে ঘোষণাকারী AS সত্যিই সেই প্রিফিক্সের বৈধ মালিক কি না। ফলে একটি ভুল-কনফিগার করা বা দূষিত AS নিজেকে অন্য কারো প্রিফিক্সের মালিক দাবি করলে, নেটওয়ার্কের একটি অংশ ভুলভাবে সেই দিকে ট্রাফিক পাঠাতে শুরু করতে পারে। (RPKI-এর মতো আধুনিক সমাধান এই ফাঁক পূরণের চেষ্টা করছে, বিস্তারিত এই পাঠের পরিসরের বাইরে।)
অনুশীলন
-
চিন্তা করুন: যদি দুটি রুটের local_pref এবং AS-পাথ দৈর্ঘ্য দুটোই সমান হয়, তাহলে বাস্তব BGP আরও কোন মাপকাঠি ব্যবহার করতে পারে (নিজে থেকে চিন্তা করুন, কোডে না দেখেই)?
বাস্তব BGP-তে আরও বেশ কয়েকটি টাই-ব্রেকিং ধাপ আছে (এই পাঠের সরলীকৃত মডেলে অন্তর্ভুক্ত নয়) — যেমন সবচেয়ে কম origin type, সবচেয়ে কম MED (Multi-Exit Discriminator) মান, eBGP-প্রাপ্ত রুটকে iBGP-প্রাপ্তির চেয়ে অগ্রাধিকার, অথবা সবচেয়ে কম IGP খরচওয়ালা next-hop। মূল কথা — BGP-তে টাই-ব্রেকিং একটি দীর্ঘ, সুনির্দিষ্ট ক্রমে ধাপে ধাপে হয়, নিছক এলোমেলোভাবে নয়।
-
পরীক্ষা করুন: উপরের কোডে
routes_to_prefix-এ একটি তৃতীয় রুট যোগ করুন যারlocal_pref২৫০ (সবচেয়ে বেশি) কিন্তুas_pathচার ধাপের — Run চেপে দেখুন এটিই বিজয়ী হয় কি না।হ্যাঁ —
select_best_routeফাংশন প্রথমে সর্বোচ্চlocal_prefখোঁজে, পাথ দৈর্ঘ্য যাই হোক না কেন। ২৫০ local_pref-ওয়ালা রুটটিই বিজয়ী হবে, এমনকি সেটি চার ধাপের একটি দীর্ঘ পথ হলেও, কারণ নীতি (policy) সবসময় কারিগরি পাথ-দৈর্ঘ্যের আগে বিবেচিত হয়।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ পরবর্তী পাঠ — NAT ও ICMP — M4-এর শেষ পাঠ, ব্যবহারিক ঠিকানা অনুবাদ ও নেটওয়ার্ক ডায়াগনস্টিকস দেখাবে।
- Cloud Computing & DevOps কোর্স সঙ্গী কোর্স ক্লাউড প্রোভাইডাররা কীভাবে একাধিক ISP-এর সাথে BGP পিয়ারিং কনফিগার করে তা শিখতে দেখুন।
- Cybersecurity & Ethical Hacking কোর্স সঙ্গী কোর্স BGP হাইজ্যাকিং-এর বাস্তব ঘটনা ও প্রতিরক্ষা কৌশল (RPKI) বিস্তারিত শিখতে দেখুন।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design, Cybersecurity, Cloud Computing & DevOps ও Computer Networks — সব এক জায়গায়।