Routing and the Control Plane

A router makes a local decision for every arriving datagram: which output link should carry it next? The data plane performs that lookup using the forwarding table. The control plane determines the table’s contents, using information about destinations and the network beyond the router.

Two ways to organize control

With per-router control, each router runs routing software and exchanges messages with other routers. OSPF and BGP use this arrangement. With logically centralized control, network-control software obtains a network-wide view and uses a controller to install forwarding rules in devices. This is the SDN approach. “Logically centralized” describes the control service seen by its users; the service can run on several physical servers.

Forwarding is a fast local operation, often implemented in hardware. Routing responds on a slower timescale to changes in connectivity, costs, and policy. A datagram does not wait for a new end-to-end route calculation at every hop. It follows the entries already installed.

Represent the network as a weighted graph

In a graph $G=(N,E)$, nodes are routers and edges are links. A directly connected pair has link cost $c(x,y)$. A missing direct link has cost $\mathrm{\infty }$. For the worked graphs, costs are symmetric: $c(x,y)=c(y,x)$. The operator chooses what cost represents: link speed, delay, money, or another useful measure.

Add the costs along a path. If A–B costs 3 and A–C and C–B each cost 1, the direct path costs 3 while A–C–B costs 2. A sends traffic for B to C. Counting links would give the wrong decision here; hop count equals path cost only when every link has cost 1.

Classify the algorithm by its information

A global algorithm uses complete topology information. This does not require a single computer: OSPF runs a global link-state algorithm independently in each router. A decentralized algorithm builds its answer through local exchanges, as distance-vector routing does.

Other classifications describe when routes change. Static routes change slowly, often through manual edits. Dynamic protocols react to network changes. Load-sensitive costs follow current congestion; load-insensitive costs do not. OSPF and BGP are dynamic protocols whose ordinary route metrics do not track moment-to-moment load.

Connect routing to forwarding

An algorithm is the computation; a protocol supplies message formats, timers, and exchange rules. Dijkstra’s algorithm is a computation. OSPF is a protocol that supplies its input.

The final forwarding entry maps a destination prefix to an outgoing link. Each router chooses its own next hop, so the complete path emerges from the routers’ tables. During convergence, inconsistent tables can create loops; TTL eventually removes a looping IPv4 datagram. Between organizations, a good route must also satisfy policy: an operator can reject a low-cost path because it would carry traffic the operator has not agreed to carry.

In link-state routing, each router describes its attached links and floods that description through the network. Once the databases agree, every router has the same graph. Each router runs Dijkstra’s algorithm with itself as the source, so the shared input produces a different rooted tree at each router.

Keep tentative and final costs separate

For source $u$, $D(v)$ is the cheapest cost to $v$ found so far, and $p(v)$ is its predecessor on that path. The set $N^{\mathrm{\prime }}$ holds routers whose least costs are final. Start with the source in that set, its direct neighbors at their link costs, and all other routers at infinity.

At each iteration, choose the smallest tentative cost outside $N^{\mathrm{\prime }}$ and add that router, $w$, to the set. For each neighbor $v$ still outside, compare the existing estimate with a route through $w$:

If the second route is cheaper, record $w$ as the predecessor. Nonnegative link costs make this finalization safe. A value that has merely been updated is still tentative until its router joins $N^{\mathrm{\prime }}$.

Work from router A

Use these links: A–B 3, A–C 1, B–C 1, B–D 4, C–D 6, C–E 2, D–E 1, D–F 3, and E–F 5. Initially B has cost 3, C has cost 1, and D, E, and F have infinite cost.

For example, adding E changes D because $3+1=4$ is below 6. D was updated twice before it became final. Taking its first estimate of 7 as the answer would miss both improvements.

Recover paths and first hops

Follow predecessors backward: F ← D ← E ← C ← A. Reverse that sequence to obtain A–C–E–D–F. Its cost is $1+2+1+3=7$. The final costs from A are B 2, C 1, D 4, E 3, and F 7.

A forwarding table stores the first hop, not the predecessor of the destination. Every path in this example starts A–C, so A’s next hop is C for all five destinations. The predecessor of F is D, but D is not A’s next hop.

Equal costs, work, and changing load

If two candidates tie for smallest cost, either can be finalized first. The least costs stay the same, although a single chosen path can differ. OSPF can preserve multiple equal-cost paths for load sharing.

The simple algorithm scans candidates at each of its $n-1$ iterations, giving $O(n^2)$ running time; a priority queue can improve this. Link-state flooding also consumes messages because changed link information must reach every router in its flooding scope.

Load-sensitive costs can create feedback. All routers see a lightly loaded path, move traffic to it, and make it expensive; the next calculation moves traffic back. Load-insensitive costs avoid this particular feedback. Randomizing calculation times can also reduce synchronized switching; routers that start at different times can otherwise drift into step.

A router can learn useful paths without learning the entire graph. In distance-vector routing, it knows its attached-link costs and the latest cost estimates received from each neighbor. It uses those estimates to build its own distance vector, a list of estimated costs to all destinations.

