broadcast route suddenly missing

For some reason my broadcast route has disapeared. When I try to telnet to
my RedHat 7.2 router, it takes about 20 seconds for the login prompt to
appear.

The machine is routing, and DNS Caching perfectly.

The route that I'm missing is:

255.255.255.255 * 255.255.255.255 UH 0 0 eth1

IFCONFIG shows that the UP BROADCAST is set. I have restarted and rebooted,
but no luck.

The only thing that I have changedin the past month, is the forwarders in
the DNS. I have disabled the NAMED daemon, then tried to telnet to it, but
the same results.

I also noticed that both my NIC's were on IRQ 11. I changed it, so they are
now on different IRQ's, but no go.

Any help is appreciated.


--
"I Knew I should have taken that left turn at Albuquerque"
-Bugs Bunny





Craig Cameron

Craig Cameron wrote:
> For some reason my broadcast route has disapeared. When I try to
telnet to
> my RedHat 7.2 router, it takes about 20 seconds for the login prompt
to
> appear.
>
> The machine is routing, and DNS Caching perfectly.

Doubtful. If it's taking 20 seconds for a prompt where it used to
take, say 5, then I would immediately suspect DNS -- assuming of course
that you're telneting from another net. If you're on the same segment,
then ...

> The route that I'm missing is:
>
> 255.255.255.255 * 255.255.255.255 UH 0 0 eth1

This is so obscure, it's useless. Missing from where? Route tables?
NIC? DHCP server? DNS?

> IFCONFIG shows that the UP BROADCAST is set. I have restarted and
rebooted,
> but no luck.

What's an UP BROADCAST? That means the net connection is UP, BROADCAST
is enabled.

Actually, ifconfig output -- all of it -- is what is needed here
together with route -n. If you want to obscure your IPs, use XXX.XXX
for the first two octets, eg. But _all_ of the netmask.

[pbrain]$ /sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:400:04:06:AC
inet addr:XXX.XXX.201.57 Bcast:255.255.255.255
Mask:255.255.248.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:555440 errors:0 dropped:0 overruns:0 frame:0
TX packets:174507 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
RX bytes:377182729 (359.7 Mb) TX bytes:13127921 (12.5 Mb)
(downloaded a dbms earlier)

[pbrain]$ /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
XXX.XXX.200.0 0.0.0.0 255.255.248.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 XXX.XXX.200.1 0.0.0.0 UG 0 0 0
eth0



> The only thing that I have changed in the past month, is the
forwarders in
> the DNS. I have disabled the NAMED daemon, then tried to telnet to
it, but
> the same results.

Could be you're forwarding DNS where you should not -- no way for me to
even guess without specific data/info/command output.

> I also noticed that both my NIC's were on IRQ 11. I changed it, so
they are
> now on different IRQ's, but no go.

Why on earth did you even try this and what did you expect to gain?
The hardware "stirs" IRQ requests and it's not unusual to see 5 or 6
items on IRQ 11.

> Any help is appreciated.
>

Since I don't know where you're telenting from or the layout of your
problem net or your IPs or what netmask you _should_ be using or
whether probnet is using static IPs or DHCP or what your default route
is/should be or -- well, you get the picture. Solving network problems
requires bright light, not midnight fog. Especially long distance.

Get back with the needed info and someone around here will likely get
you an answer.

prg
email above disabled

The route I'm referring to is from the routing table. See below:

eth0 Link encap:Ethernet HWaddr 00:50:BA:5B:F0:5C
inet addr:xx.yyy.99.59 Bcast:255.255.255.255 Mask:255.255.254.0
UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1
RX packets:953 errors:0 dropped:0 overruns:0 frame:0
TX packets:917 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:98290 (95.9 Kb) TX bytes:58702 (57.3 Kb)
Interrupt:10 Base address:0x5c00

eth1 Link encap:Ethernet HWaddr 00:50:BA:4F:8B:68
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3155 errors:0 dropped:0 overruns:0 frame:0
TX packets:2230 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:194584 (190.0 Kb) TX bytes:325832 (318.1 Kb)
Interrupt:3 Base address:0x7800

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:420 (420.0 b) TX bytes:420 (420.0 b)


Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
xx.yyy.98.0 0.0.0.0 255.255.254.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 xx.yyy.98.1 0.0.0.0 UG 0 0 0 eth0

My default route on all my client machines is 192.168.1.1

All clients are static 192.168.1.x.


--
"I Knew I should have taken that left turn at Albuquerque"
-Bugs Bunny

