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 <[EMAIL PROTECTED]> > Network Manager, Easynet Italy > "I'm Winston Wolf, I solve Problems." > > === > Archive at http://www.open.com.au/archives/radiator/ > Announcements on [EMAIL PROTECTED] > To unsubscribe, email '[EMAIL PROTECTED]' 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
