DHCP আর ARP — ঠিকানা পাওয়া আর MAC খোঁজা

১ · নতুন যন্ত্রের দুটি প্রশ্ন — “আমি কে?” আর “পাশের জন কোথায়?”

আপনি একটি ক্যাফেতে বসে ফোনে Wi-Fi-র password দিলেন। পর্ব ১৪-এ দেখেছেন, ফোন access point-এর সাথে association আর 4-way handshake শেষ করল — এখন সে বাতাসে encrypted frame পাঠাতে পারে। কিন্তু একটি ওয়েবসাইট খুলতে এখনো অনেক কিছু অজানা। ফোনের নিজের IP ঠিকানা কী? এই নেটওয়ার্কের subnet কত বড়, অর্থাৎ কারা “পাশের বাড়ি”? বাইরে যাওয়ার দরজা (default gateway) কোনটি? আর নাম থেকে ঠিকানা বের করার DNS server কোথায়? এই চারটি তথ্য না জানলে ফোন একটি packet-ও ঠিকমতো পাঠাতে পারবে না।

চারটি তথ্য জানার পরেও আরেকটি সমস্যা থাকে, এবং সেটি আসে প্রতিটি packet পাঠানোর সময়। পর্ব ১২-এ দেখেছেন, LAN-এ frame যায় MAC ঠিকানা ধরে, IP ঠিকানা ধরে নয়। ফোন জানে gateway-র IP 192.168.10.1, কিন্তু frame-এর গন্তব্যের ঘরে লিখতে হবে ৪৮ bit-এর একটি MAC. সেটি কোথা থেকে আসবে?

“সংখ্যার ঠিকানায় (যেমন 203.0.113.10) ping চলে, কিন্তু কোনো সাইট খোলে না” — প্রায়ই DNS-এর সমস্যা (পর্ব ৩৫)। Mask আর subnet-এর হিসাব পর্ব ১৬–১৭-এ; এখানে শুধু এটুকু: /24-এ প্রথম তিনটি সংখ্যা মিললে দুটি যন্ত্র একই subnet-এ।

হাতে বসানো (static) বনাম স্বয়ংক্রিয় (dynamic)

চারটি তথ্য দুইভাবে দেওয়া যায়। Static কনফিগারেশন-এ প্রশাসক নিজে প্রতিটি যন্ত্রে লিখে দেন। Dynamic-এ যন্ত্র চালু হয়ে নিজেই নেটওয়ার্কের কাছে চেয়ে নেয় — আজকের প্রায় সব ফোন, ল্যাপটপ আর বাসার যন্ত্র এভাবেই চলে।

আর ARP সবসময় চলে, প্রতিটি IPv4 যন্ত্রে, স্বয়ংক্রিয়ভাবে — এটি বন্ধ হলে Ethernet বা Wi-Fi-তে একটি IPv4 packet-ও যায় না। ARP-এর বার্তা IP packet-এর ভেতরে যায় না, সরাসরি Ethernet frame-এর ভেতরে (EtherType 0x0806) — তাই অনেকে একে “layer 2 আর 3-এর মাঝের” protocol বলেন।

২ · DORA — চারটি বার্তায় ঠিকানা পাওয়া

DHCP-র মূল কথোপকথনে চারটি বার্তা, যাদের প্রথম অক্ষর মিলিয়ে নাম DORA: Discover (“কোনো DHCP server আছেন?”), Offer (“আমি আছি, এই ঠিকানাটি নিতে পারেন”), Request (“আমি এই server-এর এই ঠিকানাটিই চাই”), Ack (“ঠিক আছে, এত সময়ের জন্য আপনার”). শুরুর আগে তিনটি ধাঁধা বোঝা দরকার, কারণ পরীক্ষা আর ইন্টারভিউতে এগুলোই জিজ্ঞেস করা হয়।

ধাঁধা ১ — যার ঠিকানা নেই, সে packet পাঠায় কীভাবে?

IP packet-এ উৎস ঠিকানার ঘর খালি রাখা যায় না। তাই client লেখে 0.0.0.0 — মানে “এই নেটওয়ার্কের এই যন্ত্র, যার এখনো ঠিকানা নেই”. গন্তব্য কে, তা-ও সে জানে না — server-এর ঠিকানা তো অজানা। তাই গন্তব্য 255.255.255.255, যার নাম limited broadcast: “এই LAN-এর সবাই”. Router এমন packet কখনো অন্য নেটওয়ার্কে পাঠায় না। Ethernet frame-এর গন্তব্যও broadcast ff:ff:ff:ff:ff:ff, তাই switch এটি সব port-এ flood করে (পর্ব ১২) — VLAN থাকলে শুধু সেই VLAN-এর port-এ (পর্ব ১৩)।

ধাঁধা ২ — কেন UDP, আর কেন দুটি নির্দিষ্ট port?

TCP-তে কথা শুরুর আগে দুই পক্ষের ঠিকানা-জানা একটি সংযোগ লাগে (পর্ব ২৯) — যার ঠিকানাই নেই, সে সংযোগ বানাবে কীভাবে? তাই DHCP চলে UDP-র ওপর (UDP-র বিস্তারিত পর্ব ২৮-এ)। Server শোনে port 67-এ, client 68-এ। সাধারণ client প্রোগ্রাম অস্থায়ী ephemeral port নেয়, কিন্তু DHCP client-এর port স্থির, কারণ server-এর উত্তর প্রায়ই broadcast হয়ে সব যন্ত্রে পৌঁছায় — এলোমেলো port হলে অন্য যন্ত্রের অন্য কোনো প্রোগ্রাম ভুল বার্তা পেত। UDP reliability দেয় না, তাই উত্তর না এলে client নিজেই আবার পাঠায়, প্রতিবার অপেক্ষা প্রায় দ্বিগুণ করে।

ধাঁধা ৩ — কোন উত্তর কোন প্রশ্নের, আর উত্তর পৌঁছাবে কীভাবে?

একসাথে দশটি ল্যাপটপ খুললে দশটি কথোপকথন চলে, সব broadcast. প্রতিটি client একটি এলোমেলো ৩২ bit-এর transaction ID (xid) বাছে, server প্রতিটি উত্তরে সেটি ফেরত দেয়, আর client শুধু নিজের xid (আর chaddr-এ নিজের MAC)-ওয়ালা উত্তর নেয়। আর উত্তর পৌঁছানো: server Offer-টি client-এর নতুন ঠিকানায় unicast করতে পারে, কিন্তু অনেক TCP/IP stack ঠিকানা কনফিগার হওয়ার আগে নিজের নামে আসা unicast IP packet গ্রহণই করে না। তাই এমন client Discover-এ broadcast flag (flags ঘরের সবচেয়ে বাঁ দিকের bit, 0x8000) চালু করে বলে: “উত্তর broadcast করে পাঠাবেন।” Flag বন্ধ থাকলে server সাধারণত Offer পাঠায় নতুন ঠিকানায়, frame-এর গন্তব্য client-এর MAC দিয়ে — ARP ছাড়াই, কারণ MAC তো Discover-এই লেখা ছিল।

