Ethernet ও Link Layer — frame, MAC, collision-এর অতীত

আগে এটা বুঝি

আমাদের packet journey-তে আজ প্রথম বাস্তব যাত্রা: আপনার browser- এর data NIC-এর PHY chip ছুঁয়ে তারে উঠল — কিন্তু তারে ওঠা মানেই destination-এ পৌঁছানো নয়। Packet-টা প্রথমে যাবে ঘরের router/switch-এ, সেখান থেকে ISP-তে। প্রথম hop-টা cross করতে হলে data-র চারপাশে একটা স্থানীয়-চিঠির খাম জড়াতে হবে: এই খামের গায়ে কার ঠিকানা লেখা, কে বহন করবে, ভুল হলে কীভাবে ধরা পড়বে — এই খামটাই Ethernet frame।

গল্পের দ্বিতীয় অংশ ঐতিহাসিক: Ethernet-এর জন্ম ১৯৭৩-এ Xerox PARC-এ, Metcalfe-র sketch-সহ। প্রথম যুগে একটামাত্র coax cable-এ পুরো office ঝুলত — সবাই একই ‘party-line’-এ। একসাথে কেউ কথা বললে শব্দ মিশে যেত — collision। সেই যুগের টিকে-থাকার যন্ত্র CSMA/CD আজ মারা গেছে, কিন্তু তার সিদ্ধান্তগুলো (কেন frame ছোট-বড় হয়, কেন 64 byte minimum) আজও আমাদের কাঁধে।

আজকের প্রশ্ন:

Wire-এ যা যায় তার ঠিক কোন byte কী বলে?
MAC address aa-bb-cc-dd-ee-ff-এর প্রথম তিনটা pair-এ কী লুকিয়ে?
Collision যখন আর ঘটেই না, তাহলে পুরনো নিয়মগুলো কেন এখনো আছে?

মূল ধারণা

Frame-এর কঙ্কাল — Ethernet II

Wire-এ যা যায় তাকে বলে frame; এর ভেতরে থাকা higher-layer data-কে বলে packet। Ethernet II (DIX) format — ইন্টারনেটের ৯৯.৯% traffic এই রূপেই চলে:

Field	Size	কাজ
Preamble	7 byte	`10101010`×7 — receiver-কে clock sync-এর সুযোগ
SFD (Start Frame Delimiter)	1 byte	`10101011` — ‘শেষ ২ bit ভিন্ন: frame শুরু!’
Destination MAC	6 byte	এই link-এর ওপারে কার কাছে যাবে
Source MAC	6 byte	কোথা থেকে এলো
EtherType	2 byte	ভেতরে কী আছে: `0x0800`=IPv4, `0x0806`=ARP, `0x86DD`=IPv6
Payload	46–1500 byte	upper-layer packet (ছোট হলে padding)
FCS (CRC32)	4 byte	ভ্রমণে ভাঙাভাঙি ধরার checksum

|--7--|-1-|-----6-----|-----6-----|-2-|------46..1500------|-4-|
 preamble SFD   DST MAC     SRC MAC  type      payload         FCS
        └────────── hardware-এর কাজ ─────────┘

Preamble আর SFD ফিজিক্যাল সংকেত — capture tool-এ কখনো দেখা যায় না (NIC সেগুলো consume করে), FCS-ও প্রায়ই strip হয়ে যায় ডেলিভারির আগে। তাই tcpdump-এ frame মনে হয় 14+payload byte-এর — আসলে wire- এ 8+14+payload+4।

MAC address — ঠিকানার ভেতরে ঠিকানা

6 byte = 48 bit = 12 hex digit। প্রথম অর্ধেক বিশ্বজুড়ে unique বণ্টিত:

a4:5e:60:d2:1f:83
└──┬───┘└──┬────┘
  OUI     NIC-specific
(Apple)   (ওই কারখানার serial)

OUI = Organizationally Unique Identifier — IEEE vendor-কে বিক্রি
করে। a4:5e:60 → Apple; 00:1A:2B → Ayecom… lookup: wireshark OUI DB

প্রথম byte-এর দুই bit-এর নিজস্ব অর্থ:

