Computer Networks: Protocols, Routing, and Security

The core follows the 2013 Computer Networks syllabus from undergraduate Computer Engineering at Kırıkkale University: OSI and TCP/IP models, Ethernet, IPv4, subnetting, switching, routing and basic network services. IPv6, QUIC, modern Ethernet and Wi-Fi, network security, data-centre fabrics, cloud networking and model-driven automation are presented in their later standards context; 2024-2026 specifications are not attributed to the historical course material.

Unit 1: The Basic Network Model

Network performance analysis separates serialization, propagation, queuing, and processing delays. One-way delay cannot be interpreted reliably without defined measurement points and clock synchronization. Examine median and tail percentiles together with packet loss; averages may hide queue bursts. Application-level performance also depends on retransmissions and transport-protocol behavior.

1.1. Definition and Scope of Computer Networks

A computer network is a communication system in which endpoints exchange data under common rules. A cable or radio link alone is not a network; addressing, protocols, media, and intermediate devices must work together.

Three groups are enough for the basic model:

• Endpoints: computers, servers, phones, cameras, sensors, virtual machines, containers.
• Intermediate devices: switches, routers, access points, firewalls, load balancers.
• Media: copper, fiber, radio.

A network function does not have to be a physical appliance. Routing, firewalling, and load balancing can run on hardware, virtual machines, containers, or cloud services.

1.2. Network Performance

Link speed alone does not describe network quality.

• Bandwidth: theoretical link capacity.
• **Throughput:** data rate actually achieved.
• Goodput: useful application data after protocol overhead and retransmissions.
• **Latency:** end-to-end delay.
• Jitter: variation in delay.
• Loss: fraction of packets not delivered.
• Availability: fraction of time the service remains usable.

A useful delay model is:

total delay =
transmission + propagation + processing + queueing

More bandwidth can reduce serialization time. It cannot remove propagation delay caused by distance.

The application determines which metric matters. Backup traffic mainly cares about completion time. Interactive systems care about latency. Voice and live video care about latency, jitter, and loss together.

1.3. Delay, RTT, and One-Way Measurement

Treating latency as a single number is insufficient for many diagnoses. End-to-end packet delay can be approximated as the sum of four components:

d_end_to_end = d_processing + d_queueing + d_transmission + d_propagation

Transmission delay is the time required to serialize a packet onto a link:

d_transmission = L / R

where L is packet length in bits and R is link rate in bits per second. Propagation delay depends on physical distance and propagation speed in the medium; increasing link rate does not remove it. Processing delay covers forwarding lookups and other data-plane work. Queueing delay varies with load and is a major contributor to jitter and tail latency.

RTT (Round-Trip Time) observes the forward and reverse path together. Ping commonly uses ICMP Echo Request/Echo Reply to sample RTT; it does not directly measure one-way delay. Forward and reverse routes may differ, and even a symmetric route can have asymmetric queue occupancy, so in general:

one-way delay != RTT / 2

One-way delay measurement requires sufficiently synchronized clocks at both endpoints, a known timestamping point, and a stated uncertainty budget. RTT is therefore easier to deploy operationally, but it cannot by itself identify which direction is degraded.

1.4. Jitter and Packet Delay Variation

There is no single universal computation called jitter. In general network engineering the term describes temporal variation in packet delay; IP Performance Metrics uses more precise notions such as IP Packet Delay Variation (IPDV) and Packet Delay Variation (PDV). If a tool reports only "jitter = 12 ms" without defining its estimator, results from different tools should not be assumed to be directly comparable.

For RTP/RTCP real-time media, RFC 3550 defines a specific interarrival jitter estimator. If S_i is the RTP timestamp and R_i is receiver arrival time expressed in the same timestamp units, the relative transit-time difference for consecutive packets is:

D(i-1,i) = (R_i - S_i) - (R_{i-1} - S_{i-1})

and the smoothed estimate is:

J_i = J_{i-1} + (|D(i-1,i)| - J_{i-1}) / 16

This value is not the same metric as a simple variation of RTT samples reported by a speed-test service. A measurement should record the metric definition, sampling interval, packet size, traffic class, and observation duration.

Real-time receivers can absorb irregular arrivals with a jitter buffer:

packet network
     |
irregular arrival
     |
jitter buffer
     |
decoder / playout

A larger buffer tolerates more transient variation but increases playout latency. A small buffer reduces latency but increases the probability that a late packet misses its playout deadline. VoIP and live-media systems can therefore use adaptive buffering rather than one fixed delay.

A statement such as "30 ms of jitter is always acceptable" is not a protocol-independent engineering rule. The acceptable range depends on codec behavior, packetization interval, playout buffering, the interaction model, and the application's latency budget.

1.5. Packet Loss, Late Packets, and Retransmission

Packet loss is not limited to physical corruption. A packet may be lost because of:

• congestion drop at a queue,
• wireless retry exhaustion,
• a routing black hole or failure,
• intentional ACL/policy drop,
• resource exhaustion at a receiver or measurement instrument,
• arrival after an application deadline.

IPPM loss metrics can classify a packet as lost if it does not arrive within a specified waiting threshold. This matters for real-time media: a packet can eventually be delivered by the network yet be unusable once its playout deadline has passed. A useful conceptual model is therefore:

EffectiveLoss = NetworkLoss + LatePacketLoss

This is an engineering abstraction for deadline-sensitive applications rather than a protocol-standard equation.

With TCP, loss is commonly reflected through retransmission, congestion-control response, additional latency, and reduced throughput. For UDP-based real-time traffic, retransmitting a packet after its deadline may provide no value. QUIC provides reliable streams over UDP, but applications still need an explicit policy for deadline-sensitive data.

1.6. Tail Latency and Percentiles

An average can hide the tail of a latency distribution. A system may average 18 ms while a small fraction of samples exceed 200 ms. Percentiles are therefore useful for understanding user-visible stalls and deadline violations:

p50  median behavior
p95  value below which 95% of samples fall
p99  value below which 99% of samples fall
max  worst observed sample; not a stable statistic by itself

A rising p99 with an almost unchanged mean can reveal rare but important queue bursts, CPU/runtime pauses, wireless retransmissions, or upstream saturation. Percentiles from different measurement windows and sampling methods are not automatically comparable.

1.7. Bandwidth-Delay Product

The amount of data that may need to remain in flight on a high-rate, non-trivial-RTT path is approximated by the bandwidth-delay product (BDP):

BDP = bandwidth × RTT

For a 1 Gbit/s path with an 80 ms RTT:

1 Gbit/s × 0.08 s = 80 Mbit ≈ 10 MB

If the sender's congestion window or receiver window is far below the path BDP, one flow may fail to fill the link even when physical capacity is high. BDP must not be interpreted as a requirement to create an equally large standing device queue; data productively in flight and data waiting in a buffer are different concepts.

1.8. Network Performance Measurement Methodology

A single speed-test result does not characterize the entire path. A repeatable procedure should separate at least these conditions:

1. Wired baseline: where possible, measure over Ethernet first to remove local Wi-Fi variability.
2. Idle latency: sample RTT, loss, and jitter with no substantial background transfer.
3. Latency under load: repeat while downstream and upstream approach saturation. Good idle latency with poor loaded latency is evidence of a bottleneck queue or bufferbloat.
4. Direction: load upload and download separately; a small upstream can affect ACKs, voice, telemetry, and interactive traffic.
5. Multiple destinations: compare a nearby test server, the real application endpoint, and different networks to expose routing and peering effects.
6. Time series: collect p50/p95/p99, loss, and throughput over a meaningful interval rather than relying on one snapshot.
7. Measurement limits: client CPU, NIC, Wi-Fi PHY, browser, VPN, security software, or the test server can become the bottleneck.

A result should be interpreted together with packet type, protocol, destination, test duration, and load state. ICMP, TCP, and UDP can also traverse different policy or QoS treatment on the same nominal path.

1.9. Topology

Physical topology is the actual placement of devices and links. Logical topology is the path traffic follows.

Classical forms:

• Bus: shared medium; historically important for Ethernet.
• Ring: nodes form a loop.
• Star: endpoints connect to a central switch.
• Mesh: multiple paths exist between nodes.

A full mesh with n nodes needs:

n(n - 1) / 2

links, so cost grows quickly.

Enterprise campuses often use access, distribution, and core layers. Data centers commonly use leaf-spine fabrics. Each leaf connects to every spine, making east-west path length more predictable.

1.10. Layered Communication

Layering divides communication into smaller responsibilities. A layer can change internally while the interface to adjacent layers stays stable.

The OSI model has seven layers:

• 7 Application: Network service to applications
• 6 Presentation: Encoding, format, encryption
• 5 Session: Session lifecycle
• 4 Transport: End-to-end communication, ports
• 3 Network: IP addressing and routing
• 2 Data Link: Local delivery and framing
• 1 Physical: Carrying bits over media

Operational Internet systems are usually described with the TCP/IP model:

Application   HTTP, DNS, DHCP, SSH, SMTP
Transport     TCP, UDP, QUIC over UDP
Internet      IPv4, IPv6, ICMP, ICMPv6
Access        Ethernet, Wi-Fi, PPP

Layer boundaries are useful abstractions, not laws. QUIC runs over UDP but implements reliability, flow control, and congestion control itself.

1.11. Encapsulation

At the sender, each lower layer adds control information:

application data
      |
TCP segment / UDP datagram
      |
IP packet
      |
Ethernet or Wi-Fi frame
      |
bits / symbols

The receiver removes them in reverse order.

In ordinary routing, the destination IP identifies the final Layer 3 endpoint. The destination MAC identifies only the next Layer 2 hop. Every router builds a new Layer 2 frame. NAT and tunneling are explicit exceptions to the simple end-to-end model.

1.12. LAN and WAN

A LAN covers a limited area and usually one administrative domain. A WAN connects geographically separate networks through carrier infrastructure.

PAN, campus, and metropolitan networks are useful intermediate terms. In cloud and data-center design, administrative boundaries and latency budgets often matter more than physical distance.

1.13. Relationships Between Topics

A web request uses the layers in sequence:

URL
 |
DNS
 |
local/remote destination decision
 |
ARP or Neighbor Discovery
 |
Ethernet/Wi-Fi
 |
routing
 |
ACL/NAT/policy
 |
TCP or QUIC
 |
TLS
 |
HTTP

When one layer fails, the upper layer also appears to fail. Troubleshooting means measuring this chain.

A modern network extends the same structure:

physical link
 |
IP underlay
 |
overlay / VRF
 |
identity + policy
 |
API / automation
 |
telemetry

The desired state of the network is managed, not only individual devices.

1.14. Separating Addressing, Switching, Routing, and Transport Layers

Bandwidth is capacity; throughput is achieved transfer rate; goodput is useful application data.

Latency is delay; jitter is variation in delay.

Propagation depends on distance; serialization depends on packet size and link rate. Queueing depends on load.

OSI is a reference model; TCP/IP is an implemented protocol suite.

MAC identifies the local Layer 2 hop; IP identifies the Layer 3 destination. MAC addresses change across routed hops.

Ethernet FCS detects corruption; it does not correct it.

There is no single universal 9000-byte jumbo-frame standard.

A link light does not prove that the physical medium is certified for the target rate.

Attenuation is signal-power loss; dispersion is temporal spreading of a pulse.

OTDR locates fiber events; a power meter measures end-to-end optical power.

A switch learns from source MAC addresses and forwards by destination MAC address.

Unknown unicast is flooded inside the VLAN.

BUM means broadcast, unknown unicast, and multicast.

CAM is commonly used for MAC lookup; TCAM supports masked prefix and policy lookup.

CSMA/CD is not used on full-duplex Ethernet.

A VLAN is a Layer 2 concept; a subnet is a Layer 3 concept.

An access port carries one VLAN; a trunk carries multiple VLANs.

STP breaks Layer 2 loops; RSTP converges faster; MSTP maps VLANs to a smaller number of trees.

The current link-aggregation standard is IEEE 802.1AX; 802.3ad is the historical designation.

Link aggregation increases aggregate capacity; a single flow is not guaranteed to use all members.

VRRP provides first-hop redundancy; RFC 9568 is the current base specification.

802.1X controls access; MACsec encrypts Layer 2 traffic.

CIDR replaced classful IPv4 addressing.

/31 can be used on point-to-point IPv4 links; /32 identifies one IPv4 host route.

VLSM divides address space; summarization combines prefixes.

ARP maps IPv4 to MAC; DNS maps names to records; DHCP supplies network configuration to clients.

NAT translates addresses; it is not a firewall.

IPv6 addresses are 128 bits and IPv6 has no broadcast.

IPv6 uses Neighbor Discovery instead of ARP.

Blocking all ICMPv6 can break IPv6 operation.

SLAAC and DHCPv6 are different mechanisms.

TCP is an ordered byte stream; it does not preserve message boundaries.

UDP preserves datagram boundaries; it does not guarantee delivery or ordering.

TCP flow control protects the receiver; congestion control protects the network.

MSS limits TCP payload; MTU limits the Layer 3 packet carried by a link.

**One send() call does not have to correspond to one recv() call.**

Partial send and partial receive are normal socket behavior.

Backpressure means matching producer rate to consumer capacity, not merely enlarging queues.

Nagle reduces small segments; TCP_NODELAY is not universally faster.

TIME_WAIT is not an error; it prevents old segments from contaminating a later connection.

QUIC uses UDP but implements reliability, streams, and congestion control itself.

HTTP/3 runs over QUIC.

DNSSEC helps authenticate origin and integrity; it does not encrypt DNS queries.

DoT, DoH, and DoQ encrypt DNS transport.

RFC 10024, published in August 2026, standardizes PQ/T hybrid ML-KEM groups for TLS 1.3.

A router performs longest-prefix match first. Administrative distance and metric resolve candidates for the same prefix.

RIB stores route information; FIB stores the selected forwarding result.

CEF/FIB/adjacency structures provide fast forwarding; normal data-plane operation does not require the CPU to process every packet.

ECMP uses equal-cost paths; most implementations hash flows rather than packets.

VRF provides separate routing tables on the same device.

PBR selects a path by policy beyond destination prefix; it does not replace general routing.

BFD does not calculate routes; it detects forwarding-path reachability quickly.

RIP uses hop count; OSPF uses cost; EIGRP uses a composite metric. BGP is policy-oriented.

OSPF builds an LSDB and runs SPF. Flooding and forwarding are different operations.

DR/BDR matters on OSPF broadcast multi-access networks; it is unnecessary on point-to-point links.

A useful OSPF memory map is: Type 1 router, Type 2 network, Type 3 summary, Type 5 external, Type 7 NSSA external LSA.

BGP reaches route exchange in the Established state.

Route reflectors reduce the iBGP full-mesh requirement.

LOCAL_PREF expresses preference inside an AS; AS_PATH carries path and loop information; COMMUNITY is a policy tag.

BGP is not required to select the physically shortest path.

RPKI/ROV validates origin-AS authorization; it is not full AS_PATH validation.

RFC 9234 uses BGP Roles and OTC to reduce route leaks.

IGMP represents host membership; IGMP snooping maps membership to switch ports; PIM builds multicast trees between routers.

RPF checks whether multicast traffic arrived through the expected reverse-path interface.

PIM-SM can use an RP for a shared tree and later switch to an SPT.

QoS does not create bandwidth; it allocates scarce capacity among traffic classes.

Shaping buffers excess traffic; policing can drop or remark excess traffic.

Token bucket describes rate and burst tolerance.

Unbounded strict priority can starve other queues.

NTP is general time synchronization; PTP is used for tighter time and phase accuracy.

DetNet targets bounded latency and low loss inside a managed domain; it is not a guarantee across the public Internet.

RAW extends DetNet reliability concepts to variable wireless segments; RFC 9912 is Informational.

Wi-Fi shares airtime; PHY rate is not application throughput.

RSSI is received signal strength; SNR is the separation between signal and noise.

MIMO uses multiple antennas; spatial multiplexing carries parallel data streams.

OFDMA divides airtime into resource units.

Wi-Fi 7 is based on IEEE 802.11be; multi-link operation is one of its central changes.

IEEE P802.11bn is still a draft as of 22 August 2026; Ultra High Reliability is not only a peak-rate objective.

IEEE 802.11bf-2025 is the published WLAN sensing amendment.

SSID hiding and MAC filtering are not strong WLAN security controls.

802.11r reduces authentication/key-transition delay during roaming.

RADIUS is common for network access; TACACS+ is common for network-device administration.

CoPP limits traffic sent to the control-plane CPU.

Ingress filtering and uRPF can reduce spoofed-source traffic.

Zero Trust does not automatically trust traffic because it is inside the network; it is not a single product.

Segmentation creates network boundaries; microsegmentation can enforce policy at workload granularity.

MACsec protects Layer 2, IPsec protects Layer 3, and TLS protects application sessions.

GRE tunnels traffic; it does not encrypt by itself.

MPLS is label switching; an MPLS VPN is not inherently encrypted.

SD-WAN manages multiple WAN transports under centralized policy.

Segment Routing expresses a path as a sequence of segments/SIDs. SR-MPLS and SRv6 are the main data planes.

The underlay provides real IP reachability; the overlay is the logical network built over it.

VXLAN uses a 24-bit VNI; it is not a VLAN.

EVPN can be a control plane for VXLAN; Type 2 commonly carries MAC/IP, Type 3 BUM membership, and Type 5 IP prefixes.

800 GbE is standardized; IEEE P802.3dj, which includes 1.6 Tb/s work, is still a draft as of 22 August 2026.

NFV moves network functions into software; SR-IOV and PCI passthrough reduce abstraction overhead.

DPDK can lower packet-per-second processing cost; it also increases operational complexity.

RoCEv2 carries RDMA over UDP/IP; PFC alone does not create a lossless fabric.

Packet capture shows packet contents; flow telemetry summarizes communications.

SPAN is local capture, RSPAN carries capture across Layer 2, and ERSPAN carries it across Layer 3.

SNMP polling and streaming telemetry are different operating models.

YANG is a data model; NETCONF and RESTCONF are management protocols.

gNMI provides Capabilities, Get, Set, and Subscribe RPCs; OpenConfig provides common models.

The main value of automation is not speed but idempotency, consistency, and verifiability.

Ping proves only a form of ICMP reachability; it does not prove application health.

Traceroute is an observation of the path at measurement time, not a routing table.

Troubleshooting progresses by collecting evidence from the physical layer to the application.

Ping samples RTT; it does not directly measure one-way delay. Asymmetric paths and queues make RTT/2 an invalid general-purpose one-way measurement.

There is no single universal jitter computation in milliseconds. RTP interarrival jitter, IPDV/PDV, and speed-test RTT variation are different metrics.

A late packet can be physically delivered yet unusable to a deadline-sensitive application.

High Mbps does not guarantee low latency or low jitter. Capacity and timing quality are separate dimensions.

BDP is not queue size. Data productively in flight and a standing queue waiting in a device buffer are different concepts.

Fiber does not guarantee zero jitter. The access medium is only one segment of an end-to-end path.

Ethernet does not remove WAN-generated jitter. It can remove local wireless contention and interference from the measurement path.

QoS does not create capacity, and AQM is not a synonym for QoS marking. Scheduling, shaping, classification, and queue management have distinct roles.

ONT, modem, router, switch, and access point are different roles. A residential gateway can physically combine several of them.

The label mesh does not guarantee higher throughput. Backhaul design and airtime consumption determine the result.

1.15. Read a Packet Path Layer by Layer

Network problems become easier when addressing, forwarding, and application semantics are separated. A MAC address identifies link-layer delivery on a local segment, an IP address participates in routing across networks, and a port identifies a transport endpoint on a host. These identifiers have different scopes and are not interchangeable.

