L

Networking

Layer 2 & Layer 3 Networking

Updated 6/29/202647 min readDownload PDFEdit

Layer 2 & Layer 3 Networking — Complete Notes

Written for Nokia Software/QA Co-op Prep | Kalyan Gopalam | Northeastern University M.S. Cybersecurity

Table of Contents

  1. The OSI Model — Why It Exists
  2. Layer 2 — The Data Link Layer
  3. Layer 3 — The Network Layer
  4. Control Plane vs Data Plane
  5. Programmable Management Interfaces
  6. Real-Time Operating Systems (RTOS)
  7. Virtualization in Networking
  8. How L2 and L3 Work Together — End-to-End Packet Walk
  9. Lab Project — Build Your Own L2 Lab Right Now
  10. Nokia JD Mapping
  11. Quick Reference Cheat Sheet

1. The OSI Model — Why It Exists

Before diving into Layer 2 and Layer 3 specifically, you need to understand why the OSI model exists at all.

When networks were first being designed, every vendor — IBM, DEC, Xerox — built proprietary systems. A device from one vendor couldn't talk to a device from another. In 1984, the ISO (International Organization for Standardization) published the OSI (Open Systems Interconnection) model to create a universal reference framework. It divides the job of "move data from one computer to another" into 7 distinct layers, each with a specific, well-defined responsibility.

The idea is separation of concerns. Each layer only worries about its own job and talks to the layers immediately above and below it. This way, you can swap out the physical cable (Layer 1) from copper to fiber without rewriting the routing software (Layer 3). Each layer is independent.

┌─────────────────────────────────────────────────────┐
│  Layer 7 — Application   (HTTP, DNS, SMTP, FTP)     │
│  Layer 6 — Presentation  (TLS/SSL, encoding)        │
│  Layer 5 — Session       (session management)       │
│  Layer 4 — Transport     (TCP, UDP — ports)         │
│  Layer 3 — Network       (IP, routing)              │  ← This is what we study
│  Layer 2 — Data Link     (Ethernet, MAC, switching) │  ← This is what we study
│  Layer 1 — Physical      (cables, signals, bits)    │
└─────────────────────────────────────────────────────┘

Important mental model: As data travels down the stack on the sender's side, each layer encapsulates the data by wrapping a header around it. As data travels up the stack on the receiver's side, each layer strips its header. This process is called encapsulation and decapsulation.

Application data
     ↓ + TCP header   →  Segment       (Layer 4)
     ↓ + IP header    →  Packet        (Layer 3)
     ↓ + MAC header   →  Frame         (Layer 2)
     ↓ + physical     →  Bits on wire  (Layer 1)

The data unit name changes at each layer:

  • Layer 4 → Segment (TCP) or Datagram (UDP)
  • Layer 3 → Packet
  • Layer 2 → Frame
  • Layer 1 → Bits

This matters because when Nokia engineers talk about "Layer 2 software," they mean code that deals with frames — not packets, not segments. The terminology is precise.

2. Layer 2 — The Data Link Layer

2.1 What Layer 2 Is Responsible For

Layer 2's job is to move data between two devices that are directly connected on the same local network. It doesn't know anything about routing across the internet — that's Layer 3's job. Layer 2 only cares about getting a frame from one machine to another machine on the same LAN (Local Area Network).

Layer 2 has two sub-layers, defined by the IEEE:

  • LLC (Logical Link Control) — handles flow control and error checking between network nodes
  • MAC (Media Access Control) — handles how devices on a shared medium take turns using the channel, and defines MAC addressing

The device that operates at Layer 2 is the switch. A switch's only job in life is to receive frames on one port and forward them out the correct port based on MAC addresses. It knows nothing about IP addresses.

2.2 MAC Addresses

A MAC (Media Access Control) address is a 48-bit (6-byte) hardware address assigned to every network interface card (NIC) at the time of manufacture. It is burned into the hardware and meant to be globally unique.

Format:

AA:BB:CC:DD:EE:FF

Written as 6 pairs of hexadecimal digits, separated by colons (or dashes on Windows). Each pair is one byte. Total = 6 bytes = 48 bits.

Structure of a MAC address:

┌──────────────────────┬──────────────────────┐
│  OUI (3 bytes)       │  Device ID (3 bytes) │
│  Organizationally    │  Assigned by the     │
│  Unique Identifier   │  manufacturer        │
│  Assigned by IEEE    │                      │
└──────────────────────┴──────────────────────┘

The first 3 bytes identify the manufacturer. For example, 00:00:0C belongs to Cisco. This is why you can look up a MAC prefix and identify the vendor.

Special MAC addresses:

  • FF:FF:FF:FF:FF:FF — broadcast address. A frame sent to this address is delivered to every device on the LAN.
  • 01:xx:xx:xx:xx:xx — multicast address. The least significant bit of the first byte being 1 indicates multicast.
  • All others — unicast. Sent to a single specific device.

Important: MAC addresses operate only within a single network segment. When a packet crosses a router to a different network, the MAC address changes at every hop. The IP address stays the same end-to-end; the MAC address changes hop-by-hop.

2.3 Ethernet Frames

Ethernet is the dominant Layer 2 protocol for wired networks (defined in IEEE 802.3). It defines the exact format of a frame — how bytes are arranged when data is put on the wire.

Ethernet II Frame Structure (the most common format):

┌────────────┬──────────┬──────────┬───────────┬─────────┬─────┐
│  Preamble  │ Dest MAC │  Src MAC │ EtherType │ Payload │ FCS │
│  8 bytes   │ 6 bytes  │  6 bytes │  2 bytes  │46-1500B │4 B  │
└────────────┴──────────┴──────────┴───────────┴─────────┴─────┘

Let's go through each field:

Preamble (8 bytes) 7 bytes of alternating 10101010 bits followed by 1 byte 10101011 (Start Frame Delimiter). This is a synchronization signal that tells the receiving NIC "a frame is about to start." The preamble is stripped off before the frame reaches Layer 2 software — it's handled at Layer 1.

Destination MAC (6 bytes) The MAC address of the intended recipient. Can be unicast, multicast, or broadcast.

Source MAC (6 bytes) The MAC address of the sender. This is how switches learn — "the device with this MAC address sent a frame in on port X."