এবার পুরো কথোপকথন। অফিসের LAN 192.168.10.0/24, router R1 নিজেই DHCP server (বাসার Wi-Fi router-এর মতো): ঠিকানা 192.168.10.1, MAC 02:aa:00:00:00:01. নতুন ল্যাপটপের MAC 02:aa:00:00:00:0a. টেবিলে MAC-এর শেষ byte-টুকুই দেখানো হয়েছে।

DHCP বার্তার ভেতরে — BOOTP-এর কাঠামো আর option

প্রতিটি DHCP বার্তার শুরুতে BOOTP-এর একটি স্থির অংশ (২৩৬ byte), তারপর একটি চার byte-এর “magic cookie” 63 82 53 63, তারপর option-গুলো। Option-এর গঠন সরল: ১ byte কোড, ১ byte দৈর্ঘ্য, তারপর মান — শেষে কোড 255 (end).

 DHCP বার্তা (UDP payload)                                    (bytes)
┌────┬──────┬──────┬──────┬──────────────┬──────┬──────────────┐
│ op │htype │ hlen │ hops │ xid (4)      │ secs │ flags        │   op: 1 = request, 2 = reply
│ 1  │  1   │  1   │  1   │              │  2   │ 2 (B bit)    │
├────┴──────┴──────┴──────┼──────────────┴──────┴──────────────┤
│ ciaddr (4) client-এর বর্তমান IP │ yiaddr (4) “আপনার” নতুন IP │
├─────────────────────────┼────────────────────────────────────┤
│ siaddr (4) পরের server  │ giaddr (4) relay agent-এর IP       │
├─────────────────────────┴────────────────────────────────────┤
│ chaddr (16) client-এর MAC + padding                         │
│ sname (64) + file (128) — BOOTP-এর পুরোনো ঘর, প্রায়ই শূন্য │
├──────────────────────────────────────────────────────────────┤
│ magic cookie 63 82 53 63 │ options: কোড │ দৈর্ঘ্য │ মান … 255  │
└──────────────────────────────────────────────────────────────┘

নম্বরগুলো RFC 2132 আর পরের কয়েকটি RFC অনুযায়ী (option 82 এসেছে RFC 3046 থেকে); পরীক্ষায় সাধারণত 1, 3, 6, 51, 53 আর 54 জিজ্ঞেস হয়। প্রতিটি option-এর পুরো, হালনাগাদ তালিকা IANA-র “BOOTP and DHCP Parameters” রেজিস্ট্রিতে থাকে — কোনো বই বা AI নতুন কোনো নম্বর বললে সেখানে মিলিয়ে নেওয়াই নিরাপদ।

৩ · Lease — ঠিকানা ভাড়া, নবায়ন আর ফেরত

DHCP-র সবচেয়ে চতুর ধারণা হলো lease: ঠিকানা চিরদিনের জন্য দেওয়া হয় না, নির্দিষ্ট সময়ের জন্য ভাড়া দেওয়া হয়। কেন? কারণ যন্ত্র প্রায়ই বিদায় না বলে চলে যায় — ফোনের চার্জ শেষ, ল্যাপটপ বন্ধ করে ব্যাগে। ঠিকানা স্থায়ী হলে কিছুদিনের মধ্যেই pool ফুরিয়ে যেত। Lease-এর মেয়াদ শেষ হলে server নিশ্চিন্তে ঠিকানাটি অন্য কাউকে দিতে পারে।

কিন্তু যে যন্ত্রটি এখনো আছে, তার সংযোগ যেন মাঝপথে না কাটে। তাই client মেয়াদ শেষের অনেক আগেই নবায়ন শুরু করে, দুটি টাইমার ধরে:

একটি হাতে-কলমে হিসাব

একটি ল্যাপটপ সকাল ৯:০০-এ ৮ ঘণ্টার lease পেল (২৮,৮০০ সেকেন্ড)। T1 = ২৮,৮০০ × ০.৫ = ১৪,৪০০ সেকেন্ড = ৪ ঘণ্টা → দুপুর ১:০০-এ প্রথম নবায়নের চেষ্টা। T2 = ২৮,৮০০ × ০.৮৭৫ = ২৫,২০০ সেকেন্ড = ৭ ঘণ্টা → বিকেল ৪:০০-এ rebinding. মেয়াদ শেষ বিকেল ৫:০০-এ। দুপুর ১:০০-এ server সাড়া দিলে নতুন lease শুরু ১:০০ থেকে, আর পরের T1 বিকেল ৫:০০-এ। অর্থাৎ সব ঠিক থাকলে client প্রতি ৪ ঘণ্টায় একবার server-এর সাথে কথা বলে, আর তার ঠিকানা কখনো বদলায় না।

T1 আর T2-এর মাঝে client বারবার চেষ্টা করে। RFC 2131-এর পরামর্শ: প্রতিবার পরের সীমা (T2 বা মেয়াদ শেষ) পর্যন্ত বাকি সময়ের অর্ধেক অপেক্ষা, তবে ৬০ সেকেন্ডের কম নয়। নিচের simulator প্রথমে পুরো DORA ছাপে, তারপর ৩,৬০০ সেকেন্ডের একটি lease-এর সময়রেখা চালায়, যেখানে server ৩,০০০ সেকেন্ডে বন্ধ হয়ে যায়।