TCP provides a reliable byte stream; it does not preserve application message boundaries. Two separate send operations can arrive in one recv, or one send can be observed through several receives. The application protocol therefore needs its own length, delimiter, or framing rule. UDP provides no built-in guarantee of delivery, order, or uniqueness; in return it does not carry TCP's connection establishment and stream-control machinery.

In subnetting, the prefix length determines how many address bits belong to the network. With an IPv4 /24, eight bits remain for host addresses. In a conventional subnet, excluding network and broadcast addresses gives 2^8 - 2 = 254 usable host addresses. This rule should not be generalised blindly to point-to-point cases or IPv6.

Latency is also composite. Propagation, transmission, processing, and queueing delays contribute to end-to-end time. A high-bandwidth link can still have high latency, and packet loss can arise from queue overflow or policy rather than a faulty physical medium.

Troubleshooting should therefore gather evidence across layers instead of guessing where a packet disappeared: did name resolution succeed, is the route correct, is link-layer neighbour resolution available, did the transport connection form, and did the application protocol produce the expected response? The same symptom can originate from very different layers.

1.16. Latency Budgets and End-to-End Queue Accumulation

End-to-end request latency is not merely network round-trip time. Name resolution, connection establishment, TLS negotiation, client and server queues, application execution, and response transfer contribute different components. Connection reuse may avoid repeated setup costs without eliminating a downstream service queue. A ping RTT is not a measurement of application-level HTTP latency.

Little's law for a stable system is \(L=\lambda W\), where \(L\) is the average number of jobs present, \(\lambda\) the average completion rate, and \(W\) the average time in the system. At a sustainable rate of 100 requests/s and a mean response time of 0.2 s, roughly 20 requests are present on average. Above capacity, the law does not conjure additional throughput; its stationarity assumptions fail if the queue grows without bound.

Adding the P99 values of several stages does not generally yield the exact end-to-end P99. Dependence among stages and the alignment of individual requests matter. Measure end-to-end latency from matched start and completion events, then use network, application, and database stage times to explain the observed distribution.

Unit 2: Physical Transmission and Ethernet

2.1. Copper

Twisted pairs reduce electromagnetic interference and crosstalk. UTP has no shield. Shielded cable is useful in noisy environments only when grounding is correct.

Common categories:

Cat5e    1 Gbit/s     100 m
Cat6     1 Gbit/s     100 m
Cat6A    10 Gbit/s    100 m
Cat8     25/40 Gbit/s short data-center links

10GBASE-T can run over Cat6 at shorter distances. Channel length includes permanent cable, connection points, and patch cords.

T568A and T568B provide the same electrical purpose with different color ordering. Consistency inside a facility matters more than choosing one over the other.

Crossover cables were once required for some similar-device connections. Auto MDI/MDIX removed most of that requirement.

2.2. Structured Cabling and Testing

Structured cabling is more than cable category. The permanent link, patch panel, outlet, patch cords, and full channel must be considered together.

Common copper measurements include:

• continuity and pin mapping,
• insertion loss,
• return loss,
• NEXT and other crosstalk measurements,
• propagation delay and delay skew.

A link light proves electrical connectivity. It does not prove that the channel meets the target category or data rate. Certification testing measures that.

2.3. Fiber

Fiber carries light instead of electrical signaling and is immune to electromagnetic interference.

Single-mode fiber is used for long distance and backbone links. Multimode fiber is common for shorter building and data-center links.

Common connector and module families include:

LC, SC, MPO/MTP
SFP, SFP+, SFP28
QSFP+, QSFP28
QSFP-DD, OSFP

An optic is not selected by speed alone. Wavelength, fiber type, reach, connector, FEC requirements, and peer compatibility must match.

2.4. Fiber Loss, Dispersion, and Link Budget

Two basic limits are:

• Attenuation: optical power decreases with distance and connections.
• Dispersion: a pulse spreads in time until adjacent bits become hard to distinguish.

Modal dispersion is especially important in multimode fiber. Single-mode fiber supports longer reach, but chromatic dispersion and optical power budget still matter.

A simple budget is:

receiver power =
transmitter power
- fiber loss
- connector loss
- splice loss
- engineering margin

The result must be above receiver sensitivity and below the overload limit.

An OTDR locates reflections and loss events by distance. An optical power meter measures end-to-end power. They answer different questions.

2.5. Ethernet Speeds

Ethernet keeps a common MAC frame model across different physical layers:

100BASE-TX    100 Mbit/s
1000BASE-T    1 Gbit/s
10GBASE-T     10 Gbit/s
25G / 40G     data center
100G / 400G   fabric and backbone
800G          high-speed fabric

IEEE 802.3df-2024 defines physical-layer and management parameters for 400 and 800 Gb/s Ethernet. IEEE P802.3dj includes 1.6 Tb/s work; its second Standards Association recirculation ballot closed on 15 August 2026, but as of 22 August 2026 it is still a draft project.

At high rates, nominal bandwidth is not enough. SerDes rate, FEC latency, optical budget, cable reach, switch radix, and total fabric capacity matter.

IEEE 802.3dg-2026 moves in another direction: 100 Mb/s long-reach single-pair Ethernet, with optional power-distribution work in the project scope. Its value is not peak speed; it extends Ethernet deeper into industrial, building, sensor, and actuator networks with fewer conductors.

2.6. PoE

Power over Ethernet carries power over the data cabling.

Approximate source power classes:

802.3af       15.4 W
802.3at       30 W
802.3bt Type 3   60 W
802.3bt Type 4   90 W

The endpoint receives less because the cable dissipates power. A switch must be sized for both per-port demand and total PoE budget.

2.7. Ethernet Frame

A basic Ethernet frame contains:

Preamble + SFD   8 bytes
Destination MAC  6 bytes
Source MAC       6 bytes
Type/Length      2 bytes
Payload          46-1500 bytes
FCS              4 bytes

FCS uses CRC to detect transmission errors. It does not correct them.

The common IP MTU on Ethernet is 1500 bytes. There is no single IEEE-defined "9000-byte jumbo frame" size; around 9000 bytes is a common implementation choice.

IPv4 fragmentation depends on protocol and DF conditions. IPv6 routers do not fragment packets in transit. The source must react to Path MTU Discovery information.

Tunnels add headers and reduce effective MTU. A small ping working through GRE, IPsec, or VXLAN does not prove that full-size application traffic works.

2.8. MAC Address

A traditional Ethernet MAC address is 48 bits:

00:1A:2B:3C:4D:5E

Address bits indicate unicast/multicast and universal/local administration. Vendor-assigned addresses use an OUI.

For a destination on the same LAN, the frame targets the host MAC. For a remote IP network, the frame targets the default gateway MAC.

IP destination  = final Layer 3 target
MAC destination = target on the current Layer 2 hop

2.9. Unicast, Multicast, and Broadcast

Unicast targets one endpoint. Multicast targets a group. Broadcast targets the local Layer 2 broadcast domain.

Ethernet broadcast is:

FF:FF:FF:FF:FF:FF

IPv6 has no broadcast; defined multicast groups provide the required functions.

2.10. Channel Capacity, Coding Rate, and Effective Goodput

For an ideal band-limited additive white Gaussian noise channel, the Shannon–Hartley relationship is C = B log2(1 + S/N). Here B is channel bandwidth, S/N is the linear signal-to-noise ratio, and C is theoretical capacity in bits per second. It is not the directly attainable rate of a particular Ethernet, Wi-Fi, or modem deployment. Modulation, error-correction code rate, physical framing, retransmissions, and medium sharing can reduce usable throughput.

Performance analysis distinguishes nominal link rate, raw physical rate, transport throughput, and application goodput. Forward-error-correction redundancy can improve reliability under suitable conditions while reducing the fraction of transmitted bits that carry information. Coding design is evaluated with latency constraints and error correlation in the channel.

Unit 3: Switching and the Local Network

3.1. MAC Address Learning in Ethernet Switches

A switch learns the source MAC address of an incoming frame and associates it with the ingress port.

For the destination MAC:

• if it is known, the frame is sent only to the matching port,
• if it is unknown, the frame is flooded to eligible ports in the VLAN,
• if it is broadcast, it is flooded within the VLAN.

The MAC table is a dynamic cache. Entries age out. A host move is learned when a new source frame appears on another port.

3.2. CAM, TCAM, and BUM

MAC tables are commonly implemented with CAM-like hardware. TCAM is widely used for masked Layer 3 prefix, ACL, and policy lookups.

BUM means:

Broadcast
Unknown unicast
Multicast

Uncontrolled BUM traffic consumes bandwidth and forwarding resources. Smaller Layer 2 failure domains, multicast snooping, and overlay control planes reduce unnecessary flooding.

3.3. Store-and-Forward and Cut-through

Store-and-forward receives the complete frame and checks FCS before forwarding.

Cut-through can start forwarding after enough header bytes are received. It reduces latency but may forward a frame before the final FCS is known.

3.4. Duplex

Full-duplex Ethernet can transmit and receive at the same time. There is no collision domain and no CSMA/CD.

Autonegotiation should normally remain enabled on both ends. Manual speed or duplex settings must be changed consistently. Duplex mismatch can produce low throughput, FCS errors, and late-collision symptoms instead of a complete link failure.

3.5. VLAN

A VLAN creates a separate Layer 2 broadcast domain over shared switching infrastructure.

VLAN 10 -> users
VLAN 20 -> voice
VLAN 30 -> servers

A VLAN and an IP subnet are different concepts: Layer 2 versus Layer 3. Enterprise designs often map one VLAN to one IP subnet.

An access port normally carries one VLAN. A trunk carries multiple VLANs.

3.6. 802.1Q

802.1Q adds VLAN information to the Ethernet frame. The VLAN ID field is 12 bits, leaving roughly 4094 usable values.

The tag also carries priority and drop-eligibility information. PCP bits are used for Layer 2 QoS marking.

A native VLAN can carry selected trunk traffic untagged. Native VLAN mismatch can cause incorrect delivery and security problems. Production trunks should be explicit and carry only required VLANs.

3.7. Inter-VLAN Routing

Traffic between VLANs needs Layer 3 routing.

Common methods:

• separate physical router interfaces,
• router-on-a-stick,
• switch virtual interfaces on a Layer 3 switch.

Router-on-a-stick uses subinterfaces:

interface g0/0.10
 encapsulation dot1Q 10
 ip address 192.168.10.1 255.255.255.0

A Layer 3 switch with SVIs scales better in larger LANs and can forward in hardware.

3.8. Layer 2 Loops

Ethernet frames do not have a general TTL equivalent. Redundant Layer 2 links without loop control can cause broadcast storms, MAC-table instability, and frame duplication.

Spanning Tree blocks redundant paths that would otherwise loop.

3.9. STP, RSTP, and MSTP

Basic process:

1. elect the root bridge,
2. find the best path to the root,
3. assign port roles,
4. prevent loop-forming paths from forwarding.

Classic STP converges slowly. RSTP converges faster. PVST+, Rapid PVST+, and MST are implementation choices for different VLAN and scale requirements.

802.1D, 802.1w, and 802.1s are historically useful identifiers; much modern bridge behavior is consolidated in the IEEE 802.1Q family.

MSTP maps many VLANs to a smaller number of spanning-tree instances. Devices in one MST region must agree on region name, revision, and VLAN-to-instance mapping.

RSTP commonly uses root, designated, and alternate port roles. Role is the topology function; discarding, learning, and forwarding are data states.

Important protections:

• PortFast/edge: quickly forwards on host-facing ports.
• BPDU Guard: protects an edge port when unexpected BPDUs appear.
• Root Guard: stops an unwanted superior BPDU from changing the root.
• Loop Guard: protects against certain unidirectional-failure cases.

3.10. Link Aggregation

Several physical links can act as one logical link. The current standard is IEEE 802.1AX; 802.3ad is the historical name.

LACP negotiates and selects members. Cisco PAgP is vendor-specific.

Members must be compatible in speed, duplex, VLAN mode, native VLAN, and allowed VLANs.

Load distribution is usually flow-hash based. Four 10G members do not guarantee 40 Gbit/s to one TCP flow. Aggregate capacity appears across many flows.

Hash inputs can include source/destination MAC, IP, and port values. Keeping one flow on one member prevents packet reordering.

3.11. First-Hop Redundancy

Hosts should not depend on one physical default gateway.

• HSRP: Cisco-specific.
• VRRP: open standard; RFC 9568 is the current base specification.
• GLBP: Cisco-specific and can also distribute gateway load.

Redundancy must track more than an inside interface. A gateway that stays "up" after losing its uplink is not useful.

3.12. Switch Stacks, Virtual Chassis, and the Limits of Dynamic Layer-2 Control

Using several physical switches together can solve different problems, and these designs are not equivalent.

• LAG/LACP combines several physical links into one logical link; it does not turn multiple switches into one management entity.
• A switch stack / virtual chassis can present multiple physical switches as one logical system under a shared control and management view. Depending on the product architecture, it can provide control-plane redundancy, a common management identity, and member election.
• MLAG-class designs let an endpoint attach to two separate physical switches through one logical link bundle. The switches remain physically distinct; state synchronization and failure-domain behavior are product-specific.

The distinction matters during failure analysis. Losing one LAG member, losing a stack controller, and losing state synchronization between two chassis are different failure models.

Mechanisms such as DTP and VTP are vendor-specific historical examples of Layer-2 automation. DTP can negotiate trunk state, while VTP can distribute VLAN information within a management domain. The durable engineering lesson is not command memorization but understanding the blast radius of dynamic Layer-2 control. An unintended trunk or incorrect VLAN propagation can turn a local configuration error into a network-wide event. Explicit port roles, validation, a source of truth, and rollback planning are therefore often more valuable than relying on dynamic defaults.

3.13. 802.1X And MACsec

IEEE 802.1X authenticates a user or endpoint before normal network access.

supplicant -> switch/AP -> RADIUS

Roles:

supplicant              endpoint
authenticator           switch or AP
authentication server   usually RADIUS

MAB can be a fallback for printers or IoT devices without an 802.1X supplicant. It is not strong authentication.

IEEE 802.1AE MACsec provides confidentiality, integrity, and source authentication on Ethernet links.

Unit 4: IPv4 and Subnet Design

Subnet design begins with required usable hosts and growth margin rather than the raw number of addresses alone. After selecting a prefix, verify network address, broadcast address, and assignable range at the bit level. When creating multiple subnets, check block boundaries and absence of overlap. Mathematical address capacity is insufficient if routing aggregation and access-control requirements are not also met.

4.1. IPv4

IPv4 addresses are 32 bits:

192.168.10.25/24

/24 means:

255.255.255.0

Class A/B/C addressing was replaced by CIDR. Classes are historical knowledge; real routing and address planning use prefix length.

4.2. Network Address

Apply a bitwise AND between the address and mask:

IP       192.168.10.25
Mask     255.255.255.0
Network  192.168.10.0

If the destination is inside the local prefix, the host resolves it directly at Layer 2. Otherwise it sends the packet to the default gateway.

4.3. Private and Special Ranges

10.0.0.0/8         RFC 1918 private
172.16.0.0/12      RFC 1918 private
192.168.0.0/16     RFC 1918 private
127.0.0.0/8        loopback
169.254.0.0/16     link-local
100.64.0.0/10      shared address space / CGNAT
224.0.0.0/4        multicast

100.64.0.0/10 is not RFC 1918 private space. It is shared address space for carrier-grade NAT use.

4.4. Subnetting

With h host bits, total addresses are:

2^h

In a conventional unicast subnet:

usable hosts = 2^h - 2

because network and broadcast addresses are not assigned to hosts.

Important exceptions:

• /31: two usable addresses on point-to-point IPv4 links.
• /32: a single host route or loopback.

Example:

192.168.1.0/26
Mask:       255.255.255.192
Block:      64

Network     192.168.1.0
First host  192.168.1.1
Last host   192.168.1.62
Broadcast   192.168.1.63

A quick octet method is:

block = 256 - mask_value

Common prefix sizes:

/24  256 addresses
/25  128
/26   64
/27   32
/28   16
/29    8
/30    4
/31    2, point-to-point
/32    1, host route

Each additional prefix bit halves the address count.

4.5. VLSM and Summarization

VLSM assigns different prefix lengths to different subnets, reducing waste. Allocate from the largest host requirement to the smallest.

Route summarization does the reverse: contiguous prefixes become one shorter prefix. Summarization reduces routing-table size, but an overly broad summary can create a black hole.

4.6. ARP

ARP resolves a known IPv4 address to a MAC address on the local Layer 2 segment.

ARP Request  -> broadcast
ARP Reply    -> usually unicast

For a remote IP destination, the host does not resolve the remote host MAC. It resolves the default gateway MAC.

Gratuitous ARP is used for duplicate-address signaling and to refresh neighbor state after failover. The same trust model enables ARP spoofing.

IPv6 does not use ARP.

4.7. NAT and PAT

NAT rewrites addresses. PAT maps many internal flows to fewer public IPv4 addresses using addresses and ports.

192.168.1.10:53124
       |
203.0.113.10:41001

NAT is not a firewall. Reduced inbound reachability is a side effect, not an access-control policy.

NAT also breaks simple end-to-end address transparency and can require protocol-aware handling.

Turning prefix length into address blocks. Divide the documentation-only address block 192.0.2.0/24 into four equal subnets. Four subnets require two additional network bits, yielding prefix /26 and 2^(32−26) = 64 addresses per subnet. The network addresses are 192.0.2.0, .64, .128, and .192; the corresponding final addresses are .63, .127, .191, and .255. In conventional IPv4 subnets with broadcast addresses, reserving network and broadcast addresses leaves 62 usable host addresses per /26. Correct classification depends on a bitwise AND between an address and its subnet mask, not on a visual interpretation of dotted decimal notation. Design also requires checking the largest host requirement, growth allowance, and routing summarization boundaries.

Unit 5: IPv6

5.1. Address Structure

IPv6 uses 128-bit addresses. Eight 16-bit hextets are written in hexadecimal:

2001:0db8:0000:0000:0211:22ff:fe33:4455

Leading zeroes can be omitted:

2001:db8:0:0:211:22ff:fe33:4455

One consecutive zero run can be compressed once with :::

2001:db8::211:22ff:fe33:4455

5.2. Address Types

2000::/3    global unicast
fc00::/7    unique local
fe80::/10   link-local
ff00::/8    multicast
::1/128     loopback
::/128      unspecified

IPv6 has no broadcast.

Anycast is not a separate address format. The same unicast address is announced from several nodes; routing selects an appropriate instance.

/64 is the normal LAN prefix and is fundamental to several IPv6 mechanisms. IPv6 planning should not imitate IPv4 scarcity by carving tiny host subnets everywhere.

5.3. Link-Local

An IPv6-enabled interface uses a link-local address for communication on its own link. Neighbor Discovery, Router Advertisement, and many routing protocols rely on it.

Link-local addresses are not routed. The outgoing interface may be required when a link-local address is used as a next hop.

5.4. Interface Identifiers and Privacy

EUI-64 is a historical way to derive an interface identifier from a MAC address. Embedding stable hardware identity creates tracking concerns.

Modern clients commonly use stable but opaque identifiers and temporary privacy addresses. RFC 7217 and RFC 8981 are important references.

5.5. SLAAC and DHCPv6

SLAAC:

Router Solicitation
        |
Router Advertisement
        |
prefix + network information
        |
host creates address
        |
Duplicate Address Detection

DHCPv6 can be stateless or stateful. M and O flags in Router Advertisements signal expected configuration behavior, but actual client behavior also depends on operating-system and network policy.

