Cisco ASR 9904 Aggregation Services Router

The Cisco ASR 9904 is a compact, modular member of the Cisco ASR 9000 Series built for high-capacity aggregation and edge routing. Cisco lists the platform in a 6-RU form factor with two line-card slots, two Route Switch Processor slots, up to 4 Tbps of bandwidth per line-card slot, and up to 16 Tbps of total system capacity. That combination makes the chassis relevant when a network needs substantial throughput and carrier-class resiliency without moving immediately to a much larger chassis.

For buyers in Tanzania, the important purchasing decision is not simply whether the ASR 9904 is powerful enough. It is whether the exact combination of line cards, RSPs, optics, software release, licenses, AC or DC power, rack space, cooling, and redundancy matches the intended network role. FourTeck Tanzania can use those requirements to help define a configuration and quote rather than treating the ASR 9904 as a fixed-port appliance.

Who should evaluate the Cisco ASR 9904?

The ASR 9904 is primarily a service-provider-class routing platform, so it is most appropriate where the network design needs modular high-speed interfaces, resilient control and forwarding, sophisticated routing services, or a growth path beyond conventional enterprise branch and campus routers. Typical evaluation scenarios include ISP or carrier aggregation, provider edge, peering edge, metro Ethernet aggregation, mobile transport, broadband service aggregation, large-scale MPLS networks, and selected high-capacity enterprise or institutional cores.

A Tanzanian ISP may look at the ASR 9904 when consolidating multiple aggregation links into a smaller number of high-speed uplinks, introducing 100G or supported 400G interfaces, or building a resilient edge for IP transit, peering, L2VPN, L3VPN, EVPN, or Segment Routing. A carrier or infrastructure operator may value the chassis when rack space is constrained but two modular line-card slots provide enough interface density. A large enterprise, university, financial institution, data-centre operator, or public-sector network may also consider the platform when the requirement is closer to a service-provider edge than to a standard enterprise router.

The platform should not be selected on headline capacity alone. If the requirement is only a few fixed Ethernet ports with limited routing scale, a smaller fixed system may be simpler and more economical. Conversely, if the design already requires many line-card slots or a much higher long-term capacity ceiling, the larger ASR 9906, 9910, 9912, or 9922 chassis may be a better fit. The ASR 9904 is strongest when its 6-RU footprint and two-slot modular architecture match the actual growth plan.

Key platform specifications

These values describe the platform rather than a complete bill of materials. A production ASR 9904 solution normally requires careful selection of chassis variant, RSPs, line cards, transceivers, power components, cables, software and licenses. Port counts and protocol scale should always be checked against the exact parts and Cisco release documentation before ordering.

Why the 6-RU form factor matters

Core and edge routing decisions are often constrained by more than throughput. Rack units, available depth, weight loading, power feeds, cooling capacity, cable routing, spare ports and maintenance access can determine whether a design is operationally practical. The ASR 9904 packages two line-card slots and redundant control-plane positions into a 6-RU chassis, giving designers a way to deploy substantial modular routing capacity without consuming the rack space required by larger ASR 9900 platforms.

That compactness is especially useful where a network requires two major interface groups—for example, access or metro-facing ports on one line card and core or transit-facing ports on another—while still retaining room for redundant RSPs. It can also suit deployments in which a pair of ASR 9904 systems is preferred for node-level diversity instead of a single larger chassis. The correct topology depends on failure-domain design, capacity targets, maintenance practice and the cost of spare capacity.

Compact does not mean simple. High-density interfaces can drive significant power, optics and cooling requirements. Before committing to the chassis, verify rack dimensions, front and rear clearances, cable-management space, airflow direction, earthing, power feeds and the maximum environmental conditions at the intended site. A solution quote should therefore include facility assumptions as well as router hardware.

High availability and resilient architecture

Cisco positions the ASR 9904 with redundancy across several critical areas. The data sheet lists route-processor redundancy, fabric redundancy, power-supply redundancy, feed redundancy and software redundancy. In a dual-RSP design, the integrated fabric operates in an active/active nonblocking mode and is fully redundant. These characteristics are important for networks where planned maintenance and component failures must be considered from the beginning of the design rather than treated as exceptions.

Redundancy, however, is not created by installing a chassis alone. The full service path must be designed to avoid hidden single points of failure. That includes diverse power feeds where available, redundant upstream and downstream links, appropriate link aggregation, routing convergence, separate optical paths, resilient subscriber or service architecture, spare optics and modules, software maintenance procedures, and monitoring. A router with dual control components can still sit behind a single fibre path or a single upstream provider, so the availability target should be translated into an end-to-end topology.

