Comware

The company I currently work will soon be completing an edge security project that will see every edge port on our ~600 ProCurve 2600s/2610s move from completely unsecured static network access, to 802.1X/MAC authenticated access with policy driven dynamic VLAN and CoS assignment.

As part of this we've also removed most static VLAN configurations from the edge and opted for GVRP controlled VLAN distribution.

At a ProCurve run conference I recently attended, none of the other major customers used a similar setup, and it appeared that we were quite unique in our approach to edge network management. So much so, that many of the requests we made for enhancements to GVRP/802.1X/MAC-Auth interaction were deemed to be unfeasible.

Yet when I read back over the past three months of forum postings, I do see other people attempting to implement models very much like ours.

So i'm looking to gather more information about people who are tackling edge network management in a similar way, in the hope that any misinformation and holes in documentation can be addressed, and that more people can be encouraged to adopt this setup. Thus encouraging HP to take enhancement requests for these features seriously.

My main questions are these:
==
What is the rough size of the ProCurve based portion of your network in terms of ports?
==

==
Have you implemented a similar edge policy using 802.1X,Mac-Auth concurrent authentication and GVRP?
==

==
If so what issues did you have to overcome ? (RADIUS server config, bugs in firmware etc...)
==

==
If not would you ever consider doing so?
==

==
What resources would you like to see made available? For example would an official ProCurve white paper on the subject be of any use?
==

Many Thanks
-Arran

PS: If you're already in the process of implementing 802.1X/Mac-Auth or have implemented it and are experiencing unexpected behaviour, the answer may already be here:
http://wiki.freeradius.org/HP

Let me know if you have any more gotchas to add to those documented above :)

I would recommend to follow a few stages and cooperate with other departments who maintain the desktop and other equipment on the network.

1st don't make it to complex
2nd plan carefully and look if the current equipment supports all your wishes (sometimes you need more features to support your requirements e.g. multiple authentications per port for example)
3rd start with a pilot.
4th redesign you IP numberplan or vlan structure if needed (maybe you need to create a location based vlan approach, which can be easy configured in IDM (Identity Driven Manager)
5th Start implementing with a fall-back scenario until everything is working fine.

I would not recommend functional Vlans across large environments. Instead you can use geographical vlans and seperate the function by a dynamic ACL. Dynamic ACLs are supported in the 2610 series and higher.

Depending on the complexity of your environment the roll-out is also from simple to complex.

Hi Sietze,

Thanks for your reply.

In response to your first point: Yes KISS is still a widely used philosophy in computing. Uneeded complexity breaks things. However the complexity for this proposed setup is contained within the protocols themselves. It's reducible, modular complexity; which although it doesn't make the system any more reliable per se, does aid in quick fault diagnosis and resolution.

The biggest problems we found was where the interfaces between the protocols/features were not specified by standards.

Regarding 2 - All (non budget, cli managed) equipment from the 2600 series onwards supports the required feature set.

Regarding 4 - The point of the above setup is complete flexibility i.e. connect anywhere on the corporate network and get assigned to exactly the same VLAN, get access to exactly the same resources and have exactly the same set of restrictions imposed. That's one of the attractive features of policy based networking, the policies follow the users and the equipment.

In this case the policy is applied at the edge; apply tagging information to ingressing frames which is honored by the distribution and core network; and ensure that the tagged packets are passed around the network correctly by dynamically reconfiguring the VLAN filters on switch interlinks with GVRP/MVRP.

I'd actually argue against geographical VLANs. Yes they offer efficiency in limiting the broadcast domain to a smaller area of the phsical network, but they also add unnecessary bottlenecks when passing traffic from one geographical area of the network to another; all traffic must now be routed instead of just switched.

We decided to use departmental/function based VLANs. Yes there's inefficiency in that, and it'd be extremely hard to manage effectively without using GVRP/MVRP. But that's kind of the point, once you hand over topology management to dynamic protocols you get rid of the administrator based limitations.

Hi,

==
What is the rough size of the ProCurve based portion of your network in terms of ports?
==

Roughly, 13,000

==
Have you implemented a similar edge policy using 802.1X,Mac-Auth concurrent authentication and GVRP?
==

No

==
If not would you ever consider doing so?
==

Yes, probably in the next 6-12 months

==
What resources would you like to see made available? For example would an official ProCurve white paper on the subject be of any use?
==

An official white paper would be useful if only to outline an "HP standard" implementation.
I'd love to see more technical HP networking whitepapers but alas a lot of them seem to be very "salesman" oriented.

Your comments regarding switching vs routing do raise a few interesting points that I've wondered about in terms of best practise but I think I'll start another thread on that :)

This thread could turn out to be a great resource. I would love to see others who've rolled out something like this contribute.

1. Size: 10,000 ports
2. No policy in place. Statically configuring ports and trunks SUCKS. Looking at a dynamic protocol now.
3. Haven't started the roll-out yet.
4. We are looking at deploying GVRP etc. now and hope to do MAC-Auth soon
5. Official whitepaper would be invaluable. Prescriptive guidance; "This is how you do it" vs. "There's lots of ways to do it, here's the detailed description of each protocol"