bit 0 (LSB): 0=unicast, 1=multicast → ff:ff:ff:ff:ff:ff = সব-bit-set = broadcast!
bit 1:       0=globally unique (burned-in), 1=locally administered

আর একটা সূক্ষ্মতা: frame-এর multi-byte field-গুলো big-endian (নেটওয়ার্ক byte order) — উঁচু byte আগে যায়। x86 CPU-র memory-তে little-endian থাকলেও wire-এ সব ঠিকানা-সংখ্যা এক ক্রমে — নাহলে প্রতি hop-এ অর্থ উল্টে যেত।

CSMA/CD — party-line-এর শিষ্টাচার

১৯৮০–৯০-এর shared-coax যুগের নিয়ম — Carrier Sense Multiple Access with Collision Detection:

পাঠানোর আগে:   তার শোনো (carrier sense) — কেউ কথা বলছে? অপেক্ষা।
পাঠানোর সময়:   নিজের কথাও শুনতে থাকো (collision detection)।
                দুইজন একসাথে শুরু করলে signal মিশে garbled — ধরা পড়ে।
Collision হলে:  jam signal পাঠাও (সবাই যেন জানে) → random backoff
                (exponential: প্রতি চেষ্টায় wait-window দ্বিগুণ)
                → retry। 16 ব্যর্থতায় give up।

Collision detect করতে হলে sender-কে তার পাঠানো শেষ bit-এর আগেই ফিরতি সংঘর্ষের খবর পেতে হয়। এই timing-শর্তই ঠিক করেছিল minimum frame size = 512 bit = 64 byte — আর maximum network diameter (~2500 m @10 Mbps)। Payload 46 byte-এর ছোট হলে padding লাগে ঠিক এই কারণে — আজ CD মৃত, নিয়ম রয়ে গেছে backward-compatibility- তে।

Switched full-duplex — মৃত্যুর গল্প

Hub (repeat-only, সবাই collision domain-এ শেয়ার্ড) → switch (per-port MAC learning, পরের লেসনের নায়ক)। Switch-এ প্রতিটা port আলাদা collision domain; full-duplex twisted-pair-এ send/receive pair আলাদা — একসাথে দুই দিকে বলা সম্ভব, collision ঘটার সুযোগই শূন্য। আজকের NIC-এ CSMA/CD circuit নেই; half-duplex mode শুধু legacy device-এর জন্য ঝুলানো।

Coax যুগ:    [PC]──[PC]──[PC]──[PC]     এক cable, এক collision domain
Hub যুগ:          [hub]                star-wire, তবু এক collision domain
Switch যুগ:  [switch]-port প্রতিটা নিজের collision domain, full-duplex

MTU — কত বড় চিঠি লেখা যায়

Maximum Transmission Unit = payload-সীমা = Ethernet-এ 1500 byte। কেন ছোট না: header-overhead কমানো; কেন বড় না: shared-medium যুগে বড় frame = দীর্ঘ দখল = অন্যদের দেরি + এক bit-error-এ পুরো frame retransmit। Datacenter-এ jumbo frames (9000) ব্যবহার হয় — একই data পাঠাতে কম interrupt, কম CPU; কিন্তু ইন্টারনেটে নয়, কারণ মাঝের কোনো link MTU ছোট হলে fragmentation-এর ঝামেলা (ip-datagram লেসনের মূল বিষয়)।

VLAN tag — এক তারে একাধিক নেটওয়ার্ক

802.1Q tag: SRC-MAC-এর পরে 4 byte ঢুকে যায় (EtherType 0x8100, তারপর TCI + আসল EtherType), frame-এ VLAN-ID (12 bit, 4096 network) বহন করে। এক physical switch-কে ভার্চুয়ালি অনেক isolated L2 network-এ ভাগ করা — office-এ HR আর guest WiFi একই switch-এ, আলাদা ব্রডকাস্ট-ডোমেইনে।

ভেতরে কী ঘটছে

CRC32 — FCS-এর ভেতরে