5.6. Neighbor Discovery

ICMPv6 is part of normal IPv6 operation.

Neighbor Discovery messages include:

RS  Router Solicitation
RA  Router Advertisement
NS  Neighbor Solicitation
NA  Neighbor Advertisement
Redirect

They support:

• router discovery,
• prefix discovery,
• address resolution,
• Duplicate Address Detection,
• neighbor reachability detection.

Blocking all ICMPv6 can break IPv6. Filtering must distinguish message type and purpose.

5.7. IPv6 Header and Fragmentation

The IPv6 base header is simpler than the IPv4 header. Optional functions are carried in extension headers.

Routers do not fragment IPv6 packets in transit. If a packet is too large for the path, the source is informed with ICMPv6 Packet Too Big and must select an appropriate size.

5.8. Transition Methods

IPv4 and IPv6 coexist.

Common models:

• Dual stack: both protocols are available.
• NAT64/DNS64: an IPv6 client reaches an IPv4 service.
• 464XLAT: common in IPv6-only mobile networks for IPv4-only applications.
• Tunnels: carry IPv6 across another network in specific transition or overlay cases.

IPv6 does not require NAT for security. Stateful firewall policy remains a separate concern.

Unit 6: Transport and Application Protocols

6.1. Ports and Sockets

The transport layer separates applications on the same host by port number.

A socket endpoint can be viewed as:

IP address + port

A TCP connection is identified by source and destination IP/port pairs.

IANA port ranges:

0-1023        well-known
1024-49151    registered
49152-65535   dynamic/private

Common ports:

22    SSH
25    SMTP
53    DNS
67/68 DHCPv4
80    HTTP
123   NTP
143   IMAP
161   SNMP
443   HTTPS
445   SMB

A port number does not prove the application or its security. Port 443 is usually HTTPS, but a device cannot identify an application with certainty from the port alone.

6.2. TCP

TCP provides a connection-oriented, ordered byte stream.

Core mechanisms:

• sequence numbers,
• acknowledgments,
• retransmission,
• flow control,
• congestion control,
• checksum.

Connection setup:

Client -> SYN
Server -> SYN, ACK
Client -> ACK

Normal close uses FIN/ACK independently in each direction. RST aborts the connection.

A TCP header carries source/destination ports, sequence and acknowledgment numbers, flags, receive window, and checksum.

MSS is the maximum TCP payload announced for a segment; it is not the same as MTU. Window scaling supports large bandwidth-delay products. SACK tells the sender which blocks arrived so recovery can avoid unnecessary retransmission.

6.2.1. TCP Segment Ordering and Overlap Resolution

TCP delivers an ordered byte stream rather than application messages bounded by captured packets. A stream reconstructed from a capture may differ from the stream delivered to an endpoint because of missing packets, retransmissions, and the location of the observation point. Reassembly records the connection identity, direction, initial observed sequence number, byte intervals, and validity. Sequence numbers occupy a 32-bit modular space; wraparound cannot be handled reliably by ordinary unsigned numerical ordering alone.

A segment whose [seq, seq + len) interval precedes the expected position may contain retransmitted bytes. When intervals partially overlap, the previously observed portion can be separated from newly received bytes. Conflicting bytes at the same offset require an explicit overlap policy. A capture parser cannot universally reproduce the overlap behavior of every destination stack. Appending bytes across a missing interval without recording the gap may corrupt application-layer interpretation.

An offset-indexed structure supports ordered insertion efficiently but incurs lookup and merging costs for out-of-order intervals. Buffer bounds must be expressed in memory and retention time as well as segment count. Validation datasets should include reordered and duplicate segments, conflicting overlaps, missing SYN packets, sequence-number wraparound, and incomplete FIN/RST termination.

6.3. Flow Control and Congestion Control

These solve different problems.

Flow control protects the receiver. The advertised receive window limits how much data can remain unacknowledged.

Congestion control protects the network. The sender changes the amount of in-flight data based on loss, ECN, and delivery measurements.

Reno and related algorithms are classical loss-based designs. CUBIC is widely deployed. BBR uses a bandwidth/RTT model. The key lesson is not the algorithm name: loss and queueing change both application latency and sender behavior.

TCP's in-flight data is constrained jointly by the receiver-advertised window and the congestion window. The effective limit can be viewed approximately as min(rwnd, cwnd), with outstanding bytes accounted for at the sender. A slow receiver cannot be rescued by spare network capacity alone, and a large receive buffer does not disable congestion control on a congested path. Packet-level diagnosis should consider acknowledgements, the advertised window, retransmissions, and round-trip time together rather than attributing every low transfer rate to bandwidth.

6.4. UDP

UDP is connectionless and small. Its header is eight bytes:

source port
destination port
length
checksum

UDP itself provides no delivery guarantee, retransmission, ordering, or connection state.

Common uses include:

• DNS,
• DHCP,
• some SNMP operations,
• real-time media,
• QUIC.

An application over UDP can add its own reliability. QUIC is the important example.

6.5. QUIC and HTTP/3

QUIC is a secure transport protocol over UDP. It integrates TLS 1.3 key establishment and supports independent streams inside one connection.

HTTP/3 carries HTTP semantics over QUIC.

Important properties:

• transport and cryptographic setup are integrated,
• streams are independently ordered,
• connection identity is not tied only to the IP/port tuple,
• user-space protocol evolution is easier.

HTTP/2 multiplexes application streams over one TCP connection. A lost TCP segment can stall later bytes for all HTTP/2 streams. QUIC isolates ordering between streams, so loss normally blocks only the affected stream.

Connection IDs also make path migration, such as Wi-Fi to cellular, more natural than with classic TCP.

6.5.1. Parsing QUIC Initial Packets and Protection Boundaries

QUIC long-header Initial packets expose fields such as the version, connection identifiers, and packet type. For a supported version, Initial protection secrets can be derived using HKDF with the version-specific salt and destination connection identifier. Removing header protection and verifying the AEAD tag can permit inspection of CRYPTO frames in the Initial payload. CRYPTO-frame offsets must be preserved while assembling fragments of the TLS handshake.

Recovering Initial-protected data does not decrypt 1-RTT application traffic after the handshake. Version differences, GREASE, connection-ID migration, missing Initial packets, and loss or fragmentation at the capture point constrain interpretation. A connection identifier does not independently establish a user or device identity.

The record of each interpreted field should retain the source packet number, original offset, AEAD verification status, and protocol version. Data that fails authentication must not be forwarded as valid TLS-layer material. Recovering application traffic requires capabilities and authorized key material distinct from Initial-key derivation.

6.6. DNS

DNS is a distributed hierarchical database for names and resource records.

A normal recursive lookup follows:

client
  |
recursive resolver
  |
root
  |
TLD
  |
authoritative server

Common records:

A       IPv4
AAAA    IPv6
CNAME   alias
MX      mail exchanger
NS      authoritative server
PTR     reverse lookup
TXT     text/policy
SRV     service location
CAA     certificate authority policy

TTL controls cache lifetime. A planned DNS change can remain hidden behind old cached data if TTL is not reduced before the change.

6.7. DNSSEC and Encrypted DNS

DNSSEC signs DNS data so a resolver can validate origin and integrity. It does not encrypt the query.

Encrypted transports include:

• DoT: DNS over TLS.
• DoH: DNS over HTTPS.
• DoQ: DNS over QUIC.

They protect the client-to-resolver transport. They do not replace DNSSEC and do not automatically encrypt every hop of the authoritative hierarchy.

Enterprise networks must also govern resolver choice. An unmanaged external DoH/DoQ resolver can bypass central DNS policy.

6.8. Mapping DNS Threats to the Correct Security Control

Different DNS threats are not solved by one mechanism:

• response spoofing / cache poisoning: the resolver accepts incorrect data; DNSSEC provides verifiable origin and integrity.
• query privacy: an observer can see client-to-resolver queries; DoT, DoH, or DoQ protects that transport.
• reflection/amplification: an open or misconfigured resolver/authoritative service sends large replies toward a spoofed source; source-address validation, recursion policy, and appropriate rate limiting are relevant controls.
• DNS tunneling: an allowed DNS channel is abused as a data path; neither DNSSEC nor encrypted DNS automatically prevents this. Resolver policy, egress control, domain/statistical analysis, and endpoint security must work together.

Therefore, "DNS security enabled" is not a single feature. Define the threat model first, then choose the control.

6.9. HTTP and TLS

HTTP versions differ in transport and framing:

• HTTP/1.1: textual message syntax over TCP.
• HTTP/2: binary framing and multiplexing, usually TLS/TCP.
• HTTP/3: QUIC.

TLS 1.3 removed many legacy cipher-suite choices and simplified the handshake. Forward secrecy depends on the negotiated key-establishment method; it should not be assumed merely from the version string.

HTTP/2 multiplexing is not end-to-end execution parallelism. Carrying multiple HTTP/2 streams on one TCP connection does not give each stream independent CPU, database connections, or transaction capacity. HTTP/2 can reduce application-protocol head-of-line constraints, while TCP loss can still affect streams sharing its transport connection. HTTP/3 over QUIC changes transport-level stream independence, but cannot remove saturation in a server queue or database.

When comparing HTTP versions, control TLS establishment, connection reuse, simultaneous streams, response bytes, and client behavior. Merely observing fewer connections does not establish a better p99 or more completed valid operations. Decompose the request latency budget into DNS, connection/TLS setup, server queueing, processing, and transfer time.

6.9.1. HTTP/2 Stream Multiplexing and HPACK State Management

HTTP/2 carries multiple logical streams over one connection using framed messages. A frame payload cannot be interpreted as an HTTP message before validating its length, type, flags, and stream identifier. HEADERS and CONTINUATION frames may belong to the same header block, whereas DATA frames of different streams may be interleaved. END_STREAM and END_HEADERS denote distinct completion conditions.

HPACK operates with connection-scoped static and dynamic header tables. Dynamic-table state persists across header blocks; a missing header block or a capture that begins mid-connection can make subsequent header decoding uncertain. HTTP/2 also maintains separate stream-level and connection-level flow-control windows.

A parser must maintain per-stream state, a connection-level HPACK context, and validated frame-size limits. Treating readable bytes in one packet as an entire file or message disregards multiplexing and header compression and can produce incorrect artifacts.

6.10. Post-Quantum TLS

NIST published ML-KEM, ML-DSA, and SLH-DSA standards in 2024.

RFC 10024, published in August 2026, standardizes three post-quantum/traditional hybrid TLS 1.3 groups:

X25519MLKEM768
SecP256r1MLKEM768
SecP384r1MLKEM1024

Each combines ML-KEM with an ECDHE exchange. The purpose is transition security under both classical and post-quantum assumptions.

This does not mean that present-day quantum computers already break TLS. The concern includes "harvest now, decrypt later" for data that must remain confidential for years.

6.11. Other Application Protocols

SSH is the normal secure choice for remote administration. Telnet does not protect credentials or session data.

FTP is not encrypted by itself. SFTP or an appropriate TLS-protected transfer mechanism should be used when confidentiality is required.

NTP synchronizes time. Clock error can break log correlation, certificate validation, Kerberos-like authentication, and distributed incident analysis.

Syslog centralizes events. Classic UDP/514 is simple but does not guarantee delivery; critical environments should prefer reliable and protected transport where supported.

6.11.1. Application Protocol Identification by Content and Context

A TCP or UDP port is only a prior indicator of an application protocol. The same port can support different applications; nonstandard ports, tunnels, and proxies can also alter the apparent protocol. Passive identification combines port information with protocol signatures, message structure, connection direction, and state transitions.

An identifier can report protocol, supporting fields, confidence, parsing status. A short signature match alone is not conclusive, particularly for binary formats with coincidental byte patterns. Where signatures overlap, the parser can retain multiple candidates and update them as subsequent messages become available rather than forcing the first match.

Validation data should cover nonstandard ports, short messages, overlapping signatures, incomplete captures, and protocol upgrades. Protocol classification and complete application-content reconstruction are separate capabilities.

6.12. Complementary Application Protocols: POP3 and TFTP

Two classic protocols complete the application-protocol picture when placed in the correct context.

6.13. POP3 versus IMAP

SMTP is primarily associated with sending and relaying mail. POP3 and IMAP provide different models for mailbox access.

POP3 is traditionally a simple retrieval/download-oriented protocol. Messages can be left on the server, but the server-side state and multi-client synchronization model is less expressive than IMAP.

IMAP treats the mailbox as server-managed state with folders, flags, and synchronized views across clients.

SMTP -> sending / relay
POP3 -> simple retrieval
IMAP -> server-side mailbox synchronization

6.14. TFTP in Controlled Environments

TFTP is a small UDP-based file-transfer protocol.

It does not provide a TCP session, conventional username/password authentication, or encryption. It uses a simple block/acknowledgment exchange.

It should therefore not be treated as a lightweight replacement for secure file transfer on untrusted networks.

Typical controlled uses include:

PXE / network boot
firmware or device provisioning
closed management networks
simple bootstrapping

The important lesson is not the port number but the trust and state model assumed by the protocol.

Unit 7: Routing

7.1. Router Data Plane

A router receives a packet, looks up the destination prefix, selects a next hop, and forwards.

A simplified IPv4 path is:

1. remove the incoming Layer 2 header,
2. perform a FIB lookup,
3. decrement TTL,
4. update required header fields,
5. build a new Layer 2 frame,
6. transmit.

RIB and FIB are not the same thing. The RIB holds routes learned from protocols and static configuration. The FIB holds the selected forwarding results.

The control plane builds topology and routes. The data plane forwards packets.

A Cisco CEF-style view is:

RIB -> FIB
ARP/ND + next-hop state -> adjacency
FIB + adjacency -> fast forwarding

Hardware platforms often use TCAM for prefix and policy lookup. A high-speed router does not normally ask the CPU to perform a software route lookup for every packet.

7.2. Longest Prefix Match

The first routing rule is longest prefix match.

10.0.0.0/8
10.1.0.0/16
10.1.20.0/24

For destination 10.1.20.5, /24 wins.

Route source preference and metric are considered among candidates for the same prefix.

In a Cisco-style mental model:

1. longest prefix,
2. administrative distance among different route sources,
3. metric within the protocol.

7.3. Static Routes

A static route is explicit and predictable.

ip route 10.20.0.0 255.255.0.0 192.168.1.2

It works well in small stub networks. Manual management becomes expensive in large topologies.

Default routes are:

IPv4  0.0.0.0/0
IPv6  ::/0

A floating static route uses a less-preferred administrative distance and becomes useful when the primary route disappears.

Static routes can be thought of as:

• recursive next-hop routes,
• exit-interface routes,
• fully specified routes with both next hop and interface.

On multi-access Ethernet, an exit-interface-only route can create unnecessary address-resolution behavior; platform behavior must be understood.

7.4. ECMP, PBR, and VRF

ECMP installs multiple equal-cost paths and distributes flows across them. Per-packet distribution can reorder packets, so flow hashing is common.

Policy-Based Routing can choose a next hop using source or policy criteria instead of only the destination prefix. It is a controlled exception, not a replacement for ordinary routing.

A VRF creates an independent Layer 3 routing table on the same device. The same IP prefixes can exist in different VRFs. VRFs are fundamental to tenant separation, management networks, MPLS VPNs, and EVPN fabrics.

7.5. BFD

BFD performs fast forwarding-path liveness detection between two endpoints. OSPF, BGP, and static-route tracking can react to BFD instead of waiting for slower native timers.

BFD does not compute routes. It reports reachability.

7.6. Dynamic Routing Families

Distance vector: learns route and metric information from neighbors. RIP is the classic example. EIGRP is an advanced distance-vector protocol.

Link state: distributes topology information and calculates a shortest-path tree from a link-state database. OSPF and IS-IS are examples.

Path vector: carries path and policy attributes. BGP is the example.

Distribution of routes between neighbors does not guarantee end-to-end application reachability. A valid forward route can coexist with a missing return path, asymmetric filtering, or a translation state that prevents the response. Connectivity checks should distinguish source and destination addresses, ports, and routes in both directions. Failure to receive ICMP replies alone does not prove an application service is unreachable; filtering and protocol-specific behavior must be considered.

7.7. RIP

RIPv2 uses hop count. Fifteen is the largest reachable value; sixteen means unreachable.

Periodic full updates and slow convergence make RIP unsuitable for most large modern networks. Split horizon, route poisoning, and hold-down mechanisms exist to reduce distance-vector loops.

Its main value today is teaching convergence and routing-loop concepts.

7.8. EIGRP

EIGRP originated at Cisco and is described in informational RFC 7868; that RFC is not an IETF Standards Track specification.

DUAL uses:

• successor: best path,
• feasible successor: loop-free backup that meets the feasibility condition.

A feasible successor allows fast failover without a full recomputation.

The default composite metric mainly uses bandwidth and delay. Dynamic load/reliability terms are normally avoided because they can destabilize routing.

7.9. OSPF

OSPF is a link-state IGP.

Hello
  |
neighbor adjacency
  |
LSDB synchronization
  |
SPF / Dijkstra
  |
shortest-path tree
  |
routing table

OSPFv2 is used for IPv4. OSPFv3 was designed for IPv6 and later gained broader address-family support.

Neighbor formation depends on parameters such as area, timers, authentication, and network type. MTU mismatch can stall adjacency in EXSTART/EXCHANGE on some platforms.

7.10. Router ID

The router ID is a logical 32-bit identity. Explicit configuration is safer than letting a physical interface change determine protocol identity.

7.11. DR and BDR

On a broadcast multi-access segment, full adjacency between every router scales poorly. OSPF elects a Designated Router and Backup Designated Router.

Selection uses:

1. interface priority,
2. router ID.

Priority 0 means ineligible.

Election is normally non-preemptive. A higher-priority router that appears later does not replace the existing DR merely because it has a better priority.

Point-to-point links do not need DR/BDR.

7.12. OSPF Areas and Cost

Large LSDBs increase computation and failure propagation. OSPF areas limit scope.

Area 0 is the backbone. ABRs connect areas. ASBRs inject routes from other routing domains.

Classic Cisco cost is:

cost = reference_bandwidth / interface_bandwidth

The historical 100 Mbit/s reference cannot distinguish modern 1G, 10G, and 100G links. A modern reference bandwidth should be chosen consistently.

7.13. OSPF LSAs and Route Classes

A compact LSA memory aid:

Type 1  Router LSA        inside an area
Type 2  Network LSA       generated by DR
Type 3  Summary LSA       inter-area through ABR
Type 4  ASBR Summary      reachability to ASBR
Type 5  AS External       external route
Type 7  NSSA External     external inside NSSA

OSPF prefers intra-area, then inter-area, then external route classes according to its route-selection rules.

LSA flooding distributes topology state. SPF calculates paths from that state. Flooding and forwarding are different operations.

Summarization can reduce LSDB and route count. An over-broad summary can advertise reachability that does not exist; discard/null routing at the summary boundary is therefore important.

7.14. Redistribution

Route redistribution between routing domains must be controlled.

Bidirectional redistribution can create:

• route feedback,
• suboptimal paths,
• metric-translation errors,
• routing loops.

Route tagging and explicit filters preserve route origin and stop feedback.

7.15. BGP

BGP is the policy-routing protocol used between autonomous systems and inside large routing domains.

• eBGP: between autonomous systems.
• iBGP: inside one autonomous system.

BGP sessions normally use TCP port 179.

BGP does not simply choose the shortest physical path. Policy and attributes shape the result.

Neighbor states are:

Idle
Connect
Active
OpenSent
OpenConfirm
Established

