5.1 Nokia Service Router Hardware Architecture

Choose a router by its network role

Nokia's service-router portfolio spans customer access, aggregation, provider edge, and core roles. The important NRS I skill is explaining why a router appears at a particular point in a service-provider network. Product names are not substitutes for a network diagram: the same family can support several roles, and capabilities differ across models, installed cards, licenses, and software releases.

A Customer Edge (CE) device connects a customer site to a provider. A Provider Edge (PE) router terminates the customer's service and connects it to provider transport. A Provider (P) router primarily moves traffic across the core. These are architectural roles rather than unique hardware model names.

This table does not assert that every family has identical CLI engines, line cards, protocol features, or lifecycle status. The current NRS I course emphasizes the 7750 SR and uses MD-CLI exercises. Use that environment for practice rather than assuming every command works on every Nokia platform.

Understand a modular chassis

A modular router divides processing, connectivity, and interconnection among hardware components. A fault on one component can therefore produce a different symptom from a fault elsewhere.

The Control Processing Module (CPM) hosts system control and management software. It runs routing protocols, manages configuration, and coordinates forwarding state. Redundant CPMs can improve availability where supported and configured, but switchover behavior depends on the platform and enabled state-protection features.

The Input/Output Module (IOM) supplies forwarding resources in modular architectures. A Media Dependent Adapter (MDA) provides interface connectivity in supported IOM/MDA combinations. An Integrated Media Module (IMM) packages forwarding and interfaces together. Do not infer supported speeds solely from the name “MDA”; consult the actual card and optic specifications.

The switch fabric interconnects forwarding modules. Its packaging differs by chassis: some systems combine fabric and control functions, while others use separate modules. Power supplies, fans, and environmental monitoring support the whole system. A correct logical configuration cannot compensate for missing power, an unsupported optic, or an unprovisioned card.

Trace traffic through hardware

Consider a packet arriving on one forwarding module and leaving through another:

1. The ingress interface receives the frame and presents it to the forwarding engine.
2. Classification identifies the relevant service or routing context and policies.
3. The lookup selects an outgoing interface or tunnel action.
4. Traffic crosses the fabric when the destination forwarding module is different.
5. Egress processing applies the configured queuing and transmission treatment.

Ordinary transit forwarding does not require the CPM to copy every packet between ports. The CPM supplies control decisions and coordination. Selected local or exception traffic can still require software processing, so this architecture does not eliminate control-plane capacity limits.

Read a port identifier

A common modular interface identifier uses slot/mda/port notation. In 1/2/4, the first number identifies slot 1, the second identifies MDA position 2, and the last identifies port 4. It describes a physical interface location; it does not specify the VLAN, customer, IP address, or service.

A connector with breakout channels can use a longer identifier, such as 1/1/c1/1. Here c1 identifies a connector and the final component identifies a channel. Actual syntax depends on hardware. Fixed platforms can use hierarchical identifiers without containing field-replaceable cards for every number.

The colon adds service-delimiting information. VLAN 100 does not mean chassis slot 100, and changing an IP address does not change the port identifier. A named Layer 3 interface can bind to a port or LAG, while an Ethernet service SAP combines access connectivity with an encapsulation match.

Provisioning and operational state

Before a port can carry a service, its hardware must be supported, recognized, and appropriately provisioned. A port has administrative and operational state. Administratively enabled means configuration permits operation; it does not prove light is received, the peer is active, the optic is supported, or link settings agree.

Start with read-only observations such as show version, show card, show mda, and show port. Interpret the actual output and its legend for the release. A discovered card and a working physical link are separate checkpoints. Counters can reveal errors or drops even when a port reports Up.

For a customer outage, identify the exact SAP and underlying port before changing anything. If many services on one port fail together, investigate the common interface. If multiple ports on an MDA fail, examine the adapter and its dependencies. If routing sessions fail across otherwise healthy ports, examine control-plane state as well.

A useful lab exercise is to map each logical object back to its physical dependency. Record the service, SAP, port, MDA, and slot. Then predict which services would be affected by disabling one port versus losing the entire module. This develops the component reasoning needed to interpret an unfamiliar chassis diagram without memorizing speculative capacities.

Primary reference

Nokia 7750 SR documentation, checked October 20, 2026. Consult the selected chassis's installation guide for exact slot layout and supported hardware.