> On Sun, 25 Jan 1998, Rob Chandhok wrote:
>
> > 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>.
Not a problem, as long as the gateway for your PM is a router on the
local ethernet. A REAL BIG PROBLEM if that gateway happens to be at the
other end of a WAN off of a Wx port! Even a relatively slow stream of
packets for an un-assigned IP that bounces back and forth across a WAN
link can eat your bandwidth. (Example: A 500 byte packet with 240 hops
left will traverse each direction 120 times before it dies. That's 60KB
or 480 Kilobits. If you have a 256K WAN link, that's nearly 2 seconds of
Bandwidth!)
>
> > 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.
Clearly, a packet should never leave the PM with a destination address
in it's assigned address pool any other way than locally to an interface
with that address. This is a very old problem, perhaps as old as ComOS
and we've known about it for 3 years.
There are as I can figure only 2 good ways to work this problem. One is to
use filters to prevent any packet with a destination address in the assigned
address space from going out the Ethernet or WAN ports. The other is to
select configuration in which the Ethernet port and the assigned addresses
are all in the same subnet, which will prevent those packets from being
routed back the default route. (The subnet mask on the Ethernet port
encompasses the assigned address space.)
Frankly, if it's a matter of Livingston/Lucent fixing one thing or the
other, I'd rather they work on something that doesn't have a good
work-around. It would however be nice if they someday got to this one
since I believe it's hurting people who aren't aware of the problem.
Chuck
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.