Traffic Isolation

[Marc Bouchard]

I posted a few times here regarding the design I'm working on and I have another issue/question.

The design is a collapsed core, with routed access layer.

On each access switch, I have 4 VLANs. Data (10), VoIP (40), Wifi (20) and Wifi Guests (30), as well as local SVIs for each VLAN, which are in turn connected to the core layer via point-to-point interfaces.

Once the traffic moves into L3, there's no more isolation, as every subnet is routed to the core.

Q1: How do I isolate traffic

a) locally on the access switch, so that the various VLANs can't be routed between each other?

b) same when they reach the core layer?

Q2: They do however need to talk to the same VLAN on other access switches (VoIP for example)

Q3: Wifi Guests need to go directly to the web, nowhere else.

What I'm working with: 3560x switches with IP Base image, 4900M Core/Distribution switches with IP Services image

Ignore the static paths in the diagram, it's a BNT switch that I am stuck with

I have read about VRF (way above my current skill level/knowledge), which seems to be exactly what I need and Policy Based Routing (not supported by IP BASE image afaik). What are my options? (Please don't say training for VRF and purchasing IP Services for PBR lol)

[Reza Sharifi]

I know, I am not answering you question, but looking at your design, you have 2 access layer switches that are  doing routing. (according to your post) I also see the same vlans on both switches. why? I hope the subnets are not the same.

In a routed access layer you can't have the same subnet in 2 different switches.Can you clarify?

[Marc Bouchard]

Simply to standardise the configuration on all access switches. In this configuration, they are locally significant and they all have their own subnets.

EDIT: I also use the VLAN ID in the addressing scheme...

VLAN 10 on switch 1 will be in the IP range 10.101.10.0/24

VLAN 20 on switch 2 will be in the IP range 10.102.20.0/24

and so on...

There is no point in complicating the design by having unique VLAN IDs on every switch if they don't see each other (as far as I know)

[naresh.narang]

1. Use private VLANs on access switches.

2. Use ACLs on core.

3. Wireless can go directly to firewall interface, no need to be on core.

Sent from Cisco Technical Support iPhone App

[Marc Bouchard]

Thanks Naresh.

1. I hadn't thought of using PVLANs for that but that's not a bad idea. I was thinking more about affecting routing or blocking with ACLs. I'll dig into that option for sure.

2. Any examples for the ACLs on core to say allow VLAN 10 in switch A (10.101.10.0/24) to talk to VLAN 10 in switch B

(10.102.10.0/24) as well as accessing the servers in the datacenter (10.10.110.0/24) ?

3. Not sure I follow what you're saying here... If I have a wireless device in VLAN 30 on Switch A, its packets need to Switch A, then Core A or B, then DataCenter Switch, then finally the ASA.

Can I configure the next hop on Switch A (for VLAN 30) to be the ASA directly?

[Marc Bouchard]

Oops.. Voice VLANs can't be defined on PVLANs if I recall correctly...

[Reza Sharifi]

It is a common practice to have a unique vlan id for each subnet.  It also reduces confusion for people who manage the network.

If you do  not want the vlans to talk to each other, then you can deploy something  like this example and apply it to these vlans.  In this case vlan 10 can not communicate with vlan 20 but everything else.

vlan 10 = 192.168.10.0/24

vlan 20= 192.168.20.0/24

access-list 200 deny ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255

access-list 200 permit ip 192.168.10.0 0.0.0.255 any

int vlan 10

ip access-group 200 out

HTH

[Marc Bouchard]

Regarding the VLAN IDs, I ran that by a CCIE friend of mine and he agreed that was a good choice since the VLAN IDs are locally significant. There is no confusion here. VLAN 10 is Data VLAN everywhere, and being in a routed environment means they all have different subnets. In a switched environment, that's a different story unless you want end-to-end VLANs.

Thanks for the ALC suggestion. I think I might be better off permitting only what I want than denying everything one by one (I'd have 5 ACLs per switch with over 40-50 lines per ACL...)

I'll experiment with various options and see what I can come up with.

[Marc Bouchard]

IOS accepts this but I wonder if that's a good way of doing things.

My addressing is as follows:

A.B.C.D

A = 10 (Private Class A)

B = site identification

C = VLAN identification

D = device address

in other words, everytime I see a 10 for the 3rd octet, that's VLAN 10. I was thinking of using masks like this one to trap all 10.x.10.y addresses.

access-list 110 permit ip 10.101.10.0 0.0.0.255 10.0.10.0 0.255.0.255            (Any VLAN 10 on the network)

access-list 110 permit ip 10.101.10.0 0.0.0.255 10.0.110.0 0.255.0.255          (Any VLAN 110 on the network)

access-list 110 permit ip 10.101.10.0 0.0.0.255 10.0.120.0 0.255.0.255          (Any VLAN 120 on the network)

This would allow the workstation on Switch 1 (10.101) to access any VLAN 10s anywhere. Make sense? The logic is there, but is that something that should be done? I have no other way to summarize this to make it workable...