Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Webcast-Catalyst9k
New Member

2960s - VLAN & ACL implementation

A company with a flat network has an estate of 2960 switches. They also have Sophos UTM 425 devices with 4 spare ports.

They need to implement VLANs with ACLs to segment the network. Is it possible to implement the ACLs on the switches? Or would the VLANs need to be trunked and the Firewall provide the access control implementation?

Or will they need to upgrade the switch estate to L3 switches?

Look forward to your comments.

PL

Everyone's tags (1)
9 REPLIES

2960s - VLAN & ACL implementation

The switch only does static routing. So it's not really suited for a firewall/filtering device, it does support ACLs though. Both on the physical port and SVI but it will only do static routes. So it's probably better to route the traffic to the firewall.

Daniel Dib
CCIE #37149

Please rate helpful posts.

Daniel Dib CCIE #37149 Please rate helpful posts.
Hall of Fame Super Blue

2960s - VLAN & ACL implementation

Just to add to Daniel's post.

It all depends on how many vlans you need. As Daniel says the 2960 is limited in the number of vlans it can route for and also the type of routing ie. static only.

I'm not a big fan of routing off firewalls unless you have very strict security requirements because -

a) you often need to use subinterfaces which means each vlan is only allowed a portion of the total bandwidth of the interface

b) the configuration needed on the firewall can often become quite complex.

But it is an option. The acls used on a switch are not stateful so it depends on exactly how you want to control the traffic as to whether they are appropriate or not eg.

vlan x is not allowed to talk to vlan y is perfectly fine with these type of acls

vlan x is not allowed to initiate connections to vlan y but can send return traffic to vlan y if the connection was initiated from vlan y - this is more challenging with these type of acls and where a stateful firewall becomes more useful.

Finally, if you are going to be having a lot of vlans and providing the control of traffic between vlans is not that complex (as mentioned above) a L3 switch to do the inter vlan routing is also a valid choice.

So it all comes down to how many vlans and what type of traffic filtering/control you need.

Jon

New Member

Re: 2960s - VLAN & ACL implementation

Thank you both for your responses.

@Jon

There is currently no requirement for stateful filtering inter-VLAN, it really is only a requirement for stateless; defining whether A and B can talk to each other. They'll probably end up with no more than 12 VLANs at the very most.

So are we essentially saying that:

Yes VLANs can be implemented on 2960s (...but only 16 static routes available on 2960)

Yes ACLs can be applied on the 2960s for inter-VLAN routing

But routes will need to be manually populated in the routing table

Using L3 switches is a better option (where stateless filtering is required) because the dynamic routing will reduce the management overhead?

Is it possible to build a multi-tier architecture that uses the 2960s as access switches and L3 switches as core/distribution switches? Allowing the current 2960 estate to be maintained with only a couple of newly purchased L3 switches running HSRP used to route all traffic, meaning the only route from 2960s required is to the default gateway?

What would the considerations need to be to ensure max. bandwidth between the access layer and dist layer? Can you fit a GBIC on any model of 2960 or do they come with at least one gigabit port as standard? Unfortunately I do not have exact model details. I know that some are 2960G but suspect the others are not.

Many thanks

PL

Hall of Fame Super Blue

2960s - VLAN & ACL implementation

PL

I can't find a reference to 3960s, do you mean something else ?

How many 2960s are there ?

When you were talking about doing inter vlan routing on the 2960s were you envisaging doing it on each one or using one for all the others etc ?

Apologies for all the questions but it wouldl help to know what exactly the current setup is and how you were planning to route on the 2960s.

In answer to your general question (assuming when you say 3960s you were referring to some sort of L3 switch) yes this may be a better design but it depends on how many 2960s there are in terms of uplinks etc.

Jon

New Member

Re: 2960s - VLAN & ACL implementation

Yes. Apologies. For 3960 read "L3 switch". I have edited the posts above for clarity.

They have 7 2960s currently - 5 x 2960, 2x 2960G with the 2x Gs providing uplink to the other 5.

I wasn't sure how inter-VLAN routing could be achieved on the 2960s, hence the original question. What I'm aiming to do is find an alternative architecture to ripping and replacing all the 2960s with L3 switches, which seems not only costly, but unnecessary.

So if there are  7x 2960s at the moment: it seems feasible to just replace the two G models with L3 devices (these will still act as access switches as well as providing routing).

Thank you for asking all the questions!

PL

Hall of Fame Super Blue

Re: 2960s - VLAN & ACL implementation

PL

No problem, i thought maybe there was a new switch i hadn't heard about

Without wishing to overload you with information there is quite a bit to cover.

You certainly do not need to get rid of all your 2960s. Even if you purchase some L3 switches your 2960s could be used as access switches uplinked to the L3 switches.  Unless you have 2960-S switches you cannot stack the 2960s so if you wanted to do inter vlan routing on your existing switches you would use the 2960Gs and connect them with a L2 trunk, configure the L2 vlans and L3 vlan interfaces on each switch and then run HSRP between them for the end clients. To be honest i do not know how far these switches will go though in terms of L3 features ie. i dont know whether they even support HSRP so it would need testing.

