Router Spring Cleaning – No MOP Required

Spring is finally here, and besides being a good time to clean the attic, garage or basement, it is also a good time to clean the configuration on your Cisco IOS devices — removing unneeded ACEs from ACLs, maybe setting some interfaces as passive, removing VLANs from trunks, etc.

And while doing said cleaning, hey, why not also check the device configuration against the Cisco Guide to Harden Cisco IOS Devices, to make sure we’re doing our best to keep those Cisco IOS devices as secure as possible?

When looking over the recommendations on the hardening guide, time and again people are puzzled by this line:

“Issue the no mop enabled command in interface configuration mode in order to disable the Maintenance Operation Protocol (MOP) service.”

And they come back to us with questions like, “what is MOP, why do I have to disable it, and is it even relevant if I’m not running DECnet?” Well, today we hope to clear up some of the confusion that might surround the unMOPping of a Cisco IOS device, so gather round for a story. Sorry, no marshmallows, but I think it will be interesting nonetheless.

Many years ago, in the land of Digital Equipment Corporation (DEC), there was a set of network protocols, collectively called the “DECnet.” One of them was called DRP and its job was routing. Another one was NSP and it could be found at the transport layer. There was also SCP, located at the session layer. And of course, who could forget about NICE and MOP, which spent their days dedicated to network management chores.

MOP (the Maintenance Operation Protocol) offered many features: remote loading of system software, loopback testing, and others (none of which we will talk about today; the one we’re interested in is the “remote console” (RC) functionality). A network operator was able to establish an interactive session from a VAX/VMS host toward a device offering MOP RC capabilities. The MOP RC data was carried directly over L2 frames, with no L3 addressing at all, so any RC session was limited to devices that were either on the same physical network segment or in separate network segments that were bridged together.

Now, Cisco IOS Software has supported both MOP RC and MOP loading of images as far back as Cisco IOS 9.0, which wasn’t even Cisco IOS back then, but “System Software Release 9.0,” and we still support those features in the recently released 15.x trains (talk about a long lasting protocol!). And the MOP RC functionality is enabled by default on ethernet interfaces, so right out the box you can connect to a Cisco IOS device using a MOP RC client and, provided you have a valid set of credentials for said device, establish an interactive remote session.

We hardly need to say that for the 2010 network complexity and threat landscape a remote session protocol that runs only over L2 and provides neither data encryption nor data origin authentication is, well, far from being “state of the art,” nor our first choice to manage a Cisco IOS device.

I’m sure some people reading this are now wondering, “what do I care? I’m not running DECnet.” Well, the thing is, the MOP functionality is decoupled from the DECnet protocol stack, so even if your device isn’t configured for DECnet, you will still be able to establish a MOP RC session to the device, as long as MOP hasn’t been explicitly disabled.

And then some other people will shake their heads. “Where am I going to find a VAX/VMS host to establish a MOP RC session towards my new, shiny 1900, 2900 or 3900 router running IOS 15.1(1)T?” Well, you don’t actually need a VAX/VMS host. Thanks to the DECnet for Linux project, we have a readily available MOP RC client for Linux — the aptly named the moprc utility. And it works just peachy with our MOP RC implementation.

So some key points to note from all of this:

  • The MOP protocol (RC and remote load functionality) is still being shipped as part of Cisco IOS 15.x
  • MOP RC is enabled by default on ethernet interfaces (and yes, that includes FastEthernet and GigabitEthernet)
  • MOP (RC and dump/load) data packets are directly encapsulated on Ethernet L2 frames (Ethertype is 0x6002 for RC)
  • MOP packets can’t be routed but can be bridged
  • There is a readily available MOP RC client for Linux
  • You do have to provide valid credentials for authentication before being allowed interactive access to the device
  • A show users WILL show anyone connected to a Cisco IOS device over a MOP RC session
  • MOP RC packets are neither encrypted nor authenticated
  • Removing transport input mop from the VTY lines will not disable the MOP RC functionality

I hope this post has clarified some of the mystery surrounding our recommendation of disabling MOP. We’re also attaching, for those interested, a pcap file with a MOP RC session between a Linux host running moprc and a Cisco IOS router running release 15.1(1)T.

And that’s about it. As for me, I still have to move these boxes out of the garage before the wife comes back… my own spring cleaning chores.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. Hey, Mridul:
    Check the previous comments – Pieter also asked the same question, and the same answer still applies 🙂
    In any case, it would still be a good idea to issue the “no mop enabled” command – if supported on your combination of [hw platform, IOS/IOS-XE release, feature set], you will indeed disable MOP – if not supported, the worst that would happen is that you’ll get an error message.


  2. Hi Dario,

    This Post is really very useful.
    One Query from me – Pls tell me that Is MOP is applicable for L3 switches??coz i applied no mop enabled command on L3 switches (3750 & 4503) but in would’nt works.

  3. Thanks Dario, great technical explanation. I was troubleshooting with tcpdump and occasionally see MOP packets, which ultimately led me to your article. The command you mentioned will disable the protocol on a per interface basis.

    In case you’re using tcpdump, here is the output you’ll see with MOP. The key to identifying MOP is seeing the MAC address ab:00:00:02:00:00

    # tcpdump -ni eth2

    11:04:34.658483 00:06:e6:33:20:0a > ab:00:00:02:00:00, ethertype MOP RC (0x6002), length 77:
    0x0000: 3d00 0700 0000 0100 0303 0000 0200 0221 =…………..!
    0x0010: 0003 0006 0000 0000 0000 0400 023c 0005 ………….<..
    0x0020: 0002 d805 0600 0200 0107 0006 0006 d634 ……………4
    0x0030: 300a 6400 0179 9001 0101 9101 02ee 05 0.d..y………

  4. Hey, Pieter:Glad you liked the post :)To your questions:1) Yes, it’s also applicable to L3 switches – though the availability of MOP on L3 switches depends on the combination of (switch model, IOS release, feature set)2) Funny you would mention that 🙂 – indeed, there was an enhancement request opened for the implementation of the [no] mop enable”” global command – akin to the “”[no] cdp enable””. Sadly, the enhancement request was, at the time, closed without being implemented – as the future of DECnet and related protocols was thought to be short . . . who would figure they would outlive, say, Appletalk ? :)3) Nope. CoPP doesn’t accept a 200-range ACL, EtherType. I tried a couple more tricks, but none worked – including an FPM policy. I’ll have to circle back with the FPM development team on this . . .”

  5. Hello,I really enjoyed reading this post. Just a quick question (well, actually two).Would this also be applicable for layer3 switches, as they also run IOS (altough it’s switching IOS, but it is IOS, can do routing and they do have a lot of ethernet ports)And second question,Wouldn’t there be a command likeno service MOPwhich would be similarto no cdp enableno ip tcp-small-servers…So that instead of disabling it at the interface level, disabling it at the router level.Oh, and a third question pops into my mind (as I’m prepping for CCIE Lab Security). Would’t CoPP could be of help with this as well?