Running Config on Cisco 3750G for Review/Analysis

Joined
Dec 5, 2003
Messages
517
I have attached my running configuration for my Cisco 3750G. A quick description of the configuration: I have several hosts and three iSCSI storage appliances that I want to isolate from my public LAN. However, I want to be able to access the management interface from my Public LAN. At the same time I want to isolate my iSCSI traffic. I created a separate VLAN (VLAN 500) and moved all ports on my storage network into this VLAN. Then I configured the VLAN interface (for VLAN 500) so I could access the management functions from my stroage network. Do I need an ACL on VLAN 500 because I assigned an IP address? I assume that I am safe, as I didn't define any routes between this VLAN and the VLAN 1 that is connected to my Public LAN.

Please share any suggestions regarding this configuration, security, or performance implications.


Note: Port 21 on my Public LAN Switch is Connected to Port 24 on my SAN Switch.


CISCO 2960G Port Configuration - I don't manage this switch

interface GigabitEthernet0/21
switchport access vlan 3
switchport mode access
no logging event link-status
spanning-tree portfast




CISCO 3750G Stack - I manage this switch

version 12.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
service sequence-numbers
!
hostname CPSANSW
!
boot-start-marker
boot-end-marker
!
username XXXXX privilege 15 secret 5 X
!
no aaa new-model
clock timezone EST -5
clock summer-time EST recurring
switch 1 provision ws-c3750g-24ts
switch 2 provision ws-c3750g-24ts
system mtu routing 1500
vtp mode transparent
authentication mac-move permit
ip subnet-zero
no ip domain-lookup
ip domain-name chipit.XXXXX
!
crypto pki trustpoint HTTPS_SS_CERT_KEYPAIR
enrollment selfsigned
serial-number
revocation-check none
rsakeypair HTTPS_SS_CERT_KEYPAIR
!
crypto pki certificate chain HTTPS_SS_CERT_KEYPAIR
certificate self-signed 01
!
spanning-tree mode pvst
spanning-tree etherchannel guard misconfig
spanning-tree extend system-id
no spanning-tree vlan 1,500
!
vlan internal allocation policy ascending
!
vlan 500
name CHIP_STORAGE
!
interface GigabitEthernet1/0/1 - 23, Gi2/0/1 - 24
switchport access vlan 500
switchport mode access
flowcontrol receive desired
!
interface GigabitEthernet1/0/24
description CPSANSW MGMT UPLINK
switchport mode access
!
interface GigabitEthernet1/0/25 - 28, Gi2/0/25 - 28
shutdown
!
interface Vlan1
description MGMT VLAN
ip address 10.65.34.72 255.255.248.0
!
interface Vlan500
description STORAGE VLAN
ip address 10.32.70.1 255.255.255.0
!
ip default-gateway 10.65.32.1
ip classless
no ip http server
ip http access-class 1
ip http authentication local
ip http secure-server
!
ip sla enable reaction-alerts
!
no cdp run
!
line con 0
exec-timeout 0 0
login local
line vty 0 4
access-class 2 in
login local
transport input ssh
line vty 5 15
access-class 3 in
login local
transport input ssh
!
ntp clock-period 36029026
ntp server X
end
 
As it stands, that switch WILL route between the two vlans, all the host would need to do is set it's default gateway to the switch SVI's IP address. You will want to define ACL's and apply them to both of the SVIs.

I would also get rid of VLAN 1 for your management link back to the rest of the network. Use any other valid number except for 1, then make sure Gi1/0/24 is tagged appropriately.

I saw that you disabled spanning-tree, any particular reason why? It's a good idea to leave in place in case you or someone else makes a wiring mistake.
 
Take the IP off 500, this will make it L2 only. I thought we covered all this in your thread a couple weeks ago?

Edit: Lenny told me you want to access the switch from the storage VLAN. I don't see "ip routing" in there, but Lenny says it's the default. So do "no ip routing", that makes it a layer 2 switch which will suit your needs.
 
Last edited:
Take the IP off 500, this will make it L2 only. I thought we covered all this in your thread a couple weeks ago?