Persistent route exchange begins in Established.

Classic iBGP requires a full mesh because routes learned from one iBGP peer are not normally advertised to another iBGP peer. A route reflector removes much of that scaling burden. A confederation divides a large AS internally into sub-ASes.

Common attributes:

• LOCAL_PREF: preference inside an AS; higher is generally preferred.
• AS_PATH: traversed AS sequence and loop-prevention information.
• ORIGIN: how the prefix entered BGP.
• MED: hint to a neighboring AS about preferred entry.
• NEXT_HOP: Layer 3 next hop.
• COMMUNITY: policy tag.

Exact best-path order depends on implementation. The safe mental model is: policy first, then attributes. "BGP always chooses the shortest AS_PATH" is false.

Prefix lists, AS-path filters, and route maps/policy statements define what is accepted, modified, and advertised.

7.16. BGP Security

A false prefix announcement can divert traffic. RPKI Route Origin Validation helps validate which AS is authorized to originate a prefix.

ROV is not full path validation. It validates origin authorization, not every relationship in AS_PATH.

A route leak is different: a legitimately learned route is advertised to the wrong neighbor. RFC 9234 defines BGP Roles and the Only-to-Customer attribute to reduce this class of error.

Secure BGP operations combine prefix filtering, max-prefix limits, RPKI/ROV, session protection, and correct neighbor policy.

7.17. Segment Routing

Segment Routing lets an ingress or source encode an ordered list of logical segments.

Two main data planes are:

• SR-MPLS: segments are MPLS labels.
• SRv6: segments are IPv6 SIDs.

The design moves policy expression toward the ingress instead of maintaining per-flow signaling state throughout the core.

Uses include traffic engineering, fast reroute, service chaining, and centrally controlled paths.

SRv6 does not replace IPv6 routing; it adds programmable segment behaviors to the IPv6 data plane.

7.18. Hot-Potato Routing and End-to-End Path Selection

When an AS has several policy-acceptable egresses for the same external prefix, a router can prefer the exit with the lowest internal IGP cost to the BGP NEXT_HOP. This behavior is commonly called hot-potato routing: hand traffic to another AS as early as practical.

The objective is to reduce transport cost inside the local network:

same policy-acceptable external route set
        ↓
compare internal IGP costs
        ↓
nearest egress

The nearest egress is not necessarily the lowest-latency end-to-end path. After traffic leaves the AS, the remote network may carry it over a longer, more congested, or lower-quality path. Hot-potato selection does not directly optimize that external portion.

Policy preference and IGP distance must also be separated. LOCAL_PREF and other higher-level policy decisions can eliminate one route before IGP cost becomes relevant. Among remaining candidates, internal cost to the next hop can act as a tie-breaker, with exact ordering and extra criteria depending on implementation.

MED represents a different direction of influence. It can signal which entry into a neighboring AS is preferred, whereas hot-potato behavior concerns which exit the local AS chooses. Treating both as one shortest-path metric obscures the policy boundary.

Some networks deliberately use a cold-potato policy, carrying traffic farther across their own backbone before handing it off at a controlled egress. Transit quality, cost, peering relationships, observability, or end-to-end performance can justify that choice.

Operationally, an IGP metric change can therefore alter not only internal forwarding but also BGP egress selection. Large traffic shifts may change queueing, capacity pressure, and path asymmetry, so routing changes should be evaluated as traffic-engineering events as well as control-plane events.

Unit 8: Multicast, IP Services, and QoS

8.1. Multicast

Multicast sends one source stream to a receiver group without creating one independent unicast copy per receiver.

IPv4 multicast uses 224.0.0.0/4. Ethernet maps multicast groups to multicast MAC addresses.

Flooding every multicast frame to every switch port does not scale.

8.2. IGMP and IGMP Snooping

IGMP lets an IPv4 host report group membership to routers. IGMPv2 provides basic join/leave behavior. IGMPv3 adds source-specific membership capabilities.

IGMP snooping lets a switch observe IGMP control messages and learn which ports have receivers.

IGMP is a Layer 3 membership protocol. Snooping is a Layer 2 optimization.

IPv6 uses MLD for similar membership functions.

8.3. PIM, RPF, and Distribution Trees

PIM builds multicast routing state between routers.

• PIM Dense Mode: assumes receivers are widespread and uses flood-and-prune.
• PIM Sparse Mode: assumes receivers are sparse and uses explicit joins.

PIM-SM can begin with a shared tree around a Rendezvous Point (RP) and then move to a source-based shortest-path tree.

Reverse Path Forwarding (RPF) checks whether multicast arrived on the interface expected by the best unicast path back to the source. Failed RPF traffic is dropped.

Memory aid:

IGMP/MLD        receiver membership
IGMP snooping   Layer 2 receiver ports
PIM             multicast tree between routers
RPF             reverse-path check
RP              PIM-SM rendezvous point

8.4. DHCP

DHCPv4 automatically supplies network configuration.

DORA:

Discover
Offer
Request
Ack

Typical options include:

• IPv4 address,
• subnet mask,
• default gateway,
• DNS server,
• lease time.

If client and server are in different broadcast domains, a DHCP relay forwards the request to the server.

DHCP is trust-based. A rogue server can distribute a false gateway or DNS server. DHCP snooping distinguishes trusted uplinks from client ports and can create bindings used by other security features.

8.5. DNS, DHCP, and ARP

DNS   name -> resource record/IP
ARP   IPv4 -> MAC
DHCP  client -> network configuration

Keeping these roles separate makes troubleshooting faster.

8.6. NTP

Time affects log ordering, certificate validation, incident correlation, and many authentication systems.

NTP distributes time in a stratum hierarchy. Enterprise devices should normally use controlled internal time sources instead of arbitrary Internet servers.

8.7. PTP

NTP is suitable for general system time. Precision Time Protocol (PTP / IEEE 1588) targets much tighter phase/time accuracy for industrial, telecom, financial, and similar environments.

Grandmaster, boundary clock, and transparent clock roles reduce accumulated timing error.

PTP and NTP do not target the same precision.

8.8. SNMP

SNMP remains widely used for counters, status, and notifications.

Core components:

• manager/NMS,
• agent,
• MIB,
• OID.

SNMPv1 and v2c depend on community strings and are weak for secure management. SNMPv3 adds authentication and privacy.

Polling is not the same as model-driven streaming telemetry.

8.9. Syslog and Event Management

Central logs provide:

• failure timelines,
• security correlation,
• capacity and change evidence.

Time synchronization and logging must be designed together; an incorrect clock can invalidate a multi-device timeline.

8.10. Syslog Severity, Source Class, and Event Timelines

When evaluating syslog events, severity is not the same as real business impact. A low-severity message may be the first evidence of a major incident, while one high-severity message may be expected during controlled maintenance. Central analysis should therefore preserve at least:

• device/application source and, where available, facility,
• severity,
• a trustworthy timestamp,
• hostname or another stable device identity,
• the change window and relevant configuration version.

NTP/PTP clock correctness has direct operational and forensic value here. If device clocks disagree, the apparent order of a route flap, link-down event, authentication failure, and application error may be wrong. Log collection is therefore not just storage; it is a time-consistent event-correlation problem.

8.11. QoS

QoS does not create bandwidth. It decides how scarce capacity is used.

A common pipeline is:

classify
  |
mark
  |
queue
  |
schedule
  |
shape or police when needed

Layer 3 uses DSCP. Layer 2 can use PCP/CoS.

• Classification: identify the traffic class.
• Marking: encode class information.
• Queuing/scheduling: choose service order under contention.
• Shaping: buffer excess traffic and send it at a controlled rate.
• Policing: drop or remark traffic beyond a configured rate.

Four common QoS symptoms are:

bandwidth shortage
latency
jitter
packet loss

Delay has components:

propagation
serialization
processing
queueing

Propagation follows distance. Serialization follows packet size and link rate. Queueing changes with load and is a major source of tail latency.

A **token bucket** models rate and burst tolerance. Token rate controls the long-term rate; bucket size permits short bursts.

Strict priority is useful for real-time traffic but can starve other classes if unbounded. WFQ/CBWFQ-like schedulers divide capacity among classes. WRED/AQM-like methods try to signal congestion before a queue is completely full.

8.12. Bufferbloat, AQM, CoDel, and FQ-CoDel

When arrival rate remains above the service rate of an egress link, a queue forms. Buffering is necessary to absorb short bursts, but a buffer that remains persistently occupied can create a standing queue and large queueing delay even when packet loss appears low. This behavior is commonly called bufferbloat.

short burst --> temporary queue --> expected
sustained saturation --> standing queue --> high RTT / jitter

Tail drop waits for a buffer to fill before dropping. Active Queue Management (AQM) attempts to signal congestion before persistent buffer occupancy grows without bound, using packet drop or, where supported, ECN marking. RFC 7567 emphasizes excessive queueing delay and recommends appropriate AQM mechanisms in network devices.

CoDel (Controlled Delay) focuses on packet sojourn time rather than queue length and is designed to distinguish transient bursts from persistent queue delay. RFC 8289 is Experimental and should not be presented as an Internet Standards Track protocol.

FQ-CoDel combines flow queueing with CoDel. It distributes traffic across sub-queues so that one heavy flow is less able to dominate other flows, while CoDel controls delay within those queues. RFC 8290 is also Experimental.

QoS, scheduling, and AQM are not synonyms:

• classification/marking identifies a traffic class,
• scheduling allocates link service among waiting classes or flows,
• shaping regulates the offered egress rate,
• AQM controls persistent queue growth through congestion signals,
• ECN can carry a congestion indication instead of a drop when both ends and the network support it.

Low-latency design is therefore more than assigning voice unlimited strict priority. Unbounded strict priority can starve other traffic; classification, fair scheduling, appropriate shaping, and queue management must be designed together.

8.13. Trust Boundary

If any endpoint can mark itself as high priority, every application can claim to be voice.

Mark as close to the source as practical, but trust markings only from controlled endpoints. Untrusted edge ports can be reclassified by the switch.

8.14. ECN

Explicit Congestion Notification lets supporting endpoints and network devices signal congestion without first dropping the packet.

ECN is valuable in low-latency data centers, but it does not solve queueing by itself. AQM behavior, endpoint congestion control, and switch thresholds must agree.

8.15. DetNet, TSN, and RAW

Traditional QoS prioritizes traffic under contention. Deterministic networking aims for tighter bounds.

IETF DetNet can use reserved resources, explicit paths, and replication/elimination inside a controlled domain to target very low loss and bounded latency.

IEEE TSN addresses related deterministic requirements at Layer 2 Ethernet.

Typical domains include industrial control, professional media, in-vehicle networks, and critical real-time systems.

DetNet is not a general Internet latency guarantee.

RFC 9912, published in 2026 as an Informational RFC, defines the Reliable and Available Wireless (RAW) architecture. RAW extends DetNet reliability concepts to variable wireless segments by using path diversity, local repair, and a control loop instead of pretending that radio links are lossless.

8.16. MTU, Queueing Delay, and End-to-End Performance

High bandwidth does not guarantee low latency. Oversized buffers can cause bufferbloat, producing long queueing delays even when packet loss is low.

Packet size also matters. Paths with smaller MTUs can fragment or drop oversized traffic, and broken Path MTU Discovery can create partial, difficult-to-diagnose failures.

End-to-end measurements should separate DNS, connection establishment, TLS, time to first byte, transfer time, and application queueing. A single ping value does not describe application latency.

8.17. Network Queues and End-to-End Latency

Queueing theory explains performance by considering arrival rate, service-time distribution, utilization, and waiting time together rather than looking only at mean processing time. As utilization approaches saturation, a small increase in load can create a nonlinear increase in delay. Little's law links average work in the system with throughput and mean residence time in a stable regime, while heavy-tailed service times show why an average alone can be misleading.

• Decompose end-to-end latency into service and waiting time at each hop.
• Show how larger buffers may reduce packet loss while increasing tail latency.
• Evaluate throughput gains together with RTT and application-level timeout behavior.

Locate where waiting accumulates. Under load, latency may originate in a NIC queue, TCP send buffer, reverse-proxy connection queue, or application connection pool. These are different waiting points along one end-to-end path. A single ICMP RTT measurement or server execution timer cannot separate them. Where appropriate, correlate socket state, retransmissions, interface drops, queue-discipline counters, and HTTP client phase timings.

Comparing absolute timestamps from different machines depends on clock synchronization accuracy. Without known NTP/PTP error bounds, deriving one-way delays from cross-host timestamps can be misleading; monotonic elapsed-time measurement within one process is often safer. The objective is not to infer root cause from hop count but to establish which service center accounts for the growing latency.

8.18. Network Queues and End-to-End Latency

Queueing theory models arrivals, service times, utilization, and waiting-time distributions together rather than equating network performance with average processing time. As utilization approaches saturation, a small increase in offered load can cause nonlinear growth in latency. Little's law relates average work in a stable system to throughput and mean residence time, while heavy-tailed service distributions demonstrate why averages alone are insufficient.

• Separate the service and queueing contributions of each hop to end-to-end delay.
• Assess how larger buffers may reduce loss while increasing tail latency.
• Evaluate throughput changes together with RTT and application-level timeout behavior.

Locating queue accumulation. Under load, increasing latency may originate in an interface queue, TCP send buffer, reverse-proxy connection queue, or application connection pool. These are distinct waiting points along the processing path. A single ICMP RTT sample or server execution time cannot separate them. Socket statistics, retransmissions, interface-drop counters, queue-discipline measurements, and HTTP client phase timings should be correlated when available.

Comparing absolute timestamps from different machines requires a sufficiently accurate shared time reference. Without an estimate of NTP/PTP error, inferred one-way delays across hosts may be invalid; intervals obtained with a local monotonic clock may be more reliable. The objective is to establish where latency accumulates rather than infer root causes from hop count.

Unit 9: Wireless Networks

9.1. Characteristics of Wireless Transmission Media

A switched Ethernet port is usually a dedicated full-duplex link. Wi-Fi shares radio airtime.

Therefore:

high PHY rate != equal application throughput

Airtime contention, retransmissions, channel width, client count, modulation, interference, and scheduling determine the result.

Wi-Fi uses CSMA/CA rather than collision detection.

9.2. Airtime, Contention, Backoff, and Retransmission

In Wi-Fi, the scarce shared resource is not only bit/s capacity but airtime. A client operating at a low PHY rate, or one that requires many retransmissions, occupies the medium longer to move the same payload. WLAN capacity therefore cannot be obtained by summing the nominal PHY rates of all clients.

With CSMA/CA, a station senses the medium and transmits only after the relevant access rules permit it; a busy medium forces waiting. Random backoff reduces the chance of repeated collisions. A frame can be retried when the expected acknowledgement is not received. Contention, backoff, and retry times make service time variable and can generate jitter in dense cells.

In a hidden-node condition, two clients can both hear the AP while failing to hear each other. Each may judge the channel idle and transmit toward the AP, increasing collisions and retries. RTS/CTS can help in selected cases, but its protocol overhead means it is not a universal default solution.

Wider channels can raise peak PHY rate while consuming more spectrum and reducing spatial-reuse options in dense deployments. A 160 or 320 MHz channel is therefore not automatically superior to 80 MHz. Channel planning must account for interference, neighboring BSS density, client capability, regulation, DFS events, and coverage goals.

9.3. RF Measurements

dB expresses a ratio. dBm expresses absolute power relative to 1 mW.

Useful approximations:

+3 dB   about 2x power
-3 dB   about half power
+10 dB  10x power

RSSI represents received signal strength. Noise floor represents background noise. **SNR** is the signal margin above noise:

SNR(dB) = signal(dBm) - noise(dBm)

Higher modulation and coding rates need higher SNR. Strong RSSI alone does not prove a good link if noise is also high.

Free-space path loss grows with distance and frequency. Transmit power, antenna gain, cable loss, and receiver sensitivity belong in one RF link budget.

9.4. Bands and Channel Planning

Enterprise WLANs mainly use:

• 2.4 GHz: longer practical reach, few non-overlapping channels, heavy interference.
• 5 GHz: more channels and common enterprise use.
• 6 GHz: wide clean spectrum for Wi-Fi 6E and Wi-Fi 7, subject to local regulation and propagation limits.

Wider channels increase peak rate for one client but reduce the number of independent channels. Dense environments often perform better with narrower channels.

Co-channel interference means cells share airtime on the same channel. Adjacent-channel interference means partially overlapping transmissions interfere without clean coordination.

Antenna gain, beamwidth, and polarization shape coverage. An omnidirectional antenna does not create a perfect sphere; the real radiation pattern depends on antenna and installation.

9.5. 802.11 Generations

A compact progression:

Wi-Fi 4   802.11n    MIMO
Wi-Fi 5   802.11ac   wider 5 GHz channels, MU-MIMO
Wi-Fi 6   802.11ax   OFDMA, dense-client efficiency
Wi-Fi 6E             802.11ax in 6 GHz
Wi-Fi 7   802.11be   EHT, 320 MHz, MLO, higher capacity

IEEE 802.11be-2024 is an active standard for Extremely High Throughput.

Multi-Link Operation (MLO) lets capable devices use several links more flexibly. The goal is not only peak rate but also latency and resilience.

MIMO uses multiple radio chains. Spatial multiplexing carries independent data streams over the same time/frequency resource. Beamforming attempts to focus useful energy toward the receiver. OFDMA divides a channel into smaller resource units so airtime can be scheduled among many clients.

9.6. Wi-Fi 8 and Newer Work

IEEE P802.11bn is the Ultra High Reliability project. As of 22 August 2026, draft D2.0 is in an initial working-group ballot and the project is not a completed standard.

Its targets include, in defined scenarios:

• higher throughput,
• lower 95th-percentile latency,
• lower MPDU loss, especially during BSS transitions,
• improved AP power behavior.

The theme is reliability and predictable performance, not simply another peak-rate number.

IEEE work also includes enhanced privacy, ambient-power communication, integrated millimeter-wave operation, light communication, and post-quantum security projects. They are at different maturity levels and should not be treated as completed features.

IEEE 802.11bf-2025 WLAN Sensing is a published standard. It allows WLAN measurements to support sensing applications in addition to communication. Privacy is therefore part of the engineering problem.

9.7. WLAN Components

Core terms:

• STA: client station.
• AP: access point.
• BSS: one basic service set.
• ESS: several BSSs providing one extended service.
• SSID: logical WLAN name.
• BSSID: identifier of a specific BSS/radio context.

A simplified client path is:

discovery
  |
authentication
  |
association
  |
key establishment
  |
IP configuration

Hiding the SSID is not strong security. MAC filtering is not strong authentication.

9.8. AP Architectures

Autonomous AP: policy and configuration live on each AP.

Controller-based AP: a WLC centralizes WLAN and radio policy.

Cloud-managed AP: the management plane is hosted as a service; user traffic may still be local or centralized depending on the design.

CAPWAP is a standard protocol used by controller-based architectures for AP control/tunneling models.

Centralization is useful because channel, power, roaming, security, and firmware policies can be applied consistently.

9.9. CAPWAP, Split MAC, and the Local Data Path

A controller-based WLAN can centralize management without forcing every IEEE 802.11 function and every user packet to terminate at the controller. The IETF CAPWAP architecture defines the control relationship between an access controller and wireless termination points; its IEEE 802.11 binding distinguishes local-MAC and split-MAC operation.

With split MAC, some time-sensitive radio/MAC functions remain on the AP while identity, policy, mobility, and selected forwarding functions can be centralized. Local-MAC / local-forwarding designs can instead allow client traffic to enter the local wired network at the remote site. Product features such as FlexConnect are vendor-specific examples of this general idea.

