Software-Defined Networking (SDN) in Computer Networks - Step-by-Step Execution

Concept Flow - Software-Defined Networking (SDN)

Start: Network Devices

↓

Separate Control Plane

↓

Central SDN Controller

↓

Send Instructions to Devices

↓

Devices Forward Data as Directed

↓

Network Behavior Changes Dynamically

↓

End

SDN separates the control logic from network devices and centralizes it in a controller that directs devices how to handle data.

Execution Sample

Computer Networks

1. Controller decides path
2. Controller sends rules to switches
3. Switches forward packets per rules
4. Controller updates rules as needed

Shows how the SDN controller manages network devices by sending forwarding rules dynamically.

Analysis Table

Step	Action	Controller State	Device State	Result
1	Controller calculates best path	Path A->B->C	Idle	Ready to send rules
2	Controller sends rules to switches	Path A->B->C	Rules received	Switches configured
3	Switches forward packets	Path A->B->C	Forwarding packets on path	Data flows correctly
4	Controller detects congestion	Path A->B->C congested	Forwarding packets	Needs new path
5	Controller recalculates path	Path A->D->C	Rules outdated	Prepare new rules
6	Controller sends new rules	Path A->D->C	Rules updated	Switches reconfigured
7	Switches forward packets	Path A->D->C	Forwarding packets on new path	Data flows smoothly
8	No further changes	Stable path	Stable forwarding	Network stable

💡 Network stabilizes with updated paths and forwarding rules.

State Tracker

Variable	Start	After Step 2	After Step 5	After Step 6	Final
Controller Path	None	A->B->C	A->D->C	A->D->C	A->D->C
Switch Rules	None	Rules for A->B->C	Rules for A->B->C	Rules for A->D->C	Rules for A->D->C
Data Flow	Stopped	Flow on A->B->C	Flow on A->B->C (congested)	Flow paused	Flow on A->D->C

Key Insights - 3 Insights

Why does the controller send new rules to switches?

Because the network path became congested (see step 4), the controller recalculates a better path (step 5) and must update switches with new forwarding rules (step 6).

Do switches decide how to forward packets on their own?

No, switches follow instructions from the controller (step 2 and 6). They do not decide paths themselves, which is different from traditional networks.

What happens if the controller stops sending updates?

Switches continue forwarding using last received rules, but network cannot adapt to changes like congestion, leading to possible performance issues (see final stable state).

Visual Quiz - 3 Questions

Look at the execution table, what is the controller's path after step 5?

A A->B->C

B A->D->C

C B->C->D

D No path assigned

💡 Hint

Check the 'Controller Path' variable in variable_tracker after step 5.

At which step do switches receive updated rules for the new path?

A Step 2

B Step 4

C Step 6

D Step 8

💡 Hint

Look at the 'Action' and 'Result' columns in execution_table for when new rules are sent.

If the controller never recalculated the path, what would happen to data flow after step 4?

A Data flow would remain congested on old path

B Switches would stop forwarding packets

C Data flow would continue smoothly

D Switches would find new paths themselves

💡 Hint

Refer to step 4 and key moment about controller updates.

Concept Snapshot

Software-Defined Networking (SDN):
- Separates control plane from devices
- Central controller manages network paths
- Controller sends forwarding rules to devices
- Enables dynamic, programmable network behavior
- Devices forward data as instructed
- Improves flexibility and network management

Full Transcript

Software-Defined Networking (SDN) changes how networks work by separating the control logic from the devices that forward data. Instead of each device deciding how to send data, a central controller decides the best paths and sends instructions to devices. This lets the network adapt quickly to changes like congestion. The controller calculates paths, sends rules to switches, and updates them as needed. Switches follow these rules to forward data. If the controller stops updating, the network can't adapt and may slow down. This approach makes networks easier to manage and more flexible.

Practice

1. What is the main purpose of Software-Defined Networking (SDN)?

easy

A. To combine hardware and software into a single device

B. To replace all network cables with wireless connections

C. To increase the physical size of network devices

D. To separate the control plane from the data plane for easier network management

Solution

1. Step 1: Understand SDN architecture

   SDN separates the control plane (which decides where traffic is sent) from the data plane (which forwards traffic).