Edit: Lenny told me you want to access the switch from the storage VLAN. I don't see "ip routing" in there, but Lenny says it's the default. So do "no ip routing", that makes it a layer 2 switch which will suit your needs.

I'm about 95% sure on the ip routing default setting although I've been wrong before, I'll check it out tomorrow morning on one of mine and confirm.
 
I saw that you disabled spanning-tree, any particular reason why? It's a good idea to leave in place in case you or someone else makes a wiring mistake.

The documentation for my EqualLogic SAN recommended that I didn't use STP on access ports. If I did use it, it suggests that I use portfast. I don't see a reason, as there will be no loops in this small network. In regard to VLAN 1, I had to disable spanning tree because the port on my Public LAN switch would shutdown with STP enabled. Someone mentioned that I need to take portfast off on the Public LAN port and things should be fine... not sure why though.
 
Take the IP off 500, this will make it L2 only. I thought we covered all this in your thread a couple weeks ago?

I put this on VLAN 500 so I can manage the switch from a host within my SAN network. Also, my EqualLogic device required a default gateway.

I did a "no ip routing" within the global configuration mode, however the running config did not reflect this command. Could it be that I download a firmware without routing services? It's been 3-4 weeks since I upgraded the firmware. I did use a crypto firmware so I can use SSH and HTTPS...

So let me review. If I had routing enabled, VLAN 500 would be able to talk to VLAN 1, which can talk to my Public LAN? How does this work if there is no route to get back into my SAN network on my Public LAN?

Results after no ip-routing command:

CPSANSW#show ip route
Default gateway is 10.65.32.1

Host Gateway Last Use Total Uses Interface
ICMP redirect cache is empty
CPSANSW#


I did an "ip routing" after to test and I lost access to my switch... so I had to do a hard reset (forgot to use reload in x). What is happening here to cause me to lose access to the switch?
 
You will want to define ACL's and apply them to both of the SVIs.

I would also get rid of VLAN 1 for your management link back to the rest of the network. Use any other valid number except for 1, then make sure Gi1/0/24 is tagged appropriately.

I have two SVIs in this situation, what should the ACLs look like for these. I believe I want an ACL on the VLAN 500 interface that blocks incoming/outgoing traffic, but on VLAN 1 I don't know. Can you provide an example?

In regard to VLAN 1, I didn't think this was important. The link to my Public LAN is not a trunk (unfortunately... I don't manage these switches). The port is tagged as VLAN 3, so my thought was VLAN 1 would not add any additional risks. Why is the use of VLAN 1 considered a security hole? This has been stated to me on many occassions... I can't see what the problem is. I am just a novice... up until a couple of weeks ago I never even saw a Cisco switch.... let alone configure one. :)

Thanks everyone for your patience and guidance... I wouldn't have been able to get this far in this short of time period without your help. I did have an expert for 30-40 minutes, but his expertise is proving to have been a hinderance for me.
 
So I checked out some of my 3750's It looks like I was wrong on the ip routing default, it is not enabled by default...doh. Sorry for the confusion there, entering "no ip routing" would not show in the config because it's a default parameter. To verify whether or not ip routing is enabled, you can enter "show ip cef." With that being said, it may be easier to just leave ip routing disabled and not worry about the ACL's at all.

Regarding STP, even if you don't PLAN on having loops, it's still good to have the protection in case you make a mistake--it happens. If the 2960G switch is killing the link when you have STP enabled, it sounds like it has bpduguard applied to the port, or globally as a default. Try configuring "spanning-tree bpdufilter enable" on Gi1/0/24 on the 3750, this should disable sending of BPDU's out that interface. HOWEVER...the general idea is that you want STP to work between switches and play nice, I'd try to keep STP running between the two if it all possible.

For your SAN ports, apply the command 'switchport host' or 'spanning-tree portfast' to your access ports to speed up the process.
 
