We are using the R2000, but we have not tried the new Radius implementation. We use the R2000 with a combination of HyperARCs, NetServers, and PortMaster3s located on different networks, at different POPs. We wrote a custom C application that ties into Cistron Radius running on Solaris and is executed at each radius login. The application checks to see if the user is in a file of filtered users. If the user is not in the filtered list, the application sends a default response of : Framed-Address = 255.255.255.254, Which causes the NAS to assign a normal IP address out of the standard NAS' IP pool. This works with all our NAS types. If the user is in our file of filtered users, the custom application assigns the user a filtered IP address. Because we have multiple NAS types located at different POPs, we have to determine which POP the user is dialing into, and what type of NAS (HiperARC, NetServer, or PM3) is requesting the IP, and assign a unique IP appropriate for that POP and NAS. This is done by reading a config file that describes each NAS by listing the IP address of each NAS, the beginning IP address for the IP pool that will be assigned for that NAS, and the NAS type (HiperARC, NetServer, or PM3) . The custom application then assigns an IP address that is based on the NAS port number that the user is dialed into. So if the user is dialed into NAS PM-15 port 31, the user will be assigned an IP address equal to the beginning IP address of the pool for that NAS + the adjusted port # the user is dialed into. So, for example, if the beginning IP for that NAS pool is 192.168.5.1, the IP assigned will be 192.168.5.31. Because the NetServer starts at port 5, and the PM3s start at port 1, and the HiperARCs can be configured to have ports like 3000, the application adjusts the port number that gets added to each filtered pool IP address accordingly. The end result is that we can support filtered IP addresses for multiple NAS types on different networks, located at different POPs and allow the user to dial into any POP and still have a filtered IP address. Then our core router and a ServerIron layer 3 switch perform the task of routing the filtered IP packets past the R2000 for filtering at the NOC where we pool all backbone bandwidth. This solution has worked flawlessly for a couple of years with no maintenance, other than adding new NAS boxes to the configuration file. The only downside is that we have to allocate double the IP addresses for each NAS. One IP for non filtered, and one for filtered access. So this does waste IP addresses. If all our NAS supported OSPF and multiple IP pools, then we could eliminate the wasted IP addresses. But since they don't, this is how we addressed the problem. I am curious to see how this new Radius implementation works, and if it would work for our network configuration. Thanks, Kevin. ------------------------------------------------------ Kevin Hemsley Systems Engineer Microserv Computer Technologies, Inc. kev@ida.net KB7TYA ----- Original Message ----- From: <RickL@solunet.com> To: <usr-tc@lists.xmission.com> Sent: Thursday, June 21, 2001 3:27 PM Subject: (usr-tc) Lack of Accounting response from the Accounting server

Anyone,

I have a problem: In using an 8E6 Technologies RS2000 content filtering device, we are experiencing an issue where the ARCII has the RS2000 listed as the Primary Accounting server. This is half-way working in that the accounting start record is sent to the RS2000, then the RS2000 sends the Accounting Start packet to the Accounting server. The Accounting server then sends a response back to the RS2000, but the RS2000 NEVER sends anything to the ARC. The ARC understands this as "oh, the Accounting server didn't receive my Accounting start packet, I better send it again". And it sends, and it sends, and it sends.

I contacted 8E6 Technologies, and was told that I just need to "turn off retransmission of accounting packets". Only problem is...there is no setting to turn off retransmission of accounting packets.

Anyone ever run into a problem like this?

Rick STAC Support 888-449-5766

- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.