We’ve got quite a few for you here.
Okay… now let’s get started:
Loopbacks are a logical interface on the router that never goes down. Be sure to use them. Even if you don’t know why add them, then figure out why you did, and use them. Here are some things they’re good for:
- Sourcing Logs
- Sourcing TACACS
- Sourcing SNMP
- Sourcing Gateway registration (UC)
This is a very important best practice. When you use Loopbacks you’ll always have a well-defined management address to source traffic from that will add security and stability.
Here’s how to configure Loopbacks:
Network Time Protocol (NTP)
With all the regulations today, these are critical for many reasons, such as:
- Assisting in troubleshooting,
- Assisting in forensics,
- Correlating events, and more.
Always source your NTP from the Loopback interface.
Note: NTPs can be authenticated if you want.
How to configure NTPs:
Simple Network Management Protocol (SNMP)
If you have a network device and a management system, chances are you have an SNMP configured. Here are some things we recommend you consider:
- Do you need SNMP RW (read/write)? If not, don’t enable it
- Consider using SNMPv3 because it’s more secure.
- Any SNMP access must be secured with an ACL.
Always source your SNMP from the Loopback interface.
How to configure SNMP:
Logging goes hand-in-hand with NTP. It’s incredibly critical to your environment.
First, you must figure out how many logs to send, then where to send them, and finally, you MUST review them.
- Logs can eat bandwidth, so be aware of this.
- You should use a centralized logging service.
- Determine your policy for how long to retain logs.
What interface will we source our logs from? You guessed it – Loopbacks.
There are a lot of different ways to configure logs but here’s an example of one way.
Domain Name Server (DNS)
We’re not talking about running DNS on your routers and switches, we’re talking about adding them to DNS and giving them the ability to resolve DNS.
Let’s say you’re having a routing loop. When you do a traceroute, whether from the router or a PC, wouldn’t it be nice to know which routers/cities it is hitting/bounding between?
Let’s also pretend you have 30 routers, not 3. The bottom line? Names are easier to attach significance to than numbers. So do this, please.
Secure Socket Shell (SSH)
This one is easy… Enable it! Run SSH on everything.
Here’s the minimal configuration:
Access Control Lists (ACLs)
These are used for a lot of things, not just security. Qo5 uses ACL’s, Route-maps use them PBR uses them, etc.
They are used for re-numerating traffic. They’re important to the configuration of your router.
So it’s important to think about the best way to deploy ACL’s and set a standard ahead of time.
Our recommendation is to use NAMED ACL’s only and to remark them in a reasonable manner.
What is a reasonable manner? That depends on your environment but I would say a good guideline is to remark for each major portion of an ACL rule set.
Here’s an example:
Banners can be applied to a number of processes: login, MoTC, exec, etc. We suggest that you check the docs in Cisco on the why’s and wherefores.
Regardless of which way you go, you SHOULD use a banner which warns people away if they don’t belong there. Here’s an example:
Things to never put in a banner:
The word WELCOME, names, IP addresses, departments, or any identifiable entity.
This is very simple and basic.
Disable everything you don’t need and enable everything that you do need.
Not all of these need to be enabled or disabled, but the list is good to have pasted in.
The first section is the things we tend to disable and the second section we advise enabling.
Passwords & Secrets
- Never use “passwords” for securing your router. Only use secrets.
- Secret strength should be 8-9, which is the equivalent of SHA-256 and SCRYPT.
- Please DON”T use 4 NOT EVER! And if you see it, we recommend changing it. There have been issues with this.
- Even secret type 5 is better than 4 as there was a flaw in the algorithm that allows it to be cracked quickly.
Note: Don’t use anything easily guessable.
Ever try to type SSH to 10.1.1.1 and accidentally type “SSH 10.1.1.11” where there’s no host running SSH?
You know that really annoying long wait period (90 seconds) where you are waiting for the router to give up waiting for a SYN-ACK?
Well, you can tweak that down to anywhere between 5 seconds and 3 minutes!
Just use this simple global command called tcp synwait:
Do you really need 16 VTY ports? Probably not!
Consider using only 0-4 and disabling 5>15 by setting the timeout to 0 seconds.
Also, consider the “logging synch” command. It re-paints the line you were typing if you are interrupted with an exec message.
This is very helpful if you are typing and there are debugs or other log messages.
Names, Descriptions, Remarks
We’re a big fan of using names, remarks, and descriptors of any sort whenever possible.
- Need a static route? Give it a name!
- Want to enable an interface? Give it a description!
- Enabling an ACL? Remark it!
- Creating a VLAN? Name it!
Use system name descriptors for:
- Critical interfaces
But you don’t want to drill down so far that it’s not scalable.
This is about routing protocols.
A Graceful Restart is the ability to route through an outage/interruption in service.
Why would this happen?
You typically want to do this when you have multiple routing engines, one fails and the other is taking over. Think about dual supervisors in a chassis:
- Graceful Restart Capable – This means that the device in question actively supports Graceful Restart.
- Graceful Restart Aware – This means that the device (usually upstream/downstream) is aware of how Graceful Restart works and will assist to the best of its ability.
- It Supports OSPF, IS-IS, EIGRP, LDP, and BGP – During a Route Process (RP) failover, the router won’t learn new routes but will keep forwarding along the pre-failure paths that existed until the new adjacencies are formed.
Bidirectional Forwarding Detection (BFD)
BFD is a very useful protocol for detecting failures in an L2 network. As opposed to Graceful Restart, BFD routes around a failure rather than through one.
It’s very handy because:
- The protocol is very simple to configure and easily achieves sub-second failure.
- It works with the routing protocol (EIGRP, OSPF, BGP, IS-IS, and HSRP) but doesn’t rely on the protocol itself.
- It informs the protocol of the loss of connectivity and the routing process can then immediately expire all times and fail to a redundant path.
Note: You must check with your ISP to see if they support this feature.
ASA – TCP Ping
Ever want to see if a host is not just up, but that it is listening on a service?
You can use TCP Ping on the ASA to assist with this:
Ping tcp mywebserver.com 80
This will send Syn packets to see if it gets a syn-ack back on port 80.
This is very handy when it comes to troubleshooting an FW, and it can be used in conjunction with the “capture” command.
That’s it! Any questions? Contact us at LA Networks in Sherman Oaks, California: https://www.la-networks.com