cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
894
Views
0
Helpful
12
Replies

Options for Vlan segmentation

williamk
Level 1
Level 1

Hello,

Have a mid sized campus type network with about 30 switches (All Cisco) and 24 vlans.  The network has a core switch on which there are SVIs for each of the vlans. The core switch links to the router which give internet access.  Fairly standard setup.  I have been given the task of "segmenting" the vlans and controlling what can talk to what between the vlans.  My core switches are Cisco 3850-24XS.  I have tried using VACLs on the core switch to do this, but the performance was horrible and pretty much made the network unusable. I will be replacing the 3850s with some 9300s in the near future.

What other options do I have for accomplishing this segmentation?  Router on a stick seems like a very bad option for this size network.  My only thought is replace the SVIs on the core switch with VRFs, then do ACLs between the VRFs.  Never attempted that before, so not sure if it is possible or practical.  Also not sure if that will give any better performance then VACLs.  I do have budget constraints, so am hoping to accomplish this using existing equipment.

12 Replies 12

Martin L
VIP
VIP

What is cause for this "segmenting"  in first place? Why do u think u need "segmenting" current network? What has changed recently?

If ain't broken, don't fix it is my approach.  With 24 vlans already, I would say your network is already segmented. Maybe hardware upgrade is all that you need along with Topology change

Regards, ML
**Please Rate All Helpful Responses **

I agree with you Martin, but we have been told by a security consulting firm that having multiple vlans that are "wide open" is bad practice.  If say host on vlan 2 is compromised, it has access to all hosts on all vlans.  It should be setup so that compromised host can only access internet and whatever bare minimum connections it needs to hosts on other vlans.

Laugh - no doubt a "security consulting firm" would say that.

Are they correct?  Yes, but often context and other considerations aren't fully considered.

For example, I do a security audit of your work area and find you have 34 cents sitting in an unlocked desk drawer.  With that desk drawer being "wide open", anyone could take that 34 cents and use if for any purpose, even nefarious purposes!  So, what you should do is install this 10 ton safe, with time lock, multiple keys requiring concurrent operation, an alarm system and perhaps a full time guard (subscription), to plug this security hole.  Oh, and we're running a special, for a mere $499,999.99, we can provide this for you too, and if you order before midnight, tonight, your first six months of your guard will be free, a savings of $50,000!

Are you protecting 34 cents or a million dollars?  Value of what's being protected often very much influences what you'll spend to secure your asset.

Did the "security consulting firm" also audit all hosts for their security vulnerabilities?

