Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
2950 best practice?? 1
- Thread starter sobak
- Start date
-
1
- #2
Hmm this post could be very lengthy however in summary consider the following:
1. Approriate physical security for the switch as they're easy to crack (i.e. a locked rack)
2. Setup robust authentication, authorisation mechanisms such as TACACS/RADIUS.
3. Use strong passwords, access lists to control which IP addresses can access switch and legally-binding banner logins.
4. If a remote, critical switch, deploy some out of band management (e.g. modem). In fact, if security is a big issue for you, consider out of band management only and disable inband management (ie. telnet to device).
5. Use something other than vlan 1 for user and management traffic.
6. Prune all vlans (inc vlan 1) where they are not needed.
7. Where possible, prune the management vlan from any trunks that don't require it.
8. Consider mac security and/or 802.1x port authentication.
9. Disable unused ports.
10. Disable auto trunk negotiation on switch ports that don't need to trunk.
11. Consider removing the native vlan from all trunk links or using something totally unique for that trunk port only.
12. Consider private vlans if vlans don't need to speak to each other.
13. Consider RSTP or MST as your preferred spanning tree protocol.
14. Enable UDLD where you have uplinks.
15. Have 2 (don't need anymore) VTP servers in your VTP domain.
16. I prfer to use VTP transparent mode where I can as it minimizes administrative errors. The counter to this is VTP server eases administrative overhead - it's a personal choice.
17. Set autonegotiation on all ports and attached devices EXCEPT when attaching to other routers/switches (hard code speed/duplex for these ports and devices)
18 Get the device managed via SNMP if possible to provide you with an early heads-up regarding operational issues that you'd likely otherwise miss.
19. Get the switch to log to a syslog server (be careful with the severity of the messages you log so you don't use unnecessary bandwidth/switch resources and syslog hard disk space)
20. Sync the switch with an NTP server so that any logged info correlates to the actual time it happened!
There's a lot more to consider but this is what I can think of off the top of my head.
Good luck.
1. Approriate physical security for the switch as they're easy to crack (i.e. a locked rack)
2. Setup robust authentication, authorisation mechanisms such as TACACS/RADIUS.
3. Use strong passwords, access lists to control which IP addresses can access switch and legally-binding banner logins.
4. If a remote, critical switch, deploy some out of band management (e.g. modem). In fact, if security is a big issue for you, consider out of band management only and disable inband management (ie. telnet to device).
5. Use something other than vlan 1 for user and management traffic.
6. Prune all vlans (inc vlan 1) where they are not needed.
7. Where possible, prune the management vlan from any trunks that don't require it.
8. Consider mac security and/or 802.1x port authentication.
9. Disable unused ports.
10. Disable auto trunk negotiation on switch ports that don't need to trunk.
11. Consider removing the native vlan from all trunk links or using something totally unique for that trunk port only.
12. Consider private vlans if vlans don't need to speak to each other.
13. Consider RSTP or MST as your preferred spanning tree protocol.
14. Enable UDLD where you have uplinks.
15. Have 2 (don't need anymore) VTP servers in your VTP domain.
16. I prfer to use VTP transparent mode where I can as it minimizes administrative errors. The counter to this is VTP server eases administrative overhead - it's a personal choice.
17. Set autonegotiation on all ports and attached devices EXCEPT when attaching to other routers/switches (hard code speed/duplex for these ports and devices)
18 Get the device managed via SNMP if possible to provide you with an early heads-up regarding operational issues that you'd likely otherwise miss.
19. Get the switch to log to a syslog server (be careful with the severity of the messages you log so you don't use unnecessary bandwidth/switch resources and syslog hard disk space)
20. Sync the switch with an NTP server so that any logged info correlates to the actual time it happened!
There's a lot more to consider but this is what I can think of off the top of my head.
Good luck.
- Thread starter
- #3
- Status