1.3 Network Architecture and Device Planes

Separating decisions from forwarding

A router must learn where networks are, forward customer packets, and let an operator manage the device. These responsibilities form the control plane, data plane, and management plane. The distinction is functional: two planes may share a processor, while ordinary transit forwarding can use specialized hardware. For NRS I, classify an action by its purpose before identifying its hardware location.

An OSPF adjacency forms in the control plane. An arriving customer packet uses the data plane to select an outgoing interface. An SSH session used to inspect that adjacency belongs to management. All three may use the same physical network link, so a port does not permanently belong to one functional plane.

Control-plane state

On a modular 7750 Service Router, the Control Processing Module (CPM) hosts routing and management software. Routing protocols learn information and maintain their own databases. The routing table manager selects usable routes for each prefix from eligible candidates. The Routing Information Base (RIB) is a control-plane representation of routes; the forwarding structures derived from it are optimized for packet handling.

Do not confuse an OSPF Link-State Database with the route table. The database describes topology. SPF calculates paths from that topology. Route selection then determines which eligible routes become active. A static route can defeat an OSPF route for the same prefix because of route preference, even when the OSPF adjacency and database are healthy.

Control messages are packets too. A router must receive OSPF Hellos, TCP segments carrying BGP messages, and LDP signaling. Receiving these messages does not mean that every customer packet also passes through the control CPU.

Data-plane state

The Forwarding Information Base (FIB) contains forwarding decisions derived from selected routes, together with resolved next-hop information. It may contain multiple next hops for a prefix when Equal-Cost Multipath (ECMP) is enabled. Describing the FIB as “one next hop per prefix” would incorrectly exclude this ordinary feature.

On modular 7750 platforms, line-card forwarding engines use Nokia FP processing hardware. Input/Output Modules and their interface components provide packet processing and connectivity; the exact packaging depends on the chassis and card. The switch fabric carries traffic between forwarding modules. An Integrated Media Module combines functions that other cards separate.

For an ordinary Ethernet/IPv4 transit packet, forwarding work includes checking relevant headers, finding the longest matching destination prefix, resolving the adjacent next hop, decrementing TTL, and constructing the outgoing Ethernet frame. MPLS forwarding instead uses label entries for the active label stack. Filters and QoS policies may also inspect packet fields. Hardware forwarding is therefore more than a single destination-address lookup.

A packet walk

Suppose R1 learns 10.20.0.0/16 through R2 using OSPF. The control plane calculates and selects the route, then programs forwarding state. A customer packet for 10.20.4.9 arrives afterward:

1. The ingress forwarding engine identifies the packet and applicable service or routing context.
2. The FIB lookup selects the active /16 route, unless a more-specific installed prefix matches.
3. The forwarding entry resolves R2's adjacent interface and Layer 2 rewrite information.
4. The router applies the configured forwarding actions and transmits the packet.

The OSPF process does not run SPF separately for each arriving customer packet. If the link to R2 fails, control-plane convergence can change the programmed next hop. Until new state is available, packets may be dropped or use a preinstalled protection path. Separation improves performance; it does not promise uninterrupted delivery under every failure.

Management paths

In-band management reaches the router over production network links, often using a stable system-interface address. It shares some failure dependencies with the production network. A route failure can interrupt SSH even when the CPM itself is healthy.

Out-of-band management uses a separate management path, such as the CPM management Ethernet interface and a separate management network. A serial console is another recovery path with different dependencies. The out-of-band network needs its own working addressing, access controls, power, and connectivity. It cannot rescue a failed CPM or an inaccessible management network merely because it is separate from customer traffic.

Exception traffic and protection

Some received packets require local software processing rather than ordinary transit forwarding. Examples include management packets addressed to the router, routing-protocol messages, and selected forwarding exceptions. The precise handling depends on the platform and feature.

High volumes of such traffic can consume control resources. Hardware separation reduces CPU work associated with normal transit traffic, but it does not make a router immune to denial of service. Nokia provides CPM filtering and control-plane protection mechanisms to limit unwanted or excessive traffic. These controls need suitable configuration and capacity planning.

When diagnosing a failure, distinguish the symptoms. A healthy SSH session does not prove that a customer SAP forwards traffic. A failed ping to the router may reflect local filtering rather than a broken transit path. Check the relevant service, forwarding state, protocol state, and management path separately.

Primary reference

Nokia 7750 SR documentation, checked October 20, 2026. Hardware packaging and protection features depend on the chassis and release.