Block specific subnet in core switch

[Jonathan Chellis]

Hi all,

My network has subnets for each building; 10.100.x.x/16 - 10.107.x.x/16. Beyond that, we have subnets specific to routers, servers, switches, printers, and clients (x.x.10.x, x.x.20.x, etc.).

My printers are on x.x.30.x, and because of the subnet mask setting on clients (255.255.0.0) anyone can send a print job from one building to another. One of my buildings has been getting reams of print jobs clearly printed from another building and I'd like to block it on our core WAN switch.

Each building is connected via fiber to our core, a Catalyst 3750G. 

I'm new to the Cisco experience so I'm wondering how I can block traffic only in my x.x.30.x subnet from passing through my core switch. All traffic in other subnets must continue to be allowed.

Any help is appreciated. Thanks in advance!

[Jon Marshall]

It's not clear where the core switch is in relation to the buildings ie. does each building have it's own L3 switch and then a specific building has the core switch and all switches are connected to the core switch using L3 routed links ?

Or are the non core switch buildings using L2 switches and all the routing is done on the core switch and you use SVIs on the core switch for the building interconnections.

Are you looking to block just in one of the buildings or do you want to stop any print jobs being sent from one building to another.

Put simply we need to understand how everything is connected or else we can't really tell you where to apply the acl(s) and obviously we don't want to get it wrong as this could seriously affect your network.

Jon

[Jonathan Chellis]

Each building has it's own set of L2 switches to manage all connections in that building. One L2 switch in each building is run back to our core which manages all routing between buildings. The core 3750G happens to reside in one of our buildings but is still connected to that building via fiber link, same as the other buildings. A "star" pattern, with the center of the star being the core and the buildings at the end of each point.

And to clarify; yes, I'm trying to block all print traffic at the core to stop print jobs from being sent between buildings. Since all of our printers are on our x.x.30.x subnet I figure it'd be easy to block all traffic that happens within that subnet.

[Jon Marshall]

Thanks for clarifying.

So each building has a /16 allocated to and within each building you then split this up into subnets for clients, printers etc.

So do you have multiple vlans per building and these are trunked back to the core switch ie. you have multiple SVIs per building on the core switch.

Also when you say -

My printers are on x.x.30.x, and because of the subnet mask setting on clients (255.255.0.0) anyone can send a print job from one building to another.

Does this mean even though you split up the /16 you are still using a class B subnet mask for all the subnets ?

Sorry for all the questions but I'm not fully understanding how you have this setup ie. what does the clients subnet mask have to do with accessing the printers.

Jon

[Jonathan Chellis]

Each port on the core is set up to trunk all VLANs everywhere. Separate VLANs for data and voice for each building, and SVIs configured to each VLAN.

Yes; we use a class B subnet mask even though it's split up further.

Happy to clarify anything further if necessary. Thanks for your help.

[Jon Marshall]

Every now and then I get a post where I just can't seem to follow the setup.

Your original post seems to suggest each building has it's own printer vlan. This has to be routed on the 3750. So if you take one building, if a client in that building submits a print job it is sent via the L2 trunk to the core switch, routed from the client vlan onto the print vlan and sent back down the trunk link to the printer.

Is that correct ?

If so do you simply want to ensure that when the client submits the job it cannot be sent to any other buildings printers ?

Where my confusion is coming in is to do with the subnet mask. You may be using a class B on the clients but the SVIs for the vlans per building can't all use a class B as the 3750 wouldn't allow you to configure this (overlapping IPs)  so they must have the more specific subnet masks.

Once again, apologies for all the questions but it's still not entirely clear to me.

Jon

[Jonathan Chellis]

Each building has two unique VLANs; one for voice and one for data (everything else). No two VLAN identifiers are the same between buildings (ex. VLAN 10 and 100 belong to one building, 11 and 101 belong to another, etc). Because of our setup printers are on each building's "data" VLAN along with clients.

Each building's SVI on the core switch has it's own unique IP per building but are indeed /16 subnet masks.

And you'd be correct; I'm simply trying to prevent print jobs from being sent between buildings.

If printers were indeed on their own VLAN that'd make it easier, but the complex topology of our buildings makes setting that up pretty difficult.

[Jon Marshall · Accepted solution]

Okay, it's making more sense now.

One last question.

The clients use a class B subnet mask. Do the printers also use a class B subnet mask. So when a client talks to a printer in the same building does the traffic stay local to the building rather than go via the 3750 ie.

clients looks up printer IP and sees it is on the same IP subnet (because it has a class B subnet mask). The client sends the traffic to the printer. If the printer also has a class B subnet mask it sends traffic back to client. But if the printer has a /24 subnet mask it has to send it to the SVI on the 3750 which then forwards it to the client.

So, assuming a class B subnet mask, local printer traffic never gets to the SVI, only printer traffic destined for other buildings. In which case you can simply apply an acl inbound on the SVI per building denying any traffic destined for the remote printer subnets x.x.30.x and then obviously permitting everything else.

It really comes down to whether the printers are using a class B subnet mask as well.

Does this make sense ?

Jon

[paul driver]

hello

I think i may a picture of your network however if the printer does indeed has i own SVI on the core switch then i guess RACLs could be a solution

acess List 100 permit ip (allowed building subnet) host (building printer)

access-list 100 etc....

int x/x  ( printer svi)

ip access-group 100 out

res

paul

[Jonathan Chellis]

Yep, printers are on the same subnet mask. 

So I'd have to create a separate ACL for each SVI and destination building pair; is that accurate?

[Jon Marshall · Accepted solution]

Yes, you would need an acl per SVI.

Each acl would deny the source class B from accessing any of the remote class C x.x.30.x networks. Note that is important the destination network uses a class C wildcard mask otherwise you will stop all inter building traffic eg.

access-list 101 deny ip 10.100.0.0 0.0.255.255 10.101.30.0 0.0.0.255

access-list 101 deny ip 10.100.0.0 0.0.255.255 10.102.30.0 0.0.0.255

etc. ie. a line for each remote building

access-list 101 permit ip 10.100.0.0 0.0.255.255 any  <-- for everything else

the above acl would be applied inbound on the SVI for the building using 10.100.0.0/16.

Then you would create acls for each of the other SVI's obviously changing the acl number and the source network to match the buildings class B.

It's a bit tedious but once done you are not going to need to change them.

You could actually probably use the same acl for all SVIs if you get a bit fancy with the wildcard mask but it's been a while since I did those so I'd need a bit of time to work it out and I'd hate to give you the wrong one and bring your network down :-).

If any of the above is unclear then please let me know before implementing.

Jon

[Jonathan Chellis]

Perfect! Exactly what I was looking for.

Much appreciated.