High performance request remapping / rewriting

[Alan DeKok]

Phil Mayers <p.mayers at imperial.ac.uk> wrote:
> ...but that's still too large, so maybe:
> 
> nasip -> zone
> clientmac -> clienttype (there are 5 types - unreg, guest, roaming, 
> home, blocked)
> (clienttype, zone) -> vlan
> 
> ...which would be much smaller, but I can't see how you do this.

  The simplest way is to not use the "users" file.  Use rlm_passwd,
and have multiple instances.  e.g.

modules {
	...
  passwd nas2zone {
	filename = ${raddbdir}/nas2zone.txt
	format = "*Client-IP-Address:~Zone-Name
	hashsize = 1000
	allowmultiplekeys = no
  }

  passwd mac2type {
	filename = ${raddbdir}/mac2type.txt
	format = "*Calling-Station-Id:~MAC-Type
	hashsize = 1000
	allowmultiplekeys = no
  }
 ...
}

  List "nas2zone" and "mac2type" in the "authorize" section, and
create new attribures in the dictionary: Zone-Name & MAC-Type.

  After that, the rlm_passwd module can't really use 2 attributes to
look up data, so you'll have to use the "users" file, as in your post.

  But the "passwd" module lets you manage the nas & Mac mappings as
simple flat-text files, which is pretty nice.

> # Fallback - unknown hosts
> DEFAULT Calling-Station-Id =~ 
> "^[0-9A-F]{2}-[0-9A-F]{2}-[0-9A-F]{2}-[0-9A-F]{2}-[0-9A-F]{2}-[0-9A-F]{2}$" 
> , User-Password = `%{0}`
>    Kind = "unreg"

  The "passwd" module doesn't have defaults, so I'm not sure how to do
the above.

> Ideally an apache-like feature of DBM mapping is what's needed of 
> something like:
> 
> /etc/raddb/radiusd.conf:
> 
> attr_rewrite nas2zone {
>    attribute = NAS-IP-Address
>    searchin = packet
>    searchfor = "(.*)"
>    replacewith = "%{dbm:nas2zone:%{1}}"

  That's not a bad idea.  The dynamic string expansion functionality
of the server would be very good for that.

> The issue is that this needs to go very very fast - at peak times (e.g. 
> say a reboot of a PC cluster during overnight maintenance) the DHCP 
> servers get ~50 requests/second, so a radius server(s) would need to 
> answer with similar performance.

  That is a high load.

> I'm assuming rlm_exec would have similar if not worse performance 
> characterisitcs (spawning 50 processes a second during peak times does 
> not strike me as overly sensible). Is there an rlm_socket:

  No, sorry.  That would be a good idea, though.  OpenRADIUS does
this, which is a good idea for many situations.  But passing that much
data through a socket may be problematic.

  If all else fails, try using rlm_perl.  The version in 1.0.4 may
have issues, but the one in the CVS head should be OK.

  Alan DeKok.