Add the first link to the neighbor’s estimate

For a destination $y\mathrm{\ne }x$, the Bellman–Ford equation is

Try every neighbor $v$. Add the cost of reaching that neighbor to the neighbor’s cost to the destination, then choose the smallest total. The minimizing neighbor becomes the next hop. The cost from a router to itself stays 0; it is not replaced by a route through a neighbor.

During the exchange, routers use estimates $D$ in place of the final distances $d$. These estimates can change as information travels farther through the network.

Start, receive, recompute, advertise

At startup, a router records 0 to itself, direct-link costs to neighbors, and infinity to other destinations. It sends that vector to its neighbors. A new vector from a neighbor or a change to a local link triggers recomputation. If the router’s own vector changes, it advertises the new vector; otherwise it has no changed estimate to pass on.

The process is distributed, iterative, and asynchronous. Routers need not update in matching rounds. Information can still reach distant routers because each neighbor’s revised estimate becomes input to another calculation.

Compute a three-router example

Links A–B 4, B–C 1, and A–C 7 give these starting vectors, ordered by destination A, B, C:

After hearing B, A compares its two routes to C:

It chooses B as next hop. C makes the matching calculation for A and obtains 5 through B. Another exchange leaves the vectors unchanged. With fixed link costs and correct operation, the routers have converged.

A’s forwarding entries are “B → B, cost 4” and “C → B, cost 5.” A knows that B advertises a cost of 1 to C. It does not need B’s complete path or a drawing of the links beyond B.

How RIP supplies the protocol

The Routing Information Protocol (RIP) implements distance-vector routing with hop count. Each link costs 1, the largest usable path is 15 hops, and 16 means unreachable. RIP sends periodic updates every 30 seconds over UDP port 520. A route that has not been refreshed for 180 seconds expires.

Periodic messages belong to the protocol; the underlying algorithm’s changed-vector rule describes when there is new information to propagate. RIP also uses triggered updates to send changes sooner. Confusing these levels can lead to the claim that a stable RIP router sends no messages at all.

Distance-vector estimates are not calculated once and then frozen. A neighbor’s new claim can change the preferred next hop even when every local link stays unchanged. Conversely, receiving a message need not change the router’s own vector if none of the new totals improves or replaces its selected routes.

A distance-vector update can describe a path that depends on the router receiving it. Without that dependency being visible, two routers can each believe the other has a usable route. This is why an increase in link cost can be harder to spread than a decrease.

A cheaper link spreads quickly

Let A–B cost 2, B–C cost 1, and A–C cost 20. B reaches A directly at cost 2; C reaches A through B at cost 3. If A–B falls to 1, B advertises 1 and C changes its cost to 2. When C advertises 2 back, B keeps its direct route. The improvement settles after these two changed updates.

An expensive link exposes stale information

Now start again from costs 2, 1, and 20, and raise A–B to 40. B still has C’s earlier advertisement of 3 to A. It chooses C because $1+3=4$ is below 40. C still sends to B. Datagrams for A now bounce between B and C until their TTL expires.

C hears B’s cost 4 and computes 5. B hears 5 and computes 6. The estimates keep rising even though neither is describing an independent path to A. This is count-to-infinity: bad news advances through a chain of misleadingly small estimates.

Here an alternative eventually breaks the loop. When B advertises 20, C compares its direct cost 20 with 21 through B and selects its direct link. B then settles at 21 through C. Without a usable alternative or a finite infinity value, the counting can continue much longer.

Advertise the dependency with poisoned reverse

With poisoned reverse, a router tells the neighbor it uses for a destination that its distance to that destination is infinite. Initially C uses B to reach A, so C advertises infinity to B. B can no longer mistake C for an independent alternative.

After the cost increase, B therefore chooses its direct cost 40. C hears 40 and selects its direct link at cost 20. C can now advertise 20 to B, and B chooses cost 21 through C. The advertised value depends on the recipient: C can report its real cost to other neighbors while poisoning the route toward B when B is its next hop.

Split horizon omits such a route from the update instead of advertising infinity. Poisoned reverse prevents this two-router dependency loop, but longer loops can still occur. Triggered updates speed the spread of changes. RIP also defines infinity as 16, limiting both counting time and usable network size.

Compare the two routing families

A full link-state dissemination round has message work on the order of $n\cdot e$ for $n$ routers and $e$ links. The simple local calculation is quadratic. Distance-vector message work depends on how many successive estimates change; neighbor-only communication does not guarantee quick convergence.

OSPF and IS-IS use link-state routing. RIP uses distance vectors. BGP is a related path-vector protocol: its advertised AS sequence exposes dependencies and lets routers reject paths containing their own AS number.

The Internet is too large and too independently managed to treat every router as a node in one flat routing system. Each organization needs control of its own internal network while still offering usable routes to other organizations. Autonomous systems provide that division.

Identify the administrative boundary

An autonomous system, or AS, is a group of routers under one administration that presents a coherent routing policy to the outside. Public AS numbers, or ASNs, identify these systems globally. Regional Internet registries distribute AS number resources. The original number space was 16 bits, up to 65,535; modern ASNs use 32 bits.

An AS is a routing domain, while an ISP is a business. A university or content provider can operate an AS, and one ISP can operate several. Treating those terms as interchangeable hides the actual policy boundaries.

Use different protocols for different jobs

An interior gateway protocol (IGP) supplies internal routes. Within a routing domain, routers use a common IGP so they can exchange the information it needs. Different ASes can choose different IGPs. A provider using IS-IS can connect to a university using OSPF because their external routing exchange uses BGP.

The hierarchy serves two needs. It reduces the amount of worldwide detail that internal routers must process, and it preserves administrative autonomy. A local link change does not need to expose the complete internal topology to every other AS.

Combine an exit choice with an internal path

A gateway router connects to another AS. For an external destination, BGP identifies a usable route and its next-hop gateway address. The internal protocol supplies the path toward that address. These decisions combine to produce the forwarding entry used for an arriving packet.

Suppose router R learns that 198.51.100.0/24 is reachable through gateway G. OSPF says the path from R to G begins through neighbor H. R’s forwarding entry for the external prefix uses the link to H. G is the exit from the AS, while H is R’s immediate next hop; those roles need not belong to the same router.

Recognize when one exit is enough

A small customer with one external connection has no choice of exit. A default IPv4 route, 0.0.0.0/0, can send external traffic toward that connection. Learning every Internet route would not create an alternative exit.

With several gateways, reachability information matters: one gateway may offer a prefix that another does not, or policy may favor one provider. BGP distributes the route choices; the IGP still carries packets to the chosen exit.

Inside one AS, one operator can choose link costs to meet internal performance goals. Across ASes, cost competes with agreements about paid transit, peers, and which traffic an operator will carry. This is why choosing an Internet route involves more than extending a shortest-path calculation across the next administrative boundary.

Open Shortest Path First (OSPF) is a link-state IGP. Each router learns the topology within its area, runs Dijkstra’s algorithm from itself, and derives routes to subnets. OSPFv2 serves IPv4; OSPFv3 was designed for IPv6.

Choose costs and discover neighbors

The operator sets link weights. All weights equal to 1 produce minimum-hop routes. An illustrative inverse-speed rule with a 10 Gbit/s reference is

It gives weights 1, 10, and 100 for 10 Gbit/s, 1 Gbit/s, and 100 Mbit/s links. Weight is a configured routing measure, not a distance in kilometers.

Hello packets discover and maintain neighbors. A common LAN setting sends Hellos every 10 seconds and uses a 40-second dead interval. Missing a single Hello is therefore different from declaring the neighbor dead. Neighboring routers synchronize databases using Database Description packets, Link State Requests, Link State Updates, and Link State Acknowledgments. Routers with synchronized databases form an adjacency.

Flood fresh link descriptions

A link-state advertisement (LSA) describes routing information. A router-LSA records a router’s links and costs. LSAs travel in Link State Update packets; an LSA is the advertised information, not the name of every OSPF packet.

Changed links trigger fresh advertisements. Routers also refresh their own LSAs at least every 30 minutes. An LSA at the maximum age of one hour is removed. Sequence information and age let routers distinguish fresh descriptions from old ones.

OSPF is carried directly in IP using protocol number 89. It supplies acknowledgments and retransmissions itself. On broadcast networks, 224.0.0.5 reaches all OSPF routers and 224.0.0.6 reaches the designated routers.

Reduce LAN adjacencies

A LAN elects a designated router (DR) and a backup designated router (BDR). Other routers form full adjacencies with those two, instead of every pair becoming adjacent. The DR advertises the shared LAN in a network-LSA.

For six routers, a full mesh would need $6\times 5\mathrm{/}2=15$ adjacencies. Four ordinary routers each connect logically to the DR and BDR, plus one DR–BDR adjacency: $4\times 2+1=9$. Neighbors can hear one another without all becoming fully adjacent.

Recalculate after a failed link

Consider links A–B 3, A–C 1, B–C 1, B–D 4, C–D 6, C–E 2, D–E 1, D–F 3, and E–F 5. A initially reaches E at cost 3, D at 4, and F at 7 through C and E.

When C–E fails, C and E flood new router-LSAs that remove the link. Recalculation gives A costs B 2, D 6, E 7, and F 9. The paths to D and F now use C–B–D. A’s first hop still stays C: a changed complete path does not require a changed first forwarding hop.

OSPF supports authenticated routing messages and equal-cost multipath (ECMP). Cryptographic authentication is stronger than a plain-text password; it checks authorized message origin and integrity. ECMP lets a router retain multiple equal-cost paths. These features operate on link-state information, not on exchanged tables of estimated destination distances.

A router in a large AS need not process every internal link as part of one detailed graph. OSPF areas divide the link-state database and shortest-path work. Routers retain local detail and learn routes describing destinations beyond their own area.

Connect areas through the backbone

The backbone is area 0, also written 0.0.0.0. Other areas attach to it. Traffic between two non-backbone areas travels to the backbone and then into the destination area.

An area border router (ABR) connects areas, including the backbone. It keeps a separate database for each attached area and advertises routes between them. Information about a remote subnet can cross the boundary without exposing all the remote area’s routers and links. Summarization can also combine suitable prefixes; it does not require every remote subnet to disappear into one aggregate.

An AS boundary router (ASBR) introduces routes from outside OSPF’s domain, such as routes learned from another AS. An ABR crosses an area boundary; an ASBR introduces external routing information. One device can hold both roles.

Match advertisements to their purpose

Types 1 and 2 describe the detailed area graph. Types 3 and 4 carry inter-area reachability information. Type 5 normally spreads through the AS, with special area types restricting external advertisements.

Trace an inter-area packet

A host’s packet starts in area 7 and is destined for area 9. It first follows routes inside area 7 to an ABR, crosses area 0 to an ABR attached to area 9, and then follows routes inside area 9. This is a hierarchy inside one AS; crossing an area boundary does not turn the packet into inter-AS traffic.

An internal router has all interfaces in one area. A backbone router has at least one interface in area 0. An ABR is also a backbone router, so the role names are not mutually exclusive.

Understand what a local failure changes elsewhere

Dividing roughly 400 routers into four areas of about 100 can greatly reduce each router’s detailed graph, while adding inter-area routes. The exact database size also depends on border routers and advertised networks.

If a link repeatedly fails inside one area, its detailed LSAs and full shortest-path recomputation stay in that area. If the change also alters a destination’s advertised cost or reachability, the ABR sends changed summaries. Routers elsewhere update the affected inter-area routes. Areas therefore limit the detail and computation that spread; they do not hide every effect of a failure.

Less detail has a cost. An inter-area route follows the area hierarchy and may differ from the globally least-cost route through a flat graph of the entire AS. The operator gains smaller databases and more contained changes while giving up some freedom in path choice.

BGP-4 exchanges reachability for destination prefixes. An advertisement says that the announcing network offers a route toward that prefix. Other networks can accept it, rank it against alternatives, or refuse it according to policy.

Establish a session

BGP speakers exchange messages over a long-lived TCP connection using port 179. eBGP joins speakers in different ASes; iBGP joins speakers in the same AS. Internal sessions distribute external reachability within the AS, and need not correspond to direct physical links.

The basic iBGP design uses a full mesh between BGP speakers. Larger networks can use route reflectors to reduce the number of sessions. iBGP does not replace the IGP: the IGP still supplies internal paths needed to reach BGP next hops.

Add the AS number as a route travels outward

AS 64503 originates 203.0.113.0/24. Its advertisement to AS 64502 has AS-PATH “64503.” AS 64502 distributes the route internally over iBGP, then advertises it to AS 64501 with AS-PATH “64502 64503.” External propagation prepends the advertising AS’s number; ordinary internal distribution does not add another copy of that number.

A BGP route pairs the prefix with attributes. AS-PATH records the sequence of ASes, most recent first. NEXT-HOP identifies the router address toward which traffic should be sent, normally an interface at the neighboring gateway. An internal speaker uses the IGP to resolve a path to that address.

Reject an AS-level loop

A speaker rejects a route whose AS-PATH contains its own AS number. If AS 64501 receives “64502 64501 64503,” accepting it would send traffic along an AS sequence that returns to 64501. Carrying this dependency makes BGP a path-vector protocol and avoids the plain distance-vector count-to-infinity problem.

An AS path is not a list of every router on the packet path. Two AS hops can include many physical links, and policies can select a longer AS path. Its length alone says little about measured delay.

Interpret the basic messages

The standard suggests a hold time of 90 seconds and keepalives every 30 seconds. Negotiated settings can differ. A speaker withdraws routes learned over a session when that session fails; keeping a TCP connection open is different from proving that every advertised destination works.

After the initial exchange, BGP sends incremental changes instead of periodically sending the complete table. Rate limiting can reduce repeated announcements for one prefix; the standard suggests 30 seconds between such eBGP advertisements.

TCP provides ordered delivery between the two speakers. BGP’s own attributes, policy rules, and update processing determine which routes are retained and propagated. Reliable transport by itself supplies no proof that a neighbor is entitled to originate the advertised prefix.

Several gateways may offer a route to the same prefix. A BGP speaker first applies import policy, then compares accepted, usable routes in a defined order. It stops at the first decisive difference; a later advantage cannot undo an earlier preference.

Compare attributes in order

1. Prefer the highest LOCAL_PREF, set by the local operator.
2. Prefer the shortest AS-PATH.
3. Prefer the lowest ORIGIN value: IGP, then EGP, then INCOMPLETE.
4. Prefer the lowest MED among routes from the same neighboring AS.
5. Prefer an eBGP-learned route over an iBGP-learned route.
6. Prefer the lowest IGP cost to the NEXT-HOP.
7. Prefer the lowest advertising BGP identifier when earlier comparisons tie.

Router implementations can add steps such as vendor-specific local weight. LOCAL_PREF is distributed inside the AS and stays there. MED lets a neighboring AS suggest a preferred entry point; MED values from unrelated neighboring ASes are not compared by the ordinary rule.

Compare two exits

R in AS 64501 learns two routes over iBGP to 203.0.113.0/24. G1 offers AS-PATH “64502 64503” at IGP cost 3; G2 offers “64504 64503” at IGP cost 5. Both have LOCAL_PREF 100 and equal ORIGIN. The paths each contain two ASes. MED does not choose between these different neighboring ASes, and both routes are internal advertisements.

The IGP cost therefore decides: R chooses G1 because $3<5$. This is hot-potato routing: send traffic out through the least costly internal exit among otherwise equal routes.

If routes through AS 64504 receive LOCAL_PREF 200, G2 wins immediately. Its higher internal cost no longer matters. With equal LOCAL_PREF, a path containing only “64503” would beat both two-AS paths before hot-potato routing was considered.

Resolve the winning next hop

BGP has chosen a route through G1, but R may have no direct link to G1. OSPF supplies the least-cost internal path to that next-hop address. If the path starts on interface I, the forwarding entry becomes “203.0.113.0/24 → I.” The decision needs both protocols: BGP selects external reachability, and the IGP resolves internal delivery toward it.

Different internal routers can have different costs to G1 and G2, so otherwise equal BGP choices can lead them to use different exits. Independent policies at the other end can also make the reverse packet path different from the forward path. Internet routing is often asymmetric.

Apply the same selection to anycast

With IP anycast, multiple service locations advertise the same prefix. Routers choose among the advertisements through ordinary BGP selection. A client reaches the instance preferred by routing policy, AS path, and internal costs, which need not be the geographically closest instance.

This works well for short exchanges such as DNS queries. A routing change during a long TCP connection can send later packets to another instance that lacks the connection’s state.

Advertising a route is an invitation to send traffic toward it. An operator’s export policy therefore determines which traffic the network offers to carry. Customer, provider, and peer relationships explain the usual rules.

Distinguish transit from peering

A customer pays a provider for transit to and from the rest of the Internet. Two peers exchange traffic for themselves and their customers, often without settlement payments. Networks often establish peering at an Internet exchange point (IXP).

Peering usually does not provide a route to everything the peer can reach through its own providers. That wider service is transit. A peer relationship describes an agreement about traffic, not simply a physical cable between routers.

Separate import and export decisions

Import policy chooses which received advertisements to accept and what preference to assign them. Export policy chooses which routes to advertise to each neighbor. A route can be accepted and used locally without being offered to every other neighbor.

Usual import preferences favor customer routes, then peer routes, then provider routes. LOCAL_PREF can encode that order. Customer traffic earns revenue, peer traffic usually avoids transit charges, and provider traffic incurs transit cost. This preference can outweigh AS-PATH length.

Apply the usual export rules

An AS also advertises its own destinations according to its agreements. The table describes the common commercial pattern; operators implement policy through explicit filters and preferences.

Advertising a customer route widely attracts traffic toward the paying customer. Restricting peer- and provider-learned routes to customers avoids offering unpaid transit between outside networks. The relevant direction is where the route was learned and to whom it will be advertised, not which direction one packet happens to travel.

Follow a multihomed customer

Customer X, AS 64510, has providers B and C. X announces its own prefix to both for reachability and resilience. It accepts routes from both, but keeps a route learned from B out of advertisements to C. It also keeps C’s routes out of advertisements to B. Otherwise one provider could send traffic through X to destinations behind the other provider.

For a peer example, A and B are peers and W is A’s customer. B can use the route “A W” and export it to B’s customers. B withholds that peer-learned route from another peer C. Exporting it to C would offer transit between peers through B.

Inside one AS, a single operator can optimize internal costs. Between ASes, independent operators control price, traffic obligations, and acceptable counterparties. A missing advertisement can be an intentional refusal to carry traffic, even when a physical path exists.

Basic BGP advertisements do not prove prefix ownership or authenticate the complete AS-PATH. An incorrect announcement can spread through many networks unless policy and validation stop it. Two important failures are prefix hijacks and route leaks.

Recognize what goes wrong

A prefix hijack announces an unauthorized prefix or a more specific part of someone else’s prefix. Routers accepting the route can send traffic toward the wrong origin. Once routes for different prefix lengths are installed, forwarding uses longest-prefix matching. A /24 route inside a /22 wins for matching addresses, even if the /22 has a shorter AS-PATH. BGP comparisons between routes to one prefix and forwarding comparisons between different prefixes are separate decisions.

A route leak exports a route beyond its intended policy boundary. For example, a customer passes provider-learned routes to another provider and becomes an unintended transit network. The prefix origin can be legitimate while the propagation is wrong.

Learn from a real incident

On February 24, 2008, Pakistan Telecom, AS 17557, announced 208.65.153.0/24 as part of a domestic YouTube block. Its provider propagated that more specific route internationally. Much of the traffic for those YouTube addresses was drawn toward Pakistan.

The widely visible incident ran from 18:47 to 21:01 UTC, a little over two hours. YouTube announced the /24 itself and then two /25 prefixes while trying to recover traffic. The incident ended when the provider withdrew the false route. A locally intended change had become an international reachability failure because export filtering failed.

Filter before a mistake spreads

A provider can accept only the prefixes a customer is authorized to originate. A maximum-prefix limit can stop a session that suddenly announces far more routes than agreed. Many networks also filter IPv4 prefixes longer than /24 and IPv6 prefixes longer than /48. Such filters limit what advertisements spread; a technically more specific route has an effect only where it is accepted.

Check the authorized origin with RPKI

The Resource Public Key Infrastructure (RPKI) lets address holders publish signed Route Origin Authorizations (ROAs). A ROA names the allowed origin ASN, a prefix, and the maximum allowed prefix length.

Suppose AS 64503 is authorized for 203.0.113.0/24 with maximum length /24:

If several validated authorizations cover a route, one matching origin and length authorization makes it valid. With covering authorizations but no match, the route is invalid. Networks choose how to act on these states; rejecting invalid routes blocks many unauthorized origins. “Not found” means an authorization is absent, not that a wrong origin has been demonstrated.

Origin validation checks the final origin ASN, not every transit AS or the export relationship. Forging a path that ends with an authorized origin can therefore pass this check, and a leak can retain a valid origin. BGPsec adds path-signing mechanisms, but origin validation, route filters, and monitoring remain distinct defenses.

Software-defined networking (SDN) separates packet forwarding from the software that decides network behavior. Switches apply flow rules, while applications use a controller to read network state and install the rules they need. The arrangement makes control programmable.

Identify the three components

Data-plane switches perform match-plus-action forwarding. A flow can match fields from several layers, including Ethernet addresses, IP addresses, and transport ports. Actions can forward, drop, modify, or send a packet to the controller.

The controller maintains network state and communicates with devices. Network-control applications make decisions, such as computing a route or choosing a load-balancing rule. A routing application can still use Dijkstra’s algorithm. SDN changes the location and interfaces of control, without requiring a new shortest-path method.

The defining features work together: flow-based forwarding, separate control and data planes, control functions outside switches, and software applications that program network behavior.

Follow the controller’s layers

The southbound interface connects the controller to devices. OpenFlow is a well-known example; management protocols such as SNMP and NETCONF can also support device communication. The northbound interface connects applications to the controller, often through a REST API. “North” and “south” describe software roles, not physical positions in a network rack.

Distinguish logical from physical centralization

Applications see a coherent controller service with a network-wide view. That service can run on one server or a replicated cluster. A cluster can share load and continue after one server fails, provided its state sharing and failover work correctly. Logical centralization does not require one physical machine.

A single-server controller is a single point of failure for its control service. Replication reduces that exposure but leaves the controller a critical part of the network. Applications depend on an accurate view of the topology to produce useful rules.

Trace a routing request

Suppose a controller records the available links between four switches. A routing application reads that topology through the northbound API and computes a least-cost path. It asks the controller to install the corresponding forwarding entries. The controller translates the request into southbound messages to the affected switches. Later packets follow those installed entries locally.

Changing a routing application can therefore change network behavior without changing each switch’s built-in routing software. The same forwarding hardware can support routing, access control, or load balancing according to the installed rules.

SDN is used within organizational networks such as data centers and private wide-area networks. Google’s B4 is an example of centralized control for a private network connecting data centers. ONOS and OpenDaylight are examples of open-source controller platforms. At boundaries between independent networks, BGP still exchanges reachability; SDN control inside an AS and BGP between ASes can operate together.

OpenFlow carries commands and events between a controller and switches. It uses TCP, with registered port 6653, and can protect the connection with TLS. The controller needs both ways of communicating: it changes forwarding state and receives evidence that the state or topology has changed.

Read a flow entry

A flow entry has match fields, a priority, counters, actions, and timeouts. In a table, the highest-priority matching entry controls the packet’s handling. A broad match can therefore lose to a more specific rule with a higher priority.

In OpenFlow 1.3, a lowest-priority table-miss entry can handle a packet that matches no ordinary entry. Its action can send the packet to the controller. With no table-miss entry, an unmatched packet is dropped by default. A miss alone does not require a packet-in message.

Match messages to their jobs

Flow-mod and port-mod are both ways to modify switch state, but only flow-mod edits forwarding entries. Packet-out handles a particular packet; it does not by itself install a rule for later packets.

Repair paths after a failure

Take switches S1 through S4. The S1–S2 link fails while another route through S3 and S4 remains available.

1. S1 detects its port going down and sends port-status.
2. The controller removes the failed link from its network-state view.
3. The routing application receives the event through its northbound subscription.
4. The application recomputes paths on the revised topology.
5. A flow-table computation component turns those paths into switch rules.
6. The controller sends flow-mod messages to the switches whose entries must change, such as S1, S3, and S4.

The reporting switch supplies an event; it does not compute a network-wide repair on its own. The application also needs rules installed at the affected switches, not just a new path stored in the controller.

Install before traffic or react to its first packet

