[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Strange entry in my routing table.



Juan R. de Silva wrote:
> Here is my routing table:
> 
> 0.0.0.0       192.168.25.68   0.0.0.0         UG    0      0        0 eth0
> 192.168.24.0  0.0.0.0         255.255.252.0   U     1      0        0 eth0
> 
> The first entry IS my default gateway as I expected. 
> 
> The second line, however, is something I cannot neither recognize nor 
> explain. It obviously belongs to something on a different LAN segment, 
> which I do not have. I mean I do not have any subnets on my LAN.

If those are your only two entries then your IP address *must* be in
the 192.168.24.0/255.255.252.0 subnet.  Right?  That is the route for
your local subnet which is associated with your IP address.

> I tried to ping 192.168.24.0 with no response.

Good.  Because that is the network address.  In the old days every
host on the net would have responded to you.  If you are at home then
you might have no other hosts on the network.  If you were in a big
company or university then you might have thousands of replies coming
back to your system.  It would generally overwhelm both your system
and the switches handling your network.

> Trying 'ping -b 192.168.24.255' gives me only my own LAN IP address with 
> "Destination Host Unreachable".

That is not your broadcast address.  You list 255.255.252.0 as the
netmask for that lan segment.  That makes your broadcast address on
that network 192.168.27.255.  If you were to ping the broadcast
address then again every host on the network should respond.  Not
usually what you want.

> The wireless on my router is disabled from GUI interface. The router is 
> flashed with dd-wrt. Should I assume my router has been hacked and re-
> flash it?

No.  You should tell us what your IP address is so that we can confirm
that it is on the 192.168.24.0/255.255.252.0 network.

  $ ipcalc 192.168.24.0/255.255.252.0
  Address:   192.168.24.0         11000000.10101000.000110 00.00000000
  Netmask:   255.255.252.0 = 22   11111111.11111111.111111 00.00000000
  Wildcard:  0.0.3.255            00000000.00000000.000000 11.11111111
  =>
  Network:   192.168.24.0/22      11000000.10101000.000110 00.00000000
  HostMin:   192.168.24.1         11000000.10101000.000110 00.00000001
  HostMax:   192.168.27.254       11000000.10101000.000110 11.11111110
  Broadcast: 192.168.27.255       11000000.10101000.000110 11.11111111
  Hosts/Net: 1022                  Class C, Private Internet

> Can somebody help me to understand this, please?

When you configure an IP address on your system it always includes a
netmask for the subnet.  That information is used to create a routing
table entry for the local subnet.  It allows your system to determine
whether an address is directly accessible or if the address needs to
connect using a gateway.  If a remote address can be routed to by your
subnet then it will speak directly to it.  If it isn't on a local
subnet then it will route through a gateway route.  If no gateway
route is configured then the address is unreachable.

Hope that helps.

Bob

P.S. I have a pet peeve about the routing table printing order on
newer Linux kernels.  In the old kernels and in legacy Unix systems
the route table was top down.  Adress matching was done top to bottom.
First are the local routes and the last one listed was the default
route.  Routing was selected by walking the table top to bottom.  If
none of the local entries matched then the default route was listed at
the bottom and the packet matched that and was sent to the router.

Back in some Linux version that I don't recall they flipped the order
printed to be the opposite way.  The order you show is the new
upsidedown order.  In your order and the newer Linux kernels you match
from bottom to top.  Start at the bottom with the last entry listed
and then walk through the listing from bottom to top.  If nothing else
hits then the last entry is the default entry on top and the packet is
sent to the default route.  Needing to look at it upsidedown I find
very inconvenient and a break from traditional practice for no good
reason.

My preference now is to use this to work around the issue.

  ip route | tac

Attachment: signature.asc
Description: Digital signature


Reply to: