IMPORTANT Re: (RADIATOR) multilink problem.

[Hugh Irvine]

Hello Cesar, Hello Alessandro, Hello Everyone  -

The subject of multilink PPP (over ISDN or whatever) comes up now and again, 
so I thought it might be useful to explain a few things.

Firstly, there are two forms of utilising more than one link between two 
routers, either parallel IP links, or multi-link PPP. (For this discussion I 
will ignore "bonded" ISDN channels that some hardware supports, which in any 
case appears to both IP and PPP as a single link.)

In the case of parallel links, you essentially have completely seperate IP 
links and load sharing is accomplished by the IP routing protocol and/or the 
IP forwarding table. This is a layer 3 technology, implemented in the IP 
layer of the protocol stack. In this case, each link is handled completely 
seperately by the routers (or NAS(s)) and hence by Radiator.

In the case of Multilink PPP (over ISDN or whatever), the management of the 
multiple links is handled by PPP at layer 2. In this case, the IP layer only 
ever sees a single logical link. Problems occur in this scenario, because if 
the NAS is configured to do Radius authentication for each access request, 
then each additional channel that comes up in a Multilink PPP session will 
trigger a Radius authentication request (and probably subsequent accounting 
requests).

Obvioulsy, when dealing with the allocation of IP addresses and the 
maintenance of a session database, care is required to avoid problems such as 
allocating multiple IP addresses and incorrectly inserting and deleting user 
records.

Unfortunately, different NAS vendors implement the Radius protocol in 
different ways, so the only way to understand what the NAS is doing is to 
look at a trace 4 debug from Radiator (or the output from your favourite 
packet sniffer) to see what attributes are present in the initial access 
request, the subsequent access requests for additional Multilink PPP 
channels, and the related accounting packets.

Armed with the information gathered above, you can design a configuration 
file and a database schema to deal with the problems. Essentially what you 
are aiming to do is to recognise the initial access request from the NAS, and 
only allocate an IP address in response to the initial request. 

Accounting starts can either cause multiple records to be inserted into the 
session database (with link indicators), or the additional starts after the 
initial one can be used to increment a link count field in the user record. 
Accounting stops can be used in a similar fashion, to either decrement a link 
count in a user record, or only remove the corresponding record from the 
session database.

Finally, only the last accounting stop from the Multilink PPP session 
shutting down should be used to deallocate the IP address and remove the user 
record(s) from the session database.

Again, as each NAS does things differently, you will have to study the 
relevant NAS documentation and look at the corresponding Radius packet dumps 
to discover what information is actually in the various Radius requests. 

Once you have all of this information, you can design a suitable Radiator 
configuration file to do whatever is required.

As always, I am happy to answer questions and to assist in any way.

regards

Hugh


On Wednesday 08 August 2001 20:31, Alessandro Chiolo wrote:
> > I am try to use multilink PPP 2, 3, 4 or more channels qith cisco as5260
>
> and
>
> > radiator.(last version)
> > I am using radiator, to authenticate, ldap to store usernames, passwords,
> > etc, and mysql for ip asignament and accounting.
> > All is ok with 1 channel, but multilink have an error, 2 IPs are marked
> > as
>
> 1
>
> > in the radpool table (one per channel).
> > How can i configure multilink correctly??
>
> I see the same behaviour with our MAX TNT, so i think it's not NAS-related;
> i've noticed that the ips are freed both correctly when the user
> disconnects, so i thought i could live with it (the pool should have enough
> IPs for all the channels used without multilink anyway, so this is not
> really an issue). Of course if there's a "clean" solution i'd be glad to
> implement it...
>
> regards,
> A.Chiolo
>
> --
> Alessandro Chiolo <alessandro.chiolo at it.easynet.net>
> Network Manager, Easynet Italy
> "I'm Winston Wolf, I solve Problems."
>
> ===
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.

-- 
Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.