BGP আর ইন্টারনেটের গঠন — autonomous system, peering আর IXP

১ · একটি IGP দিয়ে কেন পুরো ইন্টারনেট চলে না

পর্ব ২৩ আর ২৪-এ দেখেছেন distance vector (RIP) আর link state (OSPF) — দুটোই একটি প্রতিষ্ঠানের নিজের নেটওয়ার্কের ভেতরে সবচেয়ে কম খরচের পথ খোঁজে। পর্ব ২২-এ এদের নাম দেওয়া হয়েছে IGP (Interior Gateway Protocol). প্রশ্ন হলো: পুরো ইন্টারনেটকে একটি বিশাল OSPF বানালে সমস্যা কী? সমস্যা তিনটি — আকার, স্বাধীনতা আর নীতি।

তাই ইন্টারনেটের routing দুই স্তরে ভাগ: প্রতিটি প্রতিষ্ঠানের ভেতরে IGP (intra-domain), আর প্রতিষ্ঠানগুলোর মাঝে EGP (Exterior Gateway Protocol, inter-domain). আজ ইন্টারনেটে চালু EGP একটিই: BGP (Border Gateway Protocol), সংস্করণ ৪, যার বর্তমান মূল মান RFC 4271 (২০০৬)।

২ · Autonomous system আর ASN

RFC 1930-এর সংজ্ঞায় autonomous system হলো এক বা একাধিক অপারেটরের চালানো IP prefix-এর একটি যুক্ত দল, যার বাইরের দিকে একটি স্পষ্ট routing নীতি আছে। সহজ কথায়: একটি ISP, একটি বিশ্ববিদ্যালয়, একটি ব্যাংক বা একটি বড় content কোম্পানির নেটওয়ার্ক — যে বাইরের দুনিয়ার কাছে এক সত্তা হিসেবে BGP বলে। প্রতিটি AS-এর একটি নম্বর, ASN (Autonomous System Number).

• বণ্টন: IP ঠিকানার মতোই — IANA থেকে পাঁচটি RIR-এর কাছে ব্লক, সেখান থেকে প্রতিষ্ঠানে (পর্ব ১৬)। বাংলাদেশের প্রতিষ্ঠানগুলো ASN পায় APNIC-এর কাছ থেকে (সরাসরি সদস্য হয়ে, বা কোনো সদস্য প্রতিষ্ঠানের মাধ্যমে)।
• ১৬ bit থেকে ৩২ bit: শুরুতে ASN ছিল ১৬ bit — ০ থেকে ৬৫,৫৩৫. এগুলো ফুরিয়ে আসছিল বলে ৩২ bit ASN আসে (প্রথমে RFC 4893, ২০০৭; এখন RFC 6793), মোট প্রায় ৪৩০ কোটি নম্বর। পুরোনো ১৬ bit-এর router-এর সাথে কথা বলতে একটি বিশেষ নম্বর ব্যবহার হয়: AS 23456 (AS_TRANS).
• লেখার ধরন: ৩২ bit ASN সাধারণ সংখ্যা হিসেবে লেখা হয় (asplain, যেমন 65551); কিছু জায়গায় “উপরের ১৬ bit.নিচের ১৬ bit” (asdot) — 65551 = 1.15, কারণ ৬৫,৫৫১ = ১ × ৬৫,৫৩৬ + ১৫ (RFC 5396).

এই পর্বের সব উদাহরণে শুধু documentation range-এর ASN (64496–64511, 65536–65551) আর documentation prefix (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 — documentation address) ব্যবহার করা হয়েছে, যাতে কোনো আসল প্রতিষ্ঠানের নম্বর ভুলবশত কনফিগারেশনে না ঢোকে। Private ASN private IP-র মতো: শুধু একটি ISP-র সাথে BGP চালানো গ্রাহককে ISP তা দিতে পারে, আর বাইরে ঘোষণার আগে AS_PATH থেকে মুছে দেয়।

তিন ধরনের AS

৩ · BGP — path vector, session আর বার্তা

পর্ব ২৩-এর distance vector-এ প্রতিবেশী শুধু বলত “ওই গন্তব্যে আমার দূরত্ব ৩”. BGP বলে আরও বেশি: “203.0.113.0/24-এ যাওয়া যায়, আর পথটি এই AS-গুলোর ভেতর দিয়ে: 64498 64500”. পুরো পথের তালিকা পাঠায় বলে একে বলে path vector protocol. এর তিনটি বড় সুবিধা:

• Loop ধরা সহজ: কোনো ঘোষণার AS_PATH-এ নিজের ASN থাকলে AS সেটি সাথে সাথে ফেলে দেয় — ঘোষণাটি আগেই তার ভেতর দিয়ে গেছে। Distance vector-এর count-to-infinity (পর্ব ২৩) AS-স্তরে এভাবে এড়ানো যায়।
• নীতি প্রয়োগ: পথে কারা আছে দেখা যায়, তাই “এই AS-এর ভেতর দিয়ে যাওয়া পথ নেব না” জাতীয় নিয়ম লেখা যায়।