If you did the above the other 2960s would be uplinked to both switches and end devices should really only be connected to the access switches because if you connected them to the 2960 pair doing inter vlan routing (distro switches) they lose the benefit of HSRP.

The cons to the above, apart from potentially not supporting HSRP,, is that the distro pair might become overloaded  depending on traffic and each access switch can only use one of it's uplinks per vlan. You can load balance the vlans across each uplinks and I can help with that if you decide that is the way you want to go. That said it sounds like the 2960Gs are uplinked to all the other switches anyway so this may be worth trying out.

In terms of routing, because all the vlans would be local to the distro pair the routing table would be automatically populated with connected routes. You would probably only need a default route pointing to the firewall for internet and routes on the firewall for the vlans/IP subnets on the 2960 switch.

If you decided to go with L3 switches for the inter vlan routing then i would recommend a pair of stackable switches. The advantage of this is that you can uplink your access switches to both members of the stack and then both uplinks can be used for each vlan so you get double the throughput compared to the 2960 solution. In addition there is no need to configure HSRP as you only configure the stack master and the config is available to both members of the stack. The only downside to stacks is when you need to upgrade the IOS it can take out the entire stack but this is not a major issue in my opinion as you don't upgrade that often.

Note that with your setup in terms of dynamic vs static routing you won't see much benefit, it is more to do with the advantages outlined above.

The next thing to consider is uplinks. Stackable switches such as the 3750/3850s have primarily copper ports. 4500/6500 switches running VSS can have a much larger set of fibre ports. Fibre ports are generally used to uplink switches and this is one of the reasons Cisco position the 4500/6500s as distribution switches and the 3750/3850 stackable switches as access switches. But there are people using 3750/3850s as a small distro set of switches. The main things to consider are -

1) the fibre uplink ports on switches are generally designed to run at wire speed ie. no oversubscription. The copper port for end device may not support wire speed so if you are using copper to uplink to other switches this may introduce oversubscription.

2) distance limitations with copper vs fibre. It depends on how far away your switches as to whether or not you can use copper ports.

So with 7 2960s each with 2 Gbps uplinks you would need 14 available fibre ports on the stackable switches, 7 on each. There are certain 3750s that support come only with 12 or 24 fibre ports but with the introduction of the 3850s the 3750s may not be the best future proofing. The 3850s only have 4 x 1Gbps fibre ports as far as i can see which isn't enough.

Ideally you would want to use the fibre uplinks from the 2960s and not copper so it would be better if the stack supported enough fibre ports or supported a convertor from fibre to copper. This is one area i am not that familiar with but i know a couple of people in these forums who know a fair bit about this so i'll drop them a line and see what they recommend.

So in summary a lot does depends on the amount of traffic you have. Currently your 2960G switches are uplinked to all the others so you might be able to get away with simply interconnecting those switches with a L2 trunk and using these to route between the vlans. As i say though having clients directly connected to these switches means HSRP will not supply a redundant gateway for those clients.

Hope i haven't just confused you. I'll try and get a couple of other guys to have a look in terms of uplinks/switch recommendations if you decide to purchase some L3 switches.

Jon

Super Bronze

Re: 2960s - VLAN & ACL implementation

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

Hope i haven't just confused you. I'll try and get a couple of other guys to have a look in terms of uplinks/switch recommendations if you decide to purchase some L3 switches.

I'm one of the other guys - Jon asked. 

As Jon notes, the 3750X series provides 12 or 24 ports SFP switches.  These also take the SFP modules, so you can add another 4 SFP ports (or 2 SFP and 1 SFP+ or 2 SFP+).  Those models should provide sufficient ports so you could attach all your existing switches to them.  A dual stack would allow hardware redundancy, for your collapsed core, and downlink redundancy if you use dual Etherchannel.

StackWisePlus offers dual 16 Gbps, so if you don't use 10g, for a dual stack, there's no ring oversubscription to 2:1 oversubscription.

There are other advantages to having a stack, as Jon notes.  The disadvantage of the 3750X series, they are getting "old", and the newer 3650s or 3850s offer improvements, but as Jon also noted, they don't (yet?) offer any SFP models.

One common issue with 3750X series, they don't provide a lot of memory for port buffering.  But aside from that, then can do VLANs, ACLs and routing.

Hall of Fame Super Blue

2960s - VLAN & ACL implementation

Joeph

Thanks for that.

Jon

New Member

Re: 2960s - VLAN & ACL implementation

Thank you to both for the detailed responses. They are much appreciated. The information you have given has been of great use.

Best wishes

PL

914
Views
27
Helpful
9
Replies
CreatePlease to create content