I was configuring a switch the other day and realized I had configured a trunk on the wrong port. God, I hate that. Instead of dumping the configuration for the port and doing a “no” on each line, I used the default command.
Switch(config)#default interface G0/1
This resets the configuration on interface G0/1 to how it was when Cisco shipped it to you. Much better than killing all the lines of the configuration one-at-a-time, eh?
NATting sucks and can be confusing. I’m sure everyone agrees to that, but you have to use it at some times. In a PIX/ASA, it’s easy to configure a simple setup, but can be super-complicated in larger networks. In a simple lab, we have set up an ASA with inside and outside interfaces, with the inside as your internal and outside as the Internet.
The NAT setup here is easy.
There’s a very-overlooked feature of access-lists – the remark. Yes, this is very basic, but it’s worth mentioning, as it has saved me anguish time and time again.
I use remarks to document each line of an ACL (on IOS, PIX, FWSM, ASA, etc.) so that when I go back later, I actually know what I did. They’re simple to use, and, I promise you, you’ll thank yourself for using it when the CTO asks why access to TCP/80 is open from the Internet to the development server.
We all have these at our desks. Not the bluetooth guys for your [tag]phone[/tag] (we could talk about that for a while), but the 900MHz headsets that your company gave you for those long and annoying calls with the boss. These things rocks, but they are oh-so [tag]insecure[/tag].
A coworker who fields support calls has one, and we decided to see how far we could go with these. We were shocked to discover that he could field a call 2 full stories downstairs from his desk. I was able to take mine 1 story away without even a single bit of static in it. I’m sure I could have taken it farther, but construction kept me from going any farther.
I’ve been looking around at some lists and forums for technical help on Cisco gear, and one thing keeps coming up – people new to [tag]Cisco[/tag] devices don’t know how to look at logs. The [tag]logs[/tag] are your friends and a great tool. You can use them to see what your router is doing, what’s going wrong, and even when something happened.
Get on your router and do a “show logging”. You’re looking at the log buffer where the router logs [tag]events[/tag]. If you don’t have anything in there, you need to run a “logging buffered informational” and “logging on” from config mode. This will turn on some logging at a basic level, and you should see some stuff going on. Keep doing a “show logging” and you’ll see the buffer start to fill up.
BGP has issues; the main one being transitive [tag]trust[/tag]. [tag]BGP[/tag] works by having networks (companies, providers, etc.) advertise [tag]routes[/tag] that it owns to its peers. These peers pass those routes on to their peers, ad nauseum, until everyone knows what networks everyone has. The big assumption here is that you are advertising only networks for which you are responsible. The word “assumption” should be emphasized.
The Pakistani government decided that a video on [tag]YouTube[/tag] was bashing Islam, so they ordered the Pakistani Internet services to block it. Instead of filtering from their network out, they decided to advertise via BGP that they were YouTube. To make things worse, they used a more-specific, 24-bit route; since YouTube advertises a 22-bit route, the new Pakistani route is preferred since its more specific. The transitive trust of the BGP cloud allowed them to tell the world that YouTube was on their network, effectively taking YouTube completely off the Internet for few hours. YouTube finally changed their advertising to a bunch of 25-bit networks, which restored connectivity, and, eventually, the Pakistani ASN withdrew the route. Here’s a timetable from Martin Brown of [tag]Renesys[/tag].
I deployed a Cisco ASA at a location and couldn’t get logged in via SSH. I would get prompted, but, no matter what username/password I put in, it would just reject me. After some digging, it turns out that I forgot this command.
aaa authentication ssh console LOCAL
When I put this in, it let me right in as expected. I have no clue what the deal was. I guess I assumed that the ASA would use the local userbase if a AAA service wasn’t configured. I guessed wrong.
Back in the day, when I used to put a new piece of IOS-based gear on the network, I would have to go through the gear already in production to remember what all those “little configurations” were that kept the devices running. Guess how many times I remembered to set the NTP server or turn off the HTTP server? Never.
To fix that problem, I started to keep a list of IOS commands that every IOS device on the network was configured with. That way, if I had another device to configure and deploy, I could just paste the list in and then do the IP and hostname stuff. It makes me feel a little more confident that the gear I deploy is more standardized and maybe even a little more secure.