নিচের stepper একটি UPDATE বার্তার যাত্রা দেখায়। ছয়টি AS: দুটি বড় backbone 64496 আর 64497 (পরস্পর peer), তাদের customer আঞ্চলিক ISP 64498 আর 64499 (এরাও পরস্পর peer), 64498-এর customer 64500 — যে 203.0.113.0/24-এর মালিক — আর 64501, যার দুটি provider (64498 আর 64499). প্রতিটি AS পরের জনকে পাঠানোর আগে নিজের ASN AS_PATH-এর সামনে বসায়।

        AS64496 ═══ peer ═══ AS64497          (backbone)
           │                    │
        AS64498 ═══ peer ═══ AS64499          (আঞ্চলিক ISP)
         │     ╲              ╱
      AS64500   ╲── AS64501 ─╱               (64501-এর দুই provider)
  203.0.113.0/24
  │ = provider (ওপরে) – customer (নিচে)    ═ = peer

Session: TCP port 179 আর হাতে বাঁধা প্রতিবেশী

OSPF-এর মতো BGP নিজে প্রতিবেশী খোঁজে না। দুই router-এর অপারেটর আগে থেকে ঠিক করেন কে কার BGP peer, তারপর দুই পাশে প্রতিবেশীর ঠিকানা আর ASN কনফিগার করেন। Router দুটি TCP port 179-এ সংযোগ খোলে (TCP-র handshake আর state পর্ব ২৯-এ)। TCP নির্ভরযোগ্য আর ক্রমিক পৌঁছানো নিশ্চিত করে, তাই BGP শুরুতে একবার পুরো table পাঠিয়ে পরে শুধু পরিবর্তন পাঠায় — RIP-এর মতো প্রতি ৩০ সেকেন্ডে পুরো table নয়।

 প্রতিটি BGP বার্তার header (১৯ byte)
 ┌──────────────────────────────────────────────┐
 │ Marker — ১৬ byte, সব bit 1 (FF FF … FF)       │
 ├───────────────────────┬──────────────────────┤
 │ Length — ২ byte       │ Type — ১ byte        │
 │ (১৯ থেকে ৪০৯৬)        │ 1 OPEN … 4 KEEPALIVE │
 └───────────────────────┴──────────────────────┘
 UPDATE-এর বাকি অংশ: Withdrawn Routes │ Path Attributes │ NLRI (prefix-গুলো)

Hold time হলো কতক্ষণ প্রতিবেশীর কোনো বার্তা না পেলে session মৃত ধরা হবে। RFC 4271 hold time ৯০ সেকেন্ড আর KEEPALIVE ৩০ সেকেন্ড পরপর প্রস্তাব করে (vendor ভেদে ডিফল্ট আলাদা)। তাই নীরব ব্যর্থতা ধরতে মিনিট দেড়েক লাগতে পারে; বাস্তবে BFD-এর মতো দ্রুত পদ্ধতিও সাথে রাখা হয়।

BGP session-এর অবস্থাগুলো একটি finite state machine মেনে চলে: Idle (কিছুই হচ্ছে না, শুরু করার অপেক্ষা) → Connect (TCP সংযোগের চেষ্টা) → Active (চেষ্টা ব্যর্থ, আবার চেষ্টা বা প্রতিবেশীর সংযোগের অপেক্ষা) → OpenSent (OPEN পাঠানো হয়েছে) → OpenConfirm (প্রতিবেশীর OPEN পাওয়া গেছে, KEEPALIVE-এর অপেক্ষা) → Established (UPDATE বিনিময় চলছে)। Router-এর আউটপুটে অনেকক্ষণ “Active” দেখা মানে সাধারণত সমস্যা — TCP সংযোগই হচ্ছে না।

eBGP আর iBGP

দুই আলাদা AS-এর router-এর session হলো eBGP (external); একই AS-এর ভেতরের দুই router-এর session iBGP (internal). বড় ISP-র border router-গুলো বাইরের route শেখে, আর iBGP দিয়ে তা ভেতরের সব router-কে জানায়। নিয়মের পার্থক্য:

• AS_PATH: eBGP-তে পাঠানোর সময় নিজের ASN যোগ হয়; iBGP-তে AS_PATH বদলায় না — একই AS-এর ভেতরে আছেন।
• NEXT_HOP: eBGP-তে নিজের ঠিকানা বসে; iBGP-তে ডিফল্ট আচরণে বদলায় না (বাইরের প্রতিবেশীর ঠিকানাই থাকে)। ভেতরের router সেই ঠিকানায় পৌঁছায় IGP দিয়ে — তাই BGP-র পাশাপাশি IGP-ও লাগে (অথবা border router-এ “next-hop-self”).
• Full mesh: iBGP-তে AS_PATH বদলায় না বলে loop ধরার উপায় নেই। তাই নিয়ম: iBGP প্রতিবেশীর কাছে শেখা route আরেক iBGP প্রতিবেশীকে জানানো যাবে না। ফলে প্রতিটি router-কে প্রতিটি router-এর সাথে সরাসরি session রাখতে হয় — n টি router-এ n(n − ১)/২ টি session. ১০০টি router-এ ৪,৯৫০টি!
• সমাধান — route reflector: একটি (বা নিরাপত্তার জন্য দুটি) router-কে নিয়মের ব্যতিক্রম করা হয় (RFC 4456): সে client-দের কাছে শেখা route অন্য client-দের “প্রতিফলিত” করে। প্রতিটি client-এর তখন শুধু reflector-এর সাথে session. আরেক পদ্ধতি confederation — বড় AS-কে কয়েকটি ছোট ভেতরের AS-এ ভাগ করা (RFC 5065).

আপনার কম্পিউটারে BGP নেই — যাচাই করে দেখুন

