Reccomended switches for dynamic vlans
Can any1 reccomend a brand / model of wireless switches that will support dynamic vlans. I finally have freeradius working very nicely, just need to (hopefully) find an inexpensive solution for the hardware side. I am currently looking into the openwrt distro to see if that will provide dynamic vlans. Thanks for all the help guys, wouldnt have gotten Freeradius setup without this mailing list thats for sure.
Jacob I use procurve switches and i'm quite happy with them. Price is almost half of cisco prices(and lifetime warranty).(although i have already seen cisco match hp prices for large purchases if you mention procurve) Until previous firmware version they even suppported cisco p protocols (and open standard). Now they moved to open standards. regards, Stieven Struyf M.I.S. Division - System Operations Komatsu Europe International NV Mechelsesteenweg 586 B-1800 Vilvoorde Stieven.Struyf@komatsu.eu Tel. +32 (0)2 2552551 "The question of whether a computer can think is no more interesting than the question of whether a submarine can swim." -- E. W. Dijkstra "Jacob Jarick" <mem.namefix@gmail.com> Sent by: freeradius-users-bounces+stieven.struyf=komatsu.eu@lists.freeradius.org 13-07-07 06:35 Please respond to FreeRadius users mailing list <freeradius-users@lists.freeradius.org> To "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> cc Subject Reccomended switches for dynamic vlans Can any1 reccomend a brand / model of wireless switches that will support dynamic vlans. I finally have freeradius working very nicely, just need to (hopefully) find an inexpensive solution for the hardware side. I am currently looking into the openwrt distro to see if that will provide dynamic vlans. Thanks for all the help guys, wouldnt have gotten Freeradius setup without this mailing list thats for sure. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html "This e-mail is property of the company and is supposed to contain only professional content. The company can at all times consult the content of this e-mail and the reply to this e-mail. By replying to this e-mail, you confirm your explicit agreement with the preceding." "Deze e-mail is het eigendom van de Vennootschap en wordt verondersteld enkel beroepsmatige informatie te bevatten. De Vennootschap kan ten allen tijden de inhoud van deze e-mail en van het antwoord daarop raadplegen. Door het beantwoorden van deze e-mail bevestigt U uitdrukkelijk uw akkoord met het voorafgaande."
Thanks very much for that information, shall follow up on it :) On 7/13/07, Stieven.Struyf@komatsu.eu <Stieven.Struyf@komatsu.eu> wrote:
Jacob I use procurve switches and i'm quite happy with them. Price is almost half of cisco prices(and lifetime warranty).(although i have already seen cisco match hp prices for large purchases if you mention procurve) Until previous firmware version they even suppported cisco p protocols (and open standard). Now they moved to open standards.
regards, Stieven Struyf M.I.S. Division - System Operations Komatsu Europe International NV Mechelsesteenweg 586 B-1800 Vilvoorde Stieven.Struyf@komatsu.eu Tel. +32 (0)2 2552551
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim." -- E. W. Dijkstra
*"Jacob Jarick" <mem.namefix@gmail.com>* Sent by: freeradius-users-bounces+stieven.struyf= komatsu.eu@lists.freeradius.org
13-07-07 06:35 Please respond to FreeRadius users mailing list <freeradius-users@lists.freeradius.org>
To "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> cc
Subject Reccomended switches for dynamic vlans
Can any1 reccomend a brand / model of wireless switches that will support dynamic vlans.
I finally have freeradius working very nicely, just need to (hopefully) find an inexpensive solution for the hardware side. I am currently looking into the openwrt distro to see if that will provide dynamic vlans.
Thanks for all the help guys, wouldnt have gotten Freeradius setup without this mailing list thats for sure. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
"This e-mail is property of the company and is supposed to contain only professional content. The company can at all times consult the content of this e-mail and the reply to this e-mail. By replying to this e-mail, you confirm your explicit agreement with the preceding."
"Deze e-mail is het eigendom van de Vennootschap en wordt verondersteld enkel beroepsmatige informatie te bevatten. De Vennootschap kan ten allen tijden de inhoud van deze e-mail en van het antwoord daarop raadplegen. Door het beantwoorden van deze e-mail bevestigt U uitdrukkelijk uw akkoord met het voorafgaande."
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Jacob Jarick wrote:
Thanks very much for that information, shall follow up on it :)
On 7/13/07, *Stieven.Struyf@komatsu.eu <mailto:Stieven.Struyf@komatsu.eu>* < Stieven.Struyf@komatsu.eu <mailto:Stieven.Struyf@komatsu.eu>> wrote:
Jacob I use procurve switches and i'm quite happy with them. Price is almost half of cisco prices(and lifetime warranty).(although i have already seen cisco match hp prices for large purchases if you mention procurve) Until previous firmware version they even suppported cisco p protocols (and open standard). Now they moved to open standards.
Yep Second Vote for HP Procurves, any of the 26** support dynamic VLAN assignment, they also have a really neat feature for authenticating admin users on their ssh, web, consol interfaces using RADIUS with failover to local... Full accounting support, Mac based authentication, supplicant port mode (where the port on one hp can authenticate to another)... Loads more stuff like filtering and ingress bandwidth limiting using VSAs. These also have a nice feature called OpenVLAN, where the switch can drop people with broken supplicants into an arbitrary vlan, where you can provide resources to help fix their supplicant software. Unfortunately these do not support POD (packet of disconnect) but apparently this can be achieved via SNMP. All dynamic VLANS must have been setup on the switch before being assigned, or now with later firmware they can be learned (though this tends to break with larger installations). Here’s the wiki page http://wiki.freeradius.org/HP For wireless, depends... do you want a centrally managed wireless infrastructure, or each WAP to be a fully functioning WAP in it's own right. If it's the latter then HP530s are a safe bet. The firmware is currently pretty buggy, but the hardware is sound. They support: Multiple BSSIDS (with fully customisable settings for each). Dynamic VLAN assignment SNMP Trigger events for loads of things. Ingress rate limiting via VSA Learning of tagged VLANS from their uplink (which is really neat) Accounting for security enabled BSSIDS (though not necessarily radius authenticated) POE they also have dual radios, so you can run b/g on one and a on the other, or buy external aerials and run both b/g. There’s also a USB expansion slot marked for use in later firmwares.... could be an 11n upgrade module? Don't support Radius admin login authentication No obvious method of disconnecting users Current Major Bugs Accounting doesn't send interim update packets properly for all BSSIDS, so you sometimes lose data transferred type info. Vlans assigned statically to a BSSID cannot then be assigned dynamically (users traffic just gets black holed). Disabling of the plaintext web server breaks DHCP (most random bug ever). When user changes from one BSSID to another, accounting gets very confused (sometimes). But we still brought 30 of them, as we have faith in HP that these issues will be fixed. Also do a really neat thing where the base can slip onto the t bars of suspended ceilings, then you run a LAN cable above the ceiling with POE... And it looks like it's a wireless wireless access point :) And at £320 a unit, yes they do include a Kensington lock slot.
additional comment on procurve switches: If you want to authenticate more than one client on a port you need multidomain authentication support. This is available on hp3500yl and up(comparable with cisco 3500 series i think) the 26xx is indeed a good cheap poe switch(only 10/100 but that should be enough for poe application) Almost all managed procurve switches support the same security features(certainly from 26xx and up), so that makes it easier to combine different models in your network without sacrificing security. most of the difference is in port speed and routing functions and whether it is chassis based or not. I can also recommend the 5400 chassis based switch. largest model can handle 12 modules(also available in 6 modules) which you can fill. cat5 modules for this switch are always 10/100/1000 with poe or modules for mini-gbics(chassis itself is quite cheap, and modules are also ok but only interesting if you have centralized cabling). one disadvantage of the procurves is that they don't support "hardware" stacking(for procurve stacking is only a management feature) to built a virtual chassis with a high speed backbone link between 2 or more switches(i think cisco has models that can do this, but also not all). regards, Stieven Struyf M.I.S. Division - System Operations Komatsu Europe International NV Mechelsesteenweg 586 B-1800 Vilvoorde Stieven.Struyf@komatsu.eu Tel. +32 (0)2 2552551 "The question of whether a computer can think is no more interesting than the question of whether a submarine can swim." -- E. W. Dijkstra freeradius-users-bounces+stieven.struyf=komatsu.eu@lists.freeradius.org wrote on 13-07-2007 11:54:25:
Jacob Jarick wrote:
Thanks very much for that information, shall follow up on it :)
On 7/13/07, *Stieven.Struyf@komatsu.eu <mailto:Stieven.Struyf@komatsu.eu>* < Stieven.Struyf@komatsu.eu <mailto:Stieven.Struyf@komatsu.eu>> wrote:
Jacob I use procurve switches and i'm quite happy with them. Price is almost half of cisco prices(and lifetime warranty).(although i have already seen cisco match hp prices for large purchases if you mention procurve) Until previous firmware version they even suppported cisco p protocols (and open standard). Now they moved to open standards.
Yep Second Vote for HP Procurves, any of the 26** support dynamic VLAN assignment, they also have a really neat feature for authenticating admin users on their ssh, web, consol interfaces using RADIUS with failover to local... Full accounting support, Mac based authentication, supplicant port mode (where the port on one hp can authenticate to another)... Loads more stuff like filtering and ingress bandwidth limiting using VSAs. These also have a nice feature called OpenVLAN, where the switch can drop people with broken supplicants into an arbitrary vlan, where you can provide resources to help fix their supplicant software.
"This e-mail is property of the company and is supposed to contain only professional content. The company can at all times consult the content of this e-mail and the reply to this e-mail. By replying to this e-mail, you confirm your explicit agreement with the preceding." "Deze e-mail is het eigendom van de Vennootschap en wordt verondersteld enkel beroepsmatige informatie te bevatten. De Vennootschap kan ten allen tijden de inhoud van deze e-mail en van het antwoord daarop raadplegen. Door het beantwoorden van deze e-mail bevestigt U uitdrukkelijk uw akkoord met het voorafgaande."
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Unfortunately these do not support POD (packet of disconnect) but apparently this can be achieved via SNMP.
I'm trying to coordinate that with HP. FreeRADIUS doesn't currently support it, either. Maybe in 2.1.
Agreed 2.1 sounds good. Yep , though you can use radclient to send test packets. Would be really cool if you could convince them to get there fucking act together in terms of support for RADIUS :( Seriously, i've actually gone to the trouble of ringing their support line and submitting bug reports, and absolutely nothing has happened ?! It's getting to the funny rotten egg smelling stuff in the aircon ducts, and petrol bombs stage :\ *sigh* Anyway, COA stuff would be really useful too, and would aid in your domination of certain .. markets/ the world. Thanks, Arran
Arran Cudbard-Bell wrote:
Seriously, i've actually gone to the trouble of ringing their support line and submitting bug reports, and absolutely nothing has happened ?! It's getting to the funny rotten egg smelling stuff in the aircon ducts, and petrol bombs stage :\
I'll talk to them. :) Part of the problem is that if no RADIUS server supports it, there's less of a need for them to support it.
Anyway, COA stuff would be really useful too, and would aid in your domination of certain .. markets/ the world.
Yup. Alan DeKok.
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Seriously, i've actually gone to the trouble of ringing their support line and submitting bug reports, and absolutely nothing has happened ?! It's getting to the funny rotten egg smelling stuff in the aircon ducts, and petrol bombs stage :\
I'll talk to them. :)
Part of the problem is that if no RADIUS server supports it, there's less of a need for them to support it.
*poke* *poke*, the codes in radclient *poke* *poke* Actually isn't it just a matter of sending a standard RADIUS packet with a POD packet type to a specified UDP port on the NAS ... possibly triggered by an SNMP write ? Dammit I need to learn C... It's like i'm constantly playing catchup in both directions... ooo new shiny XML/Ajax web technology should see what thats all about ... Ooo orange on black VT100 console that's still amazingly useful for connecting to the serial ports of nearly every network device on campus.. should learn the keyboard shortcuts for that... Sometimes I wish I had been born 20 years earlier.
Anyway, COA stuff would be really useful too, and would aid in your domination of certain .. markets/ the world.
Arran Cudbard-Bell wrote:
Actually isn't it just a matter of sending a standard RADIUS packet with a POD packet type to a specified UDP port on the NAS ... possibly triggered by an SNMP write ?
That's the easy part. The harder part is the whole reverse proxying nonsense. You can fork a program to run radclient to disconnect a session. But it's not perfect. Alan DeKok.
On Fri 13 Jul 2007, Arran Cudbard-Bell wrote:
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Seriously, i've actually gone to the trouble of ringing their support line and submitting bug reports, and absolutely nothing has happened ?! It's getting to the funny rotten egg smelling stuff in the aircon ducts, and petrol bombs stage :\
I'll talk to them. :)
Part of the problem is that if no RADIUS server supports it, there's less of a need for them to support it.
*poke* *poke*, the codes in radclient *poke* *poke*
Actually isn't it just a matter of sending a standard RADIUS packet with a POD packet type to a specified UDP port on the NAS ...
Yep. You will generally need to know the the disconnect key, but you will notice that I added a field titled "XAscendSessionSvrKey" to radacct a while back.. A couple of lines of perl and it all just works... -- Peter Nixon http://peternixon.net/
On Fri 13 Jul 2007, Peter Nixon wrote:
On Fri 13 Jul 2007, Arran Cudbard-Bell wrote:
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Seriously, i've actually gone to the trouble of ringing their support line and submitting bug reports, and absolutely nothing has happened ?! It's getting to the funny rotten egg smelling stuff in the aircon ducts, and petrol bombs stage :\
I'll talk to them. :)
Part of the problem is that if no RADIUS server supports it, there's less of a need for them to support it.
*poke* *poke*, the codes in radclient *poke* *poke*
Actually isn't it just a matter of sending a standard RADIUS packet with a POD packet type to a specified UDP port on the NAS ...
Yep. You will generally need to know the the disconnect key, but you will notice that I added a field titled "XAscendSessionSvrKey" to radacct a while back.. A couple of lines of perl and it all just works...
As Alan mentioned.. "all just works" in a non proxied environment. -- Peter Nixon http://peternixon.net/
Peter Nixon wrote:
On Fri 13 Jul 2007, Peter Nixon wrote:
On Fri 13 Jul 2007, Arran Cudbard-Bell wrote:
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Seriously, i've actually gone to the trouble of ringing their support line and submitting bug reports, and absolutely nothing has happened ?! It's getting to the funny rotten egg smelling stuff in the aircon ducts, and petrol bombs stage :\
I'll talk to them. :)
Part of the problem is that if no RADIUS server supports it, there's less of a need for them to support it.
*poke* *poke*, the codes in radclient *poke* *poke*
Actually isn't it just a matter of sending a standard RADIUS packet with a POD packet type to a specified UDP port on the NAS ...
Yep. You will generally need to know the the disconnect key, but you will notice that I added a field titled "XAscendSessionSvrKey" to radacct a while back.. A couple of lines of perl and it all just works...
As Alan mentioned.. "all just works" in a non proxied environment.
Yep, just as he said, weirdness in proxied environment ... You also need to start having packet type filters, though I can't imagine that would be too hard, and may even be available with one of those sneaky internal FreeRADIUS attributes. But if Alan wants to succeed in world domination (this seems to be the new code word), then it's something the server has to support, along with CoA packets. Both in a local and proxied environment.
Arran Cudbard-Bell wrote:
Yep, just as he said, weirdness in proxied environment ... You also need to start having packet type filters, though I can't imagine that would be too hard, and may even be available with one of those sneaky internal FreeRADIUS attributes.
It's easier just to add another set of sections to process those packets.
But if Alan wants to succeed in world domination (this seems to be the new code word), then it's something the server has to support, along with CoA packets. Both in a local and proxied environment.
It's in the plan. I'm working with people to get it in in the server, and in hardware. Alan DeKok.
Peter Nixon wrote:
On Fri 13 Jul 2007, Arran Cudbard-Bell wrote:
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Seriously, i've actually gone to the trouble of ringing their support line and submitting bug reports, and absolutely nothing has happened ?! It's getting to the funny rotten egg smelling stuff in the aircon ducts, and petrol bombs stage :\
I'll talk to them. :)
Part of the problem is that if no RADIUS server supports it, there's less of a need for them to support it.
*poke* *poke*, the codes in radclient *poke* *poke*
Actually isn't it just a matter of sending a standard RADIUS packet with a POD packet type to a specified UDP port on the NAS ...
Yep. You will generally need to know the the disconnect key, but you will notice that I added a field titled "XAscendSessionSvrKey" to radacct a while back.. A couple of lines of perl and it all just works...
Is that just the SessionId on most NASes ? Erg i'm going to have to read RFC 3576 :(
On Sat 14 Jul 2007, Arran Cudbard-Bell wrote:
Peter Nixon wrote:
On Fri 13 Jul 2007, Arran Cudbard-Bell wrote:
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Seriously, i've actually gone to the trouble of ringing their support line and submitting bug reports, and absolutely nothing has happened ?! It's getting to the funny rotten egg smelling stuff in the aircon ducts, and petrol bombs stage :\
I'll talk to them. :)
Part of the problem is that if no RADIUS server supports it, there's less of a need for them to support it.
*poke* *poke*, the codes in radclient *poke* *poke*
Actually isn't it just a matter of sending a standard RADIUS packet with a POD packet type to a specified UDP port on the NAS ...
Yep. You will generally need to know the the disconnect key, but you will notice that I added a field titled "XAscendSessionSvrKey" to radacct a while back.. A couple of lines of perl and it all just works...
Is that just the SessionId on most NASes ?
No
Erg i'm going to have to read RFC 3576 :(
I suggest you start with my summary here: http://wiki.freeradius.org/Disconnect_Messages Cheers -- Peter Nixon http://peternixon.net/
Peter Nixon wrote:
On Sat 14 Jul 2007, Arran Cudbard-Bell wrote:
Peter Nixon wrote:
On Fri 13 Jul 2007, Arran Cudbard-Bell wrote:
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Seriously, i've actually gone to the trouble of ringing their support line and submitting bug reports, and absolutely nothing has happened ?! It's getting to the funny rotten egg smelling stuff in the aircon ducts, and petrol bombs stage :\
I'll talk to them. :)
Part of the problem is that if no RADIUS server supports it, there's less of a need for them to support it.
*poke* *poke*, the codes in radclient *poke* *poke*
Actually isn't it just a matter of sending a standard RADIUS packet with a POD packet type to a specified UDP port on the NAS ...
Yep. You will generally need to know the the disconnect key, but you will notice that I added a field titled "XAscendSessionSvrKey" to radacct a while back.. A couple of lines of perl and it all just works...
Is that just the SessionId on most NASes ?
No
Erg i'm going to have to read RFC 3576 :(
I suggest you start with my summary here: http://wiki.freeradius.org/Disconnect_Messages
Cheers
Ok X-Ascend-Session-Svr-Key isn't included in the standard list of identification attributes in RFC 3576... And seeing as it's a VSA for Ascend boxes, I don't see why it would be used in any other kit ? RFC just states that a packet with Code 40 should be sent, including a list of identification attributes, and an optional Service-Type attr with value Authorize Only, if only requesting termination of a session and not CoA, to avoid ambiguous meanings of attributes, and ease translation to Diameter. On NAK NAS is also supposed to send an Error-Cause attr, describing the reason for the NAK. The fact that the Request Authenticator matches, should be enough to ensure the Disconnect Message came from an authorised local RADIUS server, and the RFC describes a reverse proxying method to use for use when proxying... Just need HP kit to support POD and CoA now ...
On Sat 14 Jul 2007, Arran Cudbard-Bell wrote:
Peter Nixon wrote:
On Sat 14 Jul 2007, Arran Cudbard-Bell wrote:
Peter Nixon wrote:
On Fri 13 Jul 2007, Arran Cudbard-Bell wrote:
Alan DeKok wrote:
Arran Cudbard-Bell wrote: > Seriously, i've actually gone to the trouble of ringing their > support line and submitting bug reports, and absolutely nothing has > happened ?! It's getting to the funny rotten egg smelling stuff in > the aircon ducts, and petrol bombs stage :\
I'll talk to them. :)
Part of the problem is that if no RADIUS server supports it, there's less of a need for them to support it.
*poke* *poke*, the codes in radclient *poke* *poke*
Actually isn't it just a matter of sending a standard RADIUS packet with a POD packet type to a specified UDP port on the NAS ...
Yep. You will generally need to know the the disconnect key, but you will notice that I added a field titled "XAscendSessionSvrKey" to radacct a while back.. A couple of lines of perl and it all just works...
Is that just the SessionId on most NASes ?
No
Erg i'm going to have to read RFC 3576 :(
I suggest you start with my summary here: http://wiki.freeradius.org/Disconnect_Messages
Cheers
Ok X-Ascend-Session-Svr-Key isn't included in the standard list of identification attributes in RFC 3576... And seeing as it's a VSA for Ascend boxes, I don't see why it would be used in any other kit ?
Cisco's use it. Maybe we should call the DB colum disconnect-key or something similar...
RFC just states that a packet with Code 40 should be sent, including a list of identification attributes, and an optional Service-Type attr with value Authorize Only, if only requesting termination of a session and not CoA, to avoid ambiguous meanings of attributes, and ease translation to Diameter. On NAK NAS is also supposed to send an Error-Cause attr, describing the reason for the NAK.
The fact that the Request Authenticator matches, should be enough to ensure the Disconnect Message came from an authorised local RADIUS server, and the RFC describes a reverse proxying method to use for use when proxying...
Just need HP kit to support POD and CoA now ...
:-) -- Peter Nixon http://peternixon.net/
Peter Nixon wrote:
On Sat 14 Jul 2007, Arran Cudbard-Bell wrote:
Peter Nixon wrote:
On Sat 14 Jul 2007, Arran Cudbard-Bell wrote:
Peter Nixon wrote:
On Fri 13 Jul 2007, Arran Cudbard-Bell wrote:
Alan DeKok wrote:
> Arran Cudbard-Bell wrote: > >> Seriously, i've actually gone to the trouble of ringing their >> support line and submitting bug reports, and absolutely nothing has >> happened ?! It's getting to the funny rotten egg smelling stuff in >> the aircon ducts, and petrol bombs stage :\ >> > I'll talk to them. :) > > Part of the problem is that if no RADIUS server supports it, > there's less of a need for them to support it. > *poke* *poke*, the codes in radclient *poke* *poke*
Actually isn't it just a matter of sending a standard RADIUS packet with a POD packet type to a specified UDP port on the NAS ...
Yep. You will generally need to know the the disconnect key, but you will notice that I added a field titled "XAscendSessionSvrKey" to radacct a while back.. A couple of lines of perl and it all just works...
Is that just the SessionId on most NASes ?
No
Erg i'm going to have to read RFC 3576 :(
I suggest you start with my summary here: http://wiki.freeradius.org/Disconnect_Messages
Cheers
Ok X-Ascend-Session-Svr-Key isn't included in the standard list of identification attributes in RFC 3576... And seeing as it's a VSA for Ascend boxes, I don't see why it would be used in any other kit ?
Cisco's use it.
Maybe we should call the DB colum disconnect-key or something similar...
Sounds good :) -snip- --- Arran
Arran said:
Peter said:
Maybe we should call the DB colum disconnect-key or something similar...
Sounds good :)
I'll third that. Maybe even VendorDisconnectKey, which pretty much sums it up. Peter - would you be changing that today, to make the 1.1.7 release? I have a few hours reserved this afternoon to finish off the MySQL testing, so I'm up for it. -- hugh
On Sun 15 Jul 2007, Hugh Messenger wrote:
Arran said:
Peter said:
Maybe we should call the DB colum disconnect-key or something similar...
Sounds good :)
I'll third that. Maybe even VendorDisconnectKey, which pretty much sums it up.
Peter - would you be changing that today, to make the 1.1.7 release? I have a few hours reserved this afternoon to finish off the MySQL testing, so I'm up for it.
Yep. The problem I have with this change though is that what are the other vendor disconnect keys? If you read the RFC it doesn't specify a specific key (Alan has been holding ongoing discussions about this on the ietf-radext list), just that there should be enough info to identify the correct session. As Cisco also uses it (and Juniper from AFAIK) XAscendSessionSvrKey has become a de-facto standard along with MS-Primary-DNS-Server and its ilk. Given that it is possible to send and have work a Disconnect-Request containing only a User-Name and there is no-where specified that there should be an individual session key I am not sure its worth changing unless someone can come up with a concrete example of a vendor who uses a session key thats different.... Is there? Cheers -- Peter Nixon http://peternixon.net/
Peter Nixon said:
Yep. The problem I have with this change though is that what are the other vendor disconnect keys? If you read the RFC it doesn't specify a specific key (Alan has been holding ongoing discussions about this on the ietf- radext list), just that there should be enough info to identify the correct session. As Cisco also uses it (and Juniper from AFAIK) XAscendSessionSvrKey has become a de-facto standard along with MS-Primary-DNS-Server and its ilk. Given that it is possible to send and have work a Disconnect-Request containing only a User-Name and there is no-where specified that there should be an individual session key I am not sure its worth changing unless someone can come up with a concrete example of a vendor who uses a session key thats different.... Is there?
I don't know of any, but as more gear starts to support PoD / CoA / Disconnect-Message / whatever, I'm sure they'll crop up. Mark my words, the Atlanta Scientific Tanning Salons and Wireless Switches latest model TanNSurf-5000 will implement TanNSurf-Disconnect-Key at some point. I guess I just don't like contributing to the de-facto standardizationificationism of vendor specific attributes. And besides which, XAscendSessionSvrKey is a biatch to type. :) Your call. You (one of) Da Man.
Peter Nixon
-- hugh
Thanks for the wealth of info guys :) On 7/16/07, Hugh Messenger <hugh@alaweb.com> wrote:
Peter Nixon said:
Yep. The problem I have with this change though is that what are the other vendor disconnect keys? If you read the RFC it doesn't specify a specific key (Alan has been holding ongoing discussions about this on the ietf- radext list), just that there should be enough info to identify the correct session. As Cisco also uses it (and Juniper from AFAIK) XAscendSessionSvrKey has become a de-facto standard along with MS-Primary-DNS-Server and its ilk. Given that it is possible to send and have work a Disconnect-Request containing only a User-Name and there is no-where specified that there should be an individual session key I am not sure its worth changing unless someone can come up with a concrete example of a vendor who uses a session key thats different.... Is there?
I don't know of any, but as more gear starts to support PoD / CoA / Disconnect-Message / whatever, I'm sure they'll crop up. Mark my words, the Atlanta Scientific Tanning Salons and Wireless Switches latest model TanNSurf-5000 will implement TanNSurf-Disconnect-Key at some point.
I guess I just don't like contributing to the de-facto standardizationificationism of vendor specific attributes. And besides which, XAscendSessionSvrKey is a biatch to type. :)
Your call. You (one of) Da Man.
Peter Nixon
-- hugh
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Fri, 2007-07-13 at 12:32 +0800, Jacob Jarick wrote:
Can any1 reccomend a brand / model of wireless switches that will support dynamic vlans.
Off the top of my head, and in no particular order: 3Com 4400, 5500 Cisco 2960, 3560/3750, 4500, 6500 Extreme X250e/X450e/8800 HP Procurve (most of them) Nortel (untested) Alacatel (untested) Foundry (untested) ...and a whole bunch more. It's a pretty common feature in any platform from the last 18 months. You really want to be looking for a few key differentiators such as: * can the device support 802.1x & mac-based fallback at the same time? * can the device authenticate >1 client on a port? * if so, can it support 802.1x for one and mac-based for another (think IP phones) * if so, can it assign separate untagged vlans to each client? * can the device assign IP ACLs from Radius replies? * can the device assign 1 untagged and >1 tagged vlans (think wlan aps) * can the device be told to let all macs in (again, wlan aps) * can the device support wake-on-lan on 802.1x unauthenticated ports? * does the device support an internal username db for fallback (think ops staff laptops while the radius servers are down during an outage) HTH
Phil Mayers wrote:
On Fri, 2007-07-13 at 12:32 +0800, Jacob Jarick wrote:
Can any1 reccomend a brand / model of wireless switches that will support dynamic vlans.
Off the top of my head, and in no particular order:
3Com 4400, 5500 Cisco 2960, 3560/3750, 4500, 6500 Extreme X250e/X450e/8800 HP Procurve (most of them)
Nortel (untested)
Are Notel still in buisiness ? I heard they invested heavily in mobile interweb and went bust.
Alacatel (untested) Foundry (untested)
...and a whole bunch more. It's a pretty common feature in any platform from the last 18 months.
You really want to be looking for a few key differentiators such as:
* can the device support 802.1x & mac-based fallback at the same time?
Yes !!! The issue that I have with most of the current switches, is that they can't fallback to mac based auth... Port Based Auth Switch >> Device : EAPOL Indentity request Switch << Device : No response *switch to mac based auth* You would of course have to keep a database of devices allowed to be authenticated by mac address.
* can the device authenticate >1 client on a port? * if so, can it support 802.1x for one and mac-based for another (think IP phones)
This would come under fallback.
* if so, can it assign separate untagged vlans to each client? * can the device assign IP ACLs from Radius replies? * can the device assign 1 untagged and >1 tagged vlans (think wlan aps)
I don't think many will allow you to assign multiple tagged VLANS, most centre around assigning one untagged VLAN... though that would be a very neat feature.
* can the device be told to let all macs in (again, wlan aps)
Well you just turn off authentication for that port (if wired), or create a non radius authenticated BSSID.
* can the device support wake-on-lan on 802.1x unauthenticated ports?
Yep , this ones pretty important, latest HP firmware for 26** supports this.
* does the device support an internal username db for fallback (think ops staff laptops while the radius servers are down during an outage)
Yep agree with you there ... though in my limited experience, it's not usually the radius server or the link to the radius server that goes down, it's the databases used for authorisation. Now FreeRADIUS supports return codes in cvs head again, it's a good idea to elect a secondary users file module to do authorisation in place of any of your db modules, if a db module should return fail... or you could stick it at the end of a fail-over group.
Nortel (untested)
Are Notel still in buisiness ? I heard they invested heavily in mobile interweb and went bust.
No, they're still in business. The products we looked at recently are fairly new.
You really want to be looking for a few key differentiators such as:
* can the device support 802.1x & mac-based fallback at the same time?
Yes !!! The issue that I have with most of the current switches, is that they can't fallback to mac based auth...
Really? I didn't do the testing personally, but I'm fairly sure most of the ones we tested did support it. Certainly 3Com, Cisco and Extreme do.
* can the device authenticate >1 client on a port? * if so, can it support 802.1x for one and mac-based for another (think IP phones)
This would come under fallback.
Not necessarily - some devices can fallback, but only in a mode with permits 1 mac per port.
* if so, can it assign separate untagged vlans to each client? * can the device assign IP ACLs from Radius replies? * can the device assign 1 untagged and >1 tagged vlans (think wlan aps)
I don't think many will allow you to assign multiple tagged VLANS, most centre around assigning one untagged VLAN... though that would be a very neat feature.
Extreme can.
Phil Mayers wrote:
Nortel (untested)
Are Notel still in buisiness ? I heard they invested heavily in mobile interweb and went bust.
No, they're still in business. The products we looked at recently are fairly new.
Thats good to know, they used to be pretty big players in the UK. I know there big UK research centre/hq near Harlow closed down a few years back. Quite sad really.
You really want to be looking for a few key differentiators such as:
* can the device support 802.1x & mac-based fallback at the same time?
Yes !!! The issue that I have with most of the current switches, is that they can't fallback to mac based auth...
Really? I didn't do the testing personally, but I'm fairly sure most of the ones we tested did support it.
Certainly 3Com, Cisco and Extreme do.
Unfortunately we didn't really have a choice, as all the 300 odd deployed edge switches were HP, and there was no way we would get funding to replace them all. Also previous experience with both 3Com and Cisco , saw them both removed permanently from our proffered suppliers list.
* if so, can it assign separate untagged vlans to each client? * can the device assign IP ACLs from Radius replies? * can the device assign 1 untagged and >1 tagged vlans (think wlan aps)
I don't think many will allow you to assign multiple tagged VLANS, most centre around assigning one untagged VLAN... though that would be a very neat feature.
Extreme can.
Well extreme looks like a good bet then. Though it looks like all their wireless stuff is centrally managed, which is probably why we didn't investigate them.
participants (7)
-
Alan DeKok -
Arran Cudbard-Bell -
Hugh Messenger -
Jacob Jarick -
Peter Nixon -
Phil Mayers -
Stieven.Struyf＠komatsu.eu