2. Step 2: Identify the main benefit

   This separation allows easier and centralized network management.

3. Final Answer:

   To separate the control plane from the data plane for easier network management -> Option D

4. Quick Check:

   SDN = Control and data plane separation [OK]

Hint: SDN means control and data parts are separate [OK]

Common Mistakes:

• Thinking SDN combines hardware and software physically
• Confusing SDN with wireless technology
• Assuming SDN increases device size

2. Which of the following is the correct component of an SDN architecture?

easy

A. Control plane, data plane, and application plane

B. Router, switch, and firewall only

C. Physical cables and wireless signals

D. User interface and database only

Solution

1. Step 1: Recall SDN components

   SDN architecture includes the control plane (manages decisions), data plane (forwards data), and application plane (network applications).

2. Step 2: Match options with components

   Only Control plane, data plane, and application plane lists these three key planes correctly.

3. Final Answer:

   Control plane, data plane, and application plane -> Option A

4. Quick Check:

   SDN components = Control, data, application planes [OK]

Hint: Remember SDN has three planes: control, data, application [OK]

Common Mistakes:

• Confusing physical devices with SDN planes
• Ignoring the application plane
• Mixing network hardware with SDN architecture

3. Consider this SDN controller command snippet:
flow_mod = { 'match': {'ip_dst': '10.0.0.5'}, 'actions': ['output:2'] }
What does this command do in the network?

medium

A. It drops all packets destined to 10.0.0.5

B. It forwards packets destined to 10.0.0.5 out of port 2

C. It blocks port 2 for all traffic

D. It sends packets from port 2 to 10.0.0.5

Solution

1. Step 1: Analyze the flow_mod command

   The command matches packets with destination IP 10.0.0.5 and sets action to output on port 2.

2. Step 2: Understand the effect

   Packets matching the destination IP will be forwarded out of port 2.

3. Final Answer:

   It forwards packets destined to 10.0.0.5 out of port 2 -> Option B

4. Quick Check:

   Match IP, output port 2 = forward packets [OK]

Hint: Match destination IP, then forward to specified port [OK]

Common Mistakes:

• Thinking it drops packets instead of forwarding
• Confusing input and output ports
• Assuming it blocks traffic

4. A network admin writes this SDN rule:
flow_mod = { 'match': {'ip_src': '192.168.1.10'}, 'actions': ['drop'] }
But packets from 192.168.1.10 are still passing through. What is the likely error?

medium

A. The action 'drop' is not a valid action keyword

B. The match field should be 'ip_dst' instead of 'ip_src'

C. The rule is missing a priority level

D. The controller is offline

Solution

1. Step 1: Check the action keyword validity

   In SDN, to drop packets, the action list should be empty or use a specific drop command depending on the controller. 'drop' as a string in actions is usually invalid.

2. Step 2: Evaluate other options

   Match on 'ip_src' is valid, priority is optional but recommended, and controller status is unrelated to this syntax error.

3. Final Answer:

   The action 'drop' is not a valid action keyword -> Option A

4. Quick Check:

   Invalid action keyword causes rule failure [OK]

Hint: Check if action keywords are valid in SDN rules [OK]

Common Mistakes:

• Assuming 'drop' is always valid in actions list
• Confusing source and destination IP fields
• Ignoring controller connectivity issues

5. In an SDN environment, how can network administrators quickly isolate a compromised device without physically disconnecting it?

hard

A. By increasing the device's bandwidth allocation

B. By unplugging the device's network cable manually

C. By updating the SDN controller to block traffic from the device's IP or MAC address

D. By restarting the device remotely

Solution

1. Step 1: Understand SDN's centralized control

   SDN allows administrators to control network behavior centrally via the controller without physical intervention.

2. Step 2: Apply isolation method

   Blocking traffic from a device's IP or MAC address at the controller level isolates it quickly and effectively.

3. Final Answer:

   By updating the SDN controller to block traffic from the device's IP or MAC address -> Option C

4. Quick Check:

   SDN controller blocks device traffic = quick isolation [OK]

Hint: Use SDN controller to block device traffic instantly [OK]

Common Mistakes:

• Thinking physical disconnection is needed
• Restarting device does not isolate it
• Increasing bandwidth helps attacker access