সাধারণ host বা বাসার router BGP চালায় না; একটি default route-ই যথেষ্ট (পর্ব ২২)। BGP চলে ISP, data center আর বড় প্রতিষ্ঠানের border router-এ (Linux-এ BIRD বা FRRouting দিয়েও)। নিচের স্ক্রিপ্ট এই পাতার কোড-চালানোর container-এ খোঁজে: কোনো BGP software আছে কি না, port 179-এ কোনো TCP socket আছে কি না (/proc/net/tcp-এ port লেখা থাকে hex-এ: ১৭৯ = 00B3), আর kernel-এর route-গুলোর কয়টি BGP বসিয়েছে।

echo "== BGP software on this machine? =="
for d in bird bgpd gobgpd vtysh; do
  command -v "$d" >/dev/null && echo "  $d: found" || echo "  $d: not found"
done
echo "== any TCP socket on port 179 (= 0x$(printf '%04X' 179))? =="
if grep -qi ':00B3 ' /proc/net/tcp /proc/net/tcp6 2>/dev/null; then
  grep -i ':00B3 ' /proc/net/tcp /proc/net/tcp6
else
  echo "  none - this machine is not a BGP speaker"
fi
echo "== routes in this kernel =="
if command -v ip >/dev/null; then
  echo "  IPv4 routes: $(ip -4 route | wc -l), installed by BGP: $(ip -4 route | grep -c 'proto bgp')"
else
  echo "  ip not found; /proc/net/route entries: $(( $(wc -l < /proc/net/route) - 1 ))"
fi

== BGP software on this machine? ==
  bird: not found
  bgpd: not found
  gobgpd: not found
  vtysh: not found
== any TCP socket on port 179 (= 0x00B3)? ==
  none - this machine is not a BGP speaker
== routes in this kernel ==
  IPv4 routes: 2, installed by BGP: 0

৪ · ব্যবসার সম্পর্ক — transit, peering আর valley-free নিয়ম

দুটি AS-এর মাঝে BGP session থাকা মানেই তারা সমান নয়। প্রতিটি সংযোগের পেছনে একটি ব্যবসায়িক চুক্তি, আর চুক্তি ঠিক করে কে কাকে কোন route জানাবে। মূল সম্পর্ক দুটি:

টাকার দিক থেকেই পছন্দের ক্রম আসে: customer-এর দিকে traffic পাঠালে আয়, peer-এ খরচ নেই, provider-এ খরচ। তাই একই prefix-এর একাধিক route থাকলে সাধারণ নীতি: customer route > peer route > provider route — AS_PATH যত লম্বাই হোক। বাস্তবে এটি বসানো হয় LOCAL_PREF দিয়ে (যেমন customer 200, peer 150, provider 100 — সংখ্যাগুলো প্রতিটি নেটওয়ার্কের নিজের পছন্দ, কোনো মান নয়)।

Export নিয়ম — কাকে কোন route জানাবেন

২০০০–২০০১ সালে Lixin Gao আর Jennifer Rexford এই ব্যবসায়িক যুক্তিকে নিয়মে বাঁধেন, যা আজ Gao-Rexford নিয়ম নামে পরিচিত:

কেন “না”? Provider-এর route peer-কে জানালে peer সেই traffic আপনাকে দেবে, আর আপনি তা টাকা দিয়ে provider-কে দিয়ে বহন করাবেন — peer বিনা টাকায় সেবা পেল, বিল এলো আপনার নামে। Peer-এর route provider-কে জানালেও একই লোকসান।

এই নিয়ম মানলে প্রতিটি বৈধ পথের আকার হয় একটি পাহাড়ের মতো: উৎস থেকে কয়েক ধাপ ওপরে (customer → provider), তারপর বড়জোর একটি peer link পাশাপাশি, তারপর কয়েক ধাপ নিচে (provider → customer). মাঝে কোথাও নিচে নেমে আবার ওপরে ওঠা — একটি “উপত্যকা” (valley) — থাকতে পারে না। তাই নাম valley-free routing. ওপরের ছয় AS-এর ছবিতে কয়েকটি পথ যাচাই করি (AS_PATH ডান থেকে বামে পড়ুন — উৎস থেকে গ্রাহকের দিকে):

Gao আর Rexford আরও দেখান: সব AS যদি customer route-কে বেশি পছন্দ করে, এই export নিয়ম মানে, আর customer-provider সম্পর্কে কোনো চক্র না থাকে (কেউ পরোক্ষে নিজেরই provider নয়), তবে BGP-র route বাছাই নিশ্চিতভাবে একটি স্থির অবস্থায় পৌঁছায়। সাধারণ BGP-তে এই নিশ্চয়তা নেই — বিরোধী নীতিতে route চিরকাল দোলাচলে থাকতে পারে। অর্থাৎ যে নিয়ম টাকা বাঁচায়, সেটিই ইন্টারনেটকে স্থিরও রাখে।

এবার একই ছয় AS-এ পুরো propagation চালাই। Simulator প্রতিটি AS-এর প্রতিবেশীর সেরা route থেকে প্রার্থী বানায়, export নিয়ম মানে, নিজের ASN থাকা পথ বাতিল করে, আর সেরাটি বাছে (আগে সম্পর্ক — customer, peer, provider — তারপর ছোট AS_PATH, শেষে কম ASN-এর প্রতিবেশী)। কিছু না বদলানো পর্যন্ত চলে। তারপর একই কাজ আবার, কিন্তু এবার multihomed AS64501 নিয়ম ভেঙে সব route সবাইকে জানায় — একটি route leak.

