> OK, I'll ask. Is the situation described in Doug's message really a
> problem? To my eyes, this looks really serious.
It is and it isn't a problem. If everything is working right then there
is no problem. If someone is sending data to an assigned IP that no
longer is connected to a modem it is a problem until the ttl for that
packet expires. One packet can bounce between the gateway and the PM as
many as 255 times. If enough packets come in fast enough the ethernet
gets saturated not to mention the router. Web servers seem to babble on
for many minutes pushing data to the client after they have disconnected.
with the deny log filter as the last one you can see this traffic and it
doesn't clog up your ethernet. Just your syslogs <g>.
> Is this something that ComOS is just doing wrong? Would enabling OSPF help?
This is with OSPF routed packets. Comos owns the assigned address space.
If it was only claiming those IP's that are in use OSPF would be a
solution. I don't want to see that kind of routing traffic. I would
rather Comos deep six a packet that comes in with a destination in the
Assigned pool that is not in use. A static in the Gateway would do
exactly the same thing. RIP might actually be superior in this case
because it seems to announce a dialup IP as a host route. But it is so
inferior in so many other ways that I won't use it anymore.
> Doug, if this really is a ComOS problem, do you have an open ticket with
> Lucent about this?
I don't have an open ticket. I thought this was a reasonably well known
problem. Megazone mentioned it recently in passing I believe.
This is a really old problem and has always existed at least since OSPF.
I remember reading that there was an RFE for a fix but it really isn't
that big a deal to correct with filters. If you want to see if you have
the problem its really easy to tell. You do a traceroute to an assigned
IP address that is currently not assigned. A routing loop will occur
where the portmaster will bounce the packet back and forth between the PM
and the gateway router. It is a killer if you have a pop running on a 56K
and have not put the filter on the wan interface. I discovered it when it
looked like a PM-2 had croaked. Some idiot was pinging one of those
assigned IP address from a netcom host and when someone was connected to
that address it would hurt that persons net performance but when nobody
was connected it brought the portmaster to a grinding halt and really
congested the router. Stuff kept running but it was really slow. I spent
a couple of days figuring it all out. I thought the PM-2 was broken and
obtained a spare. I was really stunned when the replacement unit did
exactly the same thing. I unloaded the box and put in some logging
filters and it instantly jumpped out at me what was going on. At that
time I had only very basic filters on the border routers and on the
dialups but I have a lot more now and I am not satisfied. The firewall
books are good sources of info but they really don't address the ISP. How
to protect yourself from the outside and how to protect the outside from
your customers. If everyone did this there would be a lot less problems.
Doug Ingraham From the Ferengi Rules of Acquisition.
Rapid City, SD #34 "Peace is good for business."
USA #35 "War is good for business."
> At 10:20 AM -0700 1/25/98, Doug Ingraham wrote:
> >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.
>
>
>
> -
> To unsubscribe, email 'majordomo@livingston.com' with
> 'unsubscribe portmaster-users' in the body of the message.
>
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.