What I mean:
- it is necessary to have a kind of "bit bucket" (others call it
"null intreface" to send packets destined to locally configured
but currently unavailable addresses to. This pseudo interface should
(optionally) generate ICMP unreachables.
- in the absence of said interface the only way to get rid of routing
loops (apart from having full routing propagated to the nearest device
having such interface) is to set up a static route pointing to
ethernet interface. Why it should not be set up this way I don't
understand. Having the packets looping over a default route to a
host on the ethernet (or even worse on WAN connection) is apparently not
a good idea. Does Livingston suspect PM2 box can handle 30 or so packets
over the ethernet in a quick burst?
Now we have the following setup:
A PM2ER box(es) connected to backbone via 56K FR link, servicing 30-60-90
phone lines plus Ethernet LAN (is 56K enough for this is not a question).
PM's ethernet is 192.168.1.1/24
LAN occupies all available 192.168.1/24 addresses
Dial-up pools are setup from 192.168.2/24 network
W1 is set to 192.168.3.1/30
PM has interface routes to 192.168.3/30 via W1 and 192.168.1/24 via ether0.
It also has static or RIPped in default route via W1.
Now, what about 192.168.2 network? Apparently the remote (default) router
needs some way to get information about this net. Having PM to advertises
host routes with RIP via W1 is impractical - it would eat some bandwidth,
but more important, on a saturated link RIP packets would be lost and the
remote router wouldn't know about the update for the next 30-60 etc seconds.
So one will put a static route to 192.168.2/24 on the remote router. Now
we have it - packets to inactive addresses in 192.168.2 loop over and over
his/her already saturated link. Next step is to set up a static route
to 192.168.2/24 in PM itself. One will point it to ether0 of course
(is there any other intreface suitable? No. Period.). It's easy:
add route 192.168.2.0 192.168.1.1 5
(I think the metric doesn't really matter here, so 5 is rather arbitrary value)
Now had Livingston implemented configurable RIP filters it would have been
possible to advertise this route (along with 192.168.1/24) over RIP to
the remote router but it's not necessary.
Everything seems ok, isn't it? It is until you get to think about multiple
boxes. With multiple boxes as everyone knows you need to exchange host
routes between the boxes (unless, of course, you dedicated a whole /24
for every box, which is a huge waste of adderss space... well one can
argue having both 192.168.1 and 192.168.2 in this POP is a waste of
address space - right, until the POP grows huge, or you have big LAN).
To make this happen (host route advertisements) one needs to issue
set netmask 192.168.2.0 255.255.255.255
on all the boxes. And here we go: the problem is that "set netmask"
command affects not only the way routes are advertised over the RIP
but also how the routes in the PM's routing table are treated. It's
still unclear to me if this influence is static or dynamic, but the
net result is that the effect of these two commands ("add route" and
"set netmask" depends on the order in which they have been issued.
add route 192.168.2.0 192.168.1.1 5
set netmask 192.168.2.0 255.255.255.255
would create a route to 192.168.2.0/24
set netmask 192.168.2.0 255.255.255.255
add route 192.168.2.0 192.168.1.1 5
would create a route to 192.168.2.0/32(!) which is rarely meant.
If one had entered the first combination and later issued another
"add route 192.168.2.0 ..." command (perhaps after a change of ethernet
address) he would get very suprising result (with packet loops). Moreover,
it would be impossible to delete the route:
delete route 192.168.2.0 192.168.1.1
would result in "network not in table" or whatever the exact error message is.
The only way to get this route deleted is
set netmask 192.168.2.0 255.255.255.0
delete route 192.168.2.0 192.168.1.1
set netmask 192.168.2.0 255.255.255.255
Interesting, isn't it?
And this and a couple of other related problems is because Livingston
decided not to introduce concept of explicit netmask in "route" commands
and opted for implicit netmasks with a separate "set netmask" command.
I brought up this question (well, in slightly different form)
to the list and directly to Livingston's support a year ago but
got nothing in reply.
Perhaps one may find the situation I have described too artificial
and rare, but it well illustrates the problems ComOS had and has
with routing and which anyone may run into in other situations.
Having some notes about this behaviour somewhere in
manuals/release notes/usage tips would have been great.
Wish the new release with OSPF code will clean up this mess.
>
>
> Kai:
> OK, I know I'm going to get in trouble for this with Brian, but here
> goes. Yes, the PortMaster's (in my opinion) should never send packets
> destined for an assignable (but currently unused) address back toward the
> default route. This situation is just another manifestation of that
> problem, as is unnecessary loading of the WAN circuit in PM2ER's when
> this problem results in routing loops. What I've done on our units is to
> designate the Ethernet port address as the gateway for the subnet which
> includes the assignable addresses (I use 30 address subnets). This causes
> packets for unused addresses to die right there. I don't know if in the
> case you describe it will be enough to prevent those deny complaints,
> but it should be easy to test. Brian has said several times that we are
> NOT to designate the ethernet port as a gateway, but until there is a
> change in the code, I don't see an alternative.
>
> Chuck
-- Igor V. Semenyuk Internet: iga@sovam.com SOVAM Teleport Phone: +7 095 258 4170 Moscow, Russia Fax: +7 095 258 4133