The distinction matters for two reasons:

1. failure domain: if controller reachability is lost, which parts of SSID service, authentication, and forwarding continue?
2. data path: does the client packet reach its local gateway directly, or does it traverse a centralized tunnel first?

Therefore, knowing that a WLAN uses a WLC does not by itself reveal the actual packet path. Troubleshooting should trace the control plane and user data plane separately.

9.10. Mesh, Extenders, and Wireless Backhaul

An access point, repeater/range extender, and mesh node are not equivalent roles. A simple repeater can retransmit frames over the same radio resources used for client access, increasing airtime consumption. A mesh system can coordinate backhaul topology and client steering, but the word "mesh" by itself is not a throughput guarantee.

Backhaul can be considered in three broad forms:

• wired backhaul: inter-AP transport uses Ethernet, leaving more wireless airtime for clients,
• shared wireless backhaul: the same radio/channel serves client access and backhaul, so each hop consumes additional airtime,
• dedicated wireless backhaul: a separate radio or band can reduce contention but consumes spectrum and hardware resources.

Much of the roaming decision remains client-side. Controllers and mechanisms such as 802.11k/v/r can provide information and accelerate transitions, but there is no universal mechanism that can physically force every client to use a specific AP under all conditions. Coverage design should therefore consider cell overlap, channel reuse, and minimum useful SNR rather than only maximizing received signal strength.

9.11. Roaming

A client should move between APs with minimal application disruption.

802.11k, 802.11v, and 802.11r address different parts of the problem:

• neighbor information,
• network-assisted steering,
• fast BSS transition.

The client still owns much of the roaming decision.

Layer 2 roaming can remain inside one IP subnet. Layer 3 roaming crosses an IP boundary and may require mobility tunnels or state transfer.

Roaming delay includes both RF transition and authentication/key-establishment time. 802.11r targets the latter.

9.12. WPA2 and WPA3

WEP and original WPA should be considered obsolete.

WPA2 with AES-CCMP remains a secure baseline when configured correctly. WPA3 strengthens password authentication with SAE, requires stronger management-frame protection behavior, and provides stronger enterprise profiles.

Enterprise WLANs commonly use 802.1X/EAP and RADIUS rather than one shared PSK.

Rogue APs, evil twins, weak onboarding, disabled server-certificate validation, and incorrect VLAN policy can be more serious than the nominal WPA version.

Unit 10: Network Security

10.1. Security Goals

Network security covers more than encryption.

Main goals are:

• confidentiality,
• integrity,
• availability,
• authentication,
• authorization,
• accountability.

"Inside the network" is not a trust decision. Compromised identities, configuration errors, and lateral movement require identity and policy independent of physical location.

10.2. Attack Surface

Common risk areas include:

• management interfaces,
• weak authentication,
• legacy protocols,
• unnecessary services,
• Layer 2 trust assumptions,
• DNS and routing manipulation,
• software vulnerabilities,
• cloud-policy errors,
• endpoints.

The first defense is reducing exposed surface. Disable unused services, ports, and management protocols.

10.3. Layer 2 Attacks

MAC flooding attempts to exhaust MAC-table resources.

ARP spoofing associates an attacker's MAC with another IPv4 address.

DHCP spoofing distributes a false gateway or DNS server.

VLAN hopping abuses trunk negotiation or tagging mistakes.

Defenses include:

• port security,
• DHCP snooping,
• Dynamic ARP Inspection,
• IP Source Guard,
• BPDU Guard,
• explicit access/trunk configuration,
• disabling unused ports.

These features work together. DAI often depends on DHCP-snooping bindings.

10.4. Control-Plane and Management-Plane Security

The data plane carries user packets. The control plane runs routing and adjacency protocols. The management plane changes and observes device state.

Traffic that reaches the router CPU without control can damage routing and management even when forwarding ASICs are healthy.

Control Plane Policing (CoPP) classifies and rate-limits traffic sent to the control-plane CPU.

Management-plane controls include:

• SSH/HTTPS,
• AAA,
• management ACLs,
• management VRF or out-of-band network,
• central logging,
• controlled time sources.

10.5. ACL

An ACL matches traffic on Layer 3/4 fields and applies permit/deny policy.

A useful principle is:

minimum required allow
+
implicit/default deny where appropriate

Direction and placement matter. A correct rule on the wrong interface or direction can be ineffective or destructive.

The old rule "extended ACL near source, standard ACL near destination" is a useful classroom starting point, not a universal production rule. Asymmetric paths and processing location must be considered.

10.6. Stateful Firewall

A stateful firewall tracks connection state as well as packet fields.

It can evaluate:

• who initiated a connection,
• which policy allowed it,
• whether return traffic belongs to an existing session.

A next-generation firewall may add application identity, user identity, TLS inspection, IPS, and threat intelligence. Combining features also concentrates performance cost and failure impact.

10.7. IDS and IPS

An IDS detects and reports suspicious behavior. An IPS is inline and can block it.

Common techniques:

• signatures,
• protocol anomaly detection,
• behavior analysis.

False positives and false negatives must be balanced. "Block everything unusual" is not a sustainable production policy.

10.8. DoS, DDoS, and Source Validation

DoS consumes service capacity or state. DDoS distributes the load across many sources.

Reflection/amplification attacks send small requests with a spoofed victim source address and cause larger replies to the victim. DNS and NTP have historical examples.

BCP 38 ingress filtering and appropriate use of uRPF reduce spoofed-source traffic. DDoS defense can also require upstream filtering, rate limits, anycast, scrubbing, and capacity.

10.9. AAA

AAA means:

Authentication   who are you?
Authorization    what may you do?
Accounting       what did you do?

RADIUS is common for network access, VPN, and 802.1X. TACACS+ is common for network-device administration because command authorization can be handled in detail.

RADIUS commonly uses UDP 1812/1813. TACACS+ uses TCP 49 and separates AAA functions more explicitly.

Central AAA improves privilege lifecycle and auditability. A controlled local break-glass account may remain for loss of the AAA service.

10.10. Encryption

Symmetric encryption protects bulk data efficiently. AES is the common example.

Public-key cryptography supports authentication, signatures, and key establishment.

A hash produces a fixed-size digest. New security designs should use modern collision-resistant families such as SHA-256 or stronger. MD5 and SHA-1 are not suitable for collision-resistant signature designs.

10.11. PKI and Certificates

PKI binds public keys to identities through a trust chain.

Certificate validation must check:

• signature chain,
• hostname/SAN,
• validity period,
• revocation policy where applicable,
• allowed algorithms.

Encryption without peer authentication is not sufficient. A TLS client that ignores certificate validation can create an encrypted session to an attacker.

10.12. Zero Trust and Segmentation

NIST SP 800-207 does not treat network location as automatic trust. Each access decision can consider identity, device posture, context, and policy.

Practical consequences include:

• least privilege,
• strong identity,
• continuous verification,
• microsegmentation,
• detailed telemetry.

Zero Trust is an architectural approach rather than a product name: access decisions are based on identity, device state, context and policy instead of treating network location as sufficient trust.

Segmentation reduces failure and attack domains. VLANs and VRFs segment networks; security groups and workload identity can provide finer policy.

Microsegmentation limits east-west access between workloads even when they share a subnet or fabric.

10.13. ZTNA and SASE

ZTNA tries to authorize a user to a specific application rather than grant broad remote-network access. It can reduce the scope of traditional VPN access but does not eliminate every VPN use case.

SASE combines WAN and security services under a common policy model, potentially including SD-WAN, secure web gateway, firewall-as-a-service, CASB, and ZTNA.

The architectural point is consistent policy independent of user or workload location.

10.14. MACsec, IPsec, and TLS

Encryption layer follows the threat boundary:

MACsec   Layer 2 link
IPsec    Layer 3 network/tunnel
TLS      application session

They are not mutually exclusive. One system can use all three at different boundaries.

10.15. Network Identity, Authorization and Trust Boundaries

Channel encryption, authentication and authorization are distinct mechanisms. Service-to-service trust, user identity and resource access belong to different protocol and policy layers.

The distinction becomes clearer when identity, authorization and transport trust are considered through these concepts.

The core runtime concepts include mTLS, Passkey, WebAuthn and Zero Trust.

For operation and diagnosis, OAuth 2.0, OpenID Connect, Role-Based Access Control and Attribute-Based Access Control.

10.16. Reading TLS 1.3 Controls Through RFC 9846

When auditing TLS, the first question is not merely whether encryption is enabled but whether the client has authenticated its intended endpoint. Certificate chains, hostname matching, signatures, supported versions, and ephemeral key contributions must be considered together. The handshake transcript must be bound to key derivation, application traffic must be authenticated, and resumption paths must account for replay. Operations unsafe under replay should not be treated as suitable for 0-RTT.

RFC 9846 (2026) is the current TLS 1.3 specification, superseding RFC 8446 without changing the protocol version number. It forbids reusing KeyShare values between connections and negotiating TLS 1.0/1.1. Practical checks include obsolete-version support, certificate-name validation, and whether failure logs reveal secrets. The key-agreement mathematics belongs to Cryptology.

Unit 11: WAN, VPN, and Programmable Paths

11.1. WAN Choices

WAN design compares:

• latency,
• bandwidth,
• SLA,
• redundancy,
• cost,
• cloud egress,
• security.

Common transports include:

leased circuit
Metro Ethernet
MPLS service
public Internet
fiber access
4G/5G
LEO satellite

MPLS itself is not an encryption protocol. It forwards by labels and can carry L2VPN or L3VPN services.

An MPLS label switched path carries packets through provider infrastructure. Provider-edge devices can separate customer routes with VRFs, and MP-BGP can carry VPN routes. Encryption, if required, must be provided separately.

11.2. Access Networks: xDSL and FTTx

The part of a WAN closest to the subscriber is the access network / last mile. It is useful to separate access technologies from enterprise backbone and provider-core technologies.

The xDSL family reuses copper pairs. ITU-T G.992.5 is a reference for ADSL2+, and G.993.2 for VDSL2. Achievable rate depends not only on a service tier but on loop length, attenuation, noise, crosstalk, profile selection, and the location of the cabinet or DSLAM.

customer DSL modem
      |
copper local loop
      |
DSLAM / access node
      |
provider aggregation network

ADSL allocates resources asymmetrically, favoring downstream capacity. VDSL2 can use higher frequencies to provide substantially more capacity on short copper loops, with greater sensitivity to loop conditions and distance. A lit "DSL" indicator can demonstrate physical/DSL synchronization; it does not prove that IP session establishment, DHCP/PPPoE, DNS, or higher-layer service is healthy.

FTTx names describe how far fiber extends toward the subscriber:

• FTTN: fiber reaches a neighborhood/node, with another medium for the final segment,
• FTTC: fiber reaches a cabinet or curb location,
• FTTB: fiber reaches the building,
• FTTH: fiber reaches the subscriber premises.

These labels do not by themselves determine Internet latency or guaranteed throughput; aggregation capacity, oversubscription, peering, CPE, and service policy remain part of the end-to-end result.

11.3. Passive Optical Access: OLT, ODN, ONU/ONT, GPON, and XGS-PON

A PON is a point-to-multipoint optical access architecture that can use passive splitters in the distribution plant rather than a chain of powered field switches:

             OLT
              |
             ODN
              |
       passive splitter
        /     |      \
     ONT    ONT     ONT

The OLT (Optical Line Terminal) terminates the PON at the provider side. The ODN (Optical Distribution Network) comprises fiber and passive optical components. ONU (Optical Network Unit) is the general subscriber-side optical unit; ONT (Optical Network Terminal) is commonly used for the termination located at customer premises.

The GPON transmission-convergence layer is specified by ITU-T G.984.3. Downstream traffic is delivered from the OLT across a point-to-multipoint optical structure, while upstream use of the shared medium requires coordinated transmission opportunities. TDMA and Dynamic Bandwidth Assignment (DBA) are therefore important upstream mechanisms. A PON should not be modeled as if each subscriber continuously owned the full physical aggregate line rate; the access segment contains shared resources.

XGS-PON is specified in ITU-T G.9807.1 as a nominal 10 Gbit/s downstream and 10 Gbit/s upstream symmetric PON system. That aggregate rate is still not a per-subscriber application-goodput guarantee; split ratio, DBA, service profile, upstream aggregation, and CPE can all limit the observed result.

11.4. CPE Role Boundaries: Modem, ONT, Router, Switch, and Access Point

Consumer devices often combine several functions, which makes terminology easy to blur:

A DSL or cable modem terminates the access line and performs the relevant physical- and data-link-level adaptation. An optical network terminal (ONT) terminates a passive optical network (PON) at the subscriber premises. A router forwards packets between Layer 3 networks; residential equipment often combines that function with NAT and firewall processing. An Ethernet switch forwards frames within a Layer 2 domain, whereas a wireless access point connects IEEE 802.11 clients to a distribution system. A residential gateway is the product category that integrates several of these functions in one device.

This distinction is operationally important. An optical LOS alarm, PPP/DHCP failure, exhausted NAT state, and Wi-Fi interference are different failures and should not all be reduced to "the modem is broken."

11.5. Fixed Wireless and Satellite Access

Fixed Wireless Access (FWA) connects a stationary customer CPE to an operator network through radio access. In 5G-based FWA, radio conditions, cell load, scheduler behavior, spectrum, and CPE placement affect throughput and delay variation. 3GPP TS 38.300 provides the overall architectural description of NR and NG-RAN; commercial FWA performance cannot be reduced to a single 5G radio feature.

Satellite access is constrained by orbital geometry as well as capacity. For geostationary systems, approximately 36,000 km orbital altitude gives propagation a contribution on the order of hundreds of milliseconds; ITU-R Report M.2460 gives an illustrative value of about 250 ms propagation delay and about 500 ms round trip. LEO systems reduce propagation distance, but handover, gateway selection, satellite/ground routing changes, and queueing still affect the end-to-end latency distribution.

Access technologies should therefore be compared with more than advertised Mbps:

Q = (throughput, latency, jitter, loss, availability)

Fiber commonly provides high capacity and a stable physical medium, but poor peering, excessive queueing, or a distant server can still produce high latency or jitter. Moving from Wi-Fi to Ethernet can remove local wireless contention; it does not remove congestion in the WAN.

11.6. WAN Topology

Hub-and-spoke is simple but centralizes failure and bandwidth pressure.

Partial mesh adds direct paths between important sites.

Full mesh is resilient but grows quickly in links and policy.

Cloud applications make forced backhaul through one data center expensive in latency. Local Internet egress, security policy, SD-WAN, and SASE must be designed together.

11.7. PPP, PPPoE, and Point-to-Point Session Semantics

PPP combines framing, link establishment, and network-layer parameter negotiation for carrying multiple network-layer protocols over point-to-point links. LCP establishes and negotiates the link, while the NCP family configures the network-layer protocols carried across it.

Authentication must not be confused with traffic confidentiality. PAP is not a modern mechanism for strongly protecting credentials against observation or replay. CHAP uses challenge-response rather than sending the password itself on every authentication exchange, but it still does not turn PPP into an encrypted user-data tunnel. PPP authentication and IPsec/TLS-class traffic protection solve different layer problems.

PPPoE preserves point-to-point PPP session semantics over Ethernet. Its additional encapsulation reduces the available MTU budget, which can expose unexpected MSS/PMTUD problems in access networks. An Ethernet link being up does not prove that PPP session establishment, authentication, and Layer-3 configuration have succeeded.

GRE has a similar boundary: it encapsulates packets and can connect otherwise separated networks, but it does not provide encryption or peer authentication by itself. If a secure tunnel is required, confidentiality and integrity must come from a separate security mechanism.

11.8. IPsec

IPsec protects IP traffic.

Core elements are:

• IKE for authentication and key agreement,
• ESP for confidentiality/integrity,
• Security Associations.

Modes:

• Transport: mainly protects the payload of the original IP packet.
• Tunnel: encapsulates the original packet inside a new IP packet.

Tunnel mode is common for site-to-site VPNs.

IPsec adds overhead and changes effective MTU. PMTUD and TCP MSS should be checked when small traffic works but full-size traffic fails.

11.9. GRE and WireGuard

GRE tunnels Layer 3 protocols and can carry multicast. It does not provide confidentiality by itself. GRE can be protected with IPsec.

Tunnels can be nested:

inner packet
  -> GRE
  -> IPsec
  -> outer IP

Each layer costs MTU, observability, and troubleshooting complexity.

WireGuard is a compact VPN protocol with a fixed modern cryptographic design. Key distribution, identity lifecycle, and access policy remain separate operational responsibilities.

11.10. SD-WAN

SD-WAN manages several WAN transports under one policy plane.

management/orchestration
        |
control policy
        |
branch edge
        |
MPLS + Internet + mobile

Path policy can follow application requirements:

voice       -> low-latency path
backup      -> cheap high-capacity path
critical    -> redundancy / fast failover

The core benefit is not a "faster link"; it is measurable policy across heterogeneous transports.

11.11. Segment Routing for Traffic Engineering

An IGP normally computes shortest paths. Traffic engineering may require a path that:

• has lower latency,
• avoids selected links,
• is redundant,
• crosses a service chain.

Segment Routing expresses this as a segment list. SR-MPLS uses MPLS labels. SRv6 uses IPv6 SIDs.

It can reduce the amount of per-path signaling state required in the core compared with older RSVP-TE designs, while increasing the importance of SID planning, controllers, and telemetry.

Unit 12: Data Center, Overlay, Cloud, and High-Performance Fabrics

12.1. Traffic Direction

Traditional campus traffic was largely north-south. Microservices, distributed storage, and AI clusters produce heavy east-west traffic.

A leaf-spine fabric provides many equal-cost paths:

       Spine1  Spine2
       /  |    |  ╲
   Leaf1 Leaf2 Leaf3 Leaf4

A Layer 3 underlay with ECMP avoids large spanning-tree domains.

12.2. Underlay and Overlay

The underlay provides IP reachability between tunnel endpoints.

The overlay carries tenant or logical networks over that underlay.

Troubleshooting order:

overlay failure
   |
is underlay reachable?
   |
is control plane / VNI / policy correct?

12.2.1. Layer and Identity Preservation in Encapsulated Traffic

Encapsulation formats such as VLAN, GRE, VXLAN, and ERSPAN may attach multiple physical and logical network contexts to one packet. Outer IP addresses can identify transport endpoints while inner addresses identify encapsulated endpoints. Without preserving both the VXLAN Network Identifier and VLAN context, flows with identical endpoint addresses in different logical networks may be incorrectly merged.

Every parsing layer must retain its type, header length, validated total length, and offset into the captured frame. Inner frames must not be interpreted before the enclosing length is checked. Inner and outer five-tuples must be stored separately; application sessions should not be identified solely from tunnel headers.

Tests should include nested encapsulation, invalid lengths, truncated inner frames, and MTU-related fragmentation while enforcing memory bounds. A bounded parsing depth prevents malformed input from triggering unbounded recursive decoding.

12.3. VXLAN

VXLAN carries an Ethernet frame over UDP/IP.

A VLAN ID is 12 bits. A VXLAN Network Identifier is 24 bits, allowing about 16 million segments.

inner Ethernet
     |
VXLAN
     |
UDP
     |
outer IP
     |
underlay Ethernet

A VXLAN tunnel endpoint is a VTEP.

Encapsulation adds overhead. Underlay MTU must carry the inner frame plus tunnel headers.

12.4. EVPN

VXLAN defines a data-plane encapsulation; it does not by itself define how MAC/IP reachability is distributed.

BGP EVPN provides a control plane for MAC and IP reachability.