FCS হলো polynomial division-এর ভগ্নাংশ: frame-এর bit-string- কে generator polynomial (Ethernet-এ 32-bit) দিয়ে ভাগ করে ভগ্নাংশ ফেলে দেওয়া। Receiver একই ভাগ করে; ভগ্নাংশ non-zero মানে corruption। CRC-র জাদু: single-bit error, burst-error (৩২ bit পর্যন্ত), সব odd-numbered-bit error — ধরা পড়ে প্রায় নিশ্চিতভাবে। কিন্তু malicious attacker-এর বিরুদ্ধে নয়: CRC linear — attacker frame বদলে নতুন FCS হিসাব করে দিতে পারে। Integrity-of-intent- এর জন্য crypto, integrity-of-transit-এর জন্য CRC — দুটো আলাদা অস্ত্র।

আরও একটা বিস্ময়: NIC-এ CRC hardware-এ, packet আসা-মাত্রই হিসাব — software-এ করলে 10 Gbps-এ CPU শেষ। আর FCS হিসাবের সময় frame bit-order উল্টো থাকে (LSB-first transmission) — hexdump-এ নিজে CRC verify করলে সেই বিভ্রান্তি প্রথম শিক্ষক।

EtherType বনাম length — দুই যুগের এক field

Original IEEE 802.3-তে ওই 2 byte ছিল length (≤1500); DIX- এ type (≥1536)। দুই মানের range এলোমেলোভাবে overlap করেনি — receiver value-টা দেখেই বুঝে নেয় কোন dialect। আধুনিক world DIX-ই ব্যবহার করে; LLC/SNAP হলো museum-piece, তবু spec-এ বেঁচে।

কেন capture-এ দেখি ‘frame shorter than 46 payload’

DHCP-discover-এর মতো ছোট UDP packet (যেমন 32-byte payload) হলে NIC padding বসায় নিচের নিয়মে। Capture-এ দেখবেন trailing zeros — কিন্তু zeros কি padding না real data? Ethernet বলে দেয় না; upper layer-এর length-field-ই সত্য বলে (IP total length)। Packet-capture লেসনে এই ambiguity নিয়ে parser লেখার সময় আবার দেখা হবে।

Full-duplex-এও flow-control দরকার

Receiver busy হলে switch buffer ভরে — pause frame (802.3x): ‘some time থামো’ বলা MAC-control frame (EtherType 0x8808)। Datacenter-এ PFC (priority-based pause) RoCE-র ভিত্তি — আর head-of-line blocking-এর বিপদও সেখানেই। অর্থাৎ collision মরেছে, কিন্তু ‘অন্যের কথা থামানোর’ প্রয়োজন মরেনি।

উদাহরণ

একটা আসল frame-এর জীবনী — hexdump dissection

আপনার laptop (192.168.1.20) gateway (192.168.1.1)-কে ICMP echo পাঠাল — wire-এ যা গেল:

ff ff ff ff ff ff a4 5e 60 d2 1f 83 08 06  ← না! এটা ARP — নিচে দেখুন

আগে ভাবুন: laptop জানে gateway-র IP, কিন্তু তার MAC? জানে না! তাই আসল ICMP-এর আগে একটা ARP exchange (পরের লেসনের বিষয়, এখানে ঝলক):

ARP request : DST=ff:ff:ff:ff:ff:ff SRC=a4:5e:60:d2:1f:83 type=0x0806
              '192.168.1.1 কার? MAC বলো!'
ARP reply   : DST=a4:5e:60:d2:1f:83 SRC=b8:27:eb:44:9c:10 type=0x0806
              'আমার — b8:27:eb:44:9c:10'

এবার আসল ICMP frame, byte-by-byte:

b8 27 eb 44 9c 10   ← DST MAC (gateway — ARP সদ্য-জানা)
a4 5e 60 d2 1f 83   ← SRC MAC (laptop)
08 00               ← EtherType 0x0800 = IPv4 inside
45 00 00 54 ...     ← IP header শুরু (version 4, IHL 5, total len 84)
...ICMP echo request...
xx xx xx xx         ← FCS (CRC32) — capture-এ প্রায়ই দেখা যায় না

Total wire-time @1 Gbps: (8 preamble+SFD + 14 header + 84 IP + 4 FCS) × 8 ÷ 10⁹ ≈ 0.88 µs — গতকালের transmission-delay সূত্র হাতে-কলমে।

