cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3821
Views
5
Helpful
10
Replies

Switch security best practice on public networks?

gareth_r52
Level 1
Level 1

Hello,

I am wondering if anyone has any pointers on configuring security on a Cisco 3750X switch that sits on a public (WAN) network. It will distribute connectivity to individual ASA firewalls as there are only two main links from upstream. Obviously I'll be disabling the http server, SSH (besides the management interface), etc....

I know I can create ACL's, but worried about performance? I'm looking at blocking Netbios and other protocols that are not nessesery on our network. I've been told to disable the default VLAN... is that a good idea? And instead use the management port?

I've looked around but there doesn't seem to be much information about what you should enable or disable on public switches.


Thanks in advance.

10 Replies 10

Joseph W. Doherty
Hall of Fame
Hall of Fame

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Cisco Guide to Harden Cisco IOS Devices

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080120f48.shtml

Cisco AutoSecure Data Sheet

(some of Cisco's GUI configuration packages also have a secure device section)

http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns336/networking_solutions_white_paper09186a0080183b83.shtml

Cisco Guide to Harden Cisco IOS XR Devices

(of course, yours isn't a XR, but what it discusses applies generally [much same information as 1st reference])

http://www.cisco.com/web/about/security/intelligence/CiscoIOSXR.html?referring_site=smartnavRD

3750-X switches program ACLs into hardware, as long as you don't exceed hardware resources, ACL performance is a non-issue.

3750-X uses share buffer so they are NOT very good at handling microburst on the switchport

Yes I have heard they are not good at high PPS applications, but saying that... SoftLayer seem to use 3750X with much success. I surpose it depends on the traffic levels really.

Thanks for the guides, I have already implemented those, so besides that - is there anything else that should be considered?

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

Yes I have heard they are not good at high PPS applications, but saying that... SoftLayer seem to use 3750X with much success. I surpose it depends on the traffic levels really.

It's not so much that can't handle high PPS, but often by default, they don't do well when ports are oversubscribed due to less buffer resources than say perhaps a 4900 series.  Of course if you set bounds on oversubscription ratios, by design, this problem is less likely to arise.

David's post raises an interesting point about a 3750-X being particularly sensitive to microbursts because their ports share a common buffer pool.  I've read how they can easily run out of port buffers because there's insufficient buffer resources to provide every port a large dedicated buffer pool.  This can be mitigated by yielding port dedicated buffers back to the common pool so a busy port can drawn from it.  Doing this, I could see, might lead to a microburst issues, i.e. the port can't allocate buffers from the common pool fast enough.  Again, though, this might be avoided by design or perhaps other mitigation techniques (for example, I wonder if "shut" inactive ports still reserve buffer resources, if not fewer active ports on the 3750-X might allow those buffers to be reserved by other active ports).

Thanks for the guides, I have already implemented those, so besides that - is there anything else that should be considered?

Those guides should cover about 99% for hardening the device.  What always helps my thinking is keeping in mind the difference between traffic transiting a device vs. traffic directed to that device.  I start with the premise all traffic is allowed to transit the device but no traffic is allowed to the device and then amend as necessary.

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

david.tran@finra.org wrote:

3750-X uses share buffer so they are NOT very good at handling microburst on the switchport

David, I don't recall reading anything specific about 3750-X microburst issues due to a it using shared buffers, but I can see how it could be an issue.  Usually the complaint about 3560/3750 lack of buffers is due to QoS activation which dedicates, by default, reserves 1/4 the buffers per port egress queue.  (Hmm, that might validate the issue, as I don't believe that changes the common pool reservation.  BTW, this is a nice document: https://supportforums.cisco.com/docs/DOC-8093)

Do you have any references you could provide on this phenomena?

David, I don't recall reading anything specific about 3750-X microburst issues due to a it using shared buffers, but I can see how it could be an issue.  Usually the complaint about 3560/3750 lack of buffers is due to QoS activation which dedicates, by default, reserves 1/4 the buffers per port egress queue. 

Do you have any references you could provide on this phenomena?


     Even if you reconfigure to change this behavior, the 3750-X will still have issue with microburst issue.  It is just underpowered device.  This issue gets amplified when you use the 3750-X for multicast.

Do I have any references?  Yes, TAC case and I believe I sent you the PPT on the microburst issue.  That's what TAC gave me and confirmed in my environment.

Interesting discussion. Of course, I considered the 4948 but we are looking at basically twice the price of the 3560X and 3750X switches. Assuming we are careful with the load on the switches we will be okay.
The system is working okay on a 2960S at the moment, not sure how they compare in terms of L2 but I've not had any issues with them in the environment. The 3750 is only a new addition to get routing.

Would it not be a good idea for a public switch to employ some form of rate-limiting to prevent any one port from causing this issue - or at least reduce it?


Of course this discussion reinforces what I've been telling people for years... just because it's a Gigabit switch doesn't mean it's FAST! :-)

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

Even if you reconfigure to change this behavior, the 3750-X will still have issue with microburst issue.  It is just underpowered device.  This issue gets amplified when you use the 3750-X for multicast.

Do I have any references?  Yes, TAC case and I believe I sent you the PPT on the microburst issue.  That's what TAC gave me and confirmed in my environment.

Yes, I did receive the PPT presentation (again thanks!).  I'll have to look at it again as I remember it as a presentation of microbursting in general, not a specific presentation of microbursting being a known specific issue for 3750-Xs.

Hi Joseph!

Could you send me the presentation about microburst, please? I've got the issue with 3750X output drop My email: roman_1980@rambler.ru

Review Cisco Networking for a $25 gift card