Benefits include:

• less flood-and-learn traffic,
• control-plane host-mobility signaling,
• combined L2/L3 services,
• scalable multi-tenancy.

Common EVPN route types:

Type 2  MAC/IP Advertisement
Type 3  Inclusive Multicast Ethernet Tag
Type 5  IP Prefix

Type 2 is common for host reachability, Type 3 for BUM distribution, and Type 5 for prefix-based Layer 3 reachability.

12.5. Anycast Gateway

An EVPN fabric can present the same default-gateway IP/MAC on many leaf switches. A host routes locally at its attached leaf, reducing central hairpinning and simplifying mobility.

12.6. Virtualization

Virtual machines and containers break the one-port-one-host mental model.

Traffic between two VMs can stay inside a virtual switch and never reach a physical switch. Monitoring only the physical network can miss this traffic.

12.7. NFV and Fast Data Paths

Network Functions Virtualization runs router, firewall, or load-balancer functions as virtual/software functions on general-purpose compute.

At high packet rates, the bottleneck can be per-packet work rather than CPU clock:

• interrupts,
• context switches,
• memory copies,
• cache misses.

Common acceleration methods:

• OVS-DPDK: moves important packet processing into user space and can use polling.
• SR-IOV: exposes NIC virtual functions directly to VMs.
• PCI passthrough: assigns a physical device directly to one guest.
• NIC offload: moves checksum, segmentation, tunnel, or flow operations to hardware.

Less abstraction can improve throughput and latency while reducing migration flexibility, visibility, or portability. Benchmark and operations must be considered together.

12.8. Container Networking

Kubernetes uses abstractions for pod addressing and service discovery. A CNI implementation provides the actual data path.

eBPF-based networking can implement packet processing, observability, and identity-aware policy inside the kernel and can reduce some large-scale iptables limitations.

"eBPF is faster" is not a universal rule. Performance depends on program design, kernel version, NIC offload, and workload.

12.9. Cloud Networking

Cloud providers use different names for similar primitives:

• VPC/virtual network,
• subnet,
• route table,
• security group,
• network ACL,
• Internet gateway,
• NAT gateway,
• peering,
• transit gateway,
• private service endpoint,
• dedicated private circuit.

The network becomes an API-defined resource instead of a sequence of physical-switch commands.

A "private subnet" is not automatically secure. Routes, security groups, IAM, and endpoint policy must agree.

12.10. Load Balancing and Anycast

An L4 load balancer distributes IP/port flows.

An L7 load balancer/reverse proxy can make HTTP-aware decisions.

Anycast advertises the same IP prefix from several locations and lets routing choose a nearby instance.

CDNs, DNS platforms, and global edge services combine these techniques.

12.11. AI and HPC Fabrics

Distributed accelerator clusters create synchronized east-west traffic.

Important design factors include:

• high radix,
• many ECMP paths,
• low oversubscription,
• fast telemetry,
• queue and congestion control,
• high-speed Ethernet.

800G Ethernet is standardized. P802.3dj work including 1.6T is still in draft status as of 22 August 2026.

Ethernet fabrics that target near-lossless behavior may use Priority Flow Control. Incorrect PFC design can create head-of-line blocking and congestion propagation.

RDMA reduces CPU and copy overhead for remote-memory access. RoCEv2 carries RDMA over UDP/IP. ECN, PFC, buffer sizing, and load balancing must be engineered together.

Enabling PFC alone does not create a lossless fabric. Pause propagation under poor thresholds can magnify congestion.

For critical low-latency systems, p95/p99 queueing delay matters more than the average.

12.12. Networks in Distributed AI Systems

In large AI systems, the network is more than a path between a client and a service. Dataset movement, distributed training, multi-accelerator synchronization, and remote inference can make communication latency and bandwidth part of the critical computation path.

In synchronous data-parallel training, workers compute gradients on different mini-batches and then exchange them:

local forward/backward
↓
gradient exchange / all-reduce
↓
parameter update
↓
next step

If the next step waits for collective communication, a faster accelerator cannot hide a slow fabric indefinitely. Bandwidth, latency, topology, and message size all matter.

Model and pipeline parallelism make the dependence even stronger. Intermediate activations can cross device or node boundaries every step. A partitioning scheme that ignores physical topology can create expensive traffic, so adding more accelerators does not imply linear scaling.

Remote inference has a different latency decomposition:

L_total = L_queue + L_network + L_pre + L_infer + L_post

When model execution is short, network and queue time may dominate. Average RTT is insufficient; tail latency, retransmission, connection setup, and load balancing affect user-visible behavior.

Batching can increase throughput while adding queue delay. Burst traffic can also create network queues. AI serving therefore requires an explicit throughput-latency tradeoff rather than an assumption that both can be maximized simultaneously.

RDMA and high-speed fabrics can reduce copy and communication overhead, but technology names are not performance guarantees. NIC and accelerator topology, NUMA placement, congestion control, and collective-library behavior must be measured together.

Security boundaries remain unchanged. Model inputs, embeddings, and intermediate representations are not automatically non-sensitive. Authentication, authorization, and encryption remain part of the service contract and their cost belongs in capacity planning.

Networking does not explain learning theory. It explains the communication cost that turns distributed computation and model serving into real end-to-end throughput and latency.

12.13. Networking in Distributed Artificial Intelligence Systems

In large artificial-intelligence workloads, the network is not restricted to carrying client requests. Data preprocessing, distributed training, accelerator-to-accelerator communication, and remote inference services may place communication latency and bandwidth directly on the critical path of computation.

In distributed training, workers may compute gradients over separate mini-batches. Consistent parameter updates require gradient exchange. A simplified synchronous iteration is:

local forward/backward pass
↓
gradient exchange / all-reduce
↓
parameter update
↓
next iteration

If the next iteration cannot start before collective communication completes, the network remains on the critical path regardless of compute speed. Bandwidth, latency, topology, and message size therefore affect training throughput.

Model and pipeline parallelism introduce different communication dependencies. Activations crossing accelerator boundaries must be transferred on each step; a partition that ignores physical topology may generate expensive cross-node traffic. Adding accelerators does not guarantee linear speedup when communication dominates.

For remotely served inference, a useful latency decomposition is:

L_total = L_queue + L_network + L_pre + L_infer + L_post

When inference duration is small, network transport and queueing may dominate. Mean RTT alone misses tail delays, retransmissions, connection setup, and load-balancer effects. Batching can improve throughput at the cost of waiting for a batch to fill. Throughput and latency must therefore be balanced against workload-specific service objectives.

RDMA and high-speed fabrics may reduce CPU copies during tensor exchange, but their performance depends on network/accelerator topology, NUMA placement, congestion control, and collective-communication libraries. Device names alone do not establish capacity.

Traffic to inference services requires authentication, authorization, and data classification. Embeddings and model inputs do not become nonsensitive merely because they are intermediate representations. Encryption costs, when material, belong in capacity planning; security boundaries must not be removed implicitly for performance.

The network-engineering perspective addresses the physical and logical cost of distributed computation, not the learning theory of the model. Reliable scaling requires a joint computation and communication model.

Unit 13: Network Programming and the Operating System

A network device carries protocols. An application uses those protocols through socket APIs. This is the boundary between network engineering and systems programming.

13.1. Sockets

Berkeley sockets are the base model on Unix-like systems. Windows Winsock exposes the same core concepts with platform-specific details.

TCP server lifecycle:

socket
  |
bind
  |
listen
  |
accept
  |
recv / send
  |
shutdown / close

TCP client lifecycle:

socket -> connect -> send/recv -> close

UDP has no listen/accept connection establishment. sendto and recvfrom preserve datagram boundaries.

13.2. TCP Byte Streams and Application Message Framing

TCP is an ordered byte stream. One send() call is not guaranteed to appear as one recv() call.

The application must define framing:

length prefix
delimiter
fixed-size record
self-describing format

Wrong assumption:

send(100 bytes) -> recv(100 bytes)

Valid behavior:

100 bytes enter the stream
receiver may observe 20 + 50 + 30

13.2.1. Frame and Buffer Integrity in Stateful Stream Parsing

An application parser operating over TCP cannot assume that an incoming buffer represents one complete message. Parsing must be deferred when a length prefix, delimiter, or protocol-specific header is incomplete; the minimum additional byte count can be tracked. The parser must report exactly how many bytes it consumed and must not generate the same application event twice.

For partial frames, the buffer limit B_max, retention time T_max, and concurrent-session limit should be configured independently. Many connections with short messages and a few connections carrying extremely large messages have different resource profiles. A coarse memory bound is M ≤ N_active × B_max + M_index, with actual usage depending on object and index overhead.

Pipeline states such as need-more-data, complete, invalid, and unsupported must be distinct. Capture gaps must not silently become valid reconstructed application content.

13.3. Partial I/O

send() may write fewer bytes than requested. recv() may return only part of one application message.

Production code must:

• track remaining bytes,
• distinguish interrupted/temporary errors,
• distinguish EOF from "no data yet",
• use explicit deadlines.

This is stream semantics, not an exceptional bug.

13.4. Blocking and Non-Blocking I/O

A blocking operation can park a thread until progress is possible.

A non-blocking socket returns immediately and is revisited when ready.

Common mechanisms:

select / poll
epoll       Linux
kqueue      BSD/macOS
IOCP        Windows completion model

select() is portable and useful for teaching, but repeatedly scanning large descriptor sets is expensive. epoll and kqueue scale readiness-driven designs. IOCP is closer to an asynchronous completion model.

13.5. Concurrency Models

Common server architectures:

• process per connection,
• thread per connection,
• thread pool,
• event loop,
• event loop plus worker pool.

Thread-per-connection is simple. At very high concurrency, stack memory, scheduling, and context switching become expensive.

Event loops make idle connections cheap. CPU-heavy work on the same loop can destroy tail latency.

The goal is not "fewest threads." The goal is bounded queues and predictable service time.

13.6. Backpressure

When producers exceed consumers, queues grow somewhere:

application queue
socket buffer
kernel queue
NIC queue
switch queue

Infinite buffering does not create throughput. It creates memory use and latency.

Backpressure means slowing the producer to consumer capacity. TCP receive windows do this at transport layer. Applications need bounded queues, request limits, or explicit flow credits.

13.7. Nagle and Delayed ACK

Nagle reduces tiny TCP segments by combining small writes. Delayed ACK reduces ACK traffic.

The interaction can add latency for small interactive exchanges. TCP_NODELAY should be a measured choice, not a universal performance switch.

Application-level batching can matter more than the socket option.

13.8. Timeouts and Lifecycle

Indefinite network waits are unsafe in production.

Separate budgets may be needed for:

• connect,
• read,
• write,
• idle,
• overall request deadline.

A deadline caps the full operation. Large per-step timeouts can multiply into an unacceptable end-to-end delay.

After active TCP close, the endpoint can remain in TIME_WAIT to stop delayed old segments from being confused with a new connection.

TIME_WAIT alone is not a leak. SO_REUSEADDR changes address-reuse rules; it is not a safe "disable TIME_WAIT" switch.

13.9. Connection Failure Semantics

A successful connect() proves only that TCP establishment succeeded.

Later stages can still fail:

• TLS handshake,
• certificate validation,
• authentication,
• application processing,
• proxy/gateway behavior.

Likewise, a successful local send() does not prove the remote application processed the data. It usually proves that the local stack accepted bytes.

Distributed protocols must define what "success" means.

13.10. UDP Programming

UDP preserves datagram boundaries.

If needed, the application implements its own:

• sequence numbers,
• acknowledgments,
• retransmission,
• deduplication,
• congestion control.

Low UDP header overhead does not make a poor protocol design fast. Loss, reordering, and MTU limits remain application concerns.

13.11. DNS and Byte Order

Multi-byte protocol fields use network byte order, which is big-endian.

Classic C helpers are:

htons / htonl
ntohs / ntohl

Normal applications should use getaddrinfo() for name resolution. Building raw DNS packets is appropriate when implementing a resolver, analyzer, or protocol exercise.

13.12. Raw Sockets and Packet Capture

Raw sockets expose lower-level packet control and usually require elevated privilege.

For capture, libpcap/Npcap and tools such as tcpdump/Wireshark are normally better abstractions.

Capture location matters:

host capture
SPAN
RSPAN
ERSPAN
network TAP

NIC offloads can make a host-side capture look different from the actual segmentation/checksum behavior on the wire.

13.13. TLS and SSH Programming

An encrypted socket is not simply "call encrypt."

A TLS client must:

1. establish transport,
2. perform the handshake,
3. validate certificate chain and hostname,
4. derive keys,
5. carry application data.

Disabling certificate validation can make encrypted transport useless against an active attacker.

SSH also needs server host-key validation. Blindly accepting an unknown host key transfers the man-in-the-middle decision to the user.

13.14. Authentication Boundaries in TLS and Mutual TLS

In a typical HTTPS connection, the client validates the server's certificate and the hostname it intended to reach. In mutual TLS (mTLS), the server additionally requests a client certificate and verifies the client's possession of the corresponding private key during the TLS handshake. Both endpoints can therefore authenticate at the transport layer. A valid client certificate, however, does not automatically authorize access to every application resource.

A service must explicitly map the certificate identity to an application principal and its permissions. Trusted issuers, acceptable certificate attributes, expiration and revocation checks, principal-to-scope mapping, and certificate rotation are separate operational decisions. When a reverse proxy terminates TLS, the backend must accept the asserted client identity only across a trusted boundary; an unrestricted request header supplied by the remote client is not proof of mTLS authentication. Encryption, peer authentication, and business authorization remain distinct controls.

13.15. Copies and Kernel Crossings

At high packet rates, per-packet costs dominate:

• system calls,
• memory copies,
• allocations,
• context switches,
• cache misses,
• interrupts.

sendfile-style APIs can avoid an unnecessary user-space copy for file transfer. DPDK or AF_XDP are more advanced high-speed paths.

Kernel bypass is a trade-off. Mature kernel TCP, security, scheduling, and observability features may have to be rebuilt or re-integrated.

13.16. Latency and Throughput

High throughput and low latency are different objectives.

Larger batches reduce syscall cost and increase throughput but can delay an individual request. Larger buffers absorb bursts but can increase queueing delay.

Useful measurements include:

throughput
median latency
p95 / p99 latency
queue depth
retransmission
drop
CPU
allocation

Average latency alone does not describe critical-system behavior.

Unit 14: Management, Automation, and Observability

14.1. Management Plane

Three logical planes are useful:

• Data plane: forwards packets.
• Control plane: builds routes and protocol state.
• Management plane: configuration, monitoring, administration.

Management traffic should use a dedicated network, VRF, or out-of-band path where practical.

14.2. SDN

Software-Defined Networking logically separates policy/control from packet forwarding.

application / intent
       |
control plane
       |
programmable interface
       |
data plane

This does not mean every switch becomes "dumb." The data plane still performs high-speed forwarding.

OpenFlow was important in early SDN. Modern systems also use NETCONF, gNMI, BGP, PCEP, and vendor APIs.

The important change is that network state can be read and changed by software.

14.3. Cisco IOS/IOS XE CLI Model

Classic CLI modes:

Switch>              user EXEC
Switch#              privileged EXEC
Switch(config)#      global configuration
Switch(config-if)#   interface configuration

Example:

enable
configure terminal
hostname SW1
interface gigabitEthernet 1/0/1
 description USER
 switchport mode access
 switchport access vlan 10
 no shutdown
end
copy running-config startup-config

Syntax varies by platform and release. The useful concept is hierarchical configuration, running state, and persistent state.

The old phrase "running-config in RAM, startup-config in NVRAM" remains a teaching model, not a guarantee about the internal file system of every modern platform.

14.4. Secure Remote Management

Use SSH instead of Telnet.

Basic controls:

• dedicated management path,
• AAA,
• management ACLs,
• strong keys and algorithms,
• central logs,
• time synchronization,
• no shared/default accounts.

If a web interface is required, use HTTPS with managed certificates.

14.5. Neighbor Discovery

CDP is Cisco-specific. LLDP is the open IEEE 802.1AB approach.

Neighbor discovery helps with:

• physical-link validation,
• port mapping,
• device identity,
• PoE and capabilities.

It can also expose topology information. Disable unnecessary advertisements on untrusted edge ports.

14.6. Troubleshooting Order

Random commands waste time. Work by layer:

1. Physical: link, optic power, cable, error counters.
2. Layer 2: VLAN, trunk, STP, MAC, LACP.
3. Layer 3: address, prefix, ARP/ND, gateway, route.
4. Transport: port reachability, TCP state, firewall.
5. Application: DNS, TLS, service behavior.

Do not jump upward before the lower assumption is proven.

14.7. Basic Tools

Host:

ping
traceroute / tracert
ip addr
ip route
ip neigh
ss
dig
nslookup
arp -a
tcpdump / Wireshark

On Linux, ifconfig and netstat are historical tools; modern iproute2 equivalents are ip and ss.

Network device:

show interfaces
show interfaces counters
show mac address-table
show vlan
show interfaces trunk
show spanning-tree
show etherchannel summary
show ip interface brief
show ip route
show arp
show ipv6 neighbors
show logging

14.8. NetFlow, IPFIX, and Flow Visibility

Packet capture shows individual packets. Flow telemetry answers a cheaper question: who communicated with whom, when, and how much?

NetFlow/Flexible NetFlow and standardized IPFIX can export:

• source/destination,
• ports,
• protocol,
• bytes/packets,
• start/end times.

Flow records do not contain full payload. They are useful for capacity, anomaly detection, and traffic matrices.

14.9. SPAN, RSPAN, and ERSPAN

• SPAN: local switch-port/VLAN mirroring.
• RSPAN: carries mirrored traffic to a remote switch over Layer 2.
• ERSPAN: encapsulates mirrored traffic across a Layer 3 network.

Mirroring is not lossless. If the analyzer path is oversubscribed, copies can drop even when production traffic succeeds.

14.10. IP SLA and Active Measurement

Passive counters observe existing traffic. Active measurement sends probes to measure latency, jitter, loss, or service reachability.

IP SLA-like mechanisms can support:

• continuous path-quality measurement,
• object tracking,
• failover decisions,
• SLA verification.

Synthetic probes do not perfectly represent application traffic and should be combined with passive telemetry.

14.11. Scope of ICMP Reachability Testing

Ping proves that ICMP echo works on the tested path.

It does not prove:

• a TCP port is open,
• DNS works,
• the application is healthy,
• full-size packets pass,
• forward and return paths are identical.

"Ping works, therefore the network is fine" is an invalid conclusion.

14.12. Traceroute

Traceroute increases TTL/Hop Limit and uses ICMP Time Exceeded responses from intermediate routers.

Observed paths can be:

• asymmetric,
• incomplete because some routers do not respond,
• different between probes due to load balancing.

Traceroute is a measurement, not the routing table itself.

14.13. Packet Capture

Packet analysis validates assumptions between layers.

Read from outer to inner:

Ethernet
  |
IP
  |
TCP/UDP/ICMP
  |
application protocol

For a suspected DNS problem, first verify that the query was actually sent, then whether a response arrived. Packet capture turns "the application is slow" into measurable events.

14.14. Comparison of Optical and Logical Traffic Observation Points

An optical TAP observes light on an accessible optical path, whereas SPAN duplicates selected frames to a monitoring interface. Captured traffic excludes flows that do not cross the observation point. SPAN saturation, hardware filtering, sampling, and direction-dependent replication may prevent a complete line-rate copy. Optical power budgets and physical link properties must also be considered for TAP deployment.

