IOS-XE looks like classic IOS but runs on Linux underneath

same cli, different guts

if you learned networking on classic ios, ios-xe feels familiar on purpose. you type show ip interface brief, you configure vlans, you set up ospf, and it all looks like the ios you memorized for your ccna. but under the hood, cisco rebuilt the whole thing on linux. that matters a lot if you're the one defending these boxes, because the attack surface, the failure modes, and the recovery options are different from what classic ios ever gave you.

linux underneath means isolated processes

classic ios ran as one big monolithic blob. if one process crashed, there was a real chance it took the whole router down with it. ios-xe runs on top of a linux kernel and splits things into separate processes, things like the ospf process, the bgp process, the platform manager, all running somewhat independently.

the defensive upside is resilience. a crashed process can often restart on its own without a full reload of the device. the thing to actually check as a defender is whether your monitoring is watching for those individual process restarts, not just device-level up or down. a process quietly crash-looping is a sign something is wrong, maybe a bug, maybe someone poking at the device, and if you're only watching for full reboots you'll miss it.

show platform software process list
show processes cpu sorted
show logging | include restart

get familiar with those outputs on a healthy device so you know what normal looks like before you need to spot abnormal.

install mode vs bundle mode

this is the one that trips people up during upgrades, and it's also a real security consideration. bundle mode runs the software straight from a single consolidated .bin package, it's simple but every boot re-extracts everything. install mode unpacks the image into individual packages on the file system and boots from those, which is faster and gives you more granular control, including the ability to patch specific subsystems without a full image swap.

from a defender's chair, know which mode your devices are running and why.

show version | include mode
show install summary

install mode is generally the modern recommendation and it plays nicer with rollback if an upgrade goes bad. if you've got devices in bundle mode purely out of habit, that's worth revisiting, because a clean rollback path during an incident is a defensive tool, not a nice-to-have.

netconf and restconf: config by code, and why that's a door you need to lock

ios-xe speaks netconf and restconf natively, which means you can push configuration as structured data instead of typing commands one at a time. that's great for automation, but it also means there's an api surface sitting on the device that a lot of network folks never think to check because they're used to thinking of "access" as ssh and the console port.

if you're not actively using netconf or restconf, they should be off.

show running-config | include netconf
show running-config | include restconf

if they are in use, lock them down the same way you'd lock down any management plane, restrict source addresses with an acl, put them on a dedicated management vrf if you can, and make sure whatever's authenticating to that api isn't sharing a password with three other systems. an automation tool with broad config rights and a weak credential is a bigger blast radius than most people account for.

the same cli can hide a bigger management plane

the whole point of ios-xe keeping the classic cli is so migration doesn't feel scary. but that familiarity can lull you into treating it like old ios, checking ssh access and forgetting there's now a linux subsystem, a package-based install system, and one or two api protocols riding along. your device hardening checklist from ten years ago probably doesn't cover all of that.

the takeaway

ios-xe is a genuinely better platform, more resilient, more automatable, more flexible on upgrades. but "modern" also means "more surface to check." go look at what management protocols are actually enabled on your gear, confirm you're in the install mode you think you're in, and make sure your monitoring watches processes, not just device uptime. the cli hasn't changed much, your job checking behind it just did.