> Okay, if this PM (I'm not the original author) is experiencing a login
> slowdown at peak times, is there an adjustment that should be made on the
> PM side?
>
> Thanks,
>
> Gail
>
> P.S. I'm also asking because these problems seem to come in spurts for
> me.
It is most likely your radius server or your ethernet or the links between
your portmasters and radius server is overloaded. The portmasters are
probably not the problem although they could be contributing if you don't
have any filtering on your ethernet. One filter I found necessary is an
ofilter on the ethernet. You need to make sure that packets for an
assigned dialup are not bounced back to the gateway when a customer logs
off. We had done the switched hub thing about a year ago and then it
looked like our problems were starting to reoccur. I had one PM2 I
could barely telnet into even with no modems active. The ethernet was
always busy. I put a filter on the ethernet to see what all the traffic
was and someone was pinging a dialup that was not connected. The router
knows that IP belongs to that PM and forwards the packet on. The PM gets
the packet and since that IP is not in use it sends it to the router. The
router sends it back. This continues until the ttl on the packet expires.
These were coming in fast enough that this particular PM could get nothing
done. The router was congested as well. The following filter solved the
problem.
add filter e.out
set filter e.out 1 permit 192.168.1.32/27
set filter e.out 2 permit 192.168.0.10/32
set filter e.out 3 permit log
192.168.1.32/27 is the assigned address pool in that portmaster.
102.168.0.10/32 is the address of that portmaster's ethernet.
I run this way for a bit to make sure I have not forgotten any thing. In
our network I have a block of IP addresses for customers that needs to be
allowed staticly on all portmasters so that is also given a permit
listing. Once I am certain it is all working I change the permit log to a
deny because the syslogging can create a lot of traffic.
What this does is permit only those packets whose source address is on
that portmaster onto your ethernet. A packet will not be bounced back to
your router and start looping with this filter in place. If you are using
the PM to route other subnets you will of course have to put those in the
permit list.
This is the most basic filter I can think of to solve this problem.
Really, this is a Comos problem in that it announces routes to those IP
addresses and when a packet comes in if the address is not active it
bounces it. It should probably return a host unreachable message.
In my case I had to do this because of an attack on a customer which was
affecting everything. It also fixes normal logoffs where web servers
continue to send packets at frequent intervals for many minutes after a
customer is logged off (I have seen web servers blab on for as long as 11
minutes).
This could be part of your problem or not, but you will need it once you
get beyond a certain size. It was about 180 dialups at a pop where I
noticed it start affecting things. It may very well have prevented us
from needing a switched hub for many more months if it had been
implemented earlier.
Best wishes.
Doug Ingraham From the Ferengi Rules of Acquisition.
Rapid City, SD #34 "Peace is good for business."
USA #35 "War is good for business."
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.