Capture documentation must specify interface, VLAN, direction, time reference, truncation (snaplen), and possible packet loss. If encrypted application data cannot be decoded, the limits of metadata analysis must be reported. A network observation does not prove that an application accepted a request unless endpoint processing is corroborated.

14.15. Stream Reconstruction and Measurement Errors in Packet Captures

TCP reassembly must account for sequence numbers, retransmitted segments, out-of-order arrival, overlapping byte ranges, and bidirectional session boundaries. Reconstructed data are derived from segments visible at the capture point; missing or uncaptured packets introduce uncertainty. IP fragment reassembly is distinct from TCP stream reconstruction.

A 5-tuple is not a unique session identity in all circumstances; NAT, port reuse, and long capture intervals require additional time and connection-state context. Timestamp accuracy, clock synchronization, and capture loss must be reported together. Successful transport-layer reconstruction alone does not establish application-layer meaning.

14.16. YANG

YANG is a data-modeling language for configuration and operational state.

A model can describe a tree such as:

interfaces
  interface[name]
    config
    state

Vendor models exist. OpenConfig provides common models for multi-vendor automation.

14.17. Separating the Data Model, Serialization, and Management Protocol

A common network-automation error is treating the data model, its wire representation, and the management protocol as the same thing.

desired / observed state
        |
      YANG                 data model
        |
 JSON / XML / Protobuf     encoding / serialization
        |
NETCONF / RESTCONF / gNMI  management operation and transport model

These layers are not one-to-one. YANG defines the meaning and structure of configuration and operational state; different protocols can carry that meaning using different encodings. JSON, XML, and YAML are not network-management protocols by themselves. gNMI is commonly considered in the gRPC/Protocol Buffers ecosystem.

When choosing a serialization format, readability is only one concern. Also consider:

• schema and type validation,
• lossless round trips,
• deterministic generation requirements,
• parsing cost for large configurations,
• diff and version-control behavior,
• accidental logging of secrets.

For a REST-style API, knowing the HTTP verb is also insufficient. Resource identity, idempotency expectations, optimistic-concurrency/ETag-like protection, error semantics, authentication, authorization, and rate limits are part of the contract.

14.18. NETCONF and RESTCONF

NETCONF uses structured RPC operations over YANG-modeled datastores.

Its value is more than XML. running, candidate, and startup datastore concepts can support transaction-like change workflows. Where supported, validate, lock, and confirmed-commit provide safer configuration changes.

RESTCONF exposes YANG-defined data through an HTTP resource model.

They are different protocols:

NETCONF   RPC/datastore oriented
RESTCONF  HTTP resource model
YANG      data model

14.19. gNMI and OpenConfig

gNMI is a gRPC/Protocol Buffers network-management interface.

Core RPCs are:

• Capabilities,
• Get,
• Set,
• Subscribe.

OpenConfig provides vendor-neutral models used with gNMI and other transports.

The OpenConfig gNMI specification revision history lists v0.11.0 in March 2026. The useful concept is not the version number; it is the Subscribe model for long-lived telemetry.

14.20. Streaming Telemetry

SNMP polling asks repeatedly:

NMS -> device: what is the value?

Streaming telemetry subscribes:

subscribe
   |
device -> updates

YANG-Push standardizes subscriptions to YANG datastore updates.

Benefits include:

• higher sampling frequency,
• fewer unnecessary polls,
• structured data,
• lower delay between state change and observation.

The collector side still needs capacity planning, retention limits, and cardinality control.

14.21. Automation

The purpose of network automation is not typing commands faster. It is applying intent repeatably.

Imperative:

enter interface
run VLAN command
change description

Declarative:

desired final state of this port = VLAN 10

Declarative models make idempotency and configuration-drift control easier.

Ansible is a common agentless example. Puppet, Chef, and Salt use different agent/state models. Tool choice comes after desired state, inventory/source-of-truth, and validation.

A safe automation system aims for:

same input -> same expected state

14.22. Automation, Orchestration, and Configuration Drift

Producing an idempotent change on one device is an automation problem; executing dependent multi-step changes in the correct order and within explicit failure boundaries is an orchestration problem. Creating a VLAN, updating trunk permissions, establishing the gateway policy, changing ACLs, and validating the result form a transaction-like workflow that is broader than one CLI command.

A safe network-automation pipeline should aim for a loop such as:

source of truth
      |
render / plan
      |
pre-check
      |
bounded change
      |
post-check
      |
state comparison
   /       \\
compliant  drift
           |
      rollback / reconcile

Tools such as Ansible, Chef, Puppet, and SaltStack use different agent/agentless and state models, but tool selection should come after these architectural principles. The real goal is to avoid unnecessary change when the same intent is applied again, measure drift, and know the safe rollback boundary after partial failure.

This treats network devices as verifiable state machines rather than boxes that merely execute commands. Performance also matters: automation should use bounded concurrency, backoff, and controlled batches instead of loading an unbounded number of devices simultaneously.

14.23. Git and Validation

Network configuration can be managed like code:

change
  |
version control
  |
lint/schema validation
  |
lab/digital twin/test
  |
approval
  |
deployment
  |
telemetry verification

Automation can automate mistakes too. Use scope control, dry-run/diff, canary deployment, and rollback.

14.24. Intent-Based Networking

Intent-based networking raises the abstraction from device commands to desired outcome:

intent
  |
policy
  |
device configuration
  |
telemetry
  |
compliance check
  ^

Generating configuration alone is automation. Measuring whether the intended result exists creates a closed-loop system.

14.25. API Security

A network API is a management surface and must be protected like the CLI.

Controls include:

• strong authentication,
• least-privilege tokens,
• TLS,
• secret management,
• audit logs,
• rate limits,
• certificate validation,
• no embedded secrets in source code.

A single automation account with unrestricted admin access can turn centralized control into a single attack point.

14.26. From Configuration to Verified Service: the Operational-State Chain

A command being accepted does not prove that the intended service actually works. The question-and-answer cases repeatedly expose the same engineering principle: a VLAN can exist while an inter-switch trunk is missing, a host can reach an IP address while name resolution fails, running state can differ from persistent state, and device status must be checked through multiple operational views. Configuration, state, and traffic are different classes of evidence.

A practical verification chain is:

intended state
     |
configured state
     |
control-plane state
     |
operational state
     |
forwarding / data plane
     |
end-to-end service

Success at one layer does not guarantee the next. An access port may carry the correct VLAN identifier, yet communication still fails if the VLAN is inactive, absent from the trunk, blocked by STP, or disconnected from the expected gateway path. A routing protocol can likewise be configured while adjacency is down or learned routes never become usable forwarding entries.

Production verification should therefore ask three independent questions:

1. Configuration: Was the intended configuration actually applied?
2. State: Did the protocol or feature reach the expected operational state?
3. Traffic: Do real packets traverse the expected path and produce the intended service result?

This treats a network device as an observable state machine rather than assuming that CLI acceptance is the final truth.

14.27. Verifying Layer-2 Configuration and Forwarding

Switching faults require more than configuration inspection. VLANs, trunks, STP, link aggregation, and first-hop redundancy need different evidence:

For a VLAN, the port-to-VLAN configuration establishes intended membership, operational state confirms that the VLAN and port are active, and MAC learning plus same-VLAN communication demonstrate actual forwarding. For a trunk, the allowed-VLAN policy, operational trunk status, and observed passage of tagged frames must agree. STP verification combines root selection, priority/guard/port configuration, observed port roles and states, and an active forwarding path that remains loop-free.

A LAG/EtherChannel requires compatible member parameters, a formed bundle with active members, and traffic observed across the aggregate. FHRP verification similarly combines virtual-IP and tracking policy, correct active/standby or equivalent roles, and an end-to-end gateway failover exercise. Each mechanism is therefore evaluated through configuration, operational state, and service-level traffic evidence.

For a link aggregate, mismatched speed, duplex, trunk/access mode, or related Layer-2 parameters can prevent bundling even when physical member links appear up. Likewise, knowing the STP root or an edge-port setting does not prove that application traffic is flowing; the data plane still needs independent verification.

14.28. Evidence Limits of Diagnostic Tests

A diagnostic command is useful only when its hypothesis is explicit. A simple verification ladder is:

loopback
  -> local IP stack
local interface / address
  -> host configuration
default gateway
  -> local L2 + first L3 hop
remote IP
  -> part of the routing/policy path
remote name
  -> DNS resolution + preceding network path
application request
  -> transport, TLS, and application layer

A successful 127.0.0.1 loopback probe supports the health of the local IP stack's loopback path; it does not prove the physical NIC, cable, switch port, gateway, or DNS service.

If a target is reachable by IP address but not by name, DNS configuration, resolver reachability, or the name-resolution chain becomes a strong hypothesis. The reverse is also important: successful DNS resolution does not prove that the application port or server process is healthy.

14.29. SNMP Operation Direction and Privilege Boundary

Knowing only the SNMP manager, agent, and MIB roles is incomplete; operation direction and effect matter:

manager --GET/GETNEXT/GETBULK--> agent
manager -----------SET---------> agent
agent --------TRAP/INFORM------> manager

• The GET family reads managed state.
• SET can modify a writable managed object; observation privilege and change privilege should not automatically share the same trust boundary.
• TRAP is an asynchronous notification sent by the agent.
• INFORM is a distinct notification mechanism that provides acknowledgment.

This distinction has direct security consequences. A monitoring-only principal should not receive write capability without a justified operational requirement. SNMPv3, authorization scope, and management-network isolation should be considered together.

14.30. Running State, Persistent State, and Off-Device Source

Three states should be separated operationally:

running configuration
        |
persistent / post-reboot configuration
        |
off-device backup or source of truth

A change to running state can affect service immediately but disappear after reboot if it is not persisted. Persisting configuration is still not a complete enterprise backup; if the device itself is lost, an on-device copy can disappear with it.

Reliable change management therefore aims for:

• versioned off-device source,
• pre-change diff,
• approval and scope control,
• post-change state verification,
• rollback when required,
• separate handling of secrets.

In an exam, running versus startup may be a command-level distinction. In production engineering, the real requirement is to guarantee the expected post-reboot state and an external recovery path.

14.31. Closure Condition for Verification

An incident is not closed because one command succeeds. It is closed when the original user-visible failure is gone and the system state is consistent:

change applied
      |
protocol/state verified
      |
forwarding verified
      |
application path verified
      |
logs / telemetry normal
      |
rollback information recorded

This turns network administration from command memorization into a problem of evidence-based state verification.

14.32. Measuring Network Behavior by Layer

A “slow” connection cannot be explained by one network metric. DNS resolution, connection setup, TLS/QUIC handshake, time to first byte, transfer, and application queueing can be measured separately. Ping covers only part of that path.

Packet-capture interpretation depends on observation point. NAT, offload, encryption, and virtual networking can change what is visible, so client- and server-side captures may differ.

Protocol standards, operating-system implementations, and device configuration are distinct evidence sources. Security recommendations should also be tied to a threat model; one ACL, timeout, or retry policy is not correct for every network.

14.33. Evidence-Based Network Troubleshooting and Reliable Delivery

When a previously working network fails, the central question is which evidence supports which hypothesis. Troubleshooting is a controlled diagnostic process that separates observations from causes, narrows the failure domain, and validates every intervention.

14.34. Symptom, Observation, Hypothesis, and Root Cause

A report such as “the network is slow”, “the Internet is down”, or “I cannot reach the server” is a symptom. A rising CRC counter, a lost OSPF adjacency, an unanswered DNS query, or a TCP SYN with no observed response is an observation. An observation is not automatically the root cause.

A defensible diagnostic chain preserves the following order:

symptom
  -> scope / blast radius
  -> measurable observation
  -> one or more hypotheses
  -> least-invasive discriminating test
  -> confirmed cause
  -> controlled remediation
  -> end-to-end revalidation
  -> record and rollback information

For example, packet loss seen with ping does not prove a physical-layer fault. A packet may be lost because of physical corruption, queue overflow, ACL/policy action, ICMP rate limiting, a routing fault, or the remote endpoint simply not answering. Root-cause confidence grows only when evidence from different layers is mutually consistent.

14.35. A Systematic Troubleshooting Cycle

A useful operational cycle is:

1. Bound the problem: is one user, a VLAN, a building, a site, one application, or the entire network affected?
2. Build the timeline: when did the first failure occur, is it persistent or intermittent, and does it correlate with load or time of day?
3. Identify recent changes: configuration, cabling, transceiver, firmware, security policy, routing, DNS, or application changes.
4. Compare against a healthy baseline: normal adjacencies, error-counter trends, traffic patterns, and latency distributions are needed before “abnormal” can be defined precisely.
5. Partition hypotheses by layer: do not mix physical, L2, L3, transport, security, and application causes.
6. Change one variable at a time: simultaneous edits destroy causal information and make rollback harder.
7. Validate the user's actual path after remediation: a device CLI showing up does not prove service restoration.
8. Record the evidence and rollback path: the timeline, successful rollback, and proof used for the decision should accelerate the next incident.

The goal is not to memorize a rigid checklist but to make diagnosis falsifiable and evidence driven.

14.36. Bottom-Up, Top-Down, Divide-and-Conquer, and Follow-the-Path

There is no universally correct starting point:

• Bottom-up: appropriate after new cabling, physical work, link flaps, optical alarms, or increasing interface errors.
• Top-down: useful when only one application is broken and lower-layer reachability already has strong evidence; DNS, TLS, or application behavior can be examined first.
• Divide-and-conquer: start at a discriminating midpoint and halve the search space. Reachability to a local gateway can shift attention toward L3/WAN/policy, but it does not prove that every L1/L2 property is healthy.
• Follow-the-path: inspect each forwarding decision from the host toward the destination: host route, neighbor resolution, access switch, gateway, intermediate routers, firewall/NAT, load balancer, and target service.

The objective is not the fewest commands; it is the highest information gain at the lowest operational risk.

14.37. Change Management and Rollback

Troubleshooting changes must not create a second outage. Before a production change, retain at least:

• the relevant starting configuration or state,
• the reason for the change and expected effect,
• the validation criterion,
• the rollback action,
• the failure domain that may be affected.

Actions such as bouncing a port, disabling STP, removing an ACL, or inserting a route should not be used as uncontrolled experiments. The intervention should first discriminate a hypothesis; permanent remediation follows only after the cause is established.

14.38. Physical Link Availability and Quality Assessment

An interface in the up state does not prove that the physical path is healthy. Different failure classes produce different evidence.

When a link never comes up, inspect administrative and operational state at both ends, the device and module inventory, and cable or optical measurements. Relevant causes include an administratively disabled interface, an inactive peer, an incompatible medium or module, and an incorrectly terminated cable. Repeated link flaps call for transition/reset counters and physical evidence covering optical power margin, connector contamination or looseness, bend loss, module or port condition, and power supply. DOM, OPM/OTDR, and controlled physical isolation help distinguish these factors.

Rising CRC, FCS, or input-error counters require examination of copper or fiber quality, termination, EMI/crosstalk, and port or NIC condition; error-rate trends, cable certification, and controlled port/cable substitution provide evidence. Poor throughput together with late-collision-like counters warrants a comparison of speed, duplex, and autonegotiation at both ends. An unpowered PoE endpoint is assessed through PSE capability, total power budget, negotiated class, cable path, PoE status, and the endpoint's power requirements.

Digital Optical Monitoring (DOM) data is useful, but there is no universal “good dBm” threshold. Transmit/receive power, temperature, and bias must be evaluated against the operating range of the specific optic and vendor. Dirty connectors, macro-bends, or bad patching may increase error rates even when the link still comes up.

Rising CRC/FCS counters often indicate frames corrupted along the transmission path, but one counter does not identify the physical cause. The rate of increase, the peer's counters, and cable/optical measurements should be correlated.

14.39. L2 Diagnosis: Correct VLAN, Correct Path, Loop-Free Topology

At Layer 2, “the MAC is present” or “the trunk is up” is not sufficient proof.

A VLAN mismatch can be traced through:

host address/prefix
  -> access VLAN
  -> MAC learning
  -> trunk allowed-VLAN list
  -> native/tagged behavior
  -> SVI / gateway

An access port in the wrong VLAN, a required VLAN missing from a trunk, or inconsistent native-VLAN behavior can break communication while the physical link remains up.

For an STP loop or broader L2 instability, “high traffic” alone is weak evidence. Stronger indicators include:

• the same MAC moving rapidly between ports,
• repeated topology-change events,
• sudden broadcast/unknown-unicast growth,
• CPU or forwarding-resource pressure,
• simultaneous intense frame activity on multiple links.

Controls such as BPDU Guard are operational fault-containment barriers as well as security controls. If a port is err-disabled, blindly bouncing it does not fix the root cause; the reason for protective shutdown should be established first.

14.40. L3 Diagnosis: Address, Neighbor, Route, and Return Path

For a host to reach a destination outside its own subnet, at least these conditions are needed:

valid source address/prefix
  + correct next-hop/gateway decision
  + ARP/ND resolution for the next hop
  + an appropriate forwarding route on the router
  + reachable return path
  + state/policy that permits the flow

A wrong default gateway often preserves same-subnet communication while breaking off-subnet access. The host route table and neighbor resolution should therefore be checked first.

For a missing-route diagnosis, the presence of a target prefix in a routing table is not enough. Longest-prefix-match outcome, next-hop reachability, recursive resolution, VRF context, installed/active state, and where relevant the dynamic-protocol adjacency must be considered together.

An IP address conflict may cause unstable ARP/neighbor mappings, gratuitous-ARP changes, or Duplicate Address Detection warnings. In managed environments, DHCP records, the switch MAC table, and neighbor caches should be correlated. Powering down one endpoint and probing the address is only one isolation technique; it is not universal proof in every topology.

Asymmetric routing is not inherently a failure. ECMP, multiple uplinks, and policy routing can legitimately produce different forward and reverse paths. It becomes operationally important when a stateful firewall, NAT device, or similar middlebox must observe both directions in the same state context. Troubleshooting must validate the return path, not only the forward route.

14.41. Using Packet Capture as Evidence

Packet capture is powerful but shows only what is visible at the capture point. The same flow can legitimately look different on the client NIC, an access-switch SPAN port, the two sides of a firewall, and the server NIC.

Four questions should accompany capture interpretation:

1. Where was the capture taken? Before or after NAT, a tunnel, load balancer, or proxy?
2. Which direction is visible? Is only ingress or only egress observed?
3. Could the capture itself be dropping packets? SPAN/ERSPAN or the capture host may be oversubscribed.
4. Are offloads affecting the view? Checksum and segmentation offload can make a host capture differ from actual on-wire frame boundaries or checksum state.

TCP handshake observations should be interpreted with explicit limits:

A SYN observed leaving without a response confirms that the client attempted a connection; packet loss, routing, and filtering must still be considered. An RST following a SYN demonstrates an accessible TCP response path and indicates rejection or closure at a reachable point, without identifying why an application is not listening. SYN → SYN-ACK → ACK shows that TCP establishment succeeded, while TLS, HTTP, and application-level behavior require separate checks.

Repeated TCP segments indicate missing expected acknowledgments or retransmission; lost acknowledgments, packet reordering, and incomplete capture are relevant alternative explanations. A DNS query observed without a reply establishes that a query was sent toward a resolver, not that the resolver itself is the sole source of the condition. Capture evidence is interpreted together with routing, filtering, and endpoint state.

ICMP Destination Unreachable and Packet Too Big messages are valuable evidence. Conversely, filtered or rate-limited ICMP does not automatically prove that forwarding has failed.

14.42. Testing MTU and Fragmentation Correctly

“Sending a large ping” is not by itself a definition of Path MTU testing. The IP version, ICMP overhead, DF/fragmentation behavior, and tunnel overhead must be known.