// [provider, customer] or [a, b, "peer"]. AS 64500 originates 203.0.113.0/24.
const links = [[64496, 64497, "peer"], [64496, 64498], [64497, 64499],
  [64498, 64499, "peer"], [64498, 64500], [64498, 64501], [64499, 64501]];
const rel = {};                                   // rel[a][n] = what n is for a
const set = (a, n, r) => ((rel[a] ??= {})[n] = r);
links.forEach(([a, b, p]) => p ? (set(a, b, "peer"), set(b, a, "peer"))
                               : (set(a, b, "cust"), set(b, a, "prov")));
const PREF = { self: 4, cust: 3, peer: 2, prov: 1 }; // LOCAL_PREF by relationship
const better = (x, y) => PREF[x.from] - PREF[y.from] || y.path.length - x.path.length ||
                         y.path[0] - x.path[0];
function simulate(leaker) {
  const best = { 64500: { from: "self", path: [] } };
  let loops, changed = true;
  while (changed) {
    changed = false; loops = [];
    for (const a of Object.keys(rel).map(Number)) {
      let cand = best[a]?.from === "self" ? best[a] : null;
      for (const [n, r] of Object.entries(rel[a])) {
        const b = best[n];   // valley-free: own/customer routes to all, others only to customers
        if (!b || !(b.from === "self" || b.from === "cust" || rel[n][a] === "cust" || +n === leaker)) continue;
        const path = [+n, ...b.path];                    // n prepends its own ASN
        if (path.includes(a)) { loops.push(`AS${a} rejects ${path.join(" ")}`); continue; }
        if (!cand || better({ from: r, path }, cand) > 0) cand = { from: r, path };
      }
      if (JSON.stringify(cand) !== JSON.stringify(best[a])) { best[a] = cand; changed = true; }
    }
  }
  return { best, loops };
}
const p = r => r.path.join(" ") || "(own prefix)", ok = simulate(0), leak = simulate(64501);
console.log("== valley-free ==   learned-from  AS_PATH");
for (const a in ok.best) console.log(`  AS${a}   ${ok.best[a].from.padEnd(4)}   ${p(ok.best[a])}`);
console.log("loop check:\n  " + ok.loops.join("\n  ") + "\n== AS64501 leaks ==");
for (const a in leak.best) if (p(leak.best[a]) !== p(ok.best[a]))
  console.log(`  AS${a}  ${p(ok.best[a])}  ->  ${p(leak.best[a])} (${leak.best[a].from})`);

== valley-free ==   learned-from  AS_PATH
  AS64496   cust   64498 64500
  AS64497   peer   64496 64498 64500
  AS64498   cust   64500
  AS64499   peer   64498 64500
  AS64500   self   (own prefix)
  AS64501   prov   64498 64500
loop check:
  AS64498 rejects 64496 64498 64500
  AS64500 rejects 64498 64500
== AS64501 leaks ==
  AS64497  64496 64498 64500  ->  64499 64501 64498 64500 (cust)
  AS64499  64498 64500  ->  64501 64498 64500 (cust)

৫ · Tier, IXP আর বাংলাদেশ

পর্ব ০২-এ ইন্টারনেটের স্তরগুলো মোটা দাগে দেখেছেন (network-types-topologies). এবার BGP-র চোখে:

• Tier-1: যে নেটওয়ার্ক কারও কাছ থেকে transit কেনে না, বাকি সব tier-1-এর সাথে peering করেই পুরো ইন্টারনেটে পৌঁছায় (“transit-free”). কোনো সরকারি তালিকা নেই, আর কে tier-1 তা নিয়ে সংজ্ঞা ও মত ভিন্ন।
• Tier-2: কিছু transit কেনে, আবার অনেকের সাথে peering করে, আর নিজেও অন্যকে transit বিক্রি করে। বেশিরভাগ বড় আঞ্চলিক আর জাতীয় ISP এমন।
• Tier-3 / access ISP: মূলত transit কেনে আর শেষ গ্রাহককে সংযোগ দেয়।

তবে আজকের ইন্টারনেট আর পরিষ্কার পিরামিড নয়। বড় content কোম্পানি আর CDN নিজস্ব backbone নিয়ে হাজারো ISP-র সাথে সরাসরি peering করে, ফলে অনেক traffic tier-1-কে ছোঁয়ই না। একে বলা হয় ইন্টারনেটের “চ্যাপ্টা হয়ে যাওয়া” (flattening).

IXP — এক জায়গায় অনেকের peering

দুই ISP peering করতে চাইলে তাদের মাঝে একটি তার লাগে। ৫০টি ISP সবাই সবার সাথে আলাদা তার টানলে লাগবে ৫০ × ৪৯ ÷ ২ = ১,২২৫টি link. IXP (Internet Exchange Point) এর সমাধান: একটি ভবনে একটি বড় switch-এর কাঠামো (layer 2), প্রতিটি সদস্য একটি port-এ যুক্ত হয়, আর সেই একই port দিয়ে অনেক সদস্যের সাথে BGP session চালায়। অনেক IXP-তে একটি route server থাকে — সদস্যরা শুধু তার সাথে একটি session খুলে সবার route পায় (multilateral peering). Route server নিজে traffic বহন করে না, শুধু route পৌঁছে দেয়, আর সাধারণত নিজের ASN AS_PATH-এ যোগ করে না (RFC 7947).