EtherType (2 bytes) This is critical. It tells the receiver what protocol is inside the payload. Common values:

  • 0x0800 — IPv4
  • 0x86DD — IPv6
  • 0x0806 — ARP
  • 0x8100 — 802.1Q VLAN tag (we'll cover this below)
  • 0x8847 — MPLS unicast

When Layer 2 software reads this field, it knows how to hand the payload off to the right Layer 3 handler.

Payload (46–1500 bytes) The actual data being carried. The minimum is 46 bytes (padding is added if needed). The maximum is 1500 bytes — this is the MTU (Maximum Transmission Unit) for Ethernet. If your IP packet is larger than 1500 bytes, it must be fragmented.

FCS — Frame Check Sequence (4 bytes) A CRC-32 checksum computed over the entire frame. The receiver recomputes the checksum and compares it to the FCS field. If they don't match, the frame is silently discarded. This is Layer 2's error detection mechanism. Note: it detects errors but doesn't correct them — that's TCP's job at Layer 4.

2.4 How a Switch Works — MAC Learning

This is the single most important concept in Layer 2 networking. Understanding this deeply is what separates someone who "knows networking" from someone who just memorized terms.

A switch maintains a table called the CAM table (Content Addressable Memory table), also called the MAC address table or forwarding database (FDB). This table maps MAC addresses to physical switch ports.

How the CAM table gets populated — MAC learning:

When a switch is first powered on, its CAM table is empty. It has no idea which device is connected to which port. Here is exactly what happens step by step:

Step 1 — Frame arrives Device A (MAC: AA:AA:AA:AA:AA:AA) on port 1 sends a frame to Device B (MAC: BB:BB:BB:BB:BB:BB) on port 3.

Step 2 — Learn the source The switch reads the source MAC from the frame: AA:AA:AA:AA:AA:AA. It records this in the CAM table:

MAC Address          Port    Age
AA:AA:AA:AA:AA:AA    1       0s

This is MAC learning — the switch now knows where Device A lives.

Step 3 — Look up the destination The switch looks up BB:BB:BB:BB:BB:BB in the CAM table. It's not there yet. The switch doesn't know which port Device B is on.

Step 4 — Flood Since the destination is unknown, the switch sends the frame out all ports except the port it arrived on (port 1). This is called unknown unicast flooding. Every device on the network receives this frame, but only Device B will accept it (others drop it because the destination MAC doesn't match theirs).

Step 5 — Device B replies Device B sends a reply back to Device A. The switch now sees a frame arriving on port 3 with source MAC BB:BB:BB:BB:BB:BB. It learns:

MAC Address          Port    Age
AA:AA:AA:AA:AA:AA    1       5s
BB:BB:BB:BB:BB:BB    3       0s

Step 6 — Direct forwarding from now on Now the switch knows both devices. All future frames between A and B go directly — no flooding. The switch hardware forwards them in microseconds.

CAM table aging: Entries don't stay forever. If the switch hasn't seen traffic from a MAC address in a certain time (typically 300 seconds by default), it removes the entry. This handles the case where a device moves to a different port or is unplugged.

What happens with broadcast? A frame destined for FF:FF:FF:FF:FF:FF is always flooded out all ports. The switch has no choice — broadcast is meant for everyone.

The security implication (relevant to your background): A MAC flooding attack works by sending thousands of frames with fake source MACs, filling up the CAM table. When the table is full, the switch can't learn new entries and starts flooding all unknown traffic — effectively turning a switch into a hub. An attacker can now capture traffic with a sniffer. This is why port security features (limiting MAC count per port) exist — and why Nokia builds security hardening into their L2 software.

2.5 VLANs — IEEE 802.1Q

A VLAN (Virtual LAN) lets you divide one physical switch into multiple logical networks. Devices in different VLANs cannot communicate at Layer 2, even if they're plugged into the same physical switch. This is a fundamental tool for network segmentation.

Why VLANs exist: Without VLANs, every broadcast on the network (ARP requests, DHCP, etc.) reaches every device. As networks grow, this broadcast traffic becomes overwhelming. VLANs contain broadcasts to a smaller broadcast domain.

Also: a company's finance team and engineering team shouldn't be able to sniff each other's traffic just because they're in the same building. VLANs enforce logical separation.

How 802.1Q tagging works:

IEEE 802.1Q defines a method for inserting a 4-byte tag into the Ethernet frame to identify which VLAN it belongs to.

Standard Ethernet frame:

| Dest MAC | Src MAC | EtherType | Payload | FCS |

802.1Q tagged frame:

| Dest MAC | Src MAC | 0x8100 | TCI | EtherType | Payload | FCS |

The 0x8100 EtherType tells the receiver "this frame has a VLAN tag." The next 2 bytes are the TCI (Tag Control Information):

┌──────┬───┬────────────────┐
│ PCP  │ DEI│   VLAN ID     │
│3 bits│1 b │   12 bits     │
└──────┴───┴────────────────┘
  • PCP (Priority Code Point): 3 bits for QoS — allows traffic prioritization (0–7)
  • DEI (Drop Eligible Indicator): 1 bit, marks frames that can be dropped during congestion
  • VLAN ID: 12 bits = values 0–4095. VLAN 0 and 4095 are reserved. So you can have 1–4094 usable VLANs.

Access ports vs Trunk ports:

This is critical to understand. Switch ports operate in two modes:

Access port:

  • Belongs to exactly one VLAN
  • Frames going out this port have the VLAN tag stripped off — the end device never sees the tag
  • Used for connecting end devices (computers, servers, printers)
  • Example: Your laptop is on VLAN 10. The switch port strips the tag before delivering to your laptop.

Trunk port:

  • Carries traffic for multiple VLANs simultaneously
  • Frames keep their 802.1Q tag so the receiving switch knows which VLAN they belong to
  • Used for switch-to-switch connections and switch-to-router connections
  • Example: Two switches connected together. The trunk link carries VLAN 10, 20, and 30 all on one cable, tagged.

Inter-VLAN routing: Devices in different VLANs cannot reach each other at Layer 2 — that's the point. If you want VLAN 10 to talk to VLAN 20, you need a router (Layer 3 device) in between. The router has a subinterface for each VLAN on the trunk link and routes between them. This is called Router-on-a-Stick.

In modern networks, a Layer 3 switch has built-in routing and can route between VLANs without an external router, using SVIs (Switched Virtual Interfaces).

2.6 Spanning Tree Protocol (STP)

The problem STP solves:

For redundancy, networks are designed with multiple paths between switches. But if you have a loop in the network, broadcasts will circulate forever. Here's what happens:

  1. Switch A sends a broadcast
  2. Switch B receives it on port 1, floods it out port 2 to Switch C
  3. Switch C receives it, floods it out port 2 back to Switch A
  4. Switch A receives its own broadcast and floods it again
  5. This repeats infinitely — broadcast storm

The network is destroyed within seconds. The CAM tables fill with contradictory entries as the same MAC appears to move between ports. This is called a Layer 2 loop and it is catastrophic.

STP (IEEE 802.1D) solves this by detecting loops and logically blocking one of the redundant paths. Only one path is active at a time. If the active path fails, the blocked path is activated.

How STP works — step by step:

Step 1 — Root Bridge Election Every switch has a Bridge ID = 2 bytes priority + 6 bytes MAC address. Default priority is 32768.

  • Switches exchange BPDU (Bridge Protocol Data Unit) messages
  • The switch with the lowest Bridge ID becomes the Root Bridge
  • Since priority is equal by default, the switch with the lowest MAC address wins
  • The Root Bridge is the center of the spanning tree

Step 2 — Root Port Selection Every non-root switch selects one Root Port — the port closest to the Root Bridge (lowest path cost). Path cost is determined by link speed:

  • 10 Mbps = cost 100
  • 100 Mbps = cost 19
  • 1 Gbps = cost 4
  • 10 Gbps = cost 2

Step 3 — Designated Port Selection On every network segment (link), one port is elected the Designated Port — the port that forwards traffic toward the Root Bridge. On root bridge, all ports are designated.

Step 4 — Blocking Redundant Ports Any port that is neither a Root Port nor a Designated Port is put into blocking state. It doesn't forward frames but still listens for BPDUs.

STP Port States:

Blocking → Listening → Learning → Forwarding
  • Blocking: Doesn't forward frames, listens for BPDUs only
  • Listening: Listens to BPDUs, participates in election, no frame forwarding
  • Learning: Starts learning MAC addresses, no frame forwarding yet
  • Forwarding: Fully active, forwards frames and learns MACs

The transition from blocking to forwarding takes 30–50 seconds by default (a problem!).

RSTP (Rapid STP, IEEE 802.1w): A faster version of STP. Converges in under 1 second by using a proposal/agreement mechanism instead of waiting through timers. RSTP is the modern standard. Nokia implements RSTP and MSTP (Multiple Spanning Tree Protocol, which allows different VLANs to have different spanning trees).

2.7 ARP — Address Resolution Protocol

ARP is the glue between Layer 2 and Layer 3. This is how your computer finds a MAC address when it only knows an IP address.

The problem: Your computer wants to send data to IP address 192.168.1.50. It knows the IP address. But to build an Ethernet frame, it needs the destination MAC address. Where does it get it?

ARP to the rescue:

  1. Your computer checks its ARP cache (a local table of IP→MAC mappings). If found, done.
  2. If not found, it broadcasts an ARP Request frame to FF:FF:FF:FF:FF:FF:
    • "Who has 192.168.1.50? Tell 192.168.1.10"
  3. Every device on the LAN receives this. Only 192.168.1.50 responds with an ARP Reply (unicast):
    • "I have 192.168.1.50. My MAC is AA:BB:CC:DD:EE:FF"
  4. Your computer caches this mapping (typically for 20 minutes) and builds the Ethernet frame.

ARP Table:

$ arp -a
? (192.168.1.1) at a4:91:b1:xx:xx:xx [ether] on eth0
? (192.168.1.50) at AA:BB:CC:DD:EE:FF [ether] on eth0

ARP only works within a single subnet. If you're sending to an IP on a different network, ARP resolves the MAC of the default gateway (router), not the final destination. The router then handles routing to the destination.

Security note (your background): ARP spoofing / ARP poisoning is a classic Layer 2 attack. An attacker broadcasts fake ARP replies claiming "I have IP 192.168.1.1, my MAC is attacker:mac." Victims update their ARP cache with the fake mapping, and traffic flows to the attacker instead. This is the foundation of Man-in-the-Middle attacks on local networks. Tools like arpspoof and ettercap automate this.

2.8 LACP — Link Aggregation

LACP (Link Aggregation Control Protocol, IEEE 802.3ad) allows multiple physical network links to be bonded together into a single logical link. This gives you:

  • Higher bandwidth — a 4-port LAG with 1 Gbps ports = 4 Gbps logical link
  • Redundancy — if one physical link fails, others continue carrying traffic

The switch and the connected device negotiate via LACP PDUs to agree on which ports to bundle. The result is a LAG (Link Aggregation Group) or port-channel — a single logical interface.

Nokia builds LACP into their switch software. From the software side, LACP involves implementing the state machine, sending/receiving LACPDUs, and programming the hardware to distribute traffic across member links.

2.9 MACsec — Layer 2 Encryption

MACsec (IEEE 802.1AE) is encryption at Layer 2 — it encrypts Ethernet frames between switches. This is distinct from TLS (Layer 7) or IPsec (Layer 3). MACsec protects traffic on the wire between two directly connected devices.

Directly relevant to your security background. Nokia implements MACsec in their platforms, and it's a growing area as enterprises demand encryption even inside their data centers.

3. Layer 3 — The Network Layer

3.1 What Layer 3 Is Responsible For

Layer 3's job is to move packets between different networks. While Layer 2 only operates within one LAN, Layer 3 is what makes the internet work — routing packets from a device in Boston to a server in Tokyo, across hundreds of intermediate routers.

Layer 3 introduces two key concepts Layer 2 doesn't have:

  1. Logical addressing — IP addresses (not hardware-bound, assignable)
  2. Routing — choosing the best path through a network of networks

The device that operates at Layer 3 is the router. A router's job: receive a packet, look at the destination IP, consult the routing table, forward it toward the destination.

3.2 IP Addressing

IPv4 addresses are 32-bit numbers written in dotted decimal notation: 192.168.1.100. Each of the four numbers is one byte (0–255).

Subnet masks define the boundary between the network portion and the host portion of an IP address:

  • 192.168.1.100/24 means the first 24 bits are the network, last 8 bits identify the host
  • Network: 192.168.1.0, Host: 100
  • This subnet can hold 2^8 - 2 = 254 hosts (subtract network address and broadcast)

CIDR (Classless Inter-Domain Routing) is the modern system that replaced the old Class A/B/C system. It uses the /prefix notation to define arbitrary subnet sizes.

IPv6 addresses are 128-bit, written as 8 groups of 4 hex digits: 2001:0db8:85a3:0000:0000:8a2e:0370:7334. IPv6 was designed to solve IPv4 address exhaustion (only ~4.3 billion IPv4 addresses exist).

3.3 The IP Packet Header

Understanding the IP header is essential for any networking engineer. Here is the IPv4 header:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |     DSCP    |ECN|          Total Length       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Let's go through every field that matters:

Version (4 bits): 4 for IPv4, 6 for IPv6. First thing a router checks.

IHL — Internet Header Length (4 bits): Length of the header in 32-bit words. Minimum value is 5 (= 20 bytes, no options). Maximum is 15 (= 60 bytes).

DSCP — Differentiated Services Code Point (6 bits): QoS marking. Allows routers to prioritize certain traffic (e.g., VoIP packets marked EF — Expedited Forwarding — get sent first).

Total Length (16 bits): Total size of the packet including header and payload. Maximum = 65,535 bytes.

Identification (16 bits), Flags (3 bits), Fragment Offset (13 bits): These three fields together manage IP fragmentation. If a packet is larger than the MTU of a link, it must be split into smaller fragments. Each fragment carries the same Identification field so the destination knows they belong together. The Fragment Offset indicates where in the original packet this fragment begins. The Don't Fragment (DF) flag, when set, tells routers not to fragment — if the packet is too big, drop it and send an ICMP "Fragmentation Needed" message back.

TTL — Time to Live (8 bits): This is a loop prevention mechanism at Layer 3. Every router that forwards a packet decrements the TTL by 1. When TTL reaches 0, the router drops the packet and sends an ICMP "Time Exceeded" message back to the sender. Default TTL values: 64 (Linux), 128 (Windows), 255 (Cisco). The traceroute command works by sending packets with incrementing TTLs (1, 2, 3...) to map the path.

Protocol (8 bits): Tells the receiver what's inside the payload. This is Layer 3's version of EtherType:

  • 6 = TCP
  • 17 = UDP
  • 1 = ICMP
  • 89 = OSPF
  • 47 = GRE (tunneling)

Header Checksum (16 bits): Error check for the header only (not the payload — that's TCP/UDP's job). Recomputed at every hop because TTL changes.

Source Address (32 bits): IP address of the sender. Stays the same the entire path end-to-end.

Destination Address (32 bits): IP address of the destination. Stays the same the entire path end-to-end.

3.4 Routing Tables — RIB and FIB

This is the core of Layer 3. Every router maintains tables that tell it where to send packets.

RIB — Routing Information Base

The RIB is the full routing table — the "master database" of all routes the router knows about. It contains routes learned from multiple sources:

  • Static routes — manually configured by an admin
  • Directly connected — subnets the router is directly plugged into
  • OSPF routes — learned from OSPF neighbors
  • BGP routes — learned from BGP peers

When multiple protocols learn routes to the same destination, the router picks the best one using Administrative Distance (AD) — a measure of trustworthiness. Lower AD wins:

Route Source              Administrative Distance
Connected                        0
Static                           1
OSPF                           110
BGP (external)                 200

FIB — Forwarding Information Base

The FIB is a compiled, optimized subset of the RIB. While the RIB contains all known routes (potentially millions in a carrier router), the FIB contains only the best routes, structured for fast lookup. The FIB is what the data plane actually uses when forwarding packets. In hardware-accelerated routers, the FIB is programmed into the ASIC (Application-Specific Integrated Circuit) for nanosecond lookup times.

This is a critical distinction Nokia engineers care about. The control plane software manages the RIB and programs the FIB. The data plane hardware reads the FIB.

3.5 Longest Prefix Match

When a router looks up where to send a packet, multiple routes might match the destination IP. The router always picks the most specific (longest prefix) match.

Example routing table:

10.0.0.0/8        via 192.168.1.1
10.10.0.0/16      via 192.168.1.2
10.10.20.0/24     via 192.168.1.3
0.0.0.0/0         via 203.0.113.1   (default route)

Packet destined for 10.10.20.55:

  • Matches 10.0.0.0/8 (8-bit prefix)
  • Matches 10.10.0.0/16 (16-bit prefix)
  • Matches 10.10.20.0/24 (24-bit prefix) ← winner — most specific
  • Matches 0.0.0.0/0 (0-bit prefix — matches everything)

The router forwards via 192.168.1.3. Longest prefix wins, always.

This lookup must happen for every single packet at line rate — potentially millions of packets per second. This is why specialized hardware (TCAM — Ternary Content Addressable Memory) is used in high-end routers. TCAM can perform longest prefix match in a single clock cycle.

3.6 ICMP

ICMP (Internet Control Message Protocol, Protocol number 1) is a Layer 3 protocol used for diagnostics and error reporting between routers and hosts. It rides inside IP packets but is part of Layer 3.

Common ICMP messages:

  • Type 0: Echo Reply — response to a ping
  • Type 8: Echo Request — the ping itself
  • Type 3: Destination Unreachable — router can't forward packet
  • Type 11: Time Exceeded — TTL hit 0 (used by traceroute)
  • Type 5: Redirect — tells a host to use a different gateway

ping and traceroute are the two most common network troubleshooting tools, and both use ICMP.

3.7 OSPF — Open Shortest Path First

OSPF is an Interior Gateway Protocol (IGP) — it's used for routing within a single organization or autonomous system. OSPF is a link-state protocol, meaning every router builds a complete map of the entire network topology.

How OSPF works — step by step:

Step 1 — Neighbor Discovery Routers send Hello packets out their interfaces every 10 seconds (default). When two routers receive each other's hellos, they form an adjacency (neighbor relationship). They must agree on parameters: subnet, area, timers, authentication.

Step 2 — Link State Advertisements (LSAs) Each router generates LSAs describing its connected links and their costs. These LSAs are flooded throughout the OSPF area — every router in the area receives every LSA.

Step 3 — LSDB — Link State Database Every router stores all received LSAs in its LSDB. Because all routers receive the same LSAs, every router in the area has an identical LSDB — an identical map of the network.

Step 4 — SPF Calculation Each router independently runs Dijkstra's Shortest Path First algorithm on its LSDB. This computes the shortest path (lowest cost) from itself to every other router. The result is installed in the RIB.

OSPF Cost: OSPF assigns a cost to each interface: Cost = Reference bandwidth / Interface bandwidth. Default reference is 100 Mbps:

  • FastEthernet (100 Mbps) = cost 1
  • GigabitEthernet (1 Gbps) = cost 1 (same as Fast by default — often adjusted)
  • Serial (1.544 Mbps) = cost 64

Lower cost = preferred path.

OSPF Areas: Large networks are divided into areas to limit LSA flooding. All areas must connect to Area 0 (Backbone Area). Routers between areas are ABRs (Area Border Routers). This hierarchical design makes OSPF scalable to large enterprise networks.

Nokia's OSPF implementation involves writing the state machine, LSA generation, flooding logic, SPF computation, and RIB installation in C.

3.8 BGP — Border Gateway Protocol

BGP is the routing protocol of the internet. It is the only Exterior Gateway Protocol (EGP) in widespread use. Every ISP, cloud provider (AWS, GCP, Azure), CDN (Cloudflare, Akamai), and large enterprise runs BGP.

BGP is a path-vector protocol. Instead of computing shortest paths by distance/cost, BGP routes carry the full AS Path — the list of Autonomous Systems the route has traversed. Loop prevention is simple: if you see your own AS number in the path, reject the route.

Autonomous System (AS): An AS is a collection of IP prefixes under the control of one organization, with a unified routing policy. Each AS has a globally unique ASN (Autonomous System Number), 16-bit (1–65535) or 32-bit. Examples:

  • AS15169 = Google
  • AS16509 = Amazon AWS
  • AS36351 = Nokia

iBGP vs eBGP:

  • eBGP (External BGP): BGP between routers in different ASes. This is what connects ISPs to each other.
  • iBGP (Internal BGP): BGP between routers within the same AS. Used to carry external route information through the AS.

BGP Session Establishment: BGP uses TCP port 179. Two BGP routers form a session by:

  1. TCP 3-way handshake on port 179
  2. Exchange OPEN messages (negotiate version, ASN, hold timer)
  3. Exchange KEEPALIVE messages to confirm
  4. Exchange UPDATE messages to share routes
  5. Send NOTIFICATION if an error occurs (terminates session)

BGP keeps the TCP session alive with KEEPALIVE messages every 60 seconds (default). If 3 consecutive keepalives are missed (180 second hold timer), the session drops and routes are withdrawn.

BGP Path Selection: BGP uses a complex set of attributes to decide which path is best. The selection process (in order):

  1. Highest Weight (Cisco-proprietary, local to router)
  2. Highest Local Preference (preferred exit point, shared within AS)
  3. Prefer locally originated routes
  4. Shortest AS Path
  5. Lowest Origin (IGP < EGP < Incomplete)
  6. Lowest MED (Multi-Exit Discriminator — hint to neighbors)
  7. Prefer eBGP over iBGP
  8. Lowest IGP metric to next-hop
  9. Lowest Router ID

Nokia's SR (Service Router) product line is one of the most widely deployed BGP platforms in the world at carrier ISPs. Their BGP implementation must handle millions of routes and thousands of peers.

3.9 MPLS — Multiprotocol Label Switching

MPLS is a technique for speeding up packet forwarding in large networks. Instead of doing a full IP lookup (longest prefix match) at every router, MPLS assigns short labels to packets at the network edge and forwards based on those labels in the core.

How MPLS works:

                    MPLS Network
                ┌─────────────────┐
Packet in →  [LER]→[LSR]→[LSR]→[LER] → Packet out
  (IP)       (push  (swap  (swap  (pop)    (IP)
              label) label) label)
  • LER (Label Edge Router): Sits at the edge. Inspects the IP packet, assigns a label based on FEC (Forwarding Equivalence Class), and pushes it onto the packet. On the exit side, pops the label.
  • LSR (Label Switch Router): Core routers. Never look at the IP header. They read the label, look up the LFIB (Label Forwarding Information Base), swap the label for a new one, and forward out the right interface. This is extremely fast.

MPLS label structure (4 bytes):

┌─────────────────────┬──────┬───┬──────┐
│  Label (20 bits)    │ TC   │ S │ TTL  │
│  0–1,048,575        │3 bits│1b │8 bits│
└─────────────────────┴──────┴───┴──────┘
  • Label: The forwarding identifier (20 bits = ~1 million possible labels)
  • TC (Traffic Class): QoS bits (was called EXP)
  • S (Bottom of Stack): 1 indicates this is the last label in a stack
  • TTL: Same loop prevention as IP TTL

MPLS is inserted between Layer 2 and Layer 3 headers — sometimes called Layer 2.5.

MPLS is foundational to MPLS VPNs (how service providers offer private WAN services to enterprise customers) and Traffic Engineering (controlling exact paths traffic takes through the network, bypassing normal shortest-path routing).

4. Control Plane vs Data Plane

This distinction is one of the most important concepts in modern networking. The Nokia JD explicitly mentions it: "control and data plane functionalities."

┌──────────────────────────────────────────────────────────────────┐
│                        CONTROL PLANE                             │
│                                                                  │
│  ┌─────────┐  ┌─────────┐  ┌──────────┐  ┌──────────────────┐  │
│  │  OSPF   │  │   BGP   │  │  RSVP-TE │  │  NETCONF/gNMI    │  │
│  │ daemon  │  │ daemon  │  │  daemon  │  │  management      │  │
│  └────┬────┘  └────┬────┘  └────┬─────┘  └────────┬─────────┘  │
│       └────────────┴────────────┘                  │            │
│                        ↓                           │            │
│              ┌──────────────────┐                  │            │
│              │  RIB Manager     │                  │            │
│              │  (Route Table)   │                  │            │
│              └────────┬─────────┘                  │            │
│                       ↓                            │            │
│              ┌──────────────────┐                  │            │
│              │  FIB Manager     │◄─────────────────┘            │
│              │  (Fwd Table)     │                               │
│              └────────┬─────────┘                               │
└───────────────────────┼─────────────────────────────────────────┘
                        │ programs
                        ↓
┌──────────────────────────────────────────────────────────────────┐
│                         DATA PLANE                               │
│                                                                  │
│    ┌─────────────────────────────────────────────────────────┐   │
│    │           ASIC / Network Processor / FPGA               │   │
│    │                                                         │   │
│    │  Packet in → [parse headers] → [FIB lookup] → [fwd]    │   │
│    │                                                         │   │
│    │  Operates at line rate: 100s of Gbps                    │   │
│    │  Nanosecond per-packet decisions                        │   │
│    └─────────────────────────────────────────────────────────┘   │
└──────────────────────────────────────────────────────────────────┘

Control Plane:

  • The "brain" — computes how traffic should flow
  • Runs on general-purpose CPUs
  • Runs routing protocols: OSPF, BGP, MPLS signaling (RSVP-TE, LDP)
  • Handles management: NETCONF, gNMI, SNMP
  • Written in C/C++, runs on Linux or RTOS
  • Speed: milliseconds to seconds (okay, because it's doing complex computation, not per-packet work)
  • What Nokia software engineers spend most of their time on

Data Plane:

  • The "muscle" — actually forwards packets
  • Runs on specialized hardware: ASICs, network processors, FPGAs
  • Does MAC learning, IP lookups, label swapping, QoS, ACLs — all at line rate
  • Programmed by the control plane (FIB is downloaded into hardware)
  • Speed: nanoseconds per packet, terabits per second throughput
  • Writing data plane code means writing firmware for ASICs or configuring pipeline stages — much more hardware-adjacent

Management Plane: Often mentioned separately. This is how humans and automation systems interact with the device — SSH, NETCONF, gNMI, SNMP. It rides on the control plane CPU but is logically distinct.

Why this separation matters for security: Control plane protection is critical. If an attacker floods a router with BGP UPDATE messages or malformed OSPF packets, they could crash the routing daemon. CoPP (Control Plane Policing) rate-limits traffic destined for the CPU to protect the control plane. Nokia implements CoPP in their platforms.

5. Programmable Management Interfaces

The Nokia JD lists gNMI, NETCONF, and gNOI. These are the modern ways software talks to network devices — replacing the old human-typed CLI. This is the network automation layer.

5.1 NETCONF

NETCONF (Network Configuration Protocol, RFC 6241) is an IETF-standard protocol for configuring and managing network devices programmatically.

Key characteristics:

  • Transport: SSH (TCP port 830)
  • Data encoding: XML
  • Data model: YANG (Yet Another Next Generation — RFC 6020)
  • Operations: <get>, <get-config>, <edit-config>, <copy-config>, <delete-config>, <lock>, <unlock>, <commit>

NETCONF architecture:

┌─────────────────────────────────────────────┐
│         Manager (Client)                    │
│  Python script / Ansible / NSO              │
│  using ncclient library                     │
└──────────────────┬──────────────────────────┘
                   │ SSH (port 830)
                   │ XML over SSH
                   │
┌──────────────────▼──────────────────────────┐
│         Agent (Server) = Network Device     │
│  NETCONF server on router/switch            │
│  YANG data models describe config/state     │
└─────────────────────────────────────────────┘

Example NETCONF RPC (get interfaces):

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get>
    <filter type="subtree">
      <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"/>
    </filter>
  </get>
</rpc>

YANG data models: YANG defines the structure of configuration and operational data on a device. Think of it like a schema for device config. Every configurable item (interface, VLAN, routing protocol) has a YANG model. NETCONF uses these models to structure the XML it sends and receives.

Why NETCONF matters: Before NETCONF, configuring a network device meant SSHing in and typing CLI commands. CLI output is unstructured text — hard to parse in software. NETCONF gives you structured, machine-readable configuration and state data. It's the foundation of modern Infrastructure as Code for networking.

5.2 gNMI

gNMI (gRPC Network Management Interface) is Google's modern replacement for SNMP and a complement to NETCONF. It uses gRPC (which uses HTTP/2 and Protocol Buffers) instead of XML over SSH.

Key characteristics:

  • Transport: gRPC over HTTP/2 (TLS)
  • Data encoding: Protocol Buffers (protobuf) — binary, much more efficient than XML
  • Data model: YANG (same models as NETCONF)
  • Operations:
    • Capabilities — ask device what YANG models it supports
    • Get — retrieve config/state
    • Set — push configuration
    • Subscribe — streaming telemetry — the killer feature

Streaming telemetry: The biggest advantage of gNMI over NETCONF is streaming telemetry. Instead of polling a device every 30 seconds ("what's the interface counter now?"), gNMI lets you subscribe to data streams. The device pushes updates to you in real-time whenever values change. You get sub-second operational data — interface counters, BGP state, CPU usage — streamed continuously.

Controller subscribes to interface counters
   → Device streams data every 100ms
   → Controller graphs in real-time (Grafana, Prometheus)

This is how modern network operations centers monitor network health in 2026.

5.3 gNOI

gNOI (gRPC Network Operations Interface) handles operational tasks — things you'd otherwise do interactively on the CLI.

Operations include:

  • System.Reboot — reboot the device or specific components
  • System.SwitchControlProcessor — failover to standby CPU
  • CertificateManagement.Install — push TLS certificates
  • OS.Install — upgrade software image
  • BGP.ClearBGPNeighbor — reset a BGP session
  • Ping / Traceroute — run diagnostics from the device

gNOI completes the automation stack: NETCONF/gNMI for config and telemetry, gNOI for operations.

6. Real-Time Operating Systems (RTOS)

Nokia's JD specifically mentions Linux, QNX, and VxWorks. Network equipment runs specialized operating systems — not your standard desktop Ubuntu.

Why RTOS in networking?

Networking devices have hard real-time requirements. A packet that doesn't get forwarded within its deadline gets dropped. Control plane processes (OSPF Hello timers, BGP keepalives) must fire with precise timing. General-purpose OS schedulers (like Linux's CFS) don't guarantee this — a low-priority process might run for 50ms and block a high-priority network task.

An RTOS guarantees deterministic task scheduling — critical tasks always run within a bounded, predictable time.

Linux: While not technically an RTOS, Linux with the PREEMPT_RT patch provides near-real-time behavior. Nokia SR Linux runs on top of Linux. Linux is used for:

  • Control plane daemons (OSPF, BGP, NETCONF server)
  • Management plane
  • Virtualized network functions (VNFs)

Linux knowledge = most directly useful for the co-op role. Network namespaces, cgroups, kernel networking stack, ip command, tc (traffic control), iptables/nftables — all relevant.

VxWorks (Wind River): The dominant RTOS in telecom and networking hardware for decades. Used in routers, switches, base stations. Key features:

  • Deterministic preemptive scheduling
  • Very small footprint (runs on embedded hardware with limited RAM)
  • POSIX-compatible API
  • Used in Nokia's older hardware platforms

QNX (BlackBerry): Microkernel RTOS known for extreme reliability and security. Used in safety-critical systems (medical devices, automotive, aerospace) and high-availability telecom equipment. Key features:

  • Microkernel architecture — drivers run as user-space processes, a crashed driver doesn't crash the whole system
  • Message-passing IPC
  • Used in some Nokia telecom platforms

Key OS concepts the JD references:

  • Memory management: Virtual memory, page tables, TLB, heap vs stack, memory-mapped I/O. In embedded networking code, manual memory management with malloc/free (no garbage collection).
  • IPC (Inter-Process Communication): Shared memory, message queues, pipes, sockets. Different control plane daemons communicate via IPC — e.g., OSPF daemon notifies RIB manager of new routes.
  • Scheduling: Priority-based preemptive scheduling. A high-priority network task preempts a low-priority management task. Understanding priority inversion (and mutexes/priority inheritance as the fix) is important.
  • Concurrency: Threads, mutexes, semaphores, condition variables. Routing daemons are highly multithreaded — separate threads for Hello processing, SPF computation, RIB updates.

7. Virtualization in Networking

The JD mentions Docker, containers, and namespaces. These are increasingly used in network software development and testing.

Network Namespaces (Linux): A Linux network namespace creates an isolated network stack — its own interfaces, routing table, iptables rules, and ARP table. Two processes in different namespaces can't see each other's network interfaces.

This is the foundation of container networking. Each Docker container gets its own network namespace. This is also how network engineers create virtual topologies on a single Linux machine for testing.

# Create two network namespaces
ip netns add ns1
ip netns add ns2

# Create a virtual ethernet pair (veth pair) - like a virtual cable
ip link add veth0 type veth peer name veth1

# Put one end in each namespace
ip link set veth0 netns ns1
ip link set veth1 netns ns2

# Configure IPs
ip netns exec ns1 ip addr add 10.0.0.1/24 dev veth0
ip netns exec ns2 ip addr add 10.0.0.2/24 dev veth1

# Bring up
ip netns exec ns1 ip link set veth0 up
ip netns exec ns2 ip link set veth1 up

# Now ns1 and ns2 can ping each other
ip netns exec ns1 ping 10.0.0.2

Open vSwitch (OVS): A software-defined, production-quality L2 switch implemented in software. Used in:

  • OpenStack and KVM hypervisors
  • Network emulation labs
  • SDN environments

OVS supports VLANs, LACP, STP, QoS, tunnels (VXLAN, GRE), and can be controlled by an SDN controller via OpenFlow. For your lab, OVS is what lets you build a full L2 switching environment without physical hardware.

Docker networking: Docker uses Linux network namespaces, veth pairs, and a software bridge (docker0) to connect containers. Understanding this means understanding real L2 networking at the implementation level — exactly what Nokia engineers deal with in virtualized network functions (VNFs).

8. How L2 and L3 Work Together — End-to-End Packet Walk

Let's trace a single packet from your laptop in Boston to a web server in Tokyo. This ties everything together.

Scenario:

  • Your laptop: IP 192.168.1.100, MAC AA:AA:AA:AA:AA:AA
  • Default gateway (router): IP 192.168.1.1, MAC GW:GW:GW:GW:GW:GW
  • Destination server in Tokyo: IP 203.0.113.50

Step 1 — Application layer Your browser sends an HTTP GET request to 203.0.113.50. This generates TCP data.

Step 2 — Layer 4 TCP wraps the data in a segment: source port 52341, destination port 80. Sends to Layer 3.

Step 3 — Layer 3 on your laptop IP wraps the segment in a packet: source IP 192.168.1.100, destination IP 203.0.113.50.

  • Is 203.0.113.50 in my local subnet (192.168.1.0/24)? No.
  • Therefore, send to default gateway 192.168.1.1.
  • Do I know the MAC of 192.168.1.1? Check ARP cache. If not found → send ARP request.

Step 4 — ARP Broadcast: "Who has 192.168.1.1? Tell 192.168.1.100" Gateway replies: "I have 192.168.1.1. MAC is GW:GW:GW:GW:GW:GW" Laptop caches this in ARP table.

Step 5 — Layer 2 on your laptop Wraps the IP packet in an Ethernet frame:

  • Destination MAC: GW:GW:GW:GW:GW:GW (the gateway, NOT Tokyo's MAC)
  • Source MAC: AA:AA:AA:AA:AA:AA
  • EtherType: 0x0800 (IPv4)

Step 6 — Switch Your switch receives the frame on your port, checks CAM table, forwards to the gateway's port.

Step 7 — Gateway router (first hop) Router receives the frame. Strips the Ethernet header. Examines the IP packet:

  • Destination 203.0.113.50 — not local. Look up routing table.
  • Longest prefix match → route to upstream ISP router via interface eth1.
  • Decrement TTL from 64 to 63.
  • ARP (or neighbor discovery for IPv6) to find MAC of next-hop ISP router.
  • Build NEW Ethernet frame: new source MAC (router's eth1 MAC), new dest MAC (ISP router's MAC).
  • The IP source and destination addresses are unchanged.

Step 8 — Across the internet This process repeats at every router along the path:

  • Strip L2 header
  • Look up destination IP in routing table
  • Decrement TTL
  • Build new L2 header for next hop
  • Forward

At each hop, the MAC addresses change (they're local to each link) but the IP addresses stay the same (end-to-end). This is the fundamental architecture.

Step 9 — Tokyo ISP router The packet arrives at a router that has a direct route to 203.0.113.0/24. It ARP-resolves the server's MAC and builds the final Ethernet frame for delivery.

Step 10 — Tokyo server Strips headers in reverse order: L2 → L3 → L4 → delivers HTTP GET to the web server process.

9. Lab Project — Build Your Own L2 Lab Right Now

You already own a Raspberry Pi 4 (used in MQTT DoS lab). That's all you need to start. Here are three concrete labs you can run today.

9.1 Lab A — VLAN Segmentation with Open vSwitch

Objective: Create two VLANs, verify traffic isolation at the frame level, observe 802.1Q tags.

Prerequisites:

sudo apt update && sudo apt install -y openvswitch-switch wireshark tshark python3-pip

Step 1 — Create a virtual bridge (your software switch)

# Create the OVS bridge
sudo ovs-vsctl add-br br0
sudo ip link set br0 up

# Verify
sudo ovs-vsctl show

Step 2 — Create virtual interfaces using network namespaces

# Create two namespaces (simulating two separate devices)
sudo ip netns add host1
sudo ip netns add host2

# Create veth pairs (virtual ethernet cables)
sudo ip link add veth1-ns type veth peer name veth1-br
sudo ip link add veth2-ns type veth peer name veth2-br

# Plug the "-ns" ends into the namespaces
sudo ip link set veth1-ns netns host1
sudo ip link set veth2-ns netns host2

# Plug the "-br" ends into OVS bridge
sudo ovs-vsctl add-port br0 veth1-br
sudo ovs-vsctl add-port br0 veth2-br

# Bring up all interfaces
sudo ip link set veth1-br up
sudo ip link set veth2-br up
sudo ip netns exec host1 ip link set veth1-ns up
sudo ip netns exec host2 ip link set veth2-ns up

Step 3 — Assign IP addresses

sudo ip netns exec host1 ip addr add 192.168.10.1/24 dev veth1-ns
sudo ip netns exec host2 ip addr add 192.168.10.2/24 dev veth2-ns

Step 4 — Test connectivity without VLANs

# Should succeed — same bridge, same subnet
sudo ip netns exec host1 ping -c 3 192.168.10.2

Step 5 — Assign VLANs to ports

# Put veth1-br in VLAN 10 (access port)
sudo ovs-vsctl set port veth1-br tag=10

# Put veth2-br in VLAN 20 (different VLAN)
sudo ovs-vsctl set port veth2-br tag=20

Step 6 — Test isolation

# Should FAIL — different VLANs, L2 can't cross
sudo ip netns exec host1 ping -c 3 192.168.10.2

The ping fails. host1 (VLAN 10) cannot reach host2 (VLAN 20) at Layer 2. This proves VLAN isolation.

Step 7 — Observe with Wireshark

# Capture on the bridge to see 802.1Q tags
sudo tshark -i br0 -V | grep -A2 "802.1Q"

You'll see frames with 802.1Q headers and VLAN IDs in the capture.

Step 8 — Add a trunk port

# Create a third namespace and interface
sudo ip netns add trunk-host
sudo ip link add veth3-ns type veth peer name veth3-br
sudo ip link set veth3-ns netns trunk-host
sudo ovs-vsctl add-port br0 veth3-br
sudo ip link set veth3-br up
sudo ip netns exec trunk-host ip link set veth3-ns up

# Configure as trunk — carries both VLAN 10 and 20
sudo ovs-vsctl set port veth3-br trunks=10,20

Step 9 — Verify OVS configuration

sudo ovs-vsctl show
# Output shows your bridge, ports, and VLAN assignments

sudo ovs-ofctl dump-flows br0
# Shows the actual OpenFlow forwarding rules

9.2 Lab B — NETCONF Automation with Python

Objective: Automate VLAN configuration using Python's ncclient library — directly mirroring what Nokia builds.

Note: For a fully working NETCONF demo without real hardware, we simulate using a NETCONF-capable open-source device. The best option is Free Range Routing (FRR) or using Containerlab with a simulated device. Alternatively, this code structure is exactly what you'd use against a real Nokia device.

Install ncclient:

pip3 install ncclient lxml

Python script — connect and get running config:

#!/usr/bin/env python3
"""
NETCONF demo using ncclient
Simulates the kind of network automation Nokia builds
"""

from ncclient import manager
from ncclient.operations.errors import TimeoutExpiredError
import xml.dom.minidom

# Connection parameters (adjust for your lab device)
DEVICE = {
    'host': '192.168.1.1',      # Your device IP
    'port': 830,                 # NETCONF default port
    'username': 'admin',
    'password': 'admin',
    'hostkey_verify': False,     # Disable for lab
    'device_params': {'name': 'default'}
}

def get_interfaces(conn):
    """Get all interface configuration via NETCONF"""
    filter_xml = """
    <filter type="subtree">
        <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"/>
    </filter>
    """
    result = conn.get_config(source='running', filter=filter_xml)
    # Pretty print the XML response
    dom = xml.dom.minidom.parseString(str(result))
    print(dom.toprettyxml(indent='  '))

def configure_vlan_interface(conn, vlan_id, ip_address, prefix_len):
    """Configure a VLAN interface via NETCONF edit-config"""
    config_xml = f"""
    <config>
        <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
            <interface>
                <name>vlan{vlan_id}</name>
                <type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
                    ianaift:l2vlan
                </type>
                <enabled>true</enabled>
                <ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
                    <address>
                        <ip>{ip_address}</ip>
                        <prefix-length>{prefix_len}</prefix-length>
                    </address>
                </ipv4>
            </interface>
        </interfaces>
    </config>
    """
    conn.edit_config(target='candidate', config=config_xml)
    conn.commit()
    print(f"VLAN {vlan_id} configured with IP {ip_address}/{prefix_len}")

def main():
    try:
        with manager.connect(**DEVICE) as conn:
            print(f"Connected to {DEVICE['host']}")
            print(f"Server capabilities:")
            for cap in conn.server_capabilities:
                print(f"  - {cap}")

            # Get current config
            print("\n--- Current Interface Config ---")
            get_interfaces(conn)

            # Configure VLAN 10
            print("\n--- Configuring VLAN 10 ---")
            configure_vlan_interface(conn, 10, '192.168.10.1', 24)

    except TimeoutExpiredError:
        print("Connection timed out - check device accessibility")
    except Exception as e:
        print(f"Error: {e}")

if __name__ == '__main__':
    main()

What this demonstrates:

  • NETCONF session establishment over SSH
  • Retrieving structured config data (not scraping CLI text)
  • Pushing configuration changes via edit-config
  • Using YANG-modeled XML payloads
  • Committing changes (candidate → running datastore)

This is exactly the kind of automation Nokia builds for their network management systems.

9.3 Lab C — STP Observation

Objective: Create a loop in a virtual network, observe STP BPDUs, watch STP converge and block a port.

Step 1 — Create three bridges with a loop

# Create three OVS bridges (simulating three switches)
sudo ovs-vsctl add-br sw1
sudo ovs-vsctl add-br sw2
sudo ovs-vsctl add-br sw3

# Enable STP on all bridges
sudo ovs-vsctl set bridge sw1 stp_enable=true
sudo ovs-vsctl set bridge sw2 stp_enable=true
sudo ovs-vsctl set bridge sw3 stp_enable=true

# Create links between sw1-sw2, sw2-sw3, sw3-sw1 (the loop!)
sudo ip link add sw1-sw2-a type veth peer name sw2-sw1-a
sudo ip link add sw2-sw3-a type veth peer name sw3-sw2-a
sudo ip link add sw3-sw1-a type veth peer name sw1-sw3-a

sudo ovs-vsctl add-port sw1 sw1-sw2-a
sudo ovs-vsctl add-port sw2 sw2-sw1-a
sudo ovs-vsctl add-port sw2 sw2-sw3-a
sudo ovs-vsctl add-port sw3 sw3-sw2-a
sudo ovs-vsctl add-port sw3 sw3-sw1-a
sudo ovs-vsctl add-port sw1 sw1-sw3-a

# Bring up all interfaces
for iface in sw1-sw2-a sw2-sw1-a sw2-sw3-a sw3-sw2-a sw3-sw1-a sw1-sw3-a; do
    sudo ip link set $iface up
done
sudo ip link set sw1 up; sudo ip link set sw2 up; sudo ip link set sw3 up

Step 2 — Observe STP state

# Watch STP elect a root bridge and block a port
watch -n2 "sudo ovs-appctl stp/show sw1; sudo ovs-appctl stp/show sw2; sudo ovs-appctl stp/show sw3"

You'll see one port transition to BLOCKING state — STP has broken the loop.

Step 3 — Capture BPDUs

# BPDUs are sent to multicast 01:80:c2:00:00:00
sudo tshark -i sw1-sw2-a -f "ether dst 01:80:c2:00:00:00" -V

You'll see the actual STP BPDU packets: Root Bridge ID, path cost, port ID — the raw data STP uses to elect roles.

9.4 How to Frame This on Your Resume

Do not write "Built a VLAN lab." Write this:

L2 Network Segmentation & Automation Lab | Open vSwitch, Python, NETCONF

  • Deployed IEEE 802.1Q VLAN segmentation using Open vSwitch on Linux, configuring access and trunk ports and verifying traffic isolation at the Ethernet frame level via Wireshark/tshark
  • Automated VLAN provisioning via NETCONF using Python ncclient, constructing YANG-modeled XML payloads against a candidate datastore and committing configuration changes programmatically
  • Observed STP BPDU exchanges and root bridge election across a three-switch virtual topology, capturing blocked port convergence on looped segments

That one project bullet paragraph hits: 802.1Q, Open vSwitch, Linux, NETCONF, Python, YANG, Wireshark, STP — which maps to five JD bullets.

10. Nokia JD Mapping

Here is every bullet from the Nokia JD mapped to what you now know and what you can do:

JD RequirementWhat It MeansYour Angle
Build gNMI, NETCONF, gNOI interfacesProgrammable management APIs for network devicesNETCONF Python lab (Lab B), ncclient, YANG
Embedded system dev using Linux, QNX, VxWorksWrite C/C++ on RTOSes for networking hardwareLinux (MQTT lab on Pi), RTOS concepts studied
C/C++ for switching/routing softwareImplement L2/L3 protocol logic in CReview C fundamentals; your Java OOP maps conceptually
System validation, QA, hands-on labTest protocol behavior, write test scriptsMQTT DoS lab, Snort IDS/IPS lab, Wireshark analysis
Layer 2 networking softwareMAC learning, VLANs, STP, EthernetLab A (OVS VLAN lab)
Layer 3 networking softwareIP routing, OSPF, BGP, routing tablesTCP/IP OSI textbook (24 chapters you wrote)
Control and data planeProtocol daemons vs hardware forwardingDeep understanding from these notes
Networking protocols knowledgeTCP/IP, OSPF, BGP, MPLSCY5150, MQTT DoS lab, Snort lab
Linux software developmentShell, sockets, namespaces, kernel networkingPi MQTT lab, OVS lab
RTOS familiarityVxWorks, QNX conceptsStudied in these notes; eCTF ARM embedded work
Docker/containers/namespacesContainer networking, veth pairsOVS lab uses Linux namespaces throughout
Communication, teamworkClear technical communicationNUIoTConnect Technical Director, eCTF Team Lead

11. Quick Reference Cheat Sheet

OSI LAYERS
7 - Application     HTTP, DNS, SMTP
6 - Presentation    TLS, encoding
5 - Session         Session management
4 - Transport       TCP (segments), UDP (datagrams)
3 - Network         IP (packets)
2 - Data Link       Ethernet (frames)
1 - Physical        Bits on wire

LAYER 2 KEY TERMS
MAC Address         48-bit hardware address (AA:BB:CC:DD:EE:FF)
CAM Table           Switch's MAC-to-port mapping table
Flooding            Sending unknown dest to all ports
802.1Q              VLAN tagging standard (12-bit VLAN ID, 1-4094)
Access Port         One VLAN, strips tag to end device
Trunk Port          Multiple VLANs, carries tags between switches
STP (802.1D)        Prevents loops by blocking redundant ports
RSTP (802.1w)       Rapid STP, converges in < 1 second
ARP                 Resolves IP → MAC on local network
LACP (802.3ad)      Bonds multiple physical links
MACsec (802.1AE)    Encryption at Layer 2
Broadcast Domain    Set of devices receiving the same L2 broadcasts
MTU                 Maximum Transmission Unit = 1500 bytes (Ethernet)

LAYER 3 KEY TERMS
IP Address          32-bit logical address (192.168.1.1)
Subnet Mask         /24 = 255.255.255.0 = first 24 bits are network
RIB                 Routing Information Base — full route table
FIB                 Forwarding Information Base — compiled, in hardware
LPM                 Longest Prefix Match — most specific route wins
TTL                 Time To Live — decremented at each hop, loop prevention
AD                  Administrative Distance — lower = more trusted
OSPF                Link-state IGP, uses Dijkstra's SPF algorithm
BGP                 Path-vector EGP, runs the internet, TCP port 179
MPLS                Label-based forwarding, Layer 2.5
LER                 Label Edge Router — pushes/pops MPLS labels
LSR                 Label Switch Router — swaps labels in core
ICMP                Control messages (ping=type 8/0, traceroute=type 11)

MANAGEMENT INTERFACES
NETCONF             XML over SSH port 830, uses YANG models, RFC 6241
gNMI                gRPC/protobuf, streaming telemetry, Google standard
gNOI                gRPC operational tasks (reboot, cert install, BGP reset)
YANG                Data modeling language for device config/state

RTOS
VxWorks             Dominant telecom/networking RTOS, Wind River
QNX                 Microkernel RTOS, safety-critical, BlackBerry
Linux+PREEMPT_RT    Near-realtime Linux, used in Nokia SR Linux

ETHERNET FRAME
Preamble (8B) | Dst MAC (6B) | Src MAC (6B) | EtherType (2B) | Payload (46-1500B) | FCS (4B)
EtherType 0x0800=IPv4  0x86DD=IPv6  0x0806=ARP  0x8100=802.1Q  0x8847=MPLS

IP PACKET HEADER (key fields)
Version | IHL | DSCP | Total Length | ID | Flags | Fragment Offset
TTL | Protocol | Checksum | Source IP | Destination IP
Protocol 6=TCP  17=UDP  1=ICMP  89=OSPF  47=GRE

ATTACK RELEVANCE (security background)
MAC Flooding        Fill CAM table → switch floods all traffic → sniffing
ARP Spoofing        Fake ARP replies → MITM → traffic interception
STP Manipulation    Claim to be root bridge → become traffic hub
BGP Hijacking       Advertise more-specific routes → traffic misdirection
OSPF Injection      Inject fake LSAs → corrupt routing → black hole

Kalyan Gopalam | Northeastern University M.S. Cybersecurity | June 2026