Comware

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

Do i just combine this with ACL?

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

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.

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 <IP of="" internet="" router="">), 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 <IP of="" 3400="">. <-Syntax depends of the internet router.
hope this helps
alex</IP></IP>

Thanks EckerA!

Am I on the right track with ACL's?

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! :)

Excellent stuff.

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

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.

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

Re Shaun,

> The ACL documentation for the 3400cl did
> seem pretty concise - 80 pages in all

Yep. 10 pages of them are just there to explain the resource issues and half baked workarounds for the poor folks running into them (which are all of them - I bet you will hit this...)

> and stated that I could apply many more
> than 8 ACE's to an ACL.

I just had a look into the chapter called "Access Control Lists (ACLs) for the Series 3400cl and Series 6400cl Switches" from the latest Advanced Traffic Management Guide. It states that 3400cl and 6400cl are essentially the same in this matter:

* Only Ingress ACLs
* Only Port ACLs
* Severe Resource Issues when using ACLs.

Have a closer look at the part called "Planning an ACL Application..." and the table below "ACL Resource usage and Monitoring". The Caveat here is the "8 ACL Masks" limit that is even a limit of 7 masks as soon as IGMP snooping is active. You can tune an ACL somewhat by reorganizing it so consecutive ACEs produce the same mask (then this ACE is "free" and only draws from the absolute total of 120 rules) but in practice, this is only possible in a small number of cases. You often end up with no more than 7 or 8 ACEs, maybe a lucky 10. Of course you can *define* ACLs with more entries, but you cannot *apply* them anywhere, the switch will greet your enthusiasm with a laconic "Unable to apply access control list" message.

I could also mention that applying an ingress ACL to a port on this platform will cycle this port through Down/Up states, taking the STP topology with it, so you cannot really change ACLs without impact. Given the port ingress nature of the ACLs, you tend to shoot yourself into the foot even with tedious planning, especially when your switch is more in the center of the network. I can only repeat - while port ingress ACLs might have some use on the edge ports of access layer switches, they are completely insufficient for L3 switches in the distribution or (collapsed) core layers. You might compare the ACL docs of the yl/zl class switches to see what's closer to the state of the art here. I haven't hit a wall yet with ACLs on 6200yl for instance, but in the same network, a distribution unit made of two 6400cl is driving me crazy. We can only change ACLs there in a planned downtime, with somebody at the location standing by with a laptop and serial, and the resource limits already killed a downtime window. As a result, a part of a country-wide VPN is dysfunctional for months now. 5400zl replacements are in the pipe, blocking on layer 8 (finances)...

HTH,
Andre.

Hmmmmm.........

I was planning on creating one ACL with around 30 ACE's and applying to all relevant ports (probably 20 ports in total)

At least it's half term next week - I can do some proper testing...........

OK

If I'm readin this right - My original plan of giving each workstation VLAN an IP range on 10.*.0.0/255.255.0.0 and having the servers on 10.200.0.0/255.255.0.0 would make me run out of ACL masks rather quickly.

But, as most of my workstation VLANs will have the same ruls applied to them, if I change the workstation VLAN IP ranges to 192.*.0.0/255.255.0.0 I could pretty much do everything with one ACL mask............

so for instance;

permit 192.0.0.0 0.255.255.255 10.200.0.0 0.0.255.255

would allow all my workstaions to talk to my servers, while still preventing my workstation VLANs from talking to each other...... Is that right? If so, my ACL planning got a lot easier, and as I haven't setup the IP ranges yet, it's no extra work there either............

Well it WAS all going to plan............

I created an extended ACL;

permit ip 10.15.0.0 0.0.255.255 10.11.0.0 0.0.255.255
permit ip 10.15.0.0 0.0.255.255 10.12.0.0 0.0.255.255
permit ip 10.15.0.0 0.0.255.255 10.217.0.0 0.0.255.255
permit ip 10.16.0.0 0.0.255.255 10.11.0.0 0.0.255.255
permit ip 10.16.0.0 0.0.255.255 10.217.0.0 0.0.255.255
permit ip 10.14.0.0 0.0.255.255 10.11.0.0 0.0.255.255
permit ip 10.14.0.0 0.0.255.255 10.12.0.0 0.0.255.255
permit ip 10.14.0.0 0.0.255.255 10.217.0.0 0.0.255.255
permit ip 10.13.0.0 0.0.255.255 10.11.0.0 0.0.255.255
permit ip 10.13.0.0 0.0.255.255 10.127.0.0 0.0.255.255
permit ip 10.217.0.0 0.0.255.255 10.217.0.0 0.0.255.255

It worked initially - I set a workstation on 10.16.0.10 pinging both 10.14.0.10 and 10.217.28.12 - I applied the ACL to the port, and communication to 10.14.0.10 was blocked, whilst 10.217.28.12 carried on

But - 15-20 seconds later, I got a "Limited or no connectivity" notice (WinXP) and everything stopped. Even DHCP has stopped (DHCP server is 10.217.28.12).

I turned the rule off - applied it again, and got the exact same thing.

I tried again - This time a fresh PC - I applied the rule, plugged in the PC, and don't even get dhcp.

I'm assuming I've blocked DHCP somehow..........

I added the following two lines to my acl;

permit udp host 0.0.0.0 eq bootpc host 10.217.28.12 eq bootps
permit udp any eq bootpc host 255.255.255.255 eq bootps

That seems to have cured my DHCP issue.

Now I just have to figure out why my workstation imaging is broken - I'm PXE booting to my Novell Zen imaging server - There's a brief message about not being able to download a file..........

These things are never simple.........

Workstation imaging works fine if I assign the workstation to a WORKSTATION VLAN with the BootP settings set rather than the Printer or Phone VLANs I'd been using to test with!!!!!!!!!!