For Tanzanian deployments, site conditions should be treated as part of high availability. Confirm power quality, UPS and generator strategy, earthing, cooling, dust control, physical security and access for maintenance at each location. These are deployment checks rather than claims about a particular site or utility provider, but they materially affect the reliability of high-capacity routing systems.

Interfaces, line cards and 100G/400G planning

The ASR 9904 is a modular chassis, so there is no single fixed port specification that accurately describes every deployment. Cisco offers multiple ASR 9000 line-card generations and interface combinations. The selected cards determine port speeds, density, forwarding features, optics form factors, power consumption and software requirements. Buyers should therefore define the traffic and connectivity requirement first and choose line cards second.

A practical interface plan should list every required service and uplink speed, the number of ports needed on day one, expected growth over the planned life of the node, oversubscription policy, optic reach, fibre type, connector type, protection links and spare ports. Where 400G is required, Cisco’s routed-optical documentation lists the ASR 9904 with support for up to eight 400G QSFP-DD ports in applicable configurations. That is a platform capability statement, not a promise that any ASR 9904 chassis automatically provides eight 400G ports. The line cards, optics, RSP generation, software release and feature compatibility must be validated together.

The same caution applies to 100G, 10G and lower-speed services. Mixing legacy and newer interfaces can be useful during migration, but compatibility should be checked before ordering. If a network is moving from multiple 10G or 100G links toward 400G, the design should consider not only aggregate bandwidth but also failure impact: losing a single 400G link can remove much more capacity at once, so protection and restoration design become increasingly important.

Cisco IOS XR for service-provider routing

The ASR 9000 family uses Cisco IOS XR, an operating-system family designed for large routing environments. Current Cisco documentation for the ASR 9000 platform covers technologies including MPLS, Segment Routing, L2VPN and Ethernet services, EVPN, Layer 3 VPN, BNG, multicast, QoS, NetFlow, system management and programmability. The benefit for a network team is a common software architecture across many ASR 9000 roles, but the exact feature set must be checked against the intended IOS XR release and installed hardware.

For operations teams, software planning should include more than the initial feature checklist. Confirm the target release, recommended maintenance release, supported RSP and line-card combinations, software packages, license entitlements, telemetry or automation interfaces, routing-policy requirements, maintenance windows and rollback process. If the ASR 9904 will join an existing IOS XR network, standardizing release trains and operational tooling can reduce complexity. If it will replace a different vendor or operating system, allocate time for configuration translation, route-policy validation, lab testing and staff familiarization.

Feature support can change by release and hardware generation, so procurement documents should avoid vague statements such as “supports all MPLS features” or “supports every EVPN function.” The correct approach is to identify the precise services the network must deliver and validate those features against Cisco’s current compatibility and configuration documentation for the proposed bill of materials.

MPLS, Segment Routing and VPN service use cases

Many ASR 9904 evaluations begin with a need to aggregate traffic while preserving multiple customer, business or service contexts. Cisco’s ASR 9000 software documentation supports MPLS-based services and Segment Routing, including integration with Layer 3 VPN, VPWS, VPLS and EVPN functions in supported configurations. This makes the platform suitable for designs that need to carry multiple services across a shared backbone while maintaining logical separation and engineered forwarding behavior.

Segment Routing can be particularly relevant for operators modernizing an MPLS network. Cisco describes Segment Routing as a way to encode forwarding instructions as segments and use source-based policy for traffic engineering. In practical design terms, that can reduce dependence on some older traffic-engineering control-plane mechanisms and provide a path toward more programmable network behavior. It should still be evaluated in the context of the existing IGP, MPLS architecture, controller strategy, operational tools and migration plan.

For a Tanzania-based operator, the business question is not whether a protocol is fashionable but whether it solves a network problem: faster convergence, cleaner service provisioning, better use of backbone capacity, simpler policy control, scalable VPN delivery or an easier evolution path. A requirements workshop should map each proposed technology to a concrete service, resilience or operational objective before licenses and hardware are selected.

EVPN and Ethernet service design

Cisco documents EVPN functionality for ASR 9000 systems under IOS XR. EVPN uses a BGP-based control plane to distribute reachability information and can support service-provider Ethernet designs that need multi-homing, redundancy and more explicit control-plane learning than traditional flood-and-learn approaches. Depending on the chosen service and release, EVPN may be used with MPLS and related Ethernet service functions.