Last edited:
Lenny - Thanks for you advice regarding bridge protocol data unit filtering on Gi1/0/24... even though I didn't see this in the interface configuration I was given... must have been enabled globally. I am working with a LARGE University Network (Class B).... I don't have control over the network unfortunately (probably best that I don't given some of the silly questions I have posted here). I have learned a lot from the help I received here. Thanks again everyone for your patience and suggestions.
 
Lenny - With more thought on the situation, I have another question LOL. If I setup PortFast on my Public LAN interface and the interface on my SAN switch (Gi1/0/24). Assuming this swtich has BPDUguard enabled and then I filter BPPUs on my SAN switch interface (Gi1/0/24). How is the STP feature affected by this? Seems like loops can occur with this configuration, but again I am a complete novice here. Also, the link between by Public LAN and SAN Switch should not have PortFast, correct? I don't think there is anything I can do about this though.
 
you seem to have a fascination with PortFast that's beginning to border on irrational. In general practice you don't need to use PortFast at all, the ONLY time you need to use PortFast is when you need IMMEDIATE convergence. That is the ONLY time you need to use it.

you do not use it across trunk links, because that WILL caues loops and cause your network to crash and perhaps make it unrecoverable.

Again, YOU DO NOT NEED PORTFAST IN GENERAL PRACTICE, drill that in your head.
 
you seem to have a fascination with PortFast that's beginning to border on irrational. In general practice you don't need to use PortFast at all, the ONLY time you need to use PortFast is when you need IMMEDIATE convergence. That is the ONLY time you need to use it..
Alot of people like to get a DHCP lease without having to send out another set of DHCP req's :D. Portfast is recommended on access ports almost all of the time, if more security is needed enable BPDUguard/filter(which myself and vito have recommended in numerous threads before this).
you do not use it across trunk links, because that WILL caues loops and cause your network to crash and perhaps make it unrecoverable.
Nope, wont cause loops at all. It seems as though you think that once you use portfast on a trunk link you will automagically get loops, which is obviously not the case as a physical cabling loop would need to be introduced prior. All portfast does is skip the forward delay time, thats all.

Again, YOU DO NOT NEED PORTFAST IN GENERAL PRACTICE, drill that in your head.
Nope again, portfast is generally enabled on every single port ive ever come across on production networks, weather its standard portfast or with the trunking option.

Build you network properly and you will never run into loops. Civic, config looks pretty vanilla, but from your previous threads it seems like you wouldn't need anything crazy anyways.
 
Last edited:
^Going to have to agree here, portfast is of huge importance on end-user access ports in order to provide a quick hookup to the network. Let's not forget that enabling portfast does NOT disable STP on the interface, it just transitions the interface to the forwarding state immediately. If BPDU's are received on that interface, STP will act accordingly and start blocking if necessary.

Concerning your link from the 3750 to the 2960, you have two options here. You can make the two switches' STP instances play nice with each other, or you can macguyver it with bpdufilter. I would suggest you work with the admin of that network segment to get it straightened out. If they run BPDU Guard globally on the switch, have them disable it on the port going to your switch. If they won't, I would either enable bpdu filter on your port going to the 2960, or disable STP on the vlan tagged on that port.
 
Thanks everyone... I think I got a clear explanation of PortFast and BPDUs. The network admin SHOULD drop portfast and disable bpduguard on this port. Also should have been a trunk port. I can't do anything about it though... time to rig with the bpdu filter :).

So what is spanning tree? Just kidding... LOL.
 
Alot of people like to get a DHCP lease without having to send out another set of DHCP req's :D. Portfast is recommended on access ports almost all of the time, if more security is needed enable BPDUguard/filter(which myself and vito have recommended in numerous threads before this).

Nope, wont cause loops at all. It seems as though you think that once you use portfast on a trunk link you will automagically get loops, which is obviously not the case as a physical cabling loop would need to be introduced prior. All portfast does is skip the forward delay time, thats all.


Nope again, portfast is generally enabled on every single port ive ever come across on production networks, weather its standard portfast or with the trunking option.

Build you network properly and you will never run into loops. Civic, config looks pretty vanilla, but from your previous threads it seems like you wouldn't need anything crazy anyways.

Gotta agree here. Portfast is key in environments that are using PXE for imaging purposes, i.e. Altiris environments for imaging desktops machines. Try booting a machine to the NIC with and without portfast and you'll see what I mean. ;)
 
Back
Top