Framed- Route & ESVA Radius (was Questions: 1 Radius, 1 OSPF )

Randy Moore (ramoore@atlantech.net)
Fri, 08 Aug 1997 10:03:13 -0400

At 04:39 AM 8/8/97 -0700, MegaZone wrote:
>Once upon a time Randy Moore shaped the electrons to say...
>>1) I'm using the ESVA mods to Radius 1.16 (with COM/OS 3.5.1b17 on several
>>PM2E30s) and for a few dedicated dialup customers, I route multiple subnets
>>down their connection. Unfortunately, I can't seem to make this work
>>using RADIUS only, I always have to put in a static route for at least one
>>of the subnets.
>>
>>My question is *should* I be able to put two Framed-Route entries into a
>>single user entry in Radius and have it work? For example:
>
>Yes. That's the correct way to do it. Static routes on the NAS is a bad
>way to do it.
>
>>customer1 Password = "UNIX"
>> Framed-IP-Address = 208.198.56.242,
>> Framed-Route = "208.198.61.64/26 0.0.0.0 1",
>> Framed-Route = "208.198.61.128/26 0.0.0.0 1"
>>(note ESVA entries do look a little different than other radius versions)
>
>Well, normally I'd say you have missing data here - but I don't know how
>ESVA deals with the rest.
>
>I have seen reports that if a Framed-Route statement is the *last* line
>in a RADIUS response, that the PM seems to ignore it.
>
>I don't know if this bug was ever confirmed. With our RADIUS I just have
>people put something else last just in case.

Last night, I decided to dig into the source code for ESVA radius and
compared parts of it to Livingston's radius. It turns out that my problem
IS being caused by one of the changes/enhancements in the ESVA version.

ESVA radius changes the behaviour of the "DEFAULT" user to actually set
default attributes for any other user (that follows the DEFAULT block) in
the users file. (Which is why MZ thought I had missing data in my example
above). The way this is implimented in the code is to run through the
process of building "response pairs" twice while authentication a user.
First a list of response pairs are created using the info listed for the
DEFAULT user. Then any attributes that are listed for this specific user
are used to *write over* any data for the same attribute that was found in
the default block.

This method works very well except that NO attribute (ie Framed-Route ) can
be in the response list more than once.

As soon as I understand the code a little better, I'll try to add a hack to
allow multiple Framed-Route attributes. Are there any others that might
reasonable be repeated?

BTW, I don't believe that this can be related to the other reported bug
about Framed-Route commands as the *last* line in a block.

- Randy Moore
Atlantech Online, Inc.
(301) 593-2794
http://www.atlantech.net/