"prg" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
>
> Craig Cameron wrote:
> > For some reason my broadcast route has disapeared. When I try to
> telnet to
> > my RedHat 7.2 router, it takes about 20 seconds for the login prompt
> to
> > appear.
> >
> > The machine is routing, and DNS Caching perfectly.
>
> Doubtful. If it's taking 20 seconds for a prompt where it used to
> take, say 5, then I would immediately suspect DNS -- assuming of course
> that you're telneting from another net. If you're on the same segment,
> then ...
>
> > The route that I'm missing is:
> >
> > 255.255.255.255 * 255.255.255.255 UH 0 0 eth1
>
> This is so obscure, it's useless. Missing from where? Route tables?
> NIC? DHCP server? DNS?
>
> > IFCONFIG shows that the UP BROADCAST is set. I have restarted and
> rebooted,
> > but no luck.
>
> What's an UP BROADCAST? That means the net connection is UP, BROADCAST
> is enabled.
>
> Actually, ifconfig output -- all of it -- is what is needed here
> together with route -n. If you want to obscure your IPs, use XXX.XXX
> for the first two octets, eg. But _all_ of the netmask.
>
> [pbrain]$ /sbin/ifconfig
> eth0 Link encap:Ethernet HWaddr 00:400:04:06:AC
> inet addr:XXX.XXX.201.57 Bcast:255.255.255.255
> Mask:255.255.248.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:555440 errors:0 dropped:0 overruns:0 frame:0
> TX packets:174507 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0
> RX bytes:377182729 (359.7 Mb) TX bytes:13127921 (12.5 Mb)
> (downloaded a dbms earlier)
>
> [pbrain]$ /sbin/route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use
> Iface
> XXX.XXX.200.0 0.0.0.0 255.255.248.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 XXX.XXX.200.1 0.0.0.0 UG 0 0 0
> eth0
>
>
>
> > The only thing that I have changed in the past month, is the
> forwarders in
> > the DNS. I have disabled the NAMED daemon, then tried to telnet to
> it, but
> > the same results.
>
> Could be you're forwarding DNS where you should not -- no way for me to
> even guess without specific data/info/command output.
>
> > I also noticed that both my NIC's were on IRQ 11. I changed it, so
> they are
> > now on different IRQ's, but no go.
>
> Why on earth did you even try this and what did you expect to gain?
> The hardware "stirs" IRQ requests and it's not unusual to see 5 or 6
> items on IRQ 11.
>
> > Any help is appreciated.
> >
>
> Since I don't know where you're telenting from or the layout of your
> problem net or your IPs or what netmask you _should_ be using or
> whether probnet is using static IPs or DHCP or what your default route
> is/should be or -- well, you get the picture. Solving network problems
> requires bright light, not midnight fog. Especially long distance.
>
> Get back with the needed info and someone around here will likely get
> you an answer.
>
> prg
> email above disabled
>

Craig Cameron wrote:
> The route I'm referring to is from the routing table. See below:
>
> eth0 Link encap:Ethernet HWaddr 00:50:BA:5B:F0:5C
> inet addr:xx.yyy.99.59 Bcast:255.255.255.255
Mask:255.255.254.0
> UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1
[snip]
>
> eth1 Link encap:Ethernet HWaddr 00:50:BA:4F:8B:68
> inet addr:192.168.1.1 Bcast:192.168.1.255
Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
[snip]
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MTU:16436 Metric:1
[snip]
>
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref
Use
> Iface
> 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0
0 eth1
> xx.yyy.98.0 0.0.0.0 255.255.254.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 xx.yyy.98.1 0.0.0.0 UG 0 0
0 eth0

The default route genmask is really provided by the network entry
above, so it always appears as 0.0.0.0 -- after all, no telling what
netmask is used by "unknown" destinations.

> My default route on all my client machines is 192.168.1.1
>
> All clients are static 192.168.1.x.
[snip]

OK, the config looks consistent and presumably proper.

When you telnet into this box, do you mean from your lan side or from
outside, ie., to the public IP? The lan side (via a switch?) is
"directly" connected to eth1 on the same segment so only arp is needed
to find a host.

>From the outside, DNS will be used _if_ you use a host _name_ but
should resolve "immediately" if using IP#. Even with DNS, after the
first connection you should be able to reconnect if the DNS cache is
working effectively on the outside.

You might double check _your_ setup by observing the arp cache and
confirmiming that dhcp (on eth0) is OK
(/var/lib/dhcp/dhclient-eth0.leases on my RH machine).

Since everything you show here looks OK, I suspect a DNS problem --
sometimes happens for a day or two if tables have to be rebuilt.
Longer than that indicates someone has a config/setup problem. Your
public IP should be handled by your ISP together with maintaining DNS
entries and on the far end that DNS server should be properly
forwarding requests (and perhaps cacheing the results if the hardware
is up to it).