When evaluating EVPN on an ASR 9904, define whether the router will act as a provider edge, aggregation PE, data-centre interconnect edge, or another role. Record the required route types, multi-homing model, VLAN and bridge-domain scale, MAC scale, IRB needs, convergence target, MTU, QoS, OAM and interoperability requirements. This is especially important in multi-vendor networks, where standards support does not automatically guarantee identical operational behavior for every feature.

A staged deployment is usually easier to validate than a broad protocol migration. Build representative configurations, test failure scenarios, verify route-policy and MAC/IP learning behavior, measure convergence, and confirm monitoring visibility before introducing the service at scale. The hardware capacity of the ASR 9904 is only one dimension; service scale and software behavior must also match the intended design.

Broadband Network Gateway considerations

Cisco provides Broadband Network Gateway documentation for ASR 9000 Series routers, including subscriber management, RADIUS interaction, QoS, accounting, dynamic authorization, redundancy and related functions on supported IOS XR and hardware combinations. A BNG aggregates subscriber sessions and connects access traffic to service-provider networks, so it can combine routing, policy, authentication and service accounting responsibilities in one architecture.

If the ASR 9904 is being considered for BNG use, the design must be validated more carefully than a simple port-and-throughput calculation. Define subscriber type, session scale, IPoE or PPPoE requirements where applicable, RADIUS design, AAA redundancy, address management, QoS hierarchy, lawful-intercept requirements where legally applicable, accounting, CGN interaction, IPv6 strategy, subscriber redundancy, and failure behavior. Cisco’s current documentation also lists supported and unsupported BNG functions by software release, so release-specific verification is essential.

The right BNG architecture depends heavily on the rest of the access network. Some deployments may centralize subscriber termination, while others may distribute it. The ASR 9904 should therefore be sized against real session and service requirements and not only against aggregate traffic. Ask for a configuration review that includes both subscriber scale and forwarding capacity.

Peering, transit and Internet-edge deployment

The ASR 9904 can also be evaluated for high-capacity Internet-edge roles where the network needs substantial Ethernet bandwidth, BGP routing, policy control and redundant connectivity. In a peering or transit design, the key inputs include expected route scale, number of peers, full-table requirements, IPv4 and IPv6 policy, traffic ratios, upstream diversity, Internet exchange connectivity, DDoS strategy, telemetry and growth over the planned service life.

High interface capacity does not automatically mean the edge is correctly sized. Route scale, FIB resources, RSP selection, line-card capabilities and software release all matter. Network teams should also plan for maintenance behavior: what happens to traffic during a line-card failure, RSP switchover, software upgrade, upstream outage or fibre cut? If one chassis carries a very large percentage of Internet traffic, a second node or geographically diverse path may be necessary to meet business continuity objectives.

For procurement, provide current peak traffic, 95th-percentile traffic if tracked, projected annual growth, required port speeds, number of transit and peering sessions, route-policy complexity, desired redundancy and future services. This produces a much more useful ASR 9904 quote than simply asking for “a 16 Tbps router,” because the final hardware and optics can be matched to the real edge design.

Power, cooling and rack planning

Cisco lists AC and DC power options for the ASR 9904. The ASR 9000 data sheet describes a pay-as-you-grow power architecture, including 3 kW AC and 2.1 kW DC power-module options in the referenced platform generation, and states that mixing AC and DC modules is not supported. Power redundancy differs by configuration, so the exact power bill of materials should be selected after line cards, RSPs and the redundancy objective are known.

Do not use the maximum chassis capacity as a substitute for a site power calculation. Actual requirements vary with installed components and traffic configuration. Confirm available input voltage, circuit ratings, feed diversity, connector and PDU requirements, UPS runtime, generator coverage, earthing and planned spare capacity. In a DC plant, check polarity, distribution protection and cable sizing. In an AC deployment, verify that the electrical design can support redundant feeds without placing both feeds behind the same upstream point of failure.

Cooling deserves the same attention. Dense line cards and optics can create concentrated thermal load. Verify inlet temperature, exhaust path, rack layout and blanking or baffle requirements using Cisco installation documentation. Avoid placing a high-capacity router into a cabinet simply because the rack units are available; depth, airflow and service access must also work. A site-readiness check can prevent expensive installation delays.

Environmental and physical considerations

Cisco’s ASR 9000 data sheet lists a nominal ASR 9904 operating temperature range of 5°C to 40°C and a short-term range extending from -5°C to 55°C under defined time limits. These values are useful for equipment-room planning, but they should not be interpreted as permission to operate continuously at the short-term extreme. A controlled environment with margin below the maximum temperature supports more predictable equipment and optics operation.

