cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1520
Views
0
Helpful
4
Replies
alistair.cowan
Beginner

Simple Catalyst Setup - 3750-X (IP Base)

Hi Folks,

Bit of a newbie topic here - my apologies if this is extremely straightforward!  I have been asked last minute to recommend and order up a Layer 3 switch for a customer project - a simple segmented core network implementation...  I need to get something recommended and ordered up tomorrow morning - I've read as much Cisco documentation as I can in a three hour period, and would really appreciate someone to confirm my thinking is correct...

Please take a look at the attached JPG which I've just put together.

The setup is very simple:

  • 2x 3750-X running the latest IP Base IOS
  • Stacked together using two StackWise+ cables.
  • Both switches have around 10 VLANs configured, each containing their own class C subnet.
  • The switches have Switch Virtual Interface(s) configured for each VLAN, and use this to provide Layer 3 routing between the local VLANs, as well as the uplinked ASA firewall transit network(s)
  • ACLs are assigned to each L3 VLAN to ensure that only permitted L3 traffic is allowed (implicit deny) to be routed between those VLANs - based on source/destination/ports/protocol etc
  • The SVI(s) are configured to be HA - if one switch fails, the other switch takes over SVI and therefore full network routing is still 100% available.

Does the above all seem correct/feasible, running IP Base IOS?

Some queries:

  • I read that VTP is required in this scenario - is this definitely the case in a stacked environment, or is the VLAN configuration replicated as part of the stacked configuration replication?
  • If VTP is required, does that also imply that Ethernet (trunk?) uplinks are required between the two switches to carry the VTP information, or will this also be handled by the stacking cables?
  • Will the stack handle the HA of the L3 routing SVI's, or will I need to configure HSRP (or equivalent) here?
  • I read that VLAN ACLs are not direction-orientated - does that make them similiar in operation to VPN ACLs from the ASA series?  I've had issues with VPN ACLs before when it comes to dynamic port allocation (as used by RPC/Windows file sharing, etcetera)

I have experience with Cisco ASA and IOS from a routing perspective, but have not yet worked with IOS from a switching perspective - hence the queries!

Any advice greatly appreciated!

Alistair

2 ACCEPTED SOLUTIONS

Accepted Solutions
the-lebowski
Enthusiast

You seem to have the jist of it.  Some clarification on your questions below:

  • I read that VTP is required in this scenario - is this  definitely the case in a stacked environment, or is the VLAN  configuration replicated as part of the stacked configuration  replication?
  • Not necessary in this configuration.  Its a stack so the switches will act as one and you will configure them as one.  You can use VTP for your access layer if you want but that isn't something that is required when you stack switches. 
  • If VTP is required, does that also imply that  Ethernet (trunk?) uplinks are required between the two switches to carry  the VTP information, or will this also be handled by the stacking  cables?
  • Again they will act as one switch, so no trunks between the stacked switches is required.  If you want redundancy from the stack you should have trunks out to your access layer from each switch in-case one or the other fails. 
  • Will the stack handle the HA of the L3 routing SVI's, or will I need to configure HSRP (or equivalent) here?
  • Again one switch, so no HA with a stack.  The stack will route accordingly.  You can have redundancy across the two switches if you configure them accordingly. 
  • I  read that VLAN ACLs are not direction-orientated - does that make them  similiar in operation to VPN ACLs from the ASA series?  I've had issues  with VPN ACLs before when it comes to dynamic port allocation (as used  by RPC/Windows file sharing, etcetera)
  • Not sure what you mean here. VLAN ACLs are funky and in my experience I have had to use VLAN access maps to block traffic to and from SVI ip addresses.  Otherwise I just use regular ACLs.

View solution in original post

You have routing redundancy across the stack, if one of the switches fails the other will take over.  However, depending on how you have that stack connected to the rest of the network will determine whether or not your network remains up.  IE best practice is to have trunks or connections to your access layer via both switches in the stack.  So that if one switch goes down the other can take over and not sacrifice the entire network. 

I mean L3 ACLs like you would configure on a router, as your L3 3750's is essentially a router with lots of ports.  The problem I run into with SVIs is the traffic is not going out/in a specific physical interface.  Its going in/out virtual interfaces and I was never clear on whether or not you could apply an extended access-list ona virtual interface. 

Maybe someone else here can chime in to give a better explanation. 

