I can not stress that enough. Always get a copy of the current running config and keep it in a safe place. I had one router where a vendor configured it, I just happen to get a copy for my records. 5 months later they took a power hit and guess what, the vendor had never saved the config to NVRAM. Without my notes, this would have been very bad.
To protect against a "smurf" attack use the following comand:
!
no ip directed-broadcast
!
Other easy security measures are:
!
no service tcp-small-server
no service udp-small-server
!
You should have names that make sense. Just an IP or nothing at all makes troubleshooting much more difficult then it needs to be.
To configure the host name:
router(config) hostname california_wan ; note the lower case. Not all software can handle uppercase correctly so lower case is "safer"
Remember that SNMP can get this name from the sysName variable so again, use a name that makes sense.
Interfaces:
Always.. always use a description for each interface. A very good idea with WAN links is to use the circuit number as part of the description. When you are on the phone trying to troubleshoot a down link, this small detail can be a lifesaver for you.
Including the contact and phone number adds to your work load as this information tends to be rather transitory nowdays
!
interface serial 0.1 point to point
description San Fransico to New York PVC, circuit 001BHAC56789-001
ip address 123.456.789.1
!
You can see how easy this is to read and when you are trying to troubleshoot problems, this is what you want, nice clear descriptions
Get into the habit of specifing the bandwidth even if it's not needed. Some protocols like OSPF use the bandwidth to help figure out the metrics using this information.
If your link is slower the 256K, you *may* want to use the following command to make more buffer available depending on the link load
!
no ip route-cache
!
Always configure a loopback address. This provides several positive things.
OSPF will by default use the loopback as the router ID or use the highest IP number as the router ID. If you plan this right, you can make your OSPF IDs make sense
10.10.10.1
10.10.10.2
10.10.10.3 etc
Also with OSPF, each time a link "flaps" all the routers must recalculate the route changes. Since the loopback doesnt "flap", the network will be more stable
You can telnet to it without regard to whether the interface is "up" or not. SNMP polling is the same thing.
A stable interface is very important to protocols like SNA which is very sensitive to time delays and outage. This also applies to DLSW, STUN and RSBR
IP or PPP from a laptop if you find yourself in a bind.
SNMP
SNMP is one of those double edged swords. It can be very useful but dangerous to your peace of mind if not handled well. SNMP has two types of communities. Read Only and Read/Write. The read/write is the dangerous one. With this string, you are god on the router and there is not any password checking ( normally)
Read/write SNMP is a way to get out of the nasty box of configuring the enable password and then promptly forgetting it or mistyping it. Not that this EVER happens ( dont ask how I know this one)
It very easy to configure
router(config)snmp-server community string RO; read only snmp string
router(config)snmp-server community string RW; read/write snmp string
Do NOT use common names, your name, words like sex and the like. There are dictionary based SNMP crackers out there so be careful with your choices. Better yet, get a cracker and look at the dictionary to get an idea of what is in them.
I alway use the snmp-server chassis-id serial-number to ID the router so I can get the SN remotely.
You can specify access lists to restrict the number of workstations with access to the SNMP info.
!
access-list 60 permit 123.456.789.1 0.0.0.0 ; limits access to a single IP
!
If you want to be very paranoid then consider the following comand
!
snmp-server trap-authenication
!
This sends traps to your management station whenever a invalid community string is tried. Fun huh?
A very good friend is called SYSLOG. This is a great way to get a nice log file about things that happen to interfaces, events and debugging. I happen to use a Wintel syslog deamon from Kiwi software. There are many to choose from from both Wintel and Unix/linux
To work with syslog, use the following commands.
!
logging on
logging buffered
!
loggin 123.456.789.1 ; the IP address is the syslog management workstation
!
CDP
Very useful to both you and hackers. So the rule is if you plan to use it( good idea), make sure you turn it OFF on any outside interfaces.
!
interface ethernet 0
ip address 123.456.789.2 255.255.255.0
!
no cdp enabled
!
Telnet access is something many people ignore. It's prefectly acceptable to lock down your telnet ports to some degree. Just dont make it too restrictive ( like having to hit a certain router then bounce back)
use a strong password, again, not common names etc. Dont leave printouts of the running-config laying around. There are several password crackers that can be used to compromise your passwords if you give someone a chance
I would like to thank both Cisco TAC and Mentor Technologies for publishing very good white papers on best practices for configuration of Cisco routers. For more detailed information on best practices check out either site.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.