The router is rack- or cabinet-mountable rather than wall-mountable. Cisco documentation should be checked for the exact rack-adapter, clearance and mounting requirements. The completed system weight also depends on installed components, so rack loading and safe handling procedures should be planned before installation. Cable management is particularly important with high-density optical interfaces because bend radius, patching access and connector cleanliness affect service reliability.

For sites outside a major data-centre environment, review dust, humidity, physical access, pest control, surge protection, lightning protection, grounding and maintenance logistics. These checks are general deployment requirements and should be evaluated for the specific Tanzanian site. Where service continuity is critical, keep suitable spares and cleaning tools on hand and document escalation procedures for failed modules or optics.

Designing for growth without overbuying

A modular router is valuable when capacity can be added in stages, but growth planning should be explicit. Start with a three- to five-year traffic model if that matches your organization’s planning horizon. Record current traffic, expected customer or site growth, new services, anticipated uplink migrations, redundancy reserve and the capacity that must remain available during a component or link failure. Then translate those figures into interface and forwarding requirements.

For example, a design that needs 1.2 Tbps today may still require significantly more than 1.2 Tbps of installed connectivity once redundant links, maintenance headroom and burst growth are included. On the other hand, buying maximum port density that will never be used can lock budget into optics, licenses and hardware that provide no near-term operational value. The ASR 9904’s two line-card slots encourage disciplined planning because slot usage is a finite resource.

Ask whether each slot is intended to serve a distinct role, whether one card can handle initial traffic while the second remains available for expansion, or whether both cards are required from day one for capacity or diversity. Also confirm the upgrade path for RSPs and line cards. A good bill of materials should show the current configuration, the next expansion step and any dependencies that would make a future upgrade disruptive.

Migration from an existing edge or aggregation router

Replacing an existing core, edge or aggregation router is a service migration project, not only a hardware installation. Begin by documenting every physical interface, VLAN, subinterface, bundle, routing protocol, BGP policy, MPLS service, QoS policy, ACL, management path, telemetry feed, AAA dependency, timing requirement and out-of-band access method on the current device. Identify features that are vendor-specific or implemented differently on IOS XR.

Build the migration around rollback points. Pre-stage the ASR 9904, load the agreed software release, validate licenses, test optics, configure management access, verify time and logging, load routing policy, and test representative services before production traffic is moved. Where possible, migrate lower-risk links first and observe behavior before moving high-impact transit, customer or subscriber services.

The cutover plan should define expected convergence, maintenance ownership, communications, success criteria and rollback triggers. If the design introduces Segment Routing, EVPN, new optical speeds or a different BNG architecture at the same time, consider separating those changes into phases. Reducing the number of simultaneous variables makes fault isolation easier and lowers operational risk.

Operations, observability and automation

A high-capacity router should be integrated into the operational toolchain from day one. Current ASR 9000 IOS XR documentation includes system management, monitoring, NetFlow and programmability resources. Depending on the chosen release and design, network teams can use standards-based and Cisco-supported management mechanisms to collect state, automate configuration and integrate the router with network-management platforms.

Before deployment, define what must be monitored: interface utilization and errors, optical levels where supported, CPU and memory, RSP state, fabric health, power modules, fan status, temperatures, BGP and IGP adjacency state, route counts, MPLS or EVPN service state, packet drops, QoS queues, subscriber sessions if used, configuration changes and software alarms. Build thresholds around normal operating behavior rather than waiting for the first incident.

Automation should be introduced with the same discipline as manual configuration. Use version-controlled templates, validation, change review and backups. If NETCONF/YANG, APIs or other programmatic interfaces are part of the plan, confirm which models and operations are supported by the target software release. The objective is not automation for its own sake; it is repeatable configuration, faster verification and reduced risk when the network scales.

Security and control-plane planning

Service-provider routers sit in a sensitive position because they carry high-value control and data traffic. Security planning for the ASR 9904 should cover management access, authentication and authorization, configuration logging, secure management protocols, routing-policy controls, infrastructure ACLs, control-plane protection, route filtering, BGP session protection where appropriate, software patching and incident response.

Separate the management plane from customer or Internet-facing traffic whenever the architecture permits. Limit administrative access to known management networks, use centralized AAA with a documented emergency-access procedure, and collect logs at an external system. For BGP edges, establish prefix filtering, maximum-prefix policy, route-policy review and RPKI-based validation if it is part of the organization’s routing-security design. For customer-facing services, define anti-spoofing and ACL policy without assuming one rule fits every service.