View solution in original post

4 REPLIES 4
the-lebowski
Enthusiast

You seem to have the jist of it.  Some clarification on your questions below:

  • I read that VTP is required in this scenario - is this  definitely the case in a stacked environment, or is the VLAN  configuration replicated as part of the stacked configuration  replication?
  • Not necessary in this configuration.  Its a stack so the switches will act as one and you will configure them as one.  You can use VTP for your access layer if you want but that isn't something that is required when you stack switches. 
  • If VTP is required, does that also imply that  Ethernet (trunk?) uplinks are required between the two switches to carry  the VTP information, or will this also be handled by the stacking  cables?
  • Again they will act as one switch, so no trunks between the stacked switches is required.  If you want redundancy from the stack you should have trunks out to your access layer from each switch in-case one or the other fails. 
  • Will the stack handle the HA of the L3 routing SVI's, or will I need to configure HSRP (or equivalent) here?
  • Again one switch, so no HA with a stack.  The stack will route accordingly.  You can have redundancy across the two switches if you configure them accordingly. 
  • I  read that VLAN ACLs are not direction-orientated - does that make them  similiar in operation to VPN ACLs from the ASA series?  I've had issues  with VPN ACLs before when it comes to dynamic port allocation (as used  by RPC/Windows file sharing, etcetera)
  • Not sure what you mean here. VLAN ACLs are funky and in my experience I have had to use VLAN access maps to block traffic to and from SVI ip addresses.  Otherwise I just use regular ACLs.

Many thanks for the quick response... 9mins, that has to be a record

That all sounds good from my point of view..

At the risk of stating the obvious, I'd just like to confirm I understand this response correctly:

Again one switch, so no HA with a stack.  The stack will route accordingly.  You can have redundancy across the two switches if you configure them accordingly.

You are stating the fact that I won't have stack routing redundancy (as there's only one stack), however it is possible to have routing redundancy across the two switches, i.e. internal stack redundancy?  At this point in time we are only really concerned about individual switch redundancy - we will provision a separate stack if/when we feel stack-redundancy is required.

And regarding this response:

VLAN ACLs are funky and in my experience I have had to use VLAN access maps to block traffic to and from SVI ip addresses.  Otherwise I just use regular ACLs.

When you say "regular" ACLs - do you mean layer 2 ACLs?  Or do you mean standard IOS L3 ACLs?  I'm just trying to understand if VLAN ACLs are my only filtering option here, or can I use "regular" ACLs applied elsewhere to control inter-VLAN traffic routing?

PS. I have had previous issues with dynamic port return traffic in VPN ACLs as per this thread here .  Basically, with my lack of Cisco expertise, VPN ACLs were also "funky" and a bit of a nightmare to manage.  Luckily those VPN ACLs were relatively straightforward, but if VLAN ACLs operate the same way I'd be worried about having to rely on them for relatively complex inter-VLAN routing ACLs...

Thanks,

Alistair

You have routing redundancy across the stack, if one of the switches fails the other will take over.  However, depending on how you have that stack connected to the rest of the network will determine whether or not your network remains up.  IE best practice is to have trunks or connections to your access layer via both switches in the stack.  So that if one switch goes down the other can take over and not sacrifice the entire network. 

I mean L3 ACLs like you would configure on a router, as your L3 3750's is essentially a router with lots of ports.  The problem I run into with SVIs is the traffic is not going out/in a specific physical interface.  Its going in/out virtual interfaces and I was never clear on whether or not you could apply an extended access-list ona virtual interface. 

Maybe someone else here can chime in to give a better explanation. 

Hmm, I think I may be stuck with SVI as these switches will be serving as both the core and server access layer due to budget constraints, I'm not sure a routed port will do my job in this case...

From this page, it looks like VLAN Access Maps are the only way to filter traffic, and unfortunately they are directionless just like VPN filters in an ASA...

On a related note, another query (apologies!)...

Both switches will be configured with 4 - 8 ports statically assigned to each VLAN.  Each server will have NIC teaming (probably active/active link-based initially), with one connection into the appropriate VLAN port on each switch.

Therefore, each VLAN's routing SVI must be available on each VLAN switch port on both switches, if that makes sense?  Otherwise we could run into an issue whereby a server is transmitting to one switch, but the SVI is only active on the other...

Thanks,

Alistair