IXP-র লাভ: খরচ (দেশের traffic আর কেনা আন্তর্জাতিক transit দিয়ে যায় না), গতি আর স্থিতিস্থাপকতা। গতির একটি হিসাব: ঢাকার দুই ISP-র মধ্যে কোনো সরাসরি বা IXP-পথ না থাকলে তাদের traffic হয়তো সিঙ্গাপুরের মতো কোনো বিদেশি exchange ঘুরে আসে (একে বলে tromboning). ঢাকা থেকে সিঙ্গাপুর সরলরেখায় প্রায় ২,৯০০ কিমি. এক দিকের যাত্রা ঢাকা → সিঙ্গাপুর → ঢাকা = প্রায় ৫,৮০০ কিমি, আর round trip তার দ্বিগুণ = ১১,৬০০ কিমি. Fiber-এ আলো চলে প্রায় ২ × ১০^৮ মিটার/সেকেন্ডে, অর্থাৎ প্রতি কিমিতে ৫ µs (পর্ব ০৫)। তাই শুধু propagation delay-ই কমপক্ষে ১১,৬০০ × ৫ µs = ৫৮ ms — বাস্তবের cable সরলরেখায় যায় না বলে এর চেয়ে বেশি। দেশের ভেতরের IXP দিয়ে একই RTT সাধারণত কয়েক ms.

৬ · BGP attribute আর best-path selection

একটি router একই prefix-এর জন্য অনেক প্রতিবেশীর কাছ থেকে route পেতে পারে। বেছে নেয় প্রতিটি route-এর সাথে আসা path attribute দেখে। মূল attribute-গুলো:

বাছাইয়ের ক্রম (সরল রূপ)

RFC 4271-এর বাছাই একটি ক্রমিক ছাঁকনি: প্রতিটি ধাপে যারা সেরা, শুধু তারাই পরের ধাপে যায়। আগের শর্ত: NEXT_HOP-এ পৌঁছানো যেতে হবে।

1. সবচেয়ে বেশি LOCAL_PREF — নিজের নীতি সবার আগে।
2. সবচেয়ে ছোট AS_PATH — কম AS পেরোনো।
3. সবচেয়ে কম ORIGIN — IGP, তারপর EGP, তারপর INCOMPLETE.
4. সবচেয়ে কম MED — তবে শুধু একই প্রতিবেশী AS থেকে আসা route-গুলোর মধ্যে তুলনা (ডিফল্ট আচরণ)।
5. eBGP-তে শেখা route, iBGP-র চেয়ে আগে।
6. NEXT_HOP পর্যন্ত সবচেয়ে কম IGP cost — নিজের নেটওয়ার্ক থেকে সবচেয়ে কাছের বের হওয়ার দরজা।
7. Tie-breaker: সবচেয়ে কম BGP Identifier (router ID) যে router পাঠিয়েছে তার route, তারপর সবচেয়ে কম প্রতিবেশী-ঠিকানা।

একটি উদাহরণ: AS64500-এর router R1-এর কাছে 203.0.113.0/24-এর জন্য সাতটি route. Route ১, ২, ৩ আর ৭ এসেছে iBGP দিয়ে (AS-এর অন্য border router থেকে), বাকিগুলো সরাসরি eBGP-তে। সব route-এর শেষ AS 64510 — prefix-টির উৎস।

একই হিসাব কোডে। keepBest প্রতিটি ধাপে একটি “score” হিসাব করে (কম ভালো), সবচেয়ে কম score-এর route-গুলো রাখে আর বাকিদের বাদের তালিকা ছাপে। MED-এর ধাপে আগে প্রতিটি প্রতিবেশী AS (AS_PATH-এর প্রথম নম্বর)-এর সবচেয়ে কম MED বের করা হয়।

// Router R1 in AS 64500 has 7 candidate routes for 203.0.113.0/24.
// ebgp: learned from a neighbour AS (true) or from an iBGP peer (false).
const ORIGIN = { IGP: 0, EGP: 1, INCOMPLETE: 2 };
let routes = [
  { id: 1, path: [64501, 64510], lp: 100, origin: "IGP", med: 30, ebgp: false, igp: 10, rid: "192.0.2.2" },
  { id: 2, path: [64501, 64510], lp: 100, origin: "IGP", med: 10, ebgp: false, igp: 30, rid: "192.0.2.3" },
  { id: 3, path: [64502, 64510], lp: 100, origin: "IGP", med: 0, ebgp: false, igp: 20, rid: "192.0.2.4" },
  { id: 4, path: [64503, 64510], lp: 100, origin: "INCOMPLETE", med: 0, ebgp: true, igp: 0, rid: "192.0.2.6" },
  { id: 5, path: [64504, 64511, 64510], lp: 100, origin: "IGP", med: 0, ebgp: true, igp: 0, rid: "192.0.2.7" },
  { id: 6, path: [64505, 64510], lp: 80, origin: "IGP", med: 0, ebgp: true, igp: 0, rid: "192.0.2.8" },
  { id: 7, path: [64506, 64510], lp: 100, origin: "IGP", med: 0, ebgp: false, igp: 20, rid: "192.0.2.5" },
];
const ip = s => s.split(".").reduce((a, o) => a * 256 + Number(o), 0);
const keepBest = (name, score) => {             // keep only routes with the lowest score
  const best = Math.min(...routes.map(score));
  const out = routes.filter(r => score(r) !== best).map(r => r.id);
  routes = routes.filter(r => score(r) === best);
  console.log(name.padEnd(27) + (out.length ? "drop " + out.join(",") : "no change").padEnd(16) +
    "left: " + routes.map(r => r.id).join(","));
};
keepBest("1 highest LOCAL_PREF", r => -r.lp);
keepBest("2 shortest AS_PATH", r => r.path.length);
keepBest("3 lowest ORIGIN", r => ORIGIN[r.origin]);
// 4. MED: compared only between routes from the SAME neighbour AS (first AS in path)
const minMed = {};
routes.forEach(r => { const n = r.path[0]; minMed[n] = Math.min(minMed[n] ?? Infinity, r.med); });
keepBest("4 lowest MED (same nbr AS)", r => (r.med > minMed[r.path[0]] ? 1 : 0));
keepBest("5 eBGP over iBGP", r => (r.ebgp ? 0 : 1));
keepBest("6 lowest IGP cost to NH", r => r.igp);
keepBest("7 lowest router ID", r => ip(r.rid));
const w = routes[0];
console.log(`BEST: route ${w.id}, AS_PATH ${w.path.join(" ")}, router ID ${w.rid}`);