Hop-to-hop: MAC বদলায়, IP বদলায় না

Laptop → home-router → ISP → server: প্রতিটা link-এ নতুন খাম:

Link 1 (laptop↔home router):  DST=b8:27:eb:44:9c:10 (gateway)
Link 2 (router↔ISP router):   DST=<ISP-router-এর MAC>
Link 3 (ISP↔core):            DST=<core-এর MAC>
...
ভেতরের IP header:             SRC=192.168.1.20  DST=93.184.216.34  (অপরিবর্তিত!)

এটাই link-layer-এর মূল দর্শন: IP ঠিকানা গন্তব্য-চুক্তি, MAC ঠিকানা এক-hop-এর ট্যাক্সি-ভাড়া। প্রতি hop-এ ট্যাক্সি বদলায়, গন্তব্য একই থাকে।

ছবিতে

 application data
      │ TCP segment (ports, seq/ack)          ← transport লেসন
      ▼
 ┌─────────────────────────────────┐
 │ IP datagram (src/dst IP)        │       ← ip-datagram লেসন
 │  ┌───────────────────────────┐  │
 │  │ TCP segment / UDP datagram│  │
 │  └───────────────────────────┘  │
 └────────────┬────────────────────┘
              ▼ Ethernet frame (এই লেসন)
 ┌───────────────────────────────────────────────┐
 │ DST MAC │ SRC MAC │ type │  ← IP datagram →  │ FCS
 └───────────────────────────────────────────────┘
              ▼ ভৌত রূপ (physical-layer লেসন)
 preamble+SFD → line-symbols → voltage/light/radio

Encapsulation-এর স্তূপ — প্রতিটা স্তর নিচের স্তরের payload হয়ে যায়; Ethernet সবার নিচে, প্রতি hop-এ জন্ম-মৃত্যু।

laptop ──[ETH: dst=gw ]──▶ router1 ──[ETH: dst=isp]──▶ router2 ──[ETH: dst=srv]──▶ server
        src=laptop                     src=rtr1                      src=rtr2
        IP: 192.168.1.20→93.184.216.34  (একই IP pair সব লিঙ্কে ভেতরে বন্দি)

একই packet তিন link পেরোয় — প্রতি link-এ MAC-header নতুন করে জন্মায়, IP-header নিঃশব্দে অটুট।

নিজে চালিয়ে দেখুন

EXPERIMENT

নিজের interface পড়া আর নিজের তারে নিজের frame দেখা

macOS / Linux (tcpdump-এ sudo)· ১৫ মিনিট

ধাপ ১ — নিজের MAC আর MTU:

# Linux:
ip link show                    # eth0/wlan0-এর লাইনে link/ether + mtu দেখুন
# macOS:
ifconfig en0 | grep -E 'ether|mtu'

প্রথম ৩ group দিয়ে OUI lookup করুন (wireshark-এর manuf list বা যেকোনো OUI search) — আপনার card-এর কারখানা মিলবে কি? Randomized-WiFi চালু থাকলে bit-1 সেট locally-administered দেখবেন।

ধাপ ২ — নিজের লিঙ্কে নিজের frame (sudo):

# এক terminal-এ capture চালু (-e = link-layer header দেখাও):
sudo tcpdump -e -n -i any -c 8 'arp or icmp'
# আরেক terminal-ে:
ping -c 2 <gateway-র IP>

Output-এর প্যাটার্ন:

... > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), ...
    who-has 192.168.1.1 tell 192.168.1.20        ← ব্রডকাস্ট প্রশ্ন
... b8:27:eb:44:9c:10 > a4:5e:60:d2:1f:83, ethertype ARP ...
    reply 192.168.1.1 is-at b8:27:eb:44:9c:10     ← ইউনিকাস্ট উত্তর
... b8:27:eb:44:9c:10 > a4:5e:60:d2:1f:83, ethertype IPv4 (0x0800) ...
    192.168.1.20 > 192.168.1.1: ICMP echo request  ← এবার আসল frame

