Core Router: Role, Architecture and Design Rules

01 /Core versus edge and aggregation

Routers are named for their position. Edge routers terminate customers and services: access lists, NAT, VPN termination, per-customer VRFs. Aggregation routers collect many edge devices into a few high-speed uplinks. The core connects aggregation points to each other and to peering and transit, with the fewest devices, the highest port speeds and the shortest feature list. Policy belongs at the edge; the core only forwards, so nothing on it changes when a customer changes.

02 /Forwarding plane versus control plane

The control plane runs the protocols: OSPF or IS-IS inside, BGP outside, LDP or RSVP for MPLS, plus management, and produces a routing table (RIB) on the management CPU. The forwarding plane receives a compiled version (the FIB) and does the per-packet work in ASICs on each line card, without the CPU touching packets; that distribution is what lets a chassis scale to terabits. A core router has a forwarding plane fast enough that every port runs at full speed at once, called line rate, and protects its control plane so a flood of unusual packets cannot starve it.

03 /Chassis versus fixed

04 /Redundancy that matters

• Dual management modules with state synchronisation, so losing the active module does not reset forwarding or BGP sessions.
• N+1 power from separate feeds; confirm a full chassis with one supply failed still meets total draw.
• Redundant switch fabric, so a failed fabric card degrades capacity rather than isolating line cards.
• Two of everything at the topology level: two core routers, two paths between any pair of aggregation points, no single link or building whose loss partitions the network.
• Hitless software upgrade, or a tested procedure for failing over to the second core while patching the first.

05 /Route table scale

A provider core carrying the full internet table holds more than a million IPv4 prefixes plus a growing IPv6 table, each needing a FIB entry in fast memory on every line card. That memory sets a hard ceiling; mid-2000s routers sized for 256k or 512k routes had to be replaced or filtered as the table crossed those marks. Enterprise cores carrying only internal and default routes need a small fraction of that and can use switch-class hardware. Plan for the table size at end of life, not at purchase.

06 /Worked example: sizing a two-router core

Two core routers, C1 and C2, connect four aggregation pairs. Each aggregation router has one 100 Gbit/s link to C1 and one to C2. Peak load between aggregation blocks is 480 Gbit/s. Equal-cost paths spread it over eight 100 Gbit/s links at 60 percent each. Lose C1 entirely and the four links into C2 must carry all 480 Gbit/s: 120 percent, so the design fails its own redundancy test at peak. Either add a second 100 Gbit/s link from every aggregation router to each core, giving 60 percent after failure, or accept that peak traffic is shed during a core outage and write that down. Do the same arithmetic for forwarding memory on the surviving router.

core1# show bgp summary
  192.0.2.1    64500   4w2d      1023457
core1# show control-plane policing statistics

07 /Collapsed core and data centre core

Most enterprises do not need three tiers. A collapsed core merges core and distribution into one redundant pair of Layer 3 switches that terminate the closet VLANs, run VRRP for gateways, route between them and connect to the firewall and WAN. It saves a tier and suits up to a few thousand users. The limit is blast radius: any change to the pair touches everything, and the pair must carry both distribution policy and core throughput.

Data centre cores changed shape in the 2010s. The two-router core above rows of aggregation switches gave way to leaf-and-spine fabrics: every leaf connects to every spine, equal-cost multipath spreads flows across all paths, and no spine is special. The spine is the core in all but name: routed links, no spanning VLANs, line rate, no policy. The rules are unchanged: simple, redundant, fast.

08 /Foundry heritage: NetIron and BigIron cores

Foundry launched the NetIron 400 and 800 around 1999 and 2000 as internet core routers with full BGP tables and wire-speed chassis forwarding, when incumbent core routers were expensive and comparatively slow. The BigIron chassis served as the enterprise and data centre core; the original site carried a data centre core solutions page built around it. The NetIron MLX and XMR, around 2005 to 2007, brought 10 Gbit/s density and MPLS to provider cores and outlived the Brocade acquisition by years. Route table scale grows again during the move to IPv6, because a dual-stack core holds both full tables in forwarding memory at once; the wider set of routing topics sits in the routing chapter.

show chassis
show module
show redundancy
show ip route summary
show ip bgp summary

09 /Core router failure modes and expert tips

• FIB overflow. The table crosses the memory limit and the router drops new prefixes or forwards them in software. Alert at 80 percent of the platform limit, not at the failure.
• Microbursts. A five-minute average at 40 percent hides bursts that exhaust output buffers. Count output drops per interface, not only utilisation.
• Unprotected BGP sessions. Sessions without TCP-AO (RFC 5925) or at least the MD5 option, and eBGP without the TTL check of RFC 5082, are open to injection from anywhere the packets can reach.

A core that carries the full table should be dropping RPKI-invalid routes, because a forged origin that reaches the FIB is forwarded at line rate like everything else. Where the core also provides label-switched transport the same rule holds: keep customer state off it. Feed sampled flow export from the core into the capacity model above, so the peak figure is measured each quarter, not remembered.

Changes to core routers drafted with AI help deserve the stricter process in peer review for tool-assisted router changes.