1 highest LOCAL_PREF       drop 6          left: 1,2,3,4,5,7
2 shortest AS_PATH         drop 5          left: 1,2,3,4,7
3 lowest ORIGIN            drop 4          left: 1,2,3,7
4 lowest MED (same nbr AS) drop 1          left: 2,3,7
5 eBGP over iBGP           no change       left: 2,3,7
6 lowest IGP cost to NH    drop 2          left: 3,7
7 lowest router ID         drop 7          left: 3
BEST: route 3, AS_PATH 64502 64510, router ID 192.0.2.4

Hot-potato routing — গরম আলুর মতো দ্রুত হাত থেকে ছাড়া

ধাপ ৬-এর একটি বড় প্রভাব আছে। ধরুন একটি বাংলাদেশি ISP-র একই প্রতিবেশী AS-এর সাথে দুটি সংযোগ — একটি ঢাকায়, একটি চট্টগ্রামে। ঢাকার কোনো গ্রাহকের packet-এর জন্য দুটি route-ই সমান (একই LOCAL_PREF, AS_PATH, MED), তাই সিদ্ধান্ত হয় IGP cost দিয়ে: ঢাকার দরজাটি কাছে, তাই packet সেখান দিয়েই বের হয়, যদিও গন্তব্য হয়তো চট্টগ্রামের দিকে। প্রতিটি AS এভাবে নিজের খরচ কমাতে traffic যত তাড়াতাড়ি সম্ভব অন্যের ঘাড়ে দেয় — গরম আলুর মতো, তাই নাম hot-potato routing. ফল asymmetric routing: দুই দিকের AS-ই নিজের কাছের দরজা বাছে বলে যাওয়া আর ফেরার পথ আলাদা হয় (traceroute, পর্ব ২০)। উল্টোটি “cold-potato” — নিজের backbone-এ traffic যতটা সম্ভব দূর পর্যন্ত বহন করা।

৭ · Traffic engineering আর anycast

Traffic engineering মানে traffic কোন পথে যাবে তা নিজের ইচ্ছামতো সাজানো। বের হওয়া traffic (outbound) নিয়ন্ত্রণ সহজ: নিজের router-এ LOCAL_PREF বদলালেই হলো। কঠিন হলো ঢোকা traffic (inbound) — সেটি ঠিক হয় অন্যদের router-এর সিদ্ধান্তে। আপনি শুধু ঘোষণাকে এমনভাবে সাজাতে পারেন যাতে অন্যরা আপনার পছন্দের পথ বাছে। চারটি প্রচলিত কৌশল:

সুপরিচিত well-known community: NO_EXPORT (65535:65281) — নিজের AS-এর বাইরে আর জানানো নিষেধ, আর NO_ADVERTISE (65535:65282) — কাউকেই জানানো নিষেধ. DDoS-এর সময় প্রতিরক্ষার জন্য BLACKHOLE (65535:666, RFC 7999): আক্রান্ত একটি ঠিকানার route এই চিহ্নসহ provider-কে পাঠালে provider সেই ঠিকানার traffic নিজের প্রান্তেই ফেলে দেয় — ঠিকানাটি বিচ্ছিন্ন হয়, কিন্তু বাকি নেটওয়ার্ক বাঁচে (পর্ব ৫০)। ৩২ bit ASN-এর যুগে “ASN:মান” আকারে জায়গা কম পড়ায় এসেছে large community (RFC 8092).

একটি multihomed AS64500-এর সরল কনফিগারেশন — শুধু নিজের prefix জানানো (leak ঠেকাতে), আর backup provider-এর দিকে prepend:

! উদাহরণ — FRRouting-ধাঁচের syntax; vendor ভেদে লেখার ধরন আলাদা
router bgp 64500
 neighbor 192.0.2.1 remote-as 64496          ! মূল provider
 neighbor 198.51.100.1 remote-as 64497       ! backup provider
 address-family ipv4 unicast
  network 203.0.113.0/24
  neighbor 192.0.2.1 prefix-list OWN-ONLY out
  neighbor 198.51.100.1 prefix-list OWN-ONLY out
  neighbor 198.51.100.1 route-map PREPEND-BACKUP out
 exit-address-family
!
ip prefix-list OWN-ONLY seq 10 permit 203.0.113.0/24
!
route-map PREPEND-BACKUP permit 10
 set as-path prepend 64500 64500

OWN-ONLY নিশ্চিত করে এক provider-এর কাছে শেখা কিছুই অন্য provider-এ যায় না — অংশ ৪-এর leak এখানেই আটকে যেত। বাস্তবে প্রতিটি প্রতিবেশীর দিকে ঢোকার filter-ও লাগে, আর FRRouting-এর নতুন সংস্করণে কোনো নীতি না থাকলে eBGP route গ্রহণ বা ঘোষণাই হয় না। এটি শেখার উদাহরণ, সরাসরি কপি করার কনফিগারেশন নয়।