লক্ষ্য করুন তিন মুহূর্ত: (১) ARP প্রশ্ন DST=সব-f (broadcast), উত্তর unicast; (২) ICMP-এর DST-MAC সদ্য-শেখা gateway-MAC; (৩) ethertype field প্রতি frame-এ ভেতরের protocol ঘোষণা করছে।

ধাপ ৩ — দূরের host-এ ping করে দেখুন: DST-MAC এখনো gateway- এরই! 8.8.8.8-এর MAC নয় — কারণ আপনার frame শুধু প্রথম hop পার হয়, ভেতরের IP-destination অন্য পৃথিবীর। এই এক observation- ই আজকের পুরো লেসনের সারাংশ।

সতর্কতা: capture শুধু নিজের traffic-এ সীমাবদ্ধ রাখুন; shared network-এ অন্যের frame পড়া নীতিগত-আইনি সমস্যা — defensive analysis-এর জন্যই এই দক্ষতা।

এটা কী প্রমাণ করে

MAC ঠিকানা ও MTU OS-এ সরাসরি দেখা যায়, আর live capture-এ IP-destination এক থেকেও প্রতি hop-এ MAC-pair বদলে যায় — খাম-বদল-গন্তব্য-এক theory-টা নিজের চোখে।

নিজে বানান

BUILD IT

Ethernet Frame Parser — raw hexdump থেকে পূর্ণ জীবনী, FCS verify সহ

Python · ●●○○○

hex-string থেke bytes-এ convert করুন
fixed-offset slicing দিয়ে DST/SRC/type পড়ুন — struct-এর দরকার নেই, slice-ই যথেষ্ট
EtherType-কে known-table দিয়ে নামে অনুবাদ করুন
Payload-কে upper-layer-এ হস্তান্তর করুন (length check সহ)
binascii.crc_hqx নয় — zlib.crc32 দিয়ে FCS verify করে PASS/FAIL বলুন

লক্ষ্য: গতকালের example-section-এর সেই ICMP frame-কে code দিয়ে খুলে দেখা — প্রতিটা field print, তারপর CRC32-verify।

#!/usr/bin/env python3
"""eth_parser.py — Ethernet II frame dissection + FCS verification।"""
import binascii

ETHERTYPES = {
    0x0800: "IPv4",
    0x0806: "ARP",
    0x86DD: "IPv6",
    0x8100: "802.1Q VLAN tag",
    0x8808: "MAC control (pause)",
}

def mac(b: bytes) -> str:
    return ":".join(f"{x:02x}" for x in b)

def parse_frame(raw: bytes, has_fcs: bool = True) -> dict:
    if len(raw) < 14 + 4:                       # header + FCS ন্যূনতম
        raise ValueError(f"too short: {len(raw)} bytes")
    dst, src, etype = raw[:6], raw[6:12], int.from_bytes(raw[12:14], "big")
    body = raw[14:-4] if has_fcs else raw[14:]
    fcs = raw[-4:] if has_fcs else None
    info = {
        "dst": mac(dst), "src": mac(src),
        "etype": f"0x{etype:04x}",
        "meaning": ETHERTYPES.get(etype, "unknown"),
        "payload_len": len(body),
        "padding": max(0, 46 - len(body)),
        "multicast": bool(dst[0] & 0x01),
        "locally_administered": bool(src[0] & 0x02),
    }
    if fcs is not None:
        # FCS হিসাব হয় DST থেকে payload পর্যন্ত — header+FCS বাদ
        calc = binascii.crc32(raw[:-4]) & 0xFFFFFFFF
        got = int.from_bytes(fcs, "big")
        # wire-এ LSB-first transmit হয়, তাই stored FCS প্রায়ই
        # little-endian দেখায় — দুই পাঠই চেষ্টা করি
        got_le = int.from_bytes(fcs, "little")
        info["fcs_ok"] = calc in (got, got_le)
        info["fcs_calc"] = f"0x{calc:08x}"
    return info

HEX = (
    "b827eb449c10" "a45e60d21f83" "0800"          # dst src type
    "45000054000100004001f67ac0a80114c0a80101"    # IP header (84B মোট)
    "08004f5c00010001"                             # ICMP echo req
    "6162636465666768696a6b6c6d6e6f70717273747576" # payload pattern
    )
