Subject: RE: (usr-tc) Lack of Accounting response from the Accounting serv er

From: [email-masked]
Date: Mon, 25 Jun 2001 15:24:34 +0000

Thanks Mark. What you say makes sense. I agree any device like this should
be transparent to the RAS and Accounting server. I'll put this back on 8E6
Technologies.

Sincerely,
Rick
Team Solunet

-----Original Message-----
From: Mark Thornton [mailto:[email-masked]]
Sent: Thursday, June 21, 2001 5:52 PM
To: [email-masked]
Subject: Re: (usr-tc) Lack of Accounting response from the Accounting
server

We tried similar thing a few years ago and gave up on it due to the
inability to assure the customer or ourselves that the filter server was
acting on the accounting packets correctly. It was a different vendor but
same problem and same attitude. In my opinion it is very important in your
application that the accounting packets, both start and stop are transmitted
back to the TCH. If not and one is lost then the filter server will not set
up for the user and the grandkids will be surfing for porn. Then you get a
phone call... It isn't pretty when this happens.

You can use the command 'set accounting primary_retransmissions 1' to limit
the number of retransmits, but DO NOT set it to 0 as that means infinite
retransmits. It's 3Com, go figure...

I don't know how much you are paying for the filtering but they need to fix
it. Accept nothing less than a completely transparent proxy between your TCH
and the radius server.

Mark Thornton
San Marcos Internet, Inc
512-393-5300

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Thursday, June 21, 2001 4: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 "[email-masked]"
>  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 "[email-masked]"
 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 "[email-masked]"
 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.

---

From: [email-masked]
Date: Mon, 25 Jun 2001 15:26:46 +0000

Kevin,
Thanks for the response and info. I think I may go ahead and put this back
in 8E6 Technologies lap to fix. As Mark said...a device like this should be
completely transparent once put in place. I'll let you know what happens.

Sincerely,
Rick
Team Solunet

-----Original Message-----
From: Kevin Hemsley [mailto:[email-masked]]
Sent: Thursday, June 21, 2001 6:34 PM
To: [email-masked]
Subject: Re: (usr-tc) Lack of Accounting response from the Accounting
server

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.
[email-masked]
KB7TYA

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Thursday, June 21, 2001 3:27 PM
Subject: (usr-tc) Lack of Accounting response from the Accounting server

response
ARC
Accounting
setting

-

-