With proactive installation, entries are ready before packets arrive. With reactive installation, a configured action sends a new flow’s first packet to the controller in packet-in. The controller can arrange a rule and use packet-out when it needs to release a packet.

Reactive setup adds delay to the first packet and work for the controller. Once the entry exists, subsequent matching packets stay in the data plane. The controller handles selected events and packets, not every packet in every flow. Expiring entries can later generate flow-removed notifications, letting applications track changes to installed state.

ICMP carries network-layer reports and tests inside IP datagrams. ICMPv4 uses IPv4 protocol number 1. Its messages have a type, a code, and a checksum. The type gives the broad purpose; the code refines it.

Connect an error to the packet that caused it

An ICMPv4 error includes the original IP header and at least the first 8 bytes of the original payload. That quotation usually supplies the transport information needed to identify the affected flow. The error goes toward the original sender, which can then relate the report to a packet it sent.

Type 4, source quench, is deprecated and is not a modern congestion-control mechanism.

Work from the failure to its report

A router that reduces TTL to 0 discards the datagram and reports time exceeded. A router with no route can report network unreachable. A destination host receiving UDP for an unused port can report port unreachable. These are different failures: reaching the host does not guarantee reaching a listening application.

ICMP errors are not reliable delivery receipts. Filtering, message loss, or rate limiting can prevent a report from reaching the sender. An unanswered test therefore leaves several possible explanations.

IPv4 suppresses errors about another ICMP error, about broadcast or multicast traffic, and about fragments other than the first. These rules prevent error cascades and excessive replies. Devices also rate-limit error generation.

Distinguish ICMPv6

ICMPv6 uses IPv6 next-header value 58. Its error types are 1 destination unreachable, 2 packet too big, 3 time exceeded, and 4 parameter problem. Echo request and reply are types 128 and 129. Neighbor Discovery also uses ICMPv6 and takes over IPv6’s neighbor-resolution role from ARP.

IPv6 error rules include multicast exceptions: Packet Too Big can be sent in response to a multicast packet, and certain unknown-option errors can be as well. Applying IPv4’s blanket multicast suppression to ICMPv6 would break required behavior.

Follow path MTU discovery

For classic IPv4 path MTU discovery, the sender sets Don’t Fragment. A router that meets a smaller outgoing-link MTU drops an oversized datagram and returns type 3, code 4, reporting the next-link MTU. The sender can reduce the size of later packets.

For example, an IPv4 datagram of 1,500 bytes reaches a link with MTU 1,400 bytes while Don’t Fragment is set. The router drops it and reports fragmentation needed with MTU 1,400. The sender adjusts its IP packet size; the 1,400-byte value includes the IP header, so it is not the maximum application payload.

IPv6 routers never fragment forwarded packets. They return Packet Too Big so the source can adjust. Blocking all ICMP removes this feedback and can create a path MTU black hole: small packets work while larger ones disappear. Selective filtering preserves the messages needed for network operation.

Ping asks a target to reply. Traceroute uses probes that expire at successive hops to find responding routers along the forward path. Both report round-trip measurements, which combine outward travel, reply generation, and return travel.

Read a ping result

For IPv4, ping sends echo requests, type 8 code 0, and receives echo replies, type 0. Each successful exchange provides an RTT. If three of four probes receive replies, one of four is unanswered: the observed loss is 25%.

A reply establishes that an exchange with the target worked at that time. No reply can mean a failed target or path, but it can also mean filtered or rate-limited echo messages. Ping tests these messages, not every application protocol that might use the host.

Reveal successive hops with limited TTL

Traceroute first sends a probe with TTL 1. The first router decrements it to 0, discards it, and can return ICMP time exceeded. TTL 2 reaches the next router before expiring. Increasing TTL repeats this process farther along the path. The source records the address and elapsed time for each reply.

Classic Unix traceroute uses UDP probes to unlikely destination ports, starting at 33434. At the destination, port unreachable signals arrival. Windows tracert uses echo requests and recognizes an echo reply at the destination. Three probes at each TTL are common; separate probes can follow different load-balanced paths.

Interpret a complete trace

The destination answers at hop 5. The measured RTT rises by $95-12=83$ ms from hop 3 to hop 4 and remains high afterward. That is consistent with a slower or longer segment near that point, but the subtraction is not the one-way delay of the intervening link. The replies are different packets, may use different return paths, and include different processing and queuing delays. No link length follows from these RTTs alone.

Explain silence and unusually high middle-hop RTTs

A line reading “* * *” means the probes at that TTL received no timely reply. If later hops answer, packets are getting farther through the network. The silent router may forward normally while suppressing its own ICMP replies.

A middle router can also show a higher RTT than later routers. Creating an ICMP reply can receive lower priority than forwarding traffic, so one slow control-plane response does not establish a slow forwarding link. Persistent increases that continue to later hops deserve different attention from an isolated spike.

Keep the path’s limits in view

Traceroute reveals responding router interfaces, not a list of AS numbers. Mapping those addresses to the networks announcing them is an extra step. The trace also leaves the return path unshown, although that return path contributes to every RTT. Routing policies and hot-potato choices can make the reverse direction follow different networks, so a separate reverse trace can tell a different story.

