VLANs, Routing, Gateways + Rules?

[Shaun Neighbour]

Hi All

I'm a complete noob as far as VLANs are concerned - I've been reading everything I can find, but every time I find a "solution" it seems to come with a new problem..........

I'm the network admin for a school. The school is constantly expanding by around 100 workstaions per year (900 at the moment) and I think it's time to give my nice procurve switches something to do......

At the moment I've pretty much got a flat network - I do have a couple of VLANS, but these are completely seperate to the rest of the network, so were problem free.

My initial plan was to divide the network up into around 30 VLANS - A couple foe the differnt types of server, and then dividing workstations into logical groups. Student workstations would only have access to the workstations on their vlan and their servers, Staff workstations would have access to both staff and student servers, IT Support would have access to everything, and everyone would have internet access.

But when it came to planning the implementation, the scale of the task astounded me. Adding 30 IP addresses and 30 VLANs to each server......... you get the idea.

I then watched some Cisco videos on inter-VLAN routing - a quick phone call to Procurve tech support confirmed that my core switches (3400cl) could do this gave me hope that this project wasn't doomed.

But as with everything I've discovered about VLANs, nothing is that simple or straightforward. By enabling routing, i'd essentially be making the VLAN implementation pointless. I know there would be some benefits, but they wouldn't really justify the increased complexity or time taken to implement. Also the DHCP config for this scenario scares the **** out of me......

So..... Do I have completely the wrong end of the stick? Is there something I'm missing? I assumed after talking to the Procurve guy on the phone that routing would be the holy grail of VLAN implementation. I was expecting 300 pages of documentation explaining how to setup QoS rules to drop packets so that communication could only exist between the VLANS I wanted them to.

I can see that there could be a solution. As I said I am a VLAN noob, but I don't think my expectations of the technology were unrealistic.

If it's simply the case that I need to buy a bigger switch/router and that handles all the security, that's fine. I just need to be pointed in the right direction.

Thanks

Shaun

[Shaun Neighbour]

Do i just combine this with ACL?

[cenk sasmaztin]

hi Shaun

if I understand corect

planing and implement vlan config on your network.
if you send me some information, I make planing and implement vlan configuration your network

1-please send me your network layout
2-please send me all switch sh run print
3-please send me planing vlan quantity and vlan network address

good luck

[Shaun Neighbour]

Hi Cenk

Thanks for the offer. We have a few months to plan this, and would prefer to do it in-house.

IF applying ACL rules (I've just started reading the 80 pages of documentation) gets round the security aspect, then the onlt pieces left in the puzzle are how to get DHCP working, and how to get internet access working.

DHCP - From what I've read, I somehow need to get the routing switch to pass DHCP requests onto the DHCP server, but tag them somehow so the DHCP server knows which subnet pool to use.

Internet - All workstations use the sub-interface IP as their Default Gateway - But how does the router know where our external router is? I somehow need a default gateway for the sub-interfaces.

[EckerA · Accepted solution]

Hi,
for dhcp you need to apply the ip helper command at those vlans where the dhcp-server is not located.
for the internet router you applay a static route at the 3400 switch(ip route 0.0.0.0 0.0.0.0 ), but you although need to have static routes from your internet router back to the 3400 for each vlan.
something like ip route 192.168.0.0 255.255.255.0 . <-Syntax depends of the internet router.
hope this helps
alex

[Shaun Neighbour]

Thanks EckerA!

Am I on the right track with ACL's?

[RicN]

Yes, ACL:s is the way to go. You implement the ACL:s on the switch were your VLANs is routed.

If you just wants to restrict which network (VLAN) that can access which other VLANs than the configuration should not be too complicated.

And as EckerA was saying, use the "ip helper IP-ADDRESS-OF-YOUR-DHCP-SERVER" command on each vlan on the switch with routing, and the switch will include information so the dhcp-server will pick addresses from the correct scope. Just define them on the dhcp server and it will be working! :)

[Shaun Neighbour]

Excellent stuff.

Time to start building some test networks...........

[André Beck]

Shaun,

> Am I on the right track with ACL's?

In principle, yes. You use VLANs to partition your network into multiple isolated broadcast domains, put IP networks on top of the broadcast domains and use L3 switches (aka routers) to again allow communication between those IP networks, this time on L3 only. If you need to control which IP addresses can talk to which, the solution on an L3 switch is to apply ACLs. Remember they are stateless, you have to allow every individual packet of more complex flows (at the minimum, consider both directions of a communications relation).

So, why "in principle"? Sadly, the cl platform (I'm not entirely sure for the 3400cl, but have this issue with 6400cl) has a completely insufficient ACL implementation for an L3 switch. Instead of applying individual ingress and egress ACLs to Switch Virtual Interfaces (the virtual IP interfaces that are anchored into a VLAN, something that is often mixed up with the VLAN itself by ProCurve documentation and even in the configuration - VLANs don't have IP addresses, they are L2 entities) this platform only has port ingress ACLs. While they can still match IP addresses, their use is rather limited by both the global way of application (they match whatever enters a port, regardless of the VLAN tag it bears) and the severe lack of resources available to the ACLs (you start to get problems with just more than 8 ACEs in an ACL, with some nearly incomprehensible options to tune out some more entries in lucky constellations).

If you ask me, for L3 control ACLs on ProCurve switches, you are better off with the yl/zl platforms. Or for that matter, even the xl. I once thought the cl was just a scaled down version of the xl line, but with comparable features. Sadly, it isn't, at least not the 6400cl. Read the docs carefully for the 3400cl ACL stuff - it might be as bad. The cl is also lacking other stuff the xl has, like IP multicast routing. They are made for the access layer IMO, and that means L2 access.

HTH,
Andre.

[Shaun Neighbour]

Hi André

The ACL documentation for the 3400cl did seem pretty concise - 80 pages in all, and stated that I could apply many more than 8 ACE's to an ACL.

ACL's are the only thing I haven't tried yet - But I'll definately try they sooner rather than later now.

Thanks for the heads up!

Shaun