// DHCP DORA on one LAN, then the lease timeline (T1 = 50%, T2 = 87.5%).
const CMAC = "02:aa:00:00:00:0a", SIP = "192.168.10.1", SMAC = "02:aa:00:00:00:01";
const BIP = "255.255.255.255", BMAC = "ff:ff:ff:ff:ff:ff", xid = "0x5a1c2e7b";
const lease = 3600, ip = "192.168.10.11";
function msg(type, sIP, sp, dIP, dp, sMAC, dMAC, opts) {
  console.log(`${type.padEnd(8)} IP  ${sIP}:${sp} -> ${dIP}:${dp}   xid=${xid}`);
  console.log(`         MAC ${sMAC} -> ${dMAC}`);
  console.log(`         ${opts}`);
}
msg("DISCOVER", "0.0.0.0", 68, BIP, 67, CMAC, BMAC, "opt53=1 opt55=[1,3,6,51] flags=0x8000 (broadcast)");
msg("OFFER", SIP, 67, BIP, 68, SMAC, BMAC, `opt53=2 yiaddr=${ip} opt1=255.255.255.0 opt3=${SIP} opt6=${SIP} opt51=${lease} opt54=${SIP}`);
msg("REQUEST", "0.0.0.0", 68, BIP, 67, CMAC, BMAC, `opt53=3 opt50=${ip} opt54=${SIP}`);
msg("ACK", SIP, 67, BIP, 68, SMAC, BMAC, `opt53=5 yiaddr=${ip} opt51=${lease} opt58=${lease / 2} opt59=${lease * 7 / 8}`);

console.log("\n--- lease timeline (server goes down at t=3000 s) ---");
const up = t => t < 3000;
const log = (t, s) => console.log(String(t).padStart(5) + " s  " + s);
let t0 = 0; log(0, `BOUND: ${ip}, lease ${lease} s`);
while (true) {
  const T1 = t0 + lease / 2, T2 = t0 + lease * 7 / 8, end = t0 + lease;
  let t = T1, renewed = false;
  for (const [phase, until, how] of [["RENEWING", T2, "unicast REQUEST to " + SIP],
                                      ["REBINDING", end, "broadcast REQUEST to any server"]]) {
    for (; t < until; t += Math.max(60, Math.floor((until - t) / 2))) {
      if (up(t)) { log(t, `${phase}: ${how} -> ACK, new lease`); renewed = true; break; }
      log(t, `${phase}: ${how} -> no reply`);
    }
    if (renewed) break;
    t = until;
  }
  if (renewed) { t0 = t; continue; }
  log(end, `EXPIRED: stop using ${ip}, back to INIT -> new DISCOVER`); break;
}

DISCOVER IP  0.0.0.0:68 -> 255.255.255.255:67   xid=0x5a1c2e7b
         MAC 02:aa:00:00:00:0a -> ff:ff:ff:ff:ff:ff
         opt53=1 opt55=[1,3,6,51] flags=0x8000 (broadcast)
OFFER    IP  192.168.10.1:67 -> 255.255.255.255:68   xid=0x5a1c2e7b
         MAC 02:aa:00:00:00:01 -> ff:ff:ff:ff:ff:ff
         opt53=2 yiaddr=192.168.10.11 opt1=255.255.255.0 opt3=192.168.10.1 opt6=192.168.10.1 opt51=3600 opt54=192.168.10.1
REQUEST  IP  0.0.0.0:68 -> 255.255.255.255:67   xid=0x5a1c2e7b
         MAC 02:aa:00:00:00:0a -> ff:ff:ff:ff:ff:ff
         opt53=3 opt50=192.168.10.11 opt54=192.168.10.1
ACK      IP  192.168.10.1:67 -> 255.255.255.255:68   xid=0x5a1c2e7b
         MAC 02:aa:00:00:00:01 -> ff:ff:ff:ff:ff:ff
         opt53=5 yiaddr=192.168.10.11 opt51=3600 opt58=1800 opt59=3150

--- lease timeline (server goes down at t=3000 s) ---
    0 s  BOUND: 192.168.10.11, lease 3600 s
 1800 s  RENEWING: unicast REQUEST to 192.168.10.1 -> ACK, new lease
 3600 s  RENEWING: unicast REQUEST to 192.168.10.1 -> no reply
 4275 s  RENEWING: unicast REQUEST to 192.168.10.1 -> no reply
 4612 s  RENEWING: unicast REQUEST to 192.168.10.1 -> no reply
 4781 s  RENEWING: unicast REQUEST to 192.168.10.1 -> no reply
 4865 s  RENEWING: unicast REQUEST to 192.168.10.1 -> no reply
 4925 s  RENEWING: unicast REQUEST to 192.168.10.1 -> no reply
 4950 s  REBINDING: broadcast REQUEST to any server -> no reply
 5175 s  REBINDING: broadcast REQUEST to any server -> no reply
 5287 s  REBINDING: broadcast REQUEST to any server -> no reply
 5347 s  REBINDING: broadcast REQUEST to any server -> no reply
 5400 s  EXPIRED: stop using 192.168.10.11, back to INIT -> new DISCOVER

বাকি চারটি বার্তা — Release, Decline, Nak, Inform

ল্যাপটপ আবার চালু হলে বা Wi-Fi আবার যুক্ত হলে client সাধারণত পুরো DORA না করে আগের ঠিকানার জন্য সরাসরি broadcast Request পাঠায় (INIT-REBOOT): server রাজি হলে ACK, অন্য নেটওয়ার্কে এলে NAK. এজন্যই বাসার Wi-Fi-তে ফোন প্রায়ই প্রতিদিন একই ঠিকানা পায়।

৪ · অনেক VLAN, একটি server — relay agent, reservation আর APIPA

পর্ব ১৩-এর অফিসে মনে করুন: হিসাব VLAN 10 (192.168.10.0/24), HR VLAN 20 (192.168.20.0/24), সার্ভারগুলো VLAN 99 (192.168.99.0/24). এখন DHCP server একটিই, 192.168.99.10, সার্ভারের VLAN-এ। সমস্যা: VLAN 20-এর একটি ল্যাপটপের Discover একটি broadcast, আর broadcast নিজের VLAN-এর (broadcast domain-এর) বাইরে যায় না; router 255.255.255.255 কখনো অন্য নেটওয়ার্কে পাঠায় না। তাহলে কি প্রতিটি VLAN-এ আলাদা DHCP server লাগবে?

না — সমাধান DHCP relay agent. যে router বা layer-3 switch VLAN 20-এর gateway (পর্ব ১৩-এর SVI বা subinterface), সেটিই relay-র কাজ করে। সে VLAN 20-এর broadcast Discover ধরে, তাতে নিজের সেই VLAN-এর ঠিকানাটি giaddr ঘরে লিখে, server-এর কাছে সাধারণ unicast packet হিসেবে route করে পাঠায়। giaddr দুটি কাজ করে: server বোঝে কোন subnet-এর pool থেকে ঠিকানা দিতে হবে, আর উত্তর কোথায় ফেরত পাঠাতে হবে।

interface Vlan20
 ip address 192.168.20.1 255.255.255.0
 ip helper-address 192.168.99.10      ! এই VLAN-এর DHCP broadcast এই server-এ যাবে