Network management connects an operator’s goals to device observations and changes. Its framework has five parts: a managing server, managed devices, the devices’ data, agents that expose that data, and a protocol linking agents to the server.

Identify the objects and messages

SNMP, the Simple Network Management Protocol, usually uses UDP. Agents listen on port 161; managers receive notifications on port 162. GetRequest reads objects, GetNextRequest steps through their naming order, and GetBulkRequest reads many values efficiently. SetRequest changes writable objects. Response carries the result.

A trap is an unsolicited notification without an application-level acknowledgment. An InformRequest is acknowledged by the receiver. An agent can therefore report an event without waiting for the next monitoring poll.

A Management Information Base (MIB) defines managed objects in modules using the SMI data-definition language. Each object has an object identifier (OID) in a worldwide naming tree. The OID identifies a defined object; the agent supplies its current value.

For example, sysUpTime, OID 1.3.6.1.2.1.1.3, measures time since the device’s management system restarted. ifInOctets, OID 1.3.6.1.2.1.2.2.1.10, defines per-interface received-byte counters. A table entry also needs its interface instance to identify which interface’s value is being read.

Calculate utilization from two polls

A 100 Mbit/s interface’s counter rises from 1,250,000,000 to 1,475,000,000 bytes over 60 seconds. First find the amount received:

Convert bytes to bits and divide by elapsed time:

Incoming utilization is $30\mathrm{/}100=0.30$, or 30%. A counter is a cumulative total, not a rate; the difference and elapsed time are both needed. Keeping bytes and bits separate prevents an eightfold error.

Recognize wraparound and restart

ifInOctets is 32-bit and wraps after $2^{32}$ bytes. At 1 Gbit/s, that takes about $2^{32}\times 8\mathrm{/}{10}^9\approx 34$ seconds. A 60-second interval can hide multiple wraps, so the two values alone cannot recover the traffic total. The 64-bit ifHCInOctets is suitable for fast interfaces.

When at most one wrap occurred and no reset occurred, add $2^{32}$ to a negative difference. A device or counter restart needs separate handling; treating every decrease as a wrap can create a false traffic spike.

Choose secure monitoring and structured changes

SNMPv1 and SNMPv2c use plain-text community strings. SNMPv3 supports authentication, encryption, and object-level access control; select the security settings that provide those protections.

SNMP is widely used for monitoring. One SetRequest validates its requested changes before applying them as a group on one device. If assignment fails, the agent tries to undo the changes; an undoFailed response reports that recovery itself failed. It does not create a transaction across multiple devices. Editing individual MIB objects is also cumbersome for large configurations. A CLI can be typed or scripted, but device-by-device text commands become harder to coordinate at scale; NETCONF offers structured configuration operations instead.

NETCONF reads and changes structured device configuration. YANG defines the structure, types, and constraints of the data being managed. The protocol moves and applies data; the model describes what that data means and which values are allowed.

Open a secure session and inspect capabilities

NETCONF normally runs over SSH using port 830; secure transport can also use TLS. Client and server exchange hello messages that announce supported capabilities. Requests and replies are XML-encoded remote procedure calls (RPCs).

Capabilities matter. A manager must discover support for candidate configuration, validation, or confirmed commit before relying on it.

Separate active, prepared, and boot configurations

The running datastore is active. A supported candidate datastore is a working copy for proposed changes, and a supported startup datastore holds the configuration loaded at boot. Editing candidate alone leaves running unchanged. A commit copies the prepared candidate into active use.

A lock prevents conflicting edits while the manager works. Validation checks the candidate’s rules; it does not establish that traffic will continue to behave as intended after activation.

Coordinate two devices without assuming one atomic commit

To change the MTU on a link between R1 and R2, the manager locks both candidates, sends edit-config to each, and validates both. If either validation fails, it discards both prepared changes and releases the locks before activation.

If validation succeeds, it commits on each device and checks the replies. The commits are separate: R1 can change before R2, or one commit can succeed while the other fails. The manager must detect this partial outcome and recover, for example by restoring the earlier configuration.

With confirmed commit, a device automatically reverses the change unless the manager confirms it within a set time. This helps when a new configuration cuts off management access. Each device still has its own operation and timer; confirmed commit does not make the pair a single network-wide transaction.

Use a model to reject an invalid value

A YANG module organizes data in containers, lists, and leaves. A leaf named mtu might have type uint16 and allowed range 68–65535. The value 40 violates the range, even though it fits the unsigned integer type. Model validation checks both type and constraints.

Tools can use YANG models to check NETCONF XML or RESTCONF JSON. Standard IETF interface models, vendor models, and OpenConfig models offer different data definitions. Streaming telemetry can push modeled state at intervals, complementing polling.

SNMP remains useful for monitoring individual objects. NETCONF supplies session-based configuration operations and device-level coordination primitives. Neither protocol alone guarantees that separate devices activate a network-wide change simultaneously.