Software lifecycle is equally important. Track Cisco security advisories and release guidance relevant to the exact IOS XR train and installed modules. A resilient hardware design can still be exposed if software maintenance is neglected. Procurement and operations teams should agree on who owns security updates, how releases are tested, and how emergency changes are handled before the router enters production.

How the ASR 9904 compares within the ASR 9000 family

Cisco’s current model comparison places the ASR 9904 between compact fixed or smaller platforms and larger modular ASR 9900 chassis. The ASR 9904 provides two line-card slots in 6 RU with up to 16 Tbps capacity. The ASR 9906 expands to four line-card slots and up to 32 Tbps in 14 RU, while the ASR 9910 provides eight line-card slots and up to 64 Tbps in 21 RU. Larger 9912 and 9922 systems extend slot count and total capacity further.

This makes the decision relatively straightforward when requirements are well defined. Choose the ASR 9904 when two modular line-card slots provide enough present and future interface capacity and the 6-RU footprint is valuable. Consider a larger chassis when the design needs more independent line cards, more ports, a higher system-capacity ceiling or additional room for growth. Consider a smaller fixed platform when modularity and 16 Tbps-class capacity are unnecessary.

Do not compare models only by total terabits per second. Evaluate rack units, power, interface density at the required speeds, failure domains, upgrade path, software feature compatibility and operational standardization. A platform that is larger on paper can be less suitable if it wastes rack and power, while a compact platform can be too restrictive if both line-card slots are already full on day one.

What to include in a request for quotation

Because the Cisco ASR 9904 is modular, a useful quotation request should describe the network rather than list only the chassis name. Start with the intended role—aggregation, provider edge, Internet edge, peering, BNG, mobile transport, metro Ethernet, data-centre interconnect or another use case. Then provide current and target traffic, interface speeds, port counts, fibre type and distances, redundancy requirements, routing protocols and services.

Also include the expected software functions: BGP, IS-IS or OSPF, MPLS, Segment Routing, L2VPN, L3VPN, EVPN, QoS, multicast, NetFlow, subscriber services or automation. State whether the deployment is new or must interoperate with an existing Cisco or multi-vendor network. Note the preferred AC or DC environment, number of independent power feeds, rack type, available RU, site temperature expectations and whether optics should be included.

Finally, describe the growth horizon and maintenance model. If a second line card is expected later, say so. If the router must survive a single line, RSP, power-module or upstream failure without unacceptable service loss, make that explicit. These details allow the proposed bill of materials to be checked for compatibility and reduce the chance of missing optics, licenses, power components or capacity headroom.

Deployment checklist for Tanzania projects

Common configuration mistakes to avoid

The first common mistake is ordering a chassis before the interface matrix is complete. A model number alone does not determine whether the router will have the required 10G, 100G or 400G ports. The line cards and optics define the usable interfaces, while RSP and software choices can affect supported features and scale.

The second mistake is designing for average traffic rather than failure traffic. If one uplink or line card fails, the remaining path may need to carry much more traffic. Capacity planning should model maintenance and fault scenarios, not only normal operation. The third mistake is assuming redundancy because two components are installed. Two power supplies connected to the same feed, two uplinks in the same duct, or dual RSPs behind a single upstream path can still leave a major common failure point.

The fourth mistake is ignoring software-feature dependencies until installation. A protocol name on a product-family page is not enough; exact feature support should be confirmed for the chosen IOS XR release and hardware. The fifth mistake is leaving operations until the end. Monitoring, backups, AAA, logging, automation, out-of-band access and software lifecycle should be designed with the router, not added after it is carrying critical traffic.

A disciplined pre-order review can catch these issues early. The review should connect business requirements to topology, interfaces, hardware, software, licensing, power, optics and operational procedures in one bill of materials and implementation plan.

Frequently asked questions

Request a Cisco ASR 9904 solution quote

For a useful quote, send FourTeck Tanzania your required interface speeds and port counts, expected traffic, network role, routing and VPN features, redundancy target, rack and power environment, optic distances and growth plan. The proposed chassis, RSPs, line cards, optics, power components, licenses and software assumptions can then be reviewed as one compatible design.

No price, stock status, delivery time, warranty term or local certification is stated here because those items should be confirmed for the exact configuration and current commercial offer. This helps keep the purchasing decision tied to verified hardware and service requirements rather than assumptions.