!
interface Vlan10
 ip address 192.168.10.1 255.255.255.0
 ip helper-address 192.168.99.10

এটি একটি উদাহরণ, চালানোর কোড নয়। Cisco-তে ip helper-address ডিফল্টে DHCP ছাড়াও আরও কয়েকটি UDP broadcast সেবা forward করে (তালিকা মডেলভেদে আলাদা); অন্য vendor আর Linux-এ নাম ভিন্ন, ধারণা একই। Relay না থাকলে সাধারণ লক্ষণ: একটি নির্দিষ্ট VLAN-এর সবাই 169.254.x.x পাচ্ছে, অন্য VLAN ঠিক আছে।

Reservation — DHCP দিয়েই স্থির ঠিকানা

অফিসের প্রিন্টারের ঠিকানা প্রতি সপ্তাহে বদলালে সবার কম্পিউটারে প্রিন্টার “অফলাইন” দেখাবে। আবার প্রিন্টারে হাতে ঠিকানা বসালে কেউ ভুলে সেই ঠিকানা DHCP pool-এও রেখে দিতে পারে। Reservation দুই দিকের সুবিধা দেয়: server-এ লেখা থাকে “MAC 02:aa:00:00:00:50 সবসময় 192.168.10.50 পাবে”. প্রিন্টার সাধারণ DORA-ই করে, কিন্তু সবসময় এই ঠিকানাটিই পায়; বাসার router-এর পাতায় এর নাম প্রায়ই “Address Reservation”. একটি সাবধানতা: আধুনিক ফোন প্রতিটি Wi-Fi-তে আলাদা এলোমেলো MAC ব্যবহার করতে পারে (MAC randomization, পর্ব ১২), তাই ফোনের জন্য reservation সবসময় কাজ করে না।

কেউ সাড়া না দিলে — APIPA আর 169.254.x.x

DHCP server বন্ধ, তার ঢিলা, বা relay ভুল — client বারবার Discover পাঠিয়েও কোনো Offer পেল না। তখন কী? Windows, macOS আর অনেক প্রিন্টার নিজে নিজে একটি link-local ঠিকানা বেছে নেয় 169.254.0.0/16 থেকে (RFC 3927; প্রথম আর শেষ /24 সংরক্ষিত, তাই আসলে 169.254.1.0 থেকে 169.254.254.255). Microsoft এর নাম দিয়েছে APIPA (Automatic Private IP Addressing). যন্ত্রটি এলোমেলো একটি ঠিকানা বাছে, ARP probe দিয়ে দেখে কেউ সেটি ব্যবহার করছে কি না, তারপর নেয়। এতে একই তারের দুটি যন্ত্র router ছাড়াই কথা বলতে পারে, কিন্তু gateway নেই, তাই ইন্টারনেট নেই; আর পটভূমিতে DHCP-র চেষ্টা চলতেই থাকে। Linux-এ এই আচরণ বিতরণভেদে আলাদা — অনেক ব্যবস্থায় ডিফল্টে চালু থাকে না।

নিজের যন্ত্রে DHCP দেখা

নিচের কমান্ডগুলো একটি সাধারণ ল্যাপটপের, এই পাতায় চলবে না। Windows-এ ipconfig /all দেখায় “DHCP Enabled”, “DHCP Server”, “Lease Obtained” আর “Lease Expires”; /release আর /renew দিয়ে নিজে Release আর নতুন DORA করানো যায়:

PS> ipconfig /all          # DHCP Server, Lease Obtained, Lease Expires
PS> ipconfig /release      # DHCPRELEASE পাঠায়, ঠিকানা ছেড়ে দেয়
PS> ipconfig /renew        # নতুন করে ঠিকানা চায়
PS> Get-NetIPAddress -AddressFamily IPv4 | Format-Table InterfaceAlias, IPAddress, PrefixOrigin

Linux-এ DHCP client বিতরণভেদে আলাদা (NetworkManager, systemd-networkd, dhcpcd, পুরোনো dhclient). পর্ব ৬-এ দেখেছেন, ip addr-এর dynamic আর valid_lft বলে ঠিকানাটি DHCP-র আর lease-এর কত সেকেন্ড বাকি; ip route-এর proto dhcp বলে gateway-ও DHCP দিয়েছে।

৫ · ARP — IP জানা, MAC অজানা

এবার দ্বিতীয় প্রশ্ন। ল্যাপটপটি এখন BOUND — এখন থেকে এর নাম PC-A: 192.168.10.11, MAC 02:aa:00:00:00:0a. একই LAN-এ আছে PC-B (192.168.10.12, MAC …:0b) আর router R1 (192.168.10.1, MAC …:01). PC-A এখন PC-B-র একটি ফাইল শেয়ারে packet পাঠাতে চায়। IP header লেখা সহজ, কিন্তু Ethernet বা Wi-Fi-তে frame পাঠাতে গন্তব্য MAC লাগবে। IP ঠিকানা আর MAC-এর মধ্যে কোনো গাণিতিক সম্পর্ক নেই — MAC নির্মাতা কারখানায় বসায় (পর্ব ১২), IP দেয় নেটওয়ার্ক। তাই জিজ্ঞেস করে জানতেই হবে। এই জিজ্ঞাসার নিয়মই ARP (Address Resolution Protocol, RFC 826).

• ARP request — broadcast: “192.168.10.12 কার? 192.168.10.11-কে (MAC …:0a) জানান।” Frame-এর গন্তব্য ff:ff:ff:ff:ff:ff, তাই LAN-এর (VLAN-এর) সবাই শোনে।
• ARP reply — unicast: যার ঠিকানা 192.168.10.12, শুধু সে উত্তর দেয়, সরাসরি প্রশ্নকারীর MAC-এ: “192.168.10.12 আমার, আমার MAC …:0b.” বাকিরা request দেখে চুপচাপ ফেলে দেয়।
• দুই দিকেই শেখা: request-এর ভেতরেই প্রশ্নকারীর IP আর MAC থাকে, তাই উত্তরদাতাও তাকে cache-এ লিখে রাখে; অন্যরা (RFC 826 অনুযায়ী) শুধু আগে থেকে থাকা entry হালনাগাদ করে।

ARP packet-এর প্রতিটি ঘর

ARP নকশা করা হয়েছিল সাধারণভাবে — যেকোনো hardware ঠিকানা আর যেকোনো protocol ঠিকানার জন্য। তাই packet-এর শুরুতেই বলা থাকে কোন ধরনের ঠিকানা আর তাদের দৈর্ঘ্য কত। Ethernet আর IPv4-এর জন্য পুরো packet ২৮ byte:

 ARP packet (Ethernet frame-এর payload, EtherType 0x0806)          (bytes)