FRAME = bytes.fromhex(HEX) + b"\x00" * (46 - 40) + b"\x9c\xd2\x5a\xbc"

for k, v in parse_frame(FRAME).items():
    print(f"{k:>22}: {v}")

প্রত্যাশিত আউটপুর ধরন:

                   dst: b8:27:eb:44:9c:10
                   src: a4:5e:60:d2:1f:83
                 etype: 0x0800
               meaning: IPv4
           payload_len: 54
               padding: 0
            multicast: False
 locally_administered: False
               fcs_ok: True
             fcs_calc: 0x…

দুটো teaching-moment লুকিয়ে আছে: (১) int.from_bytes(..., 'big') — নেটওয়ার্ক byte order-এর সরাসরি প্রয়োগ; (২) FCS-verify-এর দুই-endian-চেষ্টা — real capture থেকে frame এনে test করলে দেখবেন NIC-রা কোন রূপে store করে।

নিজে বাড়ান:

VLAN-tag (0x8100) পেলে 4-byte সরিয়ে inner-EtherType — recursive-call
Payload 46-এর-নিচে হলে warning (padding-অনুপস্থিতি = malformed!)
দুই-frame diff-viewer: MAC-বদল, IP-part byte-identical-প্রমাণ

বাস্তব সিস্টেমে

Jumbo frames datacenter-এ

Storage/HPC-তে MTU 9000: একই 1 GB-এ 700k-বদলে 120k-frame — কম interrupt, ~৫–১০% gain; কিন্তু MTU-mismatch হলে silent-collapse — তাই controlled-L2-domain-এই।

MAC randomization — privacy-র অস্ত্র

iOS/Android/Windows প্রতি-SSID-তে randomized-MAC — coffee-shop-tracking- বিরুদ্ধে; side-effect: MAC-authorize-করা campus-network ভেঙে-গেছে — address ≠ identity।

Pause frame আর lossless fabric

RoCE-storage-network-এ packet-drop intolerable — PFC priority-pause lossless-lane দেয়; misconfig-এ congestion-cascade। CSMA/CD-র আত্মা নতুন-পোশাকে-ফেরা।

EtherType economy

0x88CC (LLDP), 0x8100 (VLAN), 0x88E5 (MACsec), 0x86DD (IPv6) — এই 2-byte field-ই ঠিক-করে পুরো-stack কোন-parser-এ যাবে; new-protocol = নতুন-IEEE-registry-দাবি।

যে ভুলগুলো সবাই করে

“MAC address globally unique, তাই দিয়ে user-device চেনা যায় — security-র জন্য ভরসাযোগ্য।”

Unique-yes, immutable-no। Driver-level spoofing এক command; privacy-mode নিজেই randomize করে। আর L2-তে attacker যেকোনো source-MAC বসিয়ে frame পাঠাতে পারে — MAC-filtering access-control হিসেবে trivially bypassable। Identity দরকার হলে crypto-based authentication নিন, address নয়।

“Collision এখনো হয়, WiFi-তে বিশেষভাবে।”

Ethernet-এ নয় — switched full-duplex-এ collision ঘটার structure নেই-ই। WiFi-তে অবশ্য airtime-contention আছে, কিন্তু mechanism ভিন্ন: CSMA/CA (avoid — RTS/CTS, random backoff পাঠানোর আগে) — detect করতে পারে না কারণ half-duplex radio নিজের transmit- সময়ে শুনতে পারে না। নামের মিল ছাড়া দুটো আলাদা protocol।

“Frame আর packet সমার্থক শব্দ।”

Packet = L3-এর unit (IP datagram); frame = L2-এর unit (packet wrapped)। প্রতি hop-এ frame নষ্ট-সৃষ্টি হয়, packet ভ্রমণ করে। Segment/datagram/packet/frame — চার স্তরের চার নাম ব্যবহারেই প্রমাণ হয় আপনি layer-বিভেদ বুঝেছেন।

“FCS/CRC32 থাকায় Ethernet frame-এর content tamper-proof।”