The "security consulting firm" suggests Internet access is part of a bare minimum connections for any and all hosts?  (Hmm, Internet is often considered a primary vector for "bad" stuff.  I.e. what's the source(s)/probability(ies) for a host being compromised?)

Has anyone estimated the initial costs and on-going OPEX costs to maintain this security model?

Again, not saying the "security consulting firm" is wrong, but hopefully they, and your company, have done an analysis beyond just what might be an attack vector but the odds of that attack vector being used and the cost of trying to preclude its usage.

Joseph W. Doherty
Hall of Fame
Hall of Fame

Since your VLANs all have SVIs on the core L3 switch, and since you seem to want to be able to control access between VLANs ("and controlling what can talk to what between the vlans."), unclear why you tried using VACLs and not ACLs on the SVIs.  (The ACLs should be wire speed.)

VACLs would be useful if you were trying to control access between hosts within the SAME VLAN.

Oh, and if you do want to block most intra-VLAN host to host communication, have you looked into PVLANs?

Regarding VRFs, that's if you want to segment into L3 domains, just like VLANs segregate L2, VRF segregates L3.  Basically, by default, one VRF doesn't know of IPs beyond its own L3 VRF domain.

williamk
Level 1
Level 1

I tend to agree with you Joseph.  In my opinion good endpoint protection and a good next gen firewall is adaquate enough for my network, but I'm just a basic know nothing network admin and not a "security consultant".  As such I have been asked by the powers that be to look into options.

I have not looked into PVLANS, but will certainly do so.  Perhaps I am using the wrong terminology when I say VACL.  I basically applied Access Lists to very vlan.  These access lists permitted or allowed traffic between the different vlans.  The result was a very slow network.  This was a time ago, but I thought the Cisco examples I used to configure it called them VLAN Access Lists or VACLs.  Correct me if I'm wrong.  Network terminology can be confusing, especially when you start talking different vendors.

Can you provide a config snippet example of what you had tried?

VACLs are a specific varient of an ACL, so it's possible you're misusing the term.

"Regular" ACLs, and possibly variants like VACLs should be wire speed unless they're being done in software.  Some ACLs options might force software processing as might running out of TCAM (the latter impacted by the SDM [as mentioned by @Martin L] template being used).

Martin L
VIP
VIP

You may want to look at switch SDM switching platform preferences; aka SDM template. SDM should be change or adopt based on your switch role in topology especially if you notice performance issues.  Command should be sdm prefer and show sdm prefer (or check docs). Refer to your 3850 switch docs for recommendations.  i.e. Core switch should be adopted for routing SDM.

 

Regards, ML
**Please Rate All Helpful Responses **

williamk
Level 1
Level 1

Hi guys,

Here is a real basic example of what I did.  This is for vlan 220.

ip access-list extended GuestACL
permit ip host 192.168.61.7 any
permit udp 192.168.220.0 0.0.0.255 host 192.168.61.5 eq bootps
permit udp 192.168.220.0 0.0.0.255 host 192.168.61.5 eq bootpc
permit udp 192.168.220.0 0.0.0.255 host 192.168.61.6 eq bootps
permit udp 192.168.220.0 0.0.0.255 host 192.168.61.6 eq bootpc
deny ip 192.168.61.0 0.0.0.255 192.168.220.0 0.0.0.255
permit ip any any

vlan access-map GuestACL 10
action forward
match ip address GuestACL
vlan filter GuestACL vlan-list 220

On the SDM front.  Below is the output of show sdm prefer from current core 3850 stack.  I've never tinkered with SDM templates before, so would have to do a lot of reading on that.

Showing SDM Template Info

This is the Advanced (high scale) template.
Number of VLANs: 4094
Unicast MAC addresses: 32768
Overflow Unicast MAC addresses: 512
IGMP and Multicast groups: 8192
Overflow IGMP and Multicast groups: 512
Directly connected routes: 16384
Indirect routes: 7168
Security Access Control Entries: 3072
QoS Access Control Entries: 2816
Policy Based Routing ACEs: 1024
Netflow ACEs: 768
Wireless Input Microflow policer ACEs: 256
Wireless Output Microflow policer ACEs: 256
Flow SPAN ACEs: 512
Tunnels: 256
Control Plane Entries: 512
Input Netflow flows: 8192
Output Netflow flows: 16384
SGT/DGT entries: 4096
SGT/DGT Overflow entries: 512
These numbers are typical for L2 and IPv4 features.
Some features such as IPv6, use up double the entry size;
so only half as many entries can be created.

You example is a VACL.

What IOS version were (are) you running when you tried the VACL?

williamk
Level 1
Level 1

Am and was running 03.07.05E.  Very old I know.  Problem is we are a 24X7 operation, so finding a window to upgrade a core switch can be problematic.  If I implement this again though, it would be on a 9300 stack with the latest IOS.

You don't need to upgrade the IOS to be able to use layer-3 access list. The access list works pretty much with all the versions.

https://www.cisco.com/en/US/docs/switches/lan/catalyst3850/software/release/3se/consolidated_guide/b_consolidated_3850_3se_cg_chapter_0111001.html#concept_261535CB68494213866BADEFD314085B

HTH

Hi Reza, 

The access-list worked fine.  The issue was very slow performance.  This begs the question of whether or not the hardware simply couldn't handle the overhead created by the ACLs or perhaps a problem with the old IOS.

Review Cisco Networking products for a $25 gift card