>From the outside how does a ping via DNS compare to a ping via IP#?
Any clue from traceroute output? Is the DNS server handed to you from
DHCP on a public IP and if so can you ping it? The backup DNS server?
If your ISP is reconfiguring his setup you may have flakey response for
some time till they get settled. You can check here to see if others
may be having trouble:

http://www.dslreports.com/forums/all
Don't be fooled by the dsl name -- it is far more than that would
suggest.

The only other thing I can think of off hand is that some network
traffic shaping has boinked interactive (as in telnet) use since telnet
uses a byte-by-byte (keystroke-by-keystroke) protocol. Nothing you can
do about that, though.

A bit more context about _where_ you're connecting from/to would be
very useful.

hth,
prg
email above disabled

I looked in the /var/log/messages, and it says the following:

/etc/named.conf:14: cannot redefine options

The line it is referring to is:
options { forwarders { xx.xx.63.195; xx.xx.63.212; }; forward only;};

My DNS is a caching only DNS server with the forwarders pointint to my ISP's
DNS Servers.

Like I said, the linux box routes and Internet access is fine.

Is my syntax wrong?

TIA.
--
"I Knew I should have taken that left turn at Albuquerque"
-Bugs Bunny

"prg" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
>
> Craig Cameron wrote:
> > The route I'm referring to is from the routing table. See below:
> >
> > eth0 Link encap:Ethernet HWaddr 00:50:BA:5B:F0:5C
> > inet addr:xx.yyy.99.59 Bcast:255.255.255.255
> Mask:255.255.254.0
> > UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1
> [snip]
> >
> > eth1 Link encap:Ethernet HWaddr 00:50:BA:4F:8B:68
> > inet addr:192.168.1.1 Bcast:192.168.1.255
> Mask:255.255.255.0
> > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> [snip]
> >
> > lo Link encap:Local Loopback
> > inet addr:127.0.0.1 Mask:255.0.0.0
> > UP LOOPBACK RUNNING MTU:16436 Metric:1
> [snip]
> >
> > Kernel IP routing table
> > Destination Gateway Genmask Flags Metric Ref
> Use
> > Iface
> > 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0
> 0 eth1
> > xx.yyy.98.0 0.0.0.0 255.255.254.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 xx.yyy.98.1 0.0.0.0 UG 0 0
> 0 eth0
>
> The default route genmask is really provided by the network entry
> above, so it always appears as 0.0.0.0 -- after all, no telling what
> netmask is used by "unknown" destinations.
>
> > My default route on all my client machines is 192.168.1.1
> >
> > All clients are static 192.168.1.x.
> [snip]
>
> OK, the config looks consistent and presumably proper.
>
> When you telnet into this box, do you mean from your lan side or from
> outside, ie., to the public IP? The lan side (via a switch?) is
> "directly" connected to eth1 on the same segment so only arp is needed
> to find a host.
>
> >From the outside, DNS will be used _if_ you use a host _name_ but
> should resolve "immediately" if using IP#. Even with DNS, after the
> first connection you should be able to reconnect if the DNS cache is
> working effectively on the outside.
>
> You might double check _your_ setup by observing the arp cache and
> confirmiming that dhcp (on eth0) is OK
> (/var/lib/dhcp/dhclient-eth0.leases on my RH machine).
>
> Since everything you show here looks OK, I suspect a DNS problem --
> sometimes happens for a day or two if tables have to be rebuilt.
> Longer than that indicates someone has a config/setup problem. Your
> public IP should be handled by your ISP together with maintaining DNS
> entries and on the far end that DNS server should be properly
> forwarding requests (and perhaps cacheing the results if the hardware
> is up to it).
>
> >From the outside how does a ping via DNS compare to a ping via IP#?
> Any clue from traceroute output? Is the DNS server handed to you from
> DHCP on a public IP and if so can you ping it? The backup DNS server?
> If your ISP is reconfiguring his setup you may have flakey response for
> some time till they get settled. You can check here to see if others
> may be having trouble:
>
> http://www.dslreports.com/forums/all
> Don't be fooled by the dsl name -- it is far more than that would
> suggest.
>
> The only other thing I can think of off hand is that some network
> traffic shaping has boinked interactive (as in telnet) use since telnet
> uses a byte-by-byte (keystroke-by-keystroke) protocol. Nothing you can
> do about that, though.
>
> A bit more context about _where_ you're connecting from/to would be
> very useful.
>
> hth,
> prg
> email above disabled
>

I just found the problem. When I said the only items I have changed, was
the forwarders in the caching DNS.

Well, I guess I had to change it /etc/resolv.conf

I'm new to linux, but should have known that in the Linux manner, many files
may have to be updated, rather than just one.

Thanks for all your help.

--
"I Knew I should have taken that left turn at Albuquerque"
-Bugs Bunny