┌─────────────────────────┬─────────────────────────┐
│ htype = 1 (Ethernet)  2 │ ptype = 0x0800 (IPv4) 2 │
├────────────┬────────────┼─────────────────────────┤
│ hlen = 6  1│ plen = 4  1│ oper: 1 request, 2 reply 2│
├────────────┴────────────┴─────────────────────────┤
│ sender hardware address (SHA)               6     │
│ sender protocol address (SPA)               4     │
│ target hardware address (THA)               6     │   request-এ শূন্য
│ target protocol address (TPA)               4     │
└───────────────────────────────────────────────────┘
 মোট 28 byte; Ethernet-এর ন্যূনতম payload 46 byte, তাই বাকিটা padding

নিচের simulator একটি ARP request আর একটি DHCP Discover-কে byte ধরে বানায়, প্রতিটি ঘরের offset আর hex মান ছাপে। Wireshark-এর নিচের hex প্যানেলে ঠিক এই byte-গুলোই দেখবেন।

// Build an ARP request and a DHCP DISCOVER as bytes; print offset, field and hex.
const mac = s => s.split(":").map(h => parseInt(h, 16));
const ip4 = s => s.split(".").map(Number);
const u16 = n => [n >> 8, n & 255];
const u32 = n => [n >>> 24, (n >>> 16) & 255, (n >>> 8) & 255, n & 255];
const hex = a => a.length > 16 ? `00 x ${a.length}` : a.map(b => b.toString(16).padStart(2, "0")).join(" ");
function dump(title, fields) {
  console.log(title);
  let off = 0;
  for (const [name, bytes] of fields) {
    console.log(`  ${String(off).padStart(3)}  ${name.padEnd(22)} ${hex(bytes)}`);
    off += bytes.length;
  }
  console.log(`  total: ${off} bytes`);
}
const A = "02:aa:00:00:00:0a";
dump("ARP request (Ethernet payload, EtherType 0x0806)", [
  ["htype (1=Ethernet)", u16(1)], ["ptype (IPv4)", u16(0x0800)], ["hlen, plen", [6, 4]],
  ["oper (1=request)", u16(1)], ["sender MAC", mac(A)], ["sender IP", ip4("192.168.10.11")],
  ["target MAC (unknown)", mac("00:00:00:00:00:00")], ["target IP", ip4("192.168.10.1")],
]);
dump("\nDHCP DISCOVER (UDP payload, port 68 -> 67)", [
  ["op (1=BOOTREQUEST)", [1]], ["htype, hlen, hops", [1, 6, 0]], ["xid", u32(0x5a1c2e7b)],
  ["secs", u16(0)], ["flags (broadcast)", u16(0x8000)], ["ciaddr", ip4("0.0.0.0")],
  ["yiaddr", ip4("0.0.0.0")], ["siaddr", ip4("0.0.0.0")], ["giaddr", ip4("0.0.0.0")],
  ["chaddr (16 bytes)", [...mac(A), ...Array(10).fill(0)]], ["sname + file", Array(192).fill(0)],
  ["magic cookie", [0x63, 0x82, 0x53, 0x63]], ["opt 53 (DISCOVER)", [53, 1, 1]],
  ["opt 55 (want 1,3,6,51)", [55, 4, 1, 3, 6, 51]], ["opt 255 (end)", [255]],
]);

ARP request (Ethernet payload, EtherType 0x0806)
    0  htype (1=Ethernet)     00 01
    2  ptype (IPv4)           08 00
    4  hlen, plen             06 04
    6  oper (1=request)       00 01
    8  sender MAC             02 aa 00 00 00 0a
   14  sender IP              c0 a8 0a 0b
   18  target MAC (unknown)   00 00 00 00 00 00
   24  target IP              c0 a8 0a 01
  total: 28 bytes

DHCP DISCOVER (UDP payload, port 68 -> 67)
    0  op (1=BOOTREQUEST)     01
    1  htype, hlen, hops      01 06 00
    4  xid                    5a 1c 2e 7b
    8  secs                   00 00
   10  flags (broadcast)      80 00
   12  ciaddr                 00 00 00 00
   16  yiaddr                 00 00 00 00
   20  siaddr                 00 00 00 00
   24  giaddr                 00 00 00 00
   28  chaddr (16 bytes)      02 aa 00 00 00 0a 00 00 00 00 00 00 00 00 00 00
   44  sname + file           00 x 192
  236  magic cookie           63 82 53 63
  240  opt 53 (DISCOVER)      35 01 01
  243  opt 55 (want 1,3,6,51) 37 04 01 03 06 33
  249  opt 255 (end)          ff
  total: 250 bytes

৬ · অন্য subnet-এ পাঠানো — ARP হয় gateway-র জন্য

এটি নেটওয়ার্কিংয়ের সবচেয়ে প্রচলিত ইন্টারভিউ প্রশ্নগুলোর একটি: “আপনার PC 192.168.10.11/24, gateway 192.168.10.1. আপনি 203.0.113.80-এর একটি ওয়েব সার্ভার খুললেন। PC কার MAC-এর জন্য ARP করবে?” অনেকে বলেন “ওয়েব সার্ভারের” — ভুল। ARP-এর request broadcast, আর broadcast router পার হয় না; ওয়েব সার্ভার হাজার কিলোমিটার দূরে, সে এই প্রশ্ন কখনো শুনবেই না। সঠিক উত্তর: PC ARP করে default gateway 192.168.10.1-এর MAC-এর জন্য। Frame-এর গন্তব্য MAC হয় router-এর, কিন্তু ভেতরের IP packet-এর গন্তব্য থাকে 203.0.113.80.

সিদ্ধান্তটি host নেয় একটি সরল হিসাবে: নিজের ঠিকানা আর গন্তব্য — দুটোকেই নিজের subnet mask দিয়ে bit-ধরে AND করে। ফল মিললে গন্তব্য একই subnet-এ (সরাসরি পাঠানো), না মিললে বাইরে (gateway-র কাছে)। বাস্তবে Linux এই কাজটি করে routing table দেখে (পর্ব ২২-এর longest prefix match), কিন্তু একটি সাধারণ host-এর জন্য ফল একই:

নিজের ঠিকানা   192.168.10.11  AND 255.255.255.0 = 192.168.10.0
গন্তব্য ১      192.168.10.12  AND 255.255.255.0 = 192.168.10.0   → মিলেছে: ARP করুন 192.168.10.12-এর জন্য
গন্তব্য ২      203.0.113.80   AND 255.255.255.0 = 203.0.113.0    → মেলেনি: ARP করুন gateway 192.168.10.1-এর জন্য

