I have decided to grant jon's request and post all the real information
we are dealing with here. I'll also try and post a summary of what I
have tried so far.
We have 4 class C addresses assigned to Michiana.net,
208.226.220.0-223.0. We have these variably subnetted. The class C we
are dealing with is 208.226.220.0, here is how it is subnetted out:
208.226.220.0/30 (Unusable, all 0's and 1's)
208.226.220.4/30
208.226.220.8/29
208.226.220.16/29
208.226.220.24/30
208.226.220.28/30
208.226.220.32/27
208.226.220.64/26
208.226.220.128/26 (** This is the subnet we are working with in this
issue **)
208.226.220.192/27
208.226.220.224/27
208.226.220.252/30 (Unusable, all 0's and 1's)
>From anywhere I can ping 208.226.220.135 (255.255.255.192) but I can't
connect to port 80 from anywhere (including the server it's aliased on).
One potentially important note here. If I ping one of the other aliased
IP's from the server itself it answers with the IP:
isp# ping 208.226.220.129
PING 208.226.220.129 (208.226.220.129): 56 data bytes
64 bytes from 208.226.220.129: icmp_seq=0 ttl=255 time=2.4 ms
64 bytes from 208.226.220.129: icmp_seq=1 ttl=255 time=2.2 ms
64 bytes from 208.226.220.129: icmp_seq=2 ttl=255 time=116.6 ms
--- 208.226.220.129 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 2.2/40.4/116.6 ms
However, if I ping the one that doesn't work for port 80 I get the
localhost IP number back.
isp# ping 208.226.220.135
PING 208.226.220.135 (208.226.220.135): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.8 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.5 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.5 ms
--- 208.226.220.135 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.5/0.6/0.8 ms
If I ping from any other host it responds with 208.226.220.135 however.
Go figure.
Things I have tried/checked:
- routed is not running. I do not run rip.
- There are no stray routes on the network. (i.e. there are no subnets
inside of the 208.226.220.128/26 network)
- I am getting no errors or messages of any kind in the webserver logs.
- I have rebooted and restarted the webserver (apache) numerous times.
- ifconfig reports nothing strange.
- traceroute reports nothing out of the ordinary.
- the httpd.conf file is correct (i.e. the virtual-server definitions)
- The only host numbers that exhibit this problem are:
135:10000111
136:10001000
143:10001111
144:10010000
151:10010111
152:10011000
159:10011111
160:10100000
167:10100111
168:10101000
175:10101111
176:10110000
183:10110111
184:10111000
None of these will work.
- All the rest of the numbers in that network are aliased already and
work fine. I have also now routed 208.226.222.128/26 to that same host
and begun aliasing numbers from it for virtual hosting. This is working
fine (so it isn't simply having too many aliases or anything) except for
those same numbers in that network.
- Nothing strange in my syslog.
- loopback addresses are properly set with the appropriate netmasks.
- I have also pounded on my desk, banged my head on a wall and paced
till my co-workers were ready to cement me to my chair, all to no avail.
Does this help? Is there more information that you need? Please let me
know and I will provide it. (With certain reasonable limitations of
course. ;-)
-----Original Message-----
From: Jon Lewis [mailto:jlewis@inorganic5.fdt.net]
Sent: Wednesday, July 29, 1998 9:57 PM
To: Mark Bainter
Cc: 'isp-unix@isp-tech.com'; 'isp-tech@isp-tech.com';
'linuxisp@friendly.jeffnet.org'
Subject: Re: IP Aliasing under Red Hat 5.0 (Weird problem)
On Tue, 28 Jul 1998, Mark Bainter wrote:
TCP connections to port 80 from anywhere don't work, but you can ping
them
from anywhere?...or just from the server?
> The problem follows along all of those ip numbers. Anybody got any
> answers for me?
Repost the question cleaned up a bit and with the real IP's and people
can
look into it. With made up addresses, all they can do is speculate.
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.rutgers.edu