Cisco IOS Tidbit

When testing a SNMP configuration for Cisco switches, I wanted to use a named access list to give SNMP v2c access a bit security. I started with an extended IP ACL.

When I configured an SNMP community string:

snmp-server community blahblah ro acl-snmp-read-only

The switch accepted that command.

But when I then do a "show running-config", my configuration is not there.

It seems that Cisco IOS doesn't really allow extended access list. But it doesn't tell you either. The "snmp-server community" command is simply silently dropped. This seems to be the case with code version from 12.2(55)SE4 on a C3750 to 03.01.01.SG on a Catalyst 4500 L3 switch.

Password? What password?

This morning I mindlessly did an iOS upgrade -- I came into work, plugged my iPhone to charge it; iTunes popped up and prompted me to do some upgrade. I haven't had my morning coffee yet, so I just clicked OK. When I realized it was upgrading my phone, the process was already well under way. So I decided to let it go ahead -- I am now regretting that (non-)decision.

I was working on my PC doing whatever I was supposed to do. Then this screen popped up:

I thought, hmmm.... What does that mean? Was the upgrade completed? Or did it fail?

At that point, it didn't seem that there was anything else I could do. So, I went along. Then I got this:

That made me a bit nervous. If this warning came earlier, I might have stopped the upgrade even not being fully awake. But at this point, what could I do? So I hit Restore and Update.

Now that's strange! I didn't see it doing the backup. So I definitely did not set a password on the backup. I tried my Apple account password, my Windows password, etc. It just kept giving me the same password ... was incorrect message.

So I googled iPhone upgrade backup password. This one came up on top of the result:

To put it mildly, I have never liked Apple products. Now this is pushing my dislike to a level of hatred.

Cisco IOS User Privilege

Nothing new in this entry. Just to jot down a couple of thoughts about the IOS command below:

aaa authorization exec default local group tacacs+

In Cisco IOS, a user may be assigned a privilege level from 1 to 15 for accessing a device. Each privilege level may be configured to do different things, but the most simple and common practice is likely that a user is given level 1 privilege, which by default only allows the user to do things like showing status, etc. When a user needs to change configuration on the device, he or she may use the enable command to gain the proper privilege, usually level 15.

There are a couple of ways for that privilege elevation to be authorized. One common way is to configure an enable secret on devices. The argument is that the device could be configured even when it loses connection to an authentication/authorization (AAA) server.

But on the other hand, if one by mistake messes up the enable secret configuration on a device, having an alternative authorization route allows that mistake to be fixed relatively easily without having to physically visit the device, provided that the only thing wrong on it is the enable secret and it is still talking to the AAA servers.

That leads to the IOS command line above: It says to try the local enable secret first when a user asks for the enable privilege level; If that fails, try the TACACS+ server(s) configured in the device.

References:

• How to Assign Privilege Levels with TACACS+ and RADIUS
• How to Configure tacacs Authentication and Authorization for Admin and non-Admin users in ACS 5.1