ARP cache — মনে রাখা, আর সময়মতো ভুলে যাওয়া

প্রতিটি packet-এর আগে ARP করলে LAN broadcast-এ ভরে যেত। তাই উত্তর জমা থাকে ARP cache-এ (Linux-এ নাম neighbour table). কিন্তু চিরদিন নয় — PC-B-র network card বদলালে, বা অন্য একটি যন্ত্র একই ঠিকানা পেলে, পুরোনো MAC-এ পাঠানো frame হারিয়ে যাবে। তাই entry-র একটি মেয়াদ থাকে, যা OS-ভেদে অনেক আলাদা:

সংখ্যাগুলো ডিফল্ট আর সংস্করণভেদে বদলাতে পারে — নিজের যন্ত্রে দেখে নিন। নিচের simulator ছোট একটি LAN চালায়: PC-A প্রথমে PC-B-কে পাঠায়, তারপর ইন্টারনেটের সার্ভারে, তারপর অনেক পরে আবার PC-B-কে। সরল রাখতে প্রতিটি entry শেখার ৬০ সেকেন্ড পরে মেয়াদোত্তীর্ণ ধরা হয়েছে।

// One LAN 192.168.10.0/24 with router R1 (.1). Simplified: entries expire 60 s after learning.
const H = [["PC-A", "192.168.10.11", "0a"], ["PC-B", "192.168.10.12", "0b"], ["R1", "192.168.10.1", "01"]]
  .map(([name, ip, m]) => ({ name, ip, mac: "02:aa:00:00:00:" + m, cache: {} }));
const AGE = 60, GW = "192.168.10.1", onLink = ip => ip.startsWith("192.168.10.");
function arp(me, ip, t) {
  const e = me.cache[ip];
  if (e && t - e.t < AGE) { console.log(`  cache hit: ${ip} -> ${e.mac}`); return; }
  if (e) { console.log(`  entry for ${ip} is ${t - e.t} s old -> expired`); delete me.cache[ip]; }
  console.log(`  ARP request  ${me.mac} -> ff:ff:ff:ff:ff:ff  who has ${ip}? tell ${me.ip}`);
  const owner = H.find(h => h.ip === ip);
  owner.cache[me.ip] = { mac: me.mac, t };          // the target learns the asker
  console.log(`  ARP reply    ${owner.mac} -> ${me.mac}  ${ip} is-at ${owner.mac}`);
  me.cache[ip] = { mac: owner.mac, t };
}
function send(name, dst, t) {
  const me = H.find(h => h.name === name), hop = onLink(dst) ? dst : GW;
  console.log(`t=${t}s ${name} -> ${dst}: ` +
    (hop === dst ? "same subnet, ARP for the host itself" : `other subnet, ARP for gateway ${GW}`));
  arp(me, hop, t);
  console.log(`  frame: dst MAC ${me.cache[hop].mac}, dst IP ${dst}`);
}
function show(t) {
  for (const h of H) console.log(`  [${h.name}] ` + (Object.entries(h.cache)
    .map(([ip, e]) => `${ip} ${e.mac} age ${t - e.t}s`).join("; ") || "empty"));
}
send("PC-A", "192.168.10.12", 0);
send("PC-A", "192.168.10.12", 5);
send("PC-A", "203.0.113.80", 10);
console.log("caches at t=10s:"); show(10);
send("PC-A", "203.0.113.80", 40);
send("PC-A", "192.168.10.12", 75);
console.log("caches at t=75s:"); show(75);

t=0s PC-A -> 192.168.10.12: same subnet, ARP for the host itself
  ARP request  02:aa:00:00:00:0a -> ff:ff:ff:ff:ff:ff  who has 192.168.10.12? tell 192.168.10.11
  ARP reply    02:aa:00:00:00:0b -> 02:aa:00:00:00:0a  192.168.10.12 is-at 02:aa:00:00:00:0b
  frame: dst MAC 02:aa:00:00:00:0b, dst IP 192.168.10.12
t=5s PC-A -> 192.168.10.12: same subnet, ARP for the host itself
  cache hit: 192.168.10.12 -> 02:aa:00:00:00:0b
  frame: dst MAC 02:aa:00:00:00:0b, dst IP 192.168.10.12
t=10s PC-A -> 203.0.113.80: other subnet, ARP for gateway 192.168.10.1
  ARP request  02:aa:00:00:00:0a -> ff:ff:ff:ff:ff:ff  who has 192.168.10.1? tell 192.168.10.11
  ARP reply    02:aa:00:00:00:01 -> 02:aa:00:00:00:0a  192.168.10.1 is-at 02:aa:00:00:00:01
  frame: dst MAC 02:aa:00:00:00:01, dst IP 203.0.113.80
caches at t=10s:
  [PC-A] 192.168.10.12 02:aa:00:00:00:0b age 10s; 192.168.10.1 02:aa:00:00:00:01 age 0s
  [PC-B] 192.168.10.11 02:aa:00:00:00:0a age 10s
  [R1] 192.168.10.11 02:aa:00:00:00:0a age 0s
t=40s PC-A -> 203.0.113.80: other subnet, ARP for gateway 192.168.10.1
  cache hit: 192.168.10.1 -> 02:aa:00:00:00:01
  frame: dst MAC 02:aa:00:00:00:01, dst IP 203.0.113.80
t=75s PC-A -> 192.168.10.12: same subnet, ARP for the host itself
  entry for 192.168.10.12 is 75 s old -> expired
  ARP request  02:aa:00:00:00:0a -> ff:ff:ff:ff:ff:ff  who has 192.168.10.12? tell 192.168.10.11
  ARP reply    02:aa:00:00:00:0b -> 02:aa:00:00:00:0a  192.168.10.12 is-at 02:aa:00:00:00:0b
  frame: dst MAC 02:aa:00:00:00:0b, dst IP 192.168.10.12
caches at t=75s:
  [PC-A] 192.168.10.1 02:aa:00:00:00:01 age 65s; 192.168.10.12 02:aa:00:00:00:0b age 0s
  [PC-B] 192.168.10.11 02:aa:00:00:00:0a age 0s
  [R1] 192.168.10.11 02:aa:00:00:00:0a age 65s

এই container-এর neighbour table