"Craig Cameron" <monte-(E-Mail Removed)> wrote in message
news:1Xlyd.544880$Pl.126127@pd7tw1no...
> I looked in the /var/log/messages, and it says the following:
>
> /etc/named.conf:14: cannot redefine options
>
> The line it is referring to is:
> options { forwarders { xx.xx.63.195; xx.xx.63.212; }; forward only;};
>
> My DNS is a caching only DNS server with the forwarders pointint to my
ISP's
> DNS Servers.
>
> Like I said, the linux box routes and Internet access is fine.
>
> Is my syntax wrong?
>
> TIA.
> --
> "I Knew I should have taken that left turn at Albuquerque"
> -Bugs Bunny
>
> "prg" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) oups.com...
> >
> > Craig Cameron wrote:
> > > The route I'm referring to is from the routing table. See below:
> > >
> > > eth0 Link encap:Ethernet HWaddr 00:50:BA:5B:F0:5C
> > > inet addr:xx.yyy.99.59 Bcast:255.255.255.255
> > Mask:255.255.254.0
> > > UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1
> > [snip]
> > >
> > > eth1 Link encap:Ethernet HWaddr 00:50:BA:4F:8B:68
> > > inet addr:192.168.1.1 Bcast:192.168.1.255
> > Mask:255.255.255.0
> > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> > [snip]
> > >
> > > lo Link encap:Local Loopback
> > > inet addr:127.0.0.1 Mask:255.0.0.0
> > > UP LOOPBACK RUNNING MTU:16436 Metric:1
> > [snip]
> > >
> > > Kernel IP routing table
> > > Destination Gateway Genmask Flags Metric Ref
> > Use
> > > Iface
> > > 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0
> > 0 eth1
> > > xx.yyy.98.0 0.0.0.0 255.255.254.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 xx.yyy.98.1 0.0.0.0 UG 0 0
> > 0 eth0
> >
> > The default route genmask is really provided by the network entry
> > above, so it always appears as 0.0.0.0 -- after all, no telling what
> > netmask is used by "unknown" destinations.
> >
> > > My default route on all my client machines is 192.168.1.1
> > >
> > > All clients are static 192.168.1.x.
> > [snip]
> >
> > OK, the config looks consistent and presumably proper.
> >
> > When you telnet into this box, do you mean from your lan side or from
> > outside, ie., to the public IP? The lan side (via a switch?) is
> > "directly" connected to eth1 on the same segment so only arp is needed
> > to find a host.
> >
> > >From the outside, DNS will be used _if_ you use a host _name_ but
> > should resolve "immediately" if using IP#. Even with DNS, after the
> > first connection you should be able to reconnect if the DNS cache is
> > working effectively on the outside.
> >
> > You might double check _your_ setup by observing the arp cache and
> > confirmiming that dhcp (on eth0) is OK
> > (/var/lib/dhcp/dhclient-eth0.leases on my RH machine).
> >
> > Since everything you show here looks OK, I suspect a DNS problem --
> > sometimes happens for a day or two if tables have to be rebuilt.
> > Longer than that indicates someone has a config/setup problem. Your
> > public IP should be handled by your ISP together with maintaining DNS
> > entries and on the far end that DNS server should be properly
> > forwarding requests (and perhaps cacheing the results if the hardware
> > is up to it).
> >
> > >From the outside how does a ping via DNS compare to a ping via IP#?
> > Any clue from traceroute output? Is the DNS server handed to you from
> > DHCP on a public IP and if so can you ping it? The backup DNS server?
> > If your ISP is reconfiguring his setup you may have flakey response for
> > some time till they get settled. You can check here to see if others
> > may be having trouble:
> >
> > http://www.dslreports.com/forums/all
> > Don't be fooled by the dsl name -- it is far more than that would
> > suggest.
> >
> > The only other thing I can think of off hand is that some network
> > traffic shaping has boinked interactive (as in telnet) use since telnet
> > uses a byte-by-byte (keystroke-by-keystroke) protocol. Nothing you can
> > do about that, though.
> >
> > A bit more context about _where_ you're connecting from/to would be
> > very useful.
> >
> > hth,
> > prg
> > email above disabled
> >
>
>

Craig Cameron wrote:
> I just found the problem. When I said the only items I have changed,
was
> the forwarders in the caching DNS.
>
> Well, I guess I had to change it /etc/resolv.conf
>
> I'm new to linux, but should have known that in the Linux manner,
many files
> may have to be updated, rather than just one.
>
> Thanks for all your help.
>
[snip]

We all go through this -- it never really clears as I should have told
you to check the file myself. It's not often it's the source of a
problem once it's configured, but now and then ... ;-)

Anyway, glad you cleared it up and earned some Linux kharma (for
reporting the solution) as well as zen.
Cheers,
prg
eamil above disabled