Felix Miata wrote:
>
> Pierre Fortin wrote:
>
> > Felix Miata wrote:
>
> > > > So your route command should work faster... no?
>
> > > Only if I use -n. Plenty slow otherwise.
>
> > Give us a new "route" and "route -n" output and indicate precisely where the
> > former's the delay occurs. What is st21s? It's unknown from here and from your
>
> st21s is 192.168.0.54, the Linux machine I'm trying to configure.
OK... then this name is in your /etc/hosts file.
> > message headers, you are on a dialup. The link is up when you are issuing the
> > route command, right?
>
> Not for the previous posts. These following are, and without using -n, the delay
> was before the first line was output.
>
> -n:
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 209.208.25.25 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
> 192.168.0.54 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
> 127.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 lo
> 192.168.0.0 192.168.0.254 255.255.255.0 UG 0 0 0 eth0
> 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
> 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
> 0.0.0.0 192.168.0.254 0.0.0.0 UG 0 0 0 eth0
> 0.0.0.0 192.168.0.254 0.0.0.0 UG 1 0 0 eth0
>
> without -n:
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 209.208.25.25 * 255.255.255.255 UH 0 0 0 ppp0
> st21s.atlantic. * 255.255.255.255 UH 0 0 0 eth0
> localhost * 255.255.255.255 UH 0 0 0 lo
> 192.168.0.0 192.168.0.254 255.255.255.0 UG 0 0 0 eth0
> 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
> 127.0.0.0 * 255.0.0.0 U 0 0 0 lo
> default 192.168.0.254 0.0.0.0 UG 0 0 0 eth0
> default 192.168.0.254 0.0.0.0 UG 1 0 0 eth0
>
> without -n or a connection the pause was after display of second entry:
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> st21s.atlantic. * 255.255.255.255 UH 0 0 0 eth0
> localhost * 255.255.255.255 UH 0 0 0 lo
> 192.168.0.0 192.168.0.254 255.255.255.0 UG 0 0 0 eth0
> 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
> 127.0.0.0 * 255.0.0.0 U 0 0 0 lo
> default 192.168.0.254 0.0.0.0 UG 0 0 0 eth0
> default 192.168.0.254 0.0.0.0 UG 1 0 0 eth0
>
> I don't understand why there are any .254 entries. Where do they come from?
> Nothing on my local net has IP 192.168.0.254.
Now... you got a clue when you noticed where the delay occured and a second one
when you questioned the .254 addresses... if you have no such gateway, then
this address is misconfigured in your /etc/sysconfig/network-scripts. The
gateway column of the route output need only contain a default gateway on a
LAN. Since you are using ppp to get out, all your entries only need to show '*'
which means that any packets going that way can be sent directly because there
is gateway listening. For example, on a ppp link, the other end *is* the
gateway, nothing else. On a LAN like I have, my gateway is "just another
'host'", so I should identify it, like this:
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.134.0 * 255.255.255.0 U 0 0 0 eth1
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default r41 0.0.0.0 UG 0 0 0 eth0
Alternatively, I could configure my gateway and hosts to use "proxy ARP",
negating the need for the "r41" entry; but that's for another course... :>
Note the simplicity of my route table... only one entry for each of eth0, eth1
and lo, then the all-important default which tells my machine how to get to the
rest of the world. Route tables with more than such minimalist entries are
usually a sign of misconfiguration and either troubles or timebombs...
In your case, you should only have eth0, lo and default when disconnected; plus
ppp0, and updated (IIRC) default when connected (default should point to ppp0).
Even "localhost" is redundant when 127.0.0.0 is in the table.
> I changed /etc/rc.d/rc.local from:
> route add -net 192.168.0.0 netmask 255.255.0.0 gw 192.168.0.254
> to
> route add -net 192.168.0.0 netmask 255.255.0.0 gw 192.168.0.54
You should just remove this command which causes (dup) from rc.local, because
the correct (OK) command already exists:
[I annotated this table with "(...)"]
> and got with route -n and isp connection:
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 209.208.25.20 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
> 192.168.0.54(?) 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
> 127.0.0.1(??) 0.0.0.0 255.255.255.255 UH 0 0 0 lo
> 192.168.0.0(dup)192.168.0.54 255.255.255.0 UG 0 0 0 eth0
> 192.168.0.0(OK) 0.0.0.0 255.255.255.0 U 0 0 0 eth0
> 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
> 0.0.0.0(???) 192.168.0.254 0.0.0.0 UG 0 0 0 eth0
> 0.0.0.0(????) 192.168.0.254 0.0.0.0 UG 1 0 0 eth0
Once the rc.local entry is removed, you next have to figure out why the (?)
entry is there at all, that address falls within the range specified by
192.168.0.0/255.255.255.0...
??: localhost is redundant when 127.0.0.0 exists.
???: this default should not be there since your default SHOULD be installed by
ppp when the link comes up.
????: this default should not be there at all in your case.
What does your /etc/sysconfig/network file contain? Should look like this for
ppp:
NETWORKING=yes
FORWARD_IPV4=yes
HOSTNAME=st21s.atlantic.net
DOMAINNAME=atlantic.net
GATEWAY=
GATEWAYDEV=
> Without the -n I still get the long delay.
Because your system is trying to resolve 192.168.0.254... getting rid of this
bogus entry will speed up a lot of stuff...
> > Where did you get those scripts? None of mine have the metric arg on the route
>
> Came with the OS install?
>
> > commands... so if you look closer, you'll probably find you have other route
> > commands in these files without "metric" which would explain the duplicate
> > routes. Send me a copy of these scripts; I'm curious...
>
> Sent.
Yikes... what system version are you using...?
Delete this section from your ifup:
# this is broken! it's only here for compatibility with old RH systems
if [ "${GATEWAY}" != "" -a "${GATEWAY}" != "none" ]; then
route add default gw ${GATEWAY} metric 1 ${DEVICE}
fi
It's creating the second default, without checking for an existing default.
Or better, upgrade your system... the plip file you sent has a similar problem
indicating an old distro.
HTH,
Pierre