এবার এই পাতার কোড যে container-এ চলে, তার আসল Linux kernel-এর ARP টেবিল। ip neigh আর /proc/net/arp একই টেবিলের দুটি জানালা (পর্ব ৬)। এখান থেকে বাইরে কিছু পাঠানো হচ্ছে না, তাই টেবিল খালি থাকতেই পারে — খালি মানে “এখনো কারও MAC জানার দরকার হয়নি”.

echo "== 1. neighbour (ARP) table: ip neigh =="
if command -v ip >/dev/null; then
  out=$(ip neigh show 2>/dev/null)
  if [ -n "$out" ]; then echo "$out"; else echo "(empty - no neighbour entries yet)"; fi
else
  echo "ip: not installed"
fi
echo "== 2. the same table from /proc/net/arp =="
cat /proc/net/arp
echo "rows after the header: $(tail -n +2 /proc/net/arp | wc -l)"
echo "== 3. routes: ip route =="
if command -v ip >/dev/null; then ip route show; else echo "ip: not installed"; fi
echo "== 4. default gateway decoded from /proc/net/route =="
while read -r ifc dst gw flags _; do
  [ "$dst" = "00000000" ] || continue
  printf 'default via %d.%d.%d.%d dev %s flags=%s\n' \
    "0x${gw:6:2}" "0x${gw:4:2}" "0x${gw:2:2}" "0x${gw:0:2}" "$ifc" "$flags"
done < <(tail -n +2 /proc/net/route)
echo "== 5. neighbour timers (Linux defaults can be tuned) =="
d=/proc/sys/net/ipv4/neigh/default
for f in base_reachable_time_ms gc_stale_time delay_first_probe_time; do
  [ -r "$d/$f" ] && echo "$f = $(cat "$d/$f")" || echo "$f: not readable"
done

== 1. neighbour (ARP) table: ip neigh ==
fe80::2 dev tap0 lladdr 52:56:00:00:00:02 router STALE
== 2. the same table from /proc/net/arp ==
IP address       HW type     Flags       HW address            Mask     Device
rows after the header: 0
== 3. routes: ip route ==
default via 10.0.2.2 dev tap0
10.0.2.0/24 dev tap0 proto kernel scope link src 10.0.2.100
== 4. default gateway decoded from /proc/net/route ==
default via 10.0.2.2 dev tap0 flags=0003
== 5. neighbour timers (Linux defaults can be tuned) ==
base_reachable_time_ms: not readable
gc_stale_time: not readable
delay_first_probe_time: not readable

একটি সাধারণ বাসার ল্যাপটপে একই কমান্ডের ফল দেখতে এমন (উদাহরণ, ঠিকানাগুলো এই পর্বের অফিসের মতো করে):

$ ip neigh
192.168.10.1 dev wlp2s0 lladdr 02:aa:00:00:00:01 REACHABLE
192.168.10.12 dev wlp2s0 lladdr 02:aa:00:00:00:0b STALE
192.168.10.30 dev wlp2s0 FAILED
$ cat /proc/net/arp
IP address       HW type     Flags       HW address            Mask     Device
192.168.10.1     0x1         0x2         02:aa:00:00:00:01     *        wlp2s0
192.168.10.12    0x1         0x2         02:aa:00:00:00:0b     *        wlp2s0
192.168.10.30    0x1         0x0         00:00:00:00:00:00     *        wlp2s0

REACHABLE = সম্প্রতি নিশ্চিত, STALE = পুরোনো কিন্তু ব্যবহারযোগ্য, FAILED = কোনো উত্তর আসেনি (কেউ নেই, বা অন্য VLAN-এ)। /proc/net/arp-এ Flags 0x2 = সম্পূর্ণ, 0x0 = অসম্পূর্ণ। Windows-এ arp -a বা Get-NetNeighbor.

৭ · ARP-এর বিশেষ রূপ — probe, gratuitous আর proxy ARP

ARP probe — “এই ঠিকানা কি কারও?”

DORA-র শেষ ধাপে দেখেছেন, নতুন ঠিকানা ব্যবহারের আগে client একবার যাচাই করে। এর নিয়ম RFC 5227-এ: ARP probe একটি সাধারণ ARP request, কিন্তু sender IP 0.0.0.0 — কারণ ঠিকানাটি এখনো নিজের নয়, অন্যদের cache-এ ভুল তথ্য ঢোকানো চলবে না। Target IP = যে ঠিকানাটি নিতে চাই। কেউ উত্তর দিলে ঠিকানাটি ব্যস্ত (DHCP হলে DHCPDECLINE). APIPA-ও ঠিক এভাবেই এলোমেলো 169.254 ঠিকানা যাচাই করে।

Gratuitous ARP — না চাইতেই ঘোষণা

Gratuitous ARP হলো এমন ARP বার্তা যা কেউ জিজ্ঞেস করেনি: একটি যন্ত্র নিজের IP-র জন্যই ARP পাঠায় (sender IP = target IP = নিজের ঠিকানা), সাধারণত broadcast-এ। এর তিনটি কাজ:

• ঘোষণা (ARP announcement): “এখন থেকে 192.168.10.11 আমি, MAC …:0a.” যাদের cache-এ এই IP-র পুরোনো MAC আছে, তারা হালনাগাদ করে নেয় — যেমন network card বদলানোর পরে।
• Duplicate ঠিকানা ধরা: ঘোষণার পর অন্য কেউ যদি একই IP দাবি করে উত্তর দেয়, তাহলে দুজনের ঠিকানা এক — Windows তখন “IP address conflict” সতর্কবার্তা দেখায়।
• Failover: দুটি router মিলে একটি “virtual gateway” ঠিকানা 192.168.10.1 রাখে (VRRP, Cisco-র HSRP-এর মতো protocol). মূল router বন্ধ হলে backup সেই ঠিকানা নিয়ে gratuitous ARP পাঠায়, আর switch ও host-রা কয়েক মুহূর্তে নতুন MAC শিখে নেয় — সংযোগ প্রায় কাটে না।

Proxy ARP — অন্যের হয়ে উত্তর

Proxy ARP-এ (RFC 1027, ১৯৮৭) একটি router অন্য নেটওয়ার্কের কোনো ঠিকানার জন্য আসা ARP request-এর উত্তর দেয় নিজের MAC দিয়ে — “এটি আমাকে দিন, আমি পৌঁছে দেব।” এর ইতিহাস ভাবনার প্রশ্ন ৫-এ। এটি ভুল mask-এর মতো কনফিগারেশন-ভুল লুকিয়ে রাখে, তাই অনেক প্রশাসক এটি বন্ধ রাখেন; কিছু vendor-এর ডিফল্টে এটি চালু থাকে — নিজের যন্ত্রে দেখে নিন।