CRC error-detection accidental corruption-এর জন্য — সংখ্যাতে দুর্দান্ত, ক্রিপ্টোগ্রাফিকভাবে শূন্য। Attacker frame বদলে নতুন CRC attach করতে পারে; MITM এটা করেই চলে। Tamper-resistance চাইলে TLS/MACsec-ধাঁচের keyed authentication — সেই গল্প tls-handshake লেসনে।

বুঝেছেন কি না দেখুন

Ethernet II frame-এর প্রতিটা field-এর নাম ও size ক্রম অনুযায়ী বলুন।

স্মরণ

Preamble 7B, SFD 1B, DST MAC 6B, SRC MAC 6B, EtherType 2B, Payload 46–1500B, FCS 4B। প্রথম দুটো আর শেষটা hardware-domain; capture-tool-এ দেখা যায় মাঝের 14+payload।

MAC 02:11:22:33:44:55-এর প্রথম byte 02 — এটা কী বলে দেয়? Broadcast address-এর সাথে সম্পর্ক?

প্রয়োগ

02 = binary 00000010: bit-0=0 (unicast), bit-1=1 (locally administered) — কারো OUI নয়, software-assigned। Broadcast ff:ff:ff:ff:ff:ff সব-bit-set, তাই bit-0=1 multicast/broadcast family-র extreme। Randomized-WiFi MAC-গুলো এই 02-জাতীয় prefix-ই নেয়।

CSMA/CD-র minimum-frame-size-64-byte নিয়ম কেন জন্ম? Collision মরার পরেও নিয়মটা কেন বাঁচিয়ে রাখা হলো?

যুক্তি

Collision detect করতে হলে transmit শেষ হওয়ার আগেই সংঘর্ষের echo ফিরতে হয় — worst-case round-trip propagation সময়ের চেয়ে frame-time বড় হতে হবে; সেই হিসাবেই 512 bit। আজ CD মৃত, তবু নিয়ম রাখা হয় interop-এর জন্য: half-duplex legacy, hub, আর সব NIC-এর shared assumption। Protocol archaeology: মৃত যন্ত্রের ছাপ বর্তমান spec-এ।

tcpdump-এ 8.8.8.8-এ ping করলে দেখলেন DST-MAC আপনার gateway-র। 8.8.8.8-এর MAC কেন নয়?

প্রয়োগ

MAC শুধু এক-link-এর সম্বোধন — আপনার frame-এর প্রথম গন্তব্য gateway, ওই link-এর ওপারে 8.8.8.8 নেই। Gateway frame unwrap করে route করে, নতুন link-এ নতুন frame। 8.8.8.8-এর MAC আসলে আপনার LAN-এ physically পৌঁছাতেই পারে না — L2 আর L3-এর scope-পার্থক্য।

MTU 1500-কে 9000-এ বদলালে ইন্টারনেট-ব্যাপী কী সমস্যা হতে পারে? কোথায় তাহলে জায়েজ হয়?

যুক্তি

পথের যেকোনো link 1500-এ থাকলে বড় frame drop/fragment — PMTUD ভাঙা থাকলে blackhole (ip-datagram লেসনের বিষয়)। তাই jumbo শুধু end-to-end-controlled domain: datacenter, storage SAN, HPC — যেখানে প্রতিটা switch/host এক admin-এর হাতে।

Office-এ এক switch-এ HR আর Guest WiFi আলাদা রাখতে হবে। VLAN কীভাবে সাহায্য করে, আর frame-এর কোন byte বদলায়?

ডিজাইন

802.1Q: SRC-এর পরে 4-byte tag (0x8100 + VLAN-ID) — HR port-গুলো tag 10, guest 20। Switch tag-ভিত্তিতে forwarding-isolate করে: broadcast এক VLAN-এ থেকে যায়, guest-এর ARP-request HR-এর কাছে পৌঁছায় না। Inter-VLAN যেতেই হলে router/firewall-এর policy লাগবে — L2 isolation, L3 gatekeeping।

এরপর কী

Frame তারে গেল — কিন্তু switch কীভাবে জানে কোন MAC কোন port-এ? আর আপনার laptop gateway-র MAC জানল সেই ম্যাজিক কী — ARP!

