Software-Defined Networking (SDN) পরিচিতি
এই পাঠে যা শিখবেন
- ঐতিহ্যবাহী নেটওয়ার্কিংয়ে কন্ট্রোল প্লেন ও ডেটা প্লেন একসাথে বাঁধা থাকার সীমাবদ্ধতা
- SDN কীভাবে এই দুটো আলাদা করে এবং কেন এটি নেটওয়ার্ক-ওয়াইড পলিসি সহজ করে
- SDN কন্ট্রোলার ও "নির্বোধ" সুইচের ভূমিকা বিভাজন
- Python দিয়ে একটি কেন্দ্রীয় কন্ট্রোলারের পুরো নেটওয়ার্ক-ওয়াইড ফরওয়ার্ডিং টেবিল একবারে আপডেট করার সিমুলেশন
১ · ঐতিহ্যবাহী নেটওয়ার্কিং — কন্ট্রোল প্লেন ও ডেটা প্লেন বাঁধা
এখন পর্যন্ত এই কোর্সে যত রাউটার/সুইচ দেখেছি (L12-এর সুইচ, L17-L19-এর রাউটিং প্রোটোকল), প্রতিটি ডিভাইসের নিজস্ব কন্ট্রোল প্লেন (কী সিদ্ধান্ত নেওয়া হবে — যেমন নিজের একটি কপি OSPF চালানো, L19) ও ডেটা প্লেন (আসল প্যাকেট/ফ্রেম ফরওয়ার্ড করার হার্ডওয়্যার) একই ডিভাইসে একসাথে বাঁধা। প্রতিটি ডিভাইস স্বাধীনভাবে নিজের সিদ্ধান্ত নেয় — এর ফলে পুরো নেটওয়ার্ক জুড়ে কোনো নীতি বদলাতে হলে প্রতিটি ডিভাইস আলাদাভাবে কনফিগার করতে হয়, যা বড় নেটওয়ার্কে ধীর ও ভুল-প্রবণ।
২ · SDN — কন্ট্রোল প্লেন ও ডেটা প্লেনের বিচ্ছেদ
SDNSoftware-Defined Networkingনেটওয়ার্কিং আর্কিটেকচার যা কন্ট্রোল প্লেন (সিদ্ধান্ত নেওয়া) ও ডেটা প্লেন (ফরওয়ার্ডিং) আলাদা করে, একটি কেন্দ্রীয় সফটওয়্যার কন্ট্রোলারে সিদ্ধান্ত নেওয়ার লজিক কেন্দ্রীভূত করে। এই দুটোকে সচেতনভাবে আলাদা করে — একটি কেন্দ্রীয় SDN কন্ট্রোলার পুরো নেটওয়ার্ক টপোলজি একসাথে দেখে ফরওয়ার্ডিং সিদ্ধান্ত নেয়, আর নেটওয়ার্কের প্রতিটি সুইচ শুধু একটি সরল "নির্বোধ" (dumb) ফরওয়ার্ডিং ডিভাইস হয়ে যায় — সে শুধু কন্ট্রোলার থেকে পাওয়া টেবিল অনুযায়ী ফ্রেম/প্যাকেট পাঠায়, নিজে কোনো সিদ্ধান্ত নেয় না। কন্ট্রোলার ও সুইচের মধ্যে যোগাযোগের জন্য OpenFlow-এর মতো প্রোটোকল ব্যবহৃত হয় (নাম মাত্র উল্লেখ, গভীরে যাব না)।
পুরো নেটওয়ার্ক টপোলজি একবারে দেখে সিদ্ধান্ত নেয় — কেন্দ্রীয় "মস্তিষ্ক"।
কন্ট্রোলারের দেওয়া টেবিল অনুযায়ী শুধু ফরওয়ার্ড করে — নিজে কিছু সিদ্ধান্ত নেয় না।
একবার কন্ট্রোলারে পরিবর্তন করলে তা সব সুইচে স্বয়ংক্রিয়ভাবে ছড়িয়ে যায়।
কেন্দ্রীকরণ শক্তিশালী কিন্তু কন্ট্রোলার নিজেই এখন একটি critical single point of dependency — কন্ট্রোলার অকার্যকর হলে নতুন কোনো ফরওয়ার্ডিং সিদ্ধান্ত নেওয়া যায় না (যদিও চলমান সুইচগুলো তাদের সর্বশেষ পাওয়া টেবিল অনুযায়ী চলতে থাকে)। বাস্তবে এটি একাধিক redundant কন্ট্রোলার দিয়ে সামলানো হয় — L02-এর টপোলজি আলোচনার ফল্ট-টলারেন্স নীতিরই আরেকটি প্রয়োগ।
# SDN কন্ট্রোল প্লেন / ডেটা প্লেন বিচ্ছেদের সিমুলেশন
# (in-memory ফেক টপোলজি — কোনো প্রকৃত সুইচ/নেটওয়ার্ক নয়)
import heapq
def dijkstra(graph, source):
"""সোর্স থেকে প্রতিটি নোডের shortest-path দূরত্ব ও prev-পয়েন্টার বের করে।"""
dist = {node: float("inf") for node in graph}
prev = {node: None for node in graph}
dist[source] = 0
pq = [(0, source)]
while pq:
d, node = heapq.heappop(pq)
if d > dist[node]:
continue
for neighbor, cost in graph[node].items():
nd = d + cost
if nd < dist[neighbor]:
dist[neighbor] = nd
prev[neighbor] = node
heapq.heappush(pq, (nd, neighbor))
return dist, prev
def next_hop_table(graph, source):
"""source থেকে প্রতিটি destination-এ shortest path-এর প্রথম hop-টি বের করে।"""
dist, prev = dijkstra(graph, source)
table = {}
for dest in graph:
if dest == source or dist[dest] == float("inf"):
continue
path = [dest]
while path[-1] != source:
path.append(prev[path[-1]])
path.reverse()
table[dest] = path[1] # source-এর ঠিক পরের নোড = next hop
return table
class DumbSwitch:
"""কন্ট্রোলারের দেওয়া টেবিল অনুযায়ী শুধু ফরওয়ার্ড করে — নিজে কোনো সিদ্ধান্ত নেয় না।"""
def __init__(self, name):
self.name = name
self.forwarding_table = {}
def install_table(self, table):
self.forwarding_table = table
def forward(self, dest):
return self.forwarding_table.get(dest, "DROP")
class SDNController:
"""পুরো নেটওয়ার্ক টপোলজি একবারে দেখে সব সুইচের ফরওয়ার্ডিং টেবিল কম্পিউট ও পুশ করে।"""
def __init__(self, topology):
self.topology = topology
self.switches = {name: DumbSwitch(name) for name in topology}
def compute_and_push_all_tables(self):
for name, switch in self.switches.items():
table = next_hop_table(self.topology, name)
switch.install_table(table)
# --- একটি ছোট নেটওয়ার্ক টপোলজি: {node: {neighbor: link_cost}} ---
topology = {
"A": {"B": 1, "C": 4},
"B": {"A": 1, "C": 1, "D": 5},
"C": {"A": 4, "B": 1, "D": 1},
"D": {"B": 5, "C": 1},
}
controller = SDNController(topology)
controller.compute_and_push_all_tables()
print("প্রাথমিক টপোলজি অনুযায়ী প্রতিটি সুইচের ফরওয়ার্ডিং টেবিল:")
for name, switch in controller.switches.items():
print(f" সুইচ {name}: {switch.forwarding_table}")
# --- নেটওয়ার্ক-ওয়াইড পরিবর্তন: B-C লিংক ব্যর্থ হলো ---
topology["B"]["C"] = 999
topology["C"]["B"] = 999
controller.compute_and_push_all_tables()
print("\nB-C লিংক ব্যর্থ হওয়ার পর — কন্ট্রোলার ONE কল-এই সব সুইচের টেবিল আপডেট করেছে:")
for name, switch in controller.switches.items():
print(f" সুইচ {name}: {switch.forwarding_table}")
print("\nA থেকে D-তে ফরওয়ার্ডিং সিদ্ধান্ত (আপডেটের পর):", controller.switches["A"].forward("D"))
compute_and_push_all_tables() একবার কল করলেই সব সুইচের টেবিল নতুন করে
কম্পিউট ও পুশ হয়ে যায়। ঐতিহ্যবাহী মডেলে B-C লিংক ব্যর্থ হলে A, B, C, D প্রতিটি রাউটারকে নিজে নিজে (OSPF-এর
মতো প্রোটোকলের মাধ্যমে, L19) এই পরিবর্তন "শিখতে" ও নিজের টেবিল পুনর্গণনা করতে হতো — SDN-এ কেন্দ্রীয় কন্ট্রোলার
একবারেই সবার হয়ে এই কাজ করে দেয়।
SDN-এর মূল অবদান নতুন কোনো ফরওয়ার্ডিং অ্যালগরিদম নয় (উপরের কোডে আমরা এখনও Dijkstra-ই ব্যবহার করছি, L19-এর মতো) — বরং কোথায় সেই সিদ্ধান্ত নেওয়া হচ্ছে তার স্থাপত্যগত পুনর্বিন্যাস। কেন্দ্রীকরণ নেটওয়ার্ক-ওয়াইড দৃশ্যমানতা ও প্রোগ্রামেবিলিটি দেয়, যা প্রতিটি ডিভাইসে আলাদাভাবে বিতরণকৃত সিদ্ধান্ত-গ্রহণের চেয়ে অনেক বেশি নমনীয়।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ SDN-এ "নির্বোধ সুইচ" বলতে ঠিক কী বোঝানো হচ্ছে — এরা কি একেবারেই কোনো সিদ্ধান্ত নেয় না?
"নির্বোধ" মানে এই নয় যে সুইচ কিছুই করে না — এটি এখনও প্রতিটি প্যাকেট/ফ্রেমের জন্য টেবিল লুকআপ করে ফরওয়ার্ড করে (ডেটা প্লেনের কাজ)। "নির্বোধ" বলতে বোঝানো হচ্ছে সুইচ নিজে সিদ্ধান্ত নেয় না যে কোন পথে ফরওয়ার্ড করা "উচিত" — সেই সিদ্ধান্ত সম্পূর্ণভাবে কেন্দ্রীয় কন্ট্রোলার নেয় এবং সুইচকে শুধু ফলাফল-টেবিল দিয়ে দেয়। এটি ঠিক L12-এর MAC-লার্নিং সুইচের বিপরীত — সেখানে প্রতিটি সুইচ নিজে নিজে শেখে, এখানে কন্ট্রোলার শেখায়।
প্র ০২ SDN-এ কন্ট্রোলার একটি single point of failure হয়ে গেলেও কেন এটি ঐতিহ্যবাহী মডেলের চেয়ে খারাপ নয়?
বাস্তব SDN ডিপ্লয়মেন্টে একাধিক redundant কন্ট্রোলার চালানো হয় (L02-এর মেশ/রিডানডেন্সি নীতির মতো), তাই একটি কন্ট্রোলার ব্যর্থ হলে আরেকটি দায়িত্ব নেয়। এছাড়া, একটি কন্ট্রোলার সাময়িকভাবে অনুপলব্ধ হলেও চলমান সুইচগুলো তাদের সর্বশেষ পাওয়া ফরওয়ার্ডিং টেবিল অনুযায়ী কাজ চালিয়ে যেতে পারে (ডেটা প্লেন কন্ট্রোল প্লেন থেকে স্বাধীন) — শুধু নতুন নীতি-পরিবর্তন সাময়িকভাবে আটকে থাকবে, বিদ্যমান ট্রাফিক ফরওয়ার্ডিং বন্ধ হবে না।
প্র ০৩ উপরের কোড সেলে B-C লিংক ব্যর্থ হওয়ার পর A থেকে D-তে ফরওয়ার্ডিং সিদ্ধান্ত কেন বদলে যায়?
B-C লিংকের cost 999-এ বাড়িয়ে দেওয়ার পর, A থেকে D-এর দিকের সবচেয়ে কম-costly পথ আর B-এর মধ্য দিয়ে (যা আগে B-C-D হয়ে সস্তা ছিল) যাওয়া উচিত থাকে না — Dijkstra অ্যালগরিদম স্বয়ংক্রিয়ভাবে C-এর মধ্য দিয়ে যাওয়া বিকল্প পথ (A-C-D) বেছে নেয়, যা এখন সস্তা। যেহেতু কন্ট্রোলার পুরো টপোলজি একবারে দেখে, এই পুনর্গণনা সব সুইচের জন্য একসাথে, সঠিকভাবে হয়ে যায়।
অনুশীলন
-
চিন্তা করুন: ঐতিহ্যবাহী মডেলে (প্রতিটি রাউটার নিজে OSPF চালায়) B-C লিংক ব্যর্থ হলে নেটওয়ার্ক কীভাবে সেই খবর জানত, আর SDN মডেলে কীভাবে জানে — এই দুই প্রক্রিয়ার পার্থক্য কী?
ঐতিহ্যবাহী মডেলে প্রতিটি রাউটার নিজে নিজে লিংক-স্টেট তথ্য ফ্লাড করে (L19) এবং প্রতিটি রাউটার স্বাধীনভাবে নিজের Dijkstra পুনর্গণনা করে — একটি বিতরণকৃত (distributed) প্রক্রিয়া। SDN মডেলে সুইচগুলো নিজে কোনো routing protocol চালায় না — টপোলজি পরিবর্তনের খবর (কোনো মনিটরিং মেকানিজমের মাধ্যমে) সরাসরি কেন্দ্রীয় কন্ট্রোলারে যায়, আর কন্ট্রোলার একাই সব সিদ্ধান্ত পুনর্গণনা করে সবাইকে পাঠিয়ে দেয় — একটি কেন্দ্রীভূত প্রক্রিয়া।
-
পরীক্ষা করুন: উপরের কোড সেলে টপোলজিতে একটি নতুন নোড "E" যোগ করুন (যেমন শুধু D-এর সাথে সংযুক্ত) এবং
compute_and_push_all_tables()আবার চালিয়ে দেখুন সব সুইচের টেবিলে E-তে পৌঁছানোর পথও সঠিকভাবে যোগ হয় কি না।নতুন নোড E যোগ করার পর (এবং D-এর dict-এও E-কে প্রতিবেশী হিসেবে যোগ করার পর)
next_hop_tableস্বয়ংক্রিয়ভাবে প্রতিটি সুইচের জন্য E-তে পৌঁছানোর shortest path হিসাব করবে, কারণ ফাংশনটিgraph-এর যেকোনো নোড-সংখ্যার জন্য সাধারণভাবে কাজ করে — এটিই দেখায় কেন্দ্রীভূত কন্ট্রোলার টপোলজি বৃদ্ধিতেও সহজে স্কেল করে।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ পরবর্তী পাঠ — L50-এ NFV দিয়ে দেখব কীভাবে নেটওয়ার্ক ফাংশনগুলোই সফটওয়্যার হয়ে যায়।
- Cloud Computing & DevOps কোর্স সঙ্গী কোর্স ক্লাউড প্রোভাইডারের নিজস্ব SDN-চালিত ভার্চুয়াল নেটওয়ার্কিং ব্যবহারিকভাবে দেখতে দেখুন।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design, Cybersecurity, Cloud Computing & DevOps ও Computer Networks — সব এক জায়গায়।