৮ · বিশ্বাসের দুর্বলতা — ভুয়া DHCP, ARP spoofing আর প্রতিরক্ষা

DHCP আর ARP দুটোই বিশ্বস্ত LAN-এর যুগের নকশা: উত্তরদাতার পরিচয় যাচাইয়ের কোনো ব্যবস্থা নেই। এখানে ঝুঁকিগুলো শুধু ধারণা হিসেবে আর প্রতিরক্ষাসহ দেখব, যাতে নিজের নেটওয়ার্ক রক্ষা করতে পারেন; অনুমতি ছাড়া অন্যের নেটওয়ার্কে এমন কিছু পরীক্ষা করা বেআইনি ও অনৈতিক।

ঝুঁকি ১ — ভুয়া (rogue) DHCP server

LAN-এ দ্বিতীয় কোনো DHCP server চালু হলে কিছু client তার Offer আগে পেয়ে সেটিই নেবে। প্রায়ই এটি নিরীহ ভুল — কেউ বাসার Wi-Fi router এনে অফিসের তারে লাগিয়েছেন, আর সেটি নিজের 192.168.0.x বিলি করছে; ফলে কিছু কর্মীর ইন্টারনেট “হঠাৎ” বন্ধ। কিন্তু ইচ্ছাকৃত হলে বিপদ বড়: একটি rogue DHCP server gateway বা DNS হিসেবে নিজের ঠিকানা দিতে পারে, তখন সব traffic বা সব নামের উত্তর তার হাত দিয়ে যায়। আরেকটি ঝুঁকি হলো DHCP starvation: অসংখ্য ভুয়া MAC দিয়ে pool-এর সব ঠিকানা দখল করে আসল ব্যবহারকারীদের ঠিকানা-শূন্য রাখা।

প্রতিরক্ষা — DHCP snooping

DHCP snooping switch-এর একটি বৈশিষ্ট্য (প্রায় সব managed switch-এ কোনো না কোনো নামে আছে)। প্রশাসক বলে দেন কোন port trusted — যেদিকে আসল DHCP server বা relay আছে (uplink). বাকি সব port untrusted. নিয়ম:

• Untrusted port থেকে আসা server-এর বার্তা (OFFER, ACK, NAK) switch ফেলে দেয় — ব্যবহারকারীর port-এ লাগানো কোনো router আর ঠিকানা বিলি করতে পারে না।
• প্রতিটি সফল ACK দেখে switch একটি binding table বানায়: MAC, IP, VLAN, port, lease-এর মেয়াদ। এই টেবিল পরের প্রতিরক্ষাগুলোর ভিত্তি।
• Untrusted port-এ প্রতি সেকেন্ডে কতটি DHCP বার্তা চলবে তার সীমা (rate limit) বসানো যায় — starvation কঠিন হয়। সাথে port security (পর্ব ১২) একটি port-এ MAC-এর সংখ্যা সীমিত করে।

ঝুঁকি ২ — ARP spoofing (ARP poisoning)

ARP-এ কেউ জিজ্ঞেস না করলেও reply পাঠানো যায়, আর অনেক OS সেই তথ্য cache-এ নিয়ে নেয় — gratuitous ARP-এর সুবিধাই এখানে দুর্বলতা। ARP spoofing-এ একটি যন্ত্র বারবার মিথ্যা ঘোষণা দেয়: “192.168.10.1 (gateway)-এর MAC আমার।” যাদের cache বিষিয়ে গেল, তাদের বাইরের সব packet এখন gateway-র বদলে সেই যন্ত্রে যায়। সে চাইলে packet ফেলে দিয়ে নেটওয়ার্ক বন্ধ করতে পারে, বা দেখে-বদলে আসল gateway-তে পাঠিয়ে দিতে পারে — একে বলে man-in-the-middle. শর্ত একটিই: আক্রমণকারীকে একই LAN-এ (একই VLAN-এ) থাকতে হয়; ARP router পার হয় না। তাই ক্যাফে, হোস্টেল বা হোটেলের খোলা নেটওয়ার্কে এই ঝুঁকি বেশি।

প্রতিরক্ষা — স্তরে স্তরে

ip dhcp snooping
ip dhcp snooping vlan 10,20
ip arp inspection vlan 10,20               ! DAI, snooping-এর binding table ব্যবহার করে
!
interface GigabitEthernet1/0/48
 description Uplink to core / DHCP relay
 ip dhcp snooping trust                    ! শুধু এই দিক থেকে OFFER/ACK চলবে
 ip arp inspection trust
!
interface range GigabitEthernet1/0/1 - 46
 ip dhcp snooping limit rate 15            ! প্রতি সেকেন্ডে সর্বোচ্চ 15টি DHCP বার্তা

এটি একটি উদাহরণ, চালানোর কোড নয়; rate-এর সংখ্যা শুধু নমুনা। Trust ভুল port-এ দিলে আসল DHCP-ই আটকে যায়, আর static যন্ত্রের নিয়ম না লিখে DAI চালু করলে প্রিন্টার বা সার্ভার হঠাৎ হারিয়ে যায় — তাই আগে পরিকল্পনা আর log দেখা।

৯ · AI-এর যুগে DHCP আর ARP-এর সমস্যা খোঁজা

“অফিসের কিছু কম্পিউটার 169.254 পাচ্ছে, কী করব?” — AI দ্রুত একটি তালিকা দেবে, কিন্তু DHCP আর ARP-এ কিছু ভুল বারবার দেখা যায়, আর switch-এ একটি ভুল কমান্ড পুরো VLAN-কে ঠিকানাহীন করে দিতে পারে:

AI-এর পরামর্শ প্রয়োগের আগে — চেকলিস্ট

• ক্লায়েন্টে ipconfig /all বা ip addr আর ip route দেখে লক্ষণ নিশ্চিত করেছি — ঠিকানা, gateway, DNS কোথা থেকে এসেছে
• Gateway-এ relay (helper) কনফিগারেশন আর DHCP server-এ সেই subnet-এর pool আছে কি না দেখেছি
• নিজের ল্যাবে বা অনুমতিপ্রাপ্ত নেটওয়ার্কে packet capture করে DORA-র কোন ধাপে আটকাচ্ছে দেখেছি
• প্রতিটি কমান্ড vendor-এর ডকুমেন্টেশন আর man পাতার সাথে মিলিয়েছি, আর বদলানোর আগে কনফিগারেশনের backup রেখেছি
• নিরাপত্তার কোনো বৈশিষ্ট্য (snooping, DAI, 802.1X) “সমাধান” হিসেবে বন্ধ করিনি