Anycast — একই ঠিকানা, অনেক জায়গা

Anycast-এ একই prefix পৃথিবীর অনেক জায়গা থেকে ঘোষণা করা হয়। প্রতিটি AS নিজের best-path selection অনুযায়ী তার কাছে “সবচেয়ে ভালো” জায়গাটি বাছে — ফলে ব্যবহারকারী সাধারণত কাছের কোনো সার্ভারে পৌঁছায় (BGP-র অর্থে কাছে, ভৌগোলিকভাবে সবসময় নয়)। DNS-এর root server-গুলো এর বড় উদাহরণ: নাম মাত্র ১৩টি (a থেকে m.root-servers.net), কিন্তু anycast-এর কারণে বিশ্বজুড়ে এদের এক হাজারেরও বেশি instance (সর্বশেষ সংখ্যা root-servers.org-এ দেখা যায়; DNS পর্ব ৩৫-এ)। CDN আর public DNS resolver-ও anycast ব্যবহার করে (পর্ব ৩৮)। আরেকটি লাভ: DDoS-এর traffic অনেক জায়গায় ভাগ হয়ে যায়।

৮ · BGP-র নিরাপত্তা — leak, hijack আর RPKI

মূল BGP-তে কোনো যাচাই নেই: প্রতিবেশী যা বলে, router তা বিশ্বাস করে। দুটি প্রধান সমস্যা:

• Prefix hijack: অন্যের prefix নিজের বলে ঘোষণা — হুবহু একই prefix (তাহলে কাছের AS-গুলো ভুল পথ নেয়) বা আরও নির্দিষ্ট prefix (তাহলে longest prefix match-এ প্রায় সবাই ভুল পথ নেয়)। বেশিরভাগ ঘটনা টাইপের ভুল বা কনফিগারেশনের ভুল; কিছু ইচ্ছাকৃত।
• Route leak: সঠিক উৎস, কিন্তু ঘোষণা ভুল জায়গায় ছড়ানো — valley-free নিয়ম ভাঙা (অংশ ৪)।

প্রতিরক্ষার স্তরগুলো

1. Prefix filtering: Provider গ্রাহকের কাছ থেকে শুধু তার নিজের (আর তার গ্রাহকদের) prefix নেবে — তালিকা আসে IRR বা RPKI থেকে। সাথে max-prefix সীমা, আর private বা documentation-এর মতো “bogon” আর /24-এর চেয়ে নির্দিষ্ট IPv4 prefix বাতিল।
2. IRR (Internet Routing Registry): উন্মুক্ত ডেটাবেস, যেখানে নেটওয়ার্করা লিখে রাখে “এই prefix এই AS থেকে ঘোষিত হবে” (route object, RPSL ভাষায়, RFC 2622). দুর্বলতা: সব IRR-এ লেখার অধিকার কঠোরভাবে যাচাই হয় না, আর পুরোনো তথ্য পড়ে থাকে।
3. RPKI আর ROV: নিচে বিস্তারিত — cryptography দিয়ে যাচাইযোগ্য “কে কোন prefix-এর উৎস হতে পারে”.
4. BGPsec (RFC 8205, ২০১৭): পথের প্রতিটি AS স্বাক্ষর দেয়, তাই পুরো AS_PATH যাচাই করা যায়; কিন্তু ভারী আর সবার অংশগ্রহণ লাগে বলে প্রায় চালু হয়নি। হালকা বিকল্প ASPA (provider-সম্পর্ক যাচাই) নিয়ে IETF-এ কাজ চলছে।
5. MANRS: Mutually Agreed Norms for Routing Security — ২০১৪ সালে শুরু হওয়া একটি স্বেচ্ছামূলক উদ্যোগ (Internet Society-র সহায়তায়), যেখানে নেটওয়ার্করা কয়েকটি ন্যূনতম কাজের প্রতিশ্রুতি দেয়: filtering, জাল উৎস-ঠিকানা ঠেকানো (ingress filtering), যোগাযোগের তথ্য হালনাগাদ রাখা, আর নিজের routing তথ্য IRR/RPKI-তে প্রকাশ।

RPKI, ROA আর ROV

RPKI (Resource Public Key Infrastructure, RFC 6480) হলো ঠিকানা-বণ্টনের পথ ধরে একটি certificate-এর শিকল: RIR প্রতিটি সদস্যকে certificate দেয়, যাতে লেখা থাকে কোন ঠিকানা-ব্লক তার। সেই certificate দিয়ে ঠিকানার মালিক সই করে একটি ROA (Route Origin Authorization) বানায়: “prefix 203.0.113.0/24, maxLength 24, উৎস AS64500” — অর্থাৎ এই prefix (বা maxLength পর্যন্ত তার ভেতরের অংশ) শুধু AS64500 ঘোষণা করতে পারবে। ISP-র validator software সব RIR-এর repository থেকে ROA নামিয়ে স্বাক্ষর যাচাই করে তালিকা router-এ পাঠায় (RPKI-to-Router protocol, RFC 8210).

Router প্রতিটি ঘোষণার শুধু উৎস যাচাই করে — একে বলে Route Origin Validation (ROV), RFC 6811. নিয়ম:

• NotFound: কোনো ROA এই prefix-কে ঢাকে না — কিছু বলা যায় না (আজও অনেক prefix-এর ROA নেই)। সাধারণত গ্রহণ করা হয়।
• Valid: অন্তত একটি ঢাকা ROA-তে উৎস ASN মেলে আর prefix-এর দৈর্ঘ্য maxLength-এর মধ্যে।
• Invalid: ঢাকা ROA আছে, কিন্তু একটিও মেলেনি — ভুল উৎস, বা অনুমতির চেয়ে বেশি নির্দিষ্ট prefix. ROV চালু নেটওয়ার্ক এটি ফেলে দেয়।

এবার ROV-এর নিয়মটি কোডে। দুটি ROA 203.0.113.0/24-এর জন্য (একটি মালিকের, একটি ধরা যাক তার DDoS-সুরক্ষা সেবাদাতার, যে প্রয়োজনে prefix-টি ঘোষণা করে), আর একটি 192.0.2.0/24-এর জন্য maxLength 25 দিয়ে। covers দেখে ROA-র prefix ঘোষণাটিকে ঢাকে কি না (পর্ব ১৬–১৭-এর mask-এর হিসাব)।

// Route Origin Validation (RFC 6811) for IPv4 announcements.
const roas = [   // [prefix, maxLength, origin ASN] - signed objects from the RPKI
  ["203.0.113.0/24", 24, 64500],
  ["203.0.113.0/24", 24, 64510],   // a second ROA: e.g. a DDoS-protection provider
  ["192.0.2.0/24", 25, 64501],
];
const anns = [   // [prefix, origin ASN] as seen in BGP UPDATEs
  ["203.0.113.0/24", 64500], ["203.0.113.0/24", 64510], ["203.0.113.0/24", 64511],
  ["203.0.113.0/25", 64511], ["203.0.113.128/25", 64500],
  ["192.0.2.128/25", 64501], ["192.0.2.0/26", 64501], ["198.51.100.0/24", 64502],
];
const toInt = ip => ip.split(".").reduce((a, o) => a * 256 + Number(o), 0);
const parse = p => { const [ip, len] = p.split("/"); return { net: toInt(ip), len: +len }; };
const mask = len => (len === 0 ? 0 : (0xffffffff << (32 - len)) >>> 0);
const covers = (roa, r) => roa.len <= r.len && ((r.net & mask(roa.len)) >>> 0) === roa.net;
function validate(prefix, origin) {
  const r = parse(prefix);
  const covering = roas.filter(([p]) => covers(parse(p), r));
  if (covering.length === 0) return ["NOT-FOUND", "no ROA covers this prefix"];
  const match = covering.find(([, maxLen, asn]) => asn === origin && r.len <= maxLen);
  if (match) return ["VALID", `ROA ${match[0]} max /${match[1]} AS${match[2]}`];
  const why = covering.some(([, , asn]) => asn === origin) ? "longer than maxLength" : "wrong origin AS";
  return ["INVALID", why];
}
console.log("announcement          origin    state      reason");
for (const [p, asn] of anns) {
  const [state, why] = validate(p, asn);
  console.log(`${p.padEnd(20)}  AS${asn}   ${state.padEnd(9)}  ${why}`);
}

announcement          origin    state      reason
203.0.113.0/24        AS64500   VALID      ROA 203.0.113.0/24 max /24 AS64500
203.0.113.0/24        AS64510   VALID      ROA 203.0.113.0/24 max /24 AS64510
203.0.113.0/24        AS64511   INVALID    wrong origin AS
203.0.113.0/25        AS64511   INVALID    wrong origin AS
203.0.113.128/25      AS64500   INVALID    longer than maxLength
192.0.2.128/25        AS64501   VALID      ROA 192.0.2.0/24 max /25 AS64501
192.0.2.0/26          AS64501   INVALID    longer than maxLength
198.51.100.0/24       AS64502   NOT-FOUND  no ROA covers this prefix

শেখার জন্য দেখার টুল

অনেক ISP-র looking glass, University of Oregon-এর Route Views আর RIPE NCC-র RIS-এর মতো route collector, আর RIR-দের RPKI ও whois-এর তথ্যে ইন্টারনেটের BGP নিজের চোখে দেখা যায়। এগুলো শুধু দেখার জন্য — নিজের নয় এমন নেটওয়ার্কে কিছু ঘোষণা বা পরীক্ষা করবেন না।

৯ · AI-এর যুগে BGP

BGP-র প্রশ্নে AI দ্রুত গোছানো উত্তর দেয়, কিন্তু এখানে একটি ভুল filter পুরো ইন্টারনেটে ছড়াতে পারে। AI যে ভুলগুলো প্রায়ই করে:

AI-এর উত্তর মানার আগে — চেকলিস্ট

• Best-path-এর ক্রম আর প্রতিটি attribute-এর দিক (বেশি না কম ভালো) RFC 4271 আর নিজের vendor-এর ডকুমেন্টেশনে মিলিয়েছি
• উদাহরণে শুধু documentation ASN আর prefix আছে; আসল নম্বর থাকলে বদলে নিয়েছি
• প্রতিটি eBGP প্রতিবেশীর in আর out filter আর max-prefix সীমা আছে
• কনফিগারেশন আগে VM বা ল্যাবে (যেমন কয়েকটি FRRouting container) চালিয়ে show কমান্ড আর packet capture দিয়ে দেখেছি
• ROA বানানো বা বদলানোর আগে maxLength আর সব উৎস-AS (যেমন DDoS সেবাদাতা) মিলিয়েছি, যাতে নিজের route Invalid না হয়