I always have a hard time finding this. Every once in a while I’d like to see the console messages when I’m remotely managing a switch via SSH (or Telnet). The command is simply “terminal monitor”. This only lasts for the current session but that isn’t a big deal.
Here is a little tidbit to remember. I was configuring a switch for a new iSCSI SAN install. To make it easier I was copying configuration settings from an existing SAN switch when I noticed there was nothing setting the Jumbo frames to 9000. I verified everything was ok on the production network by using ping, setting the size, and telling it not to fragment. I then used a show system MTU command and the switch shows Jumbo MTU set to 9000. I little searching online and I found that Cisco switches don’t store the Jumbo frame setting in the configuration file. Here is the quote from the Cisco documentation:
The system MTU setting is saved in the switch environmental variable in NVRAM and becomes effective when the switch reloads. Unlike the system MTU routing configuration, the MTU settings you enter with the system mtu and system mtu jumbo commands are not saved in the switch Cisco IOS configuration file, even if you enter the copy running-config startup-config privileged EXEC command. Therefore, if you use TFTP to configure a new switch by using a backup configuration file and want the system MTU to be other than the default, you must explicitly configure the system mtu and system mtu jumbo settings on the new switch and then reload the switch.
I don’t work with network gear very often so every time I need to find out which switch port a device is connected to, I’ll typically have to do a quick search to find the commands. So now I’ve decided to write a good tutorial. The network that I manage is disconnected from the internet so I can’t post screen shots, but what you see are recreations of the screen shots I printed. Read more…
Configuring Cisco devices to authenticate via Active Directory isn’t a common practice. From what I’ve seen, most network admins simply have passwords set on the vty lines and an enable password set. Amazingly it seems most passwords are either cisco or cisco123. I couldn’t find very many resources out there for how to set things up so after much trial and error I finally have it working so I’m posting it here in hopes it will help someone else. Later I’ll be trying to get 802.1x wired authentication going but this is a start. Read more…
More work securing the network. I was setting up RADIUS authentication and authorization using the Network Policy Server role of Windows 2008 R2 (that will be another post). Here is a simplified network diagram.
Everything worked perfectly for the local router (rtr01) and switch (sw01) so it was time to do the same on the remote devices. I started with the switch (sw02) and then moved onto the router (rtr02) when I ran into problems. I couldn’t log into the router. I tried the router’s local username which did work indicating the router couldn’t authenticate against the RADIUS server. This seemed very odd to me since the switch, which is further away, worked perfectly. I tried a simple ping to the server and it failed. Now I was really confused, because the switch could ping the server but the router couldn’t.
At this point I’m thinking it’s some strange configuration setting on the router so I fire up Google and start searching. I come across the Cisco Extended Ping and Traceroute commands as well as a short statement indicating the originating address is the IP of the interface the packet leaves. So I try an Extended Traceroute using an originating address of 184.108.40.206 and it works. This means that a reverse route from the server to the 172.16.19.52/30 subnet doesn’t exist. Adding the following route to sw01 fixed the problem:
ip route 172.16.19.52 255.255.255.252 220.127.116.11
Switch sw01 already had a route to the 18.104.22.168/25 network. Until now there was never a need to know how to get to the WAN interfaces of the routers.
Update: I originally posted this (on my previous blogging site) on 31 Mar 2009 and have made some updates due to broken reference links.
I ran into a strange problem while configuring an Etherchannel on a couple Cisco switches. I would set the speed and duplex on one switch to 1000 full but as soon as I set the same speed and duplex on the other switch the connection would go down. This was the first time I’ve tried to set up an Etherchannel so I incorrectly assumed it was an Etherchannel configuration mistake. After much searching I found a single sentence that indicated 1000Base-T must be set to auto/auto but no references. Luckily my colleague was looking for the same thing and sent me a link which had references and a great explanation of what happens. That link is no longer active but I’ve found others that I’ll put at the bottom of this post. Read more…
That was the error message when I tried to telnet into a newly configured switch in the lab. I had full access via the console port but couldn’t telnet into the switch. There was the standard enable secret xxxx line and a username admin secret xxxx line and nothing under the vty lines. It turns out that I forgot to set aaa new-model. Without that the vty lines expect a password to be defined just for them. Now that’s a rookie mistake!