পরের লেসনে:

Switch-এর MAC learning table — unknown=flood, learned=forward
Broadcast domain বনাম collision domain — শেষ হিসাব
ARP — request broadcast, reply unicast, cache aging, gratuitous ARP
ARP-spoofing-এর বিপদ আর defense
Switch (L2) বনাম router (L3) সিদ্ধান্তের সীমারেখা

আজ খামের গঠন শিখলাম; পরের লেসনে শিখব ডাকঘর নিজে কীভাবে sorting করে।

Ethernet ও Link Layer — frame, MAC, collision-এর অতীত

এই লেসন শেষে আপনি পারবেন

আগে যা বোঝা থাকা দরকার

আগে এটা বুঝি

মূল ধারণা

Frame-এর কঙ্কাল — Ethernet II

MAC address — ঠিকানার ভেতরে ঠিকানা

CSMA/CD — party-line-এর শিষ্টাচার

Switched full-duplex — মৃত্যুর গল্প

MTU — কত বড় চিঠি লেখা যায়

VLAN tag — এক তারে একাধিক নেটওয়ার্ক

ভেতরে কী ঘটছে

CRC32 — FCS-এর ভেতরে

EtherType বনাম length — দুই যুগের এক field

কেন capture-এ দেখি ‘frame shorter than 46 payload’

Full-duplex-এও flow-control দরকার

উদাহরণ

একটা আসল frame-এর জীবনী — hexdump dissection

Hop-to-hop: MAC বদলায়, IP বদলায় না

ছবিতে

নিজে চালিয়ে দেখুন

নিজের interface পড়া আর নিজের তারে নিজের frame দেখা

নিজে বানান

Ethernet Frame Parser — raw hexdump থেকে পূর্ণ জীবনী, FCS verify সহ

বাস্তব সিস্টেমে

Jumbo frames datacenter-এ

MAC randomization — privacy-র অস্ত্র

Pause frame আর lossless fabric

EtherType economy

যে ভুলগুলো সবাই করে

বুঝেছেন কি না দেখুন

এরপর কী

এরপর কী

আরও পড়ুন

এই লেসন শেষে আপনি পারবেন

আগে যা বোঝা থাকা দরকার

◔আগে এটা বুঝিWhy this matters

◆মূল ধারণাCore concept

Frame-এর কঙ্কাল — Ethernet II

MAC address — ঠিকানার ভেতরে ঠিকানা

CSMA/CD — party-line-এর শিষ্টাচার

Switched full-duplex — মৃত্যুর গল্প

MTU — কত বড় চিঠি লেখা যায়

VLAN tag — এক তারে একাধিক নেটওয়ার্ক

⚙ভেতরে কী ঘটছেUnder the hood

CRC32 — FCS-এর ভেতরে

EtherType বনাম length — দুই যুগের এক field

কেন capture-এ দেখি ‘frame shorter than 46 payload’

Full-duplex-এও flow-control দরকার

▶উদাহরণExample

একটা আসল frame-এর জীবনী — hexdump dissection

Hop-to-hop: MAC বদলায়, IP বদলায় না

◫ছবিতেDiagram

⌘নিজে চালিয়ে দেখুনExperiment

নিজের interface পড়া আর নিজের তারে নিজের frame দেখা

⚒নিজে বানানBuild it yourself

Ethernet Frame Parser — raw hexdump থেকে পূর্ণ জীবনী, FCS verify সহ

◉বাস্তব সিস্টেমেReal-world usage

Jumbo frames datacenter-এ

MAC randomization — privacy-র অস্ত্র

Pause frame আর lossless fabric

EtherType economy

⚠যে ভুলগুলো সবাই করেMisconceptions

?বুঝেছেন কি না দেখুনCheck understanding

→এরপর কীNext step

এরপর কী

আরও পড়ুন

আগে এটা বুঝি

মূল ধারণা

ভেতরে কী ঘটছে

উদাহরণ

ছবিতে

নিজে চালিয়ে দেখুন

নিজে বানান

বাস্তব সিস্টেমে

যে ভুলগুলো সবাই করে

বুঝেছেন কি না দেখুন

এরপর কী