• Classical IPv4 PMTUD can use ICMP “fragmentation needed” feedback for packets sent with DF semantics.
• IPv6 routers do not fragment transit packets; Packet Too Big feedback is critical to the source.
• Where ICMP feedback is unreliable, PLPMTUD/DPLPMTUD provides more robust packetization-layer probing to discover a workable packet size.
• IPsec, GRE, VXLAN, and other encapsulations reduce the effective MTU/MSS available to inner traffic; success with small packets does not prove that large transfers will succeed.

MTU diagnosis should therefore correlate the actual flow's packet sizes, ICMP feedback, encapsulation overhead, and retransmission behavior rather than relying on one command invocation.

14.43. Error Detection, FEC, and ARQ Are Distinct Mechanisms

Reliability mechanisms solve different problems in different ways:

• Parity/checksum/CRC: detect selected classes of corruption; their detection strength is not identical.
• FEC (Forward Error Correction): the sender adds redundancy so the receiver can correct errors within the code's capability without requesting retransmission.
• ARQ (Automatic Repeat reQuest): detected loss/corruption triggers retransmission.

Canonical ARQ families illustrate the design space:

Stop-and-Wait sends one unit and waits for acknowledgment. Its state management is simple, although utilization can be poor on high-RTT links. Go-Back-N allows a window of units in flight and retransmits from a loss point; receiver logic is comparatively simple, but already delivered data may be sent again. Selective Repeat retransmits only missing or corrupted units, improving bandwidth efficiency at the cost of additional receiver buffering and protocol state.

These models are common conceptual tools across link and transport protocols. TCP implements its own reliable byte-stream semantics using acknowledgments, retransmission, and separate flow/congestion windows; it should not be reduced to one data-link ARQ label.

Some high-speed Ethernet PHYs include FEC at the physical layer. The goal there is to improve link margin at the required bit-error environment rather than waiting for application-level retransmission. The exact FEC scheme depends on the selected IEEE PHY specification.

14.44. Hierarchical Campus Design and Fault-Domain Isolation

A classic enterprise campus can be described using three functional regions:

Access        -> endpoint attachment, identity, and edge policy
Distribution  -> L3 boundary, route/policy aggregation, fault-domain separation
Core          -> high-capacity, predictable transit

This does not require three physically separate device tiers in every network. Small and medium designs often combine distribution and core into a collapsed core. The important engineering questions are:

• How many users fail when an access switch or uplink fails?
• How large is the L2 failure domain?
• Are redundant paths genuinely independent?
• Where does oversubscription occur?
• Where are policy and routing boundaries?
• Does convergence time fit the application's failure budget?

Hierarchy is therefore a tool for controlling capacity, policy, and failure domains, not a mandatory diagram template.

14.45. Remote-Access VPN: a Tunnel Does Not Define the Access Policy

A site-to-site VPN connects network boundaries; a remote-access/host-to-network VPN connects an individual user or device to protected resources. Encryption alone is insufficient. At minimum, remote access needs coordinated design for:

• user and, where possible, device identity,
• MFA/certificate/key lifecycle,
• permitted prefixes and services,
• DNS resolver and search-domain behavior,
• tunnel routes,
• device posture/compliance conditions,
• session lifetime, reauthentication, and logging.

With full tunnel, default traffic may traverse the enterprise tunnel. Central policy and visibility can increase, but WAN/backhaul load and latency may increase as well.

With split tunnel, only selected enterprise networks use the VPN while other traffic exits locally. This can reduce backhaul but changes the trust boundary because the endpoint communicates with an untrusted local network and protected resources concurrently. The decision should be based on threat model, SaaS usage, DLP/inspection requirements, and capacity rather than on a one-dimensional “speed versus security” slogan.

Local-LAN access, split DNS, and overlapping private prefixes are also frequent sources of remote-access failures. A tunnel can be up while the application remains unreachable because routes or DNS selection are wrong.

For IPsec-based remote access, IKEv2 performs authentication and establishes/maintains Security Associations; the IPsec data plane protects IP-layer traffic. Product GUIs and CLI syntax change over time, while this architectural separation remains valid.

14.46. Translating Network-Security Policy into Technical Control

Network security is broader than writing firewall rules. A written policy turns who may access which resource, under what conditions, and with whose authorization into technical control. Important policy families include:

• acceptable use and egress,
• user/device access and privilege,
• firewall/ACL and segmentation,
• remote access/VPN,
• credential, key, and certificate lifecycle,
• management-plane access,
• physical access to network equipment,
• logging, time synchronization, and change records.

The objective is not to prohibit everything, but to define defaults, exception ownership, and auditable evidence. Risk, governance, and security architecture are treated in greater depth in Cybersecurity Engineering.

14.47. Interpreting Evidence Across Layers

Collecting evidence by layer reduces the chance of optimizing or changing the wrong component:

At the physical layer, evidence includes DOM/OPM measurements, cable certification, carrier transitions, and CRC/FCS trends; a lit link indicator alone cannot characterize physical health. Layer 2 evidence combines MAC tables, VLAN and trunk state, STP topology changes, and LACP state; a learned MAC address does not in itself establish a working gateway path. At Layer 3, host routes, ARP/ND, RIB/FIB, next-hop information, traceroute, and ICMP help establish forwarding behavior, but a route entry does not independently verify the return path.

At the transport layer, SYN/SYN-ACK/RST sequences, ACKs, retransmissions, and socket state establish connection behavior rather than application health. In the security layer, ACL/firewall decisions, session/NAT state, and VPN security associations are examined; successful ping alone does not establish permission for every protocol. At the application layer, DNS responses, TLS handshakes, HTTP status codes, and application logs describe service behavior; an HTTP error must be interpreted in its own protocol and application context.

Where possible, a conclusion should be supported by two independent evidence types. A suspected routing fault is stronger when both forwarding state and observed packet path agree; a suspected physical impairment is stronger when interface counters and physical measurements agree.

14.48. Compact Operational Flow

An ambiguous “web application will not open” incident can be decomposed as follows:

1. bound the scope
2. validate client IP/prefix/gateway/DNS configuration
3. validate route and neighbor state toward gateway and destination
4. test the name and IP separately to isolate DNS
5. test the target transport (TCP/QUIC) separately from the application
6. if required, capture at two useful points
7. inspect TLS and application response
8. after any change, repeat the original measurements using the same method
9. record the result and rollback information

The ordering is not absolute. The invariant is that each step should reduce the next set of plausible hypotheses.

14.49. Distinguishing Normal Traffic Surges from Anomalies

Traffic baselines depend on time of day, connection type and observation point. A packet-rate surge may be legitimate transfer activity or attack. CUSUM can flag persistent shifts, but increased utilisation does not establish an attack type. Packet loss and sampling rate also affect observation quality. The underlying detection theory is in Anomaly Detection.

References

• 3GPP. TS 38.300: NR; NR and NG-RAN Overall Description; Stage 2. https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3191
• Andrew S. Tanenbaum, Nick Feamster, David J. Wetherall. Computer Networks, 6th Edition. Pearson, 2021.
• Asaf Varol. Bilgisayar Ağları Ders Notları. Elazığ, 2010.
• Brad Edgeworth, Ramiro Garza Rios, David Hucaby, Jason Gooley. CCNP and CCIE Enterprise Core ENCOR 350-401 Official Cert Guide, 2nd Edition. Cisco Press, 2024.
• Brendan Gregg. Systems Performance: Enterprise and the Cloud. Pearson Education, 2014.
• Cemal Taner. Ağ Yöneticiliğinin Temelleri, 5th Edition. Abaküs, 2021. ISBN 9786059129794.
• Cemal Taner. Ağ Yöneticiliğinin Temelleri, 7th Edition. 2025. ISBN 9786059129794. https://www.cemaltaner.com.tr/urun/ag-yoneticiliginin-temelleri-adiniza-imzali/
• Cemal Taner. Uygulamalı Network Troubleshooting Rehberi.
• Cilium Project. Cilium Documentation. https://docs.cilium.io/
• Hjelmvik, E. NetworkMiner 3.2 Source Code: PacketParser and PacketHandlerFramework. NETRESEC.
• Hulusi Turgut. Ağ Teknolojilerine Giriş. 2004.
• IEEE 802.1 Working Group. IEEE 802.1X Port-Based Network Access Control. https://1.ieee802.org/security/802-1x/
• IEEE 802.11 Working Group. P802.11bn Ultra High Reliability Task Group. https://www.ieee802.org/11/Reports/tgbn_update.htm
• IEEE 802.3 Working Group. IEEE P802.3dj: 200/400/800 Gb/s and 1.6 Tb/s Ethernet. https://www.ieee802.org/3/dj/
• IEEE 802.3 Working Group. IEEE Std 802.3dg-2026: 100 Mb/s Long-Reach Single Pair Ethernet. https://www.ieee802.org/3/dg/
• IEEE. IEEE Std 802.11-2024: Wireless LAN MAC and PHY Specifications. https://standards.ieee.org/ieee/802.11/10548/
• IEEE. IEEE Std 802.11be-2024: Extremely High Throughput. https://standards.ieee.org/ieee/802.11be/7516/
• IEEE. IEEE Std 802.11bf-2025: Enhancements for WLAN Sensing. https://standards.ieee.org/ieee/802.11bf/11574/
• IEEE. IEEE Std 802.1AE-2018: MAC Security. https://standards.ieee.org/ieee/802.1AE/7154/
• IEEE. IEEE Std 802.1AX-2020: Link Aggregation. https://standards.ieee.org/ieee/802.1AX/6768/
• IEEE. IEEE Std 802.3df-2024: 400 Gb/s and 800 Gb/s Ethernet. https://standards.ieee.org/ieee/802.3df/11107/
• IETF. RFC 10024: Post-Quantum Traditional Hybrid Key Agreement Mechanisms for TLS 1.3. https://www.rfc-editor.org/rfc/rfc10024.html
• IETF. RFC 1034 / RFC 1035: Domain Names. https://www.rfc-editor.org/
• IETF. RFC 1350: The TFTP Protocol (Revision 2). 1992. https://www.rfc-editor.org/rfc/rfc1350
• IETF. RFC 1661 / STD 51: The Point-to-Point Protocol (PPP). https://www.rfc-editor.org/rfc/rfc1661.html
• IETF. RFC 1939: Post Office Protocol — Version 3. 1996. https://www.rfc-editor.org/rfc/rfc1939
• IETF. RFC 2131: Dynamic Host Configuration Protocol. https://www.rfc-editor.org/rfc/rfc2131.html
• IETF. RFC 2328: OSPF Version 2. https://www.rfc-editor.org/rfc/rfc2328.html
• IETF. RFC 2474 / RFC 2475: Differentiated Services. https://www.rfc-editor.org/
• IETF. RFC 2516: A Method for Transmitting PPP Over Ethernet (PPPoE). https://www.rfc-editor.org/rfc/rfc2516.html
• IETF. RFC 2681: A Round-trip Delay Metric for IPPM. https://www.rfc-editor.org/rfc/rfc2681.html
• IETF. RFC 2784: Generic Routing Encapsulation (GRE). https://www.rfc-editor.org/rfc/rfc2784.html
• IETF. RFC 2827 / BCP 38: Network Ingress Filtering. https://www.rfc-editor.org/rfc/rfc2827.html
• IETF. RFC 3376: Internet Group Management Protocol, Version 3. https://www.rfc-editor.org/rfc/rfc3376.html
• IETF. RFC 3550: RTP: A Transport Protocol for Real-Time Applications. https://www.rfc-editor.org/rfc/rfc3550.html
• IETF. RFC 4271: Border Gateway Protocol 4. https://www.rfc-editor.org/rfc/rfc4271.html
• IETF. RFC 4301: Security Architecture for the Internet Protocol. https://www.rfc-editor.org/rfc/rfc4301.html
• IETF. RFC 4821: Packetization Layer Path MTU Discovery. https://www.rfc-editor.org/rfc/rfc4821.html
• IETF. RFC 4861: Neighbor Discovery for IP version 6. https://www.rfc-editor.org/rfc/rfc4861.html
• IETF. RFC 5415: Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification. https://www.rfc-editor.org/rfc/rfc5415.html
• IETF. RFC 5416: CAPWAP Protocol Binding for IEEE 802.11. https://www.rfc-editor.org/rfc/rfc5416.html
• IETF. RFC 5424: The Syslog Protocol. https://www.rfc-editor.org/rfc/rfc5424.html
• IETF. RFC 5481: Packet Delay Variation Applicability Statement. https://www.rfc-editor.org/rfc/rfc5481.html
• IETF. RFC 6241: Network Configuration Protocol (NETCONF). https://www.rfc-editor.org/rfc/rfc6241.html
• IETF. RFC 7217: Semantically Opaque Interface Identifiers. https://www.rfc-editor.org/rfc/rfc7217.html
• IETF. RFC 7296 / STD 79: Internet Key Exchange Protocol Version 2 (IKEv2). https://www.rfc-editor.org/rfc/rfc7296.html
• IETF. RFC 7348: Virtual eXtensible Local Area Network (VXLAN). https://www.rfc-editor.org/rfc/rfc7348.html
• IETF. RFC 7567 / BCP 197: IETF Recommendations Regarding Active Queue Management. https://www.rfc-editor.org/rfc/rfc7567.html
• IETF. RFC 7679 / STD 81: A One-Way Delay Metric for IP Performance Metrics. https://www.rfc-editor.org/rfc/rfc7679.html
• IETF. RFC 7680 / STD 82: A One-Way Loss Metric for IP Performance Metrics. https://www.rfc-editor.org/rfc/rfc7680.html
• IETF. RFC 768: User Datagram Protocol. https://www.rfc-editor.org/rfc/rfc768.html
• IETF. RFC 7761: Protocol Independent Multicast - Sparse Mode. https://www.rfc-editor.org/rfc/rfc7761.html
• IETF. RFC 7858: DNS over TLS. https://www.rfc-editor.org/rfc/rfc7858.html
• IETF. RFC 7868: Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP). https://www.rfc-editor.org/rfc/rfc7868.html
• IETF. RFC 7950: The YANG 1.1 Data Modeling Language. https://www.rfc-editor.org/rfc/rfc7950.html
• IETF. RFC 8040: RESTCONF Protocol. https://www.rfc-editor.org/rfc/rfc8040.html
• IETF. RFC 8200: Internet Protocol, Version 6 (IPv6) Specification. https://www.rfc-editor.org/rfc/rfc8200.html
• IETF. RFC 8259 / STD 90: The JavaScript Object Notation (JSON) Data Interchange Format. https://www.rfc-editor.org/rfc/rfc8259.html
• IETF. RFC 8289: Controlled Delay Active Queue Management. https://www.rfc-editor.org/rfc/rfc8289.html
• IETF. RFC 8290: The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm. https://www.rfc-editor.org/rfc/rfc8290.html
• IETF. RFC 8365: Network Virtualization Overlay Solution Using EVPN. https://www.rfc-editor.org/rfc/rfc8365.html
• IETF. RFC 8402: Segment Routing Architecture. https://www.rfc-editor.org/rfc/rfc8402.html
• IETF. RFC 8484: DNS Queries over HTTPS. https://www.rfc-editor.org/rfc/rfc8484.html
• IETF. RFC 8655: Deterministic Networking Architecture. https://www.rfc-editor.org/rfc/rfc8655.html
• IETF. RFC 8899: Packetization Layer Path MTU Discovery for Datagram Transports. https://www.rfc-editor.org/rfc/rfc8899.html
• IETF. RFC 8981: Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6. https://www.rfc-editor.org/rfc/rfc8981.html
• IETF. RFC 8986: Segment Routing over IPv6 Network Programming. https://www.rfc-editor.org/rfc/rfc8986.html
• IETF. RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport. https://www.rfc-editor.org/rfc/rfc9000.html
• IETF. RFC 9114: HTTP/3. https://www.rfc-editor.org/rfc/rfc9114.html
• IETF. RFC 9234: Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages. https://www.rfc-editor.org/rfc/rfc9234.html
• IETF. RFC 9250: DNS over Dedicated QUIC Connections. https://www.rfc-editor.org/rfc/rfc9250.html
• IETF. RFC 9293: Transmission Control Protocol (TCP). https://www.rfc-editor.org/rfc/rfc9293.html
• IETF. RFC 9568: Virtual Router Redundancy Protocol Version 3. https://www.rfc-editor.org/rfc/rfc9568.html
• IETF. RFC 7541. HPACK: Header Compression for HTTP/2. https://www.rfc-editor.org/rfc/rfc7541
• IETF. RFC 9000. QUIC: A UDP-Based Multiplexed and Secure Transport. https://www.rfc-editor.org/rfc/rfc9000
• IETF. RFC 9001. Using TLS to Secure QUIC. https://www.rfc-editor.org/rfc/rfc9001
• IETF. RFC 9113. HTTP/2. https://www.rfc-editor.org/rfc/rfc9113
• IETF. RFC 9293. Transmission Control Protocol (TCP). https://www.rfc-editor.org/rfc/rfc9293
• IETF. RFC 9846, TLS 1.3, 2026. https://www.rfc-editor.org/info/rfc9846
• ITU-R. Report M.2460-0: Key elements for integration of satellite systems into Next Generation Access Technologies. 2019. https://www.itu.int/pub/R-REP-M.2460
• ITU-T. G.9807.1: 10-Gigabit-capable Symmetric Passive Optical Network (XGS-PON). https://www.itu.int/rec/T-REC-G.9807.1/en
• ITU-T. G.984.3: Gigabit-capable Passive Optical Networks (G-PON): Transmission Convergence Layer Specification. https://www.itu.int/rec/T-REC-G.984.3/en
• ITU-T. G.992.5: Asymmetric Digital Subscriber Line 2 Transceivers — Extended Bandwidth ADSL2 (ADSL2plus). https://www.itu.int/rec/T-REC-G.992.5/en
• ITU-T. G.993.2: Very High Speed Digital Subscriber Line Transceivers 2 (VDSL2). https://www.itu.int/rec/T-REC-G.993.2/en
• James F. Kurose, Keith W. Ross. Computer Networking: A Top-Down Approach, 8th Edition. Pearson, 2021.
• Jeffrey Dean et al. “Large Scale Distributed Deep Networks.” Advances in Neural Information Processing Systems, 25, 2012.
• Lewis Van Winkle. Hands-On Network Programming with C. Packt, 2019.
• Mor Harchol-Balter. Performance Modeling and Design of Computer Systems: Queueing Theory in Action. Cambridge University Press, 2013.
• NIST. FIPS 203, FIPS 204 and FIPS 205: Post-Quantum Cryptography Standards. https://csrc.nist.gov/
• NIST. SP 800-207: Zero Trust Architecture. https://csrc.nist.gov/pubs/sp/800/207/final
• OpenConfig. gRPC Network Management Interface (gNMI) Specification. https://openconfig.net/docs/gnmi/gnmi-specification/
• Wendell Odom. CCNA 200-301 Official Cert Guide, Volumes 1-2. Cisco Press.
• WireGuard. WireGuard Documentation. https://www.wireguard.com/
• Zeynep Yüksel. Ağ Güvenliği ve Güvenlik Duvarında VPN ve NAT Uygulamaları. Yıldız Technical University, master's thesis, 2007.
• Dhruba Kumar Bhattacharyya; Jugal Kumar Kalita. Network Anomaly Detection: A Machine Learning Perspective. CRC Press, 2014. https://www.routledge.com/Network-Anomaly-Detection-A-Machine-Learning-Perspective/Bhattacharyya-Kalita/p/book/9780429166877