Re: [suse-linux-uk-schools] Some showstopping network issues..
Sorry about the delay, i've been busy with a few things. Anyway heres the info: eth0 Link encap:Ethernet HWaddr 00:00:E8:8B:7E:66 inet addr:192.168.3.200 Bcast:192.168.3.255 Mask:255.255.252.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:691566 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:7 Base address:0xf000 eth1 Link encap:Ethernet HWaddr 00:90:27:73:DB:FC inet addr:10.0.40.2 Bcast:10.0.41.255 Mask:255.255.254.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:64 errors:0 dropped:0 overruns:0 frame:0 TX packets:33 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:1386 (1.3 Kb) Interrupt:5 Base address:0x1060 Memory:fa104000-fa104038 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:205 errors:0 dropped:0 overruns:0 frame:0 TX packets:205 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:20696 (20.2 Kb) TX bytes:20696 (20.2 Kb) PING 192.168.3.200 (192.168.3.200) from 192.168.3.200 : 56(84) bytes of data. 64 bytes from 192.168.3.200: icmp_seq=1 ttl=255 time=0.180 ms 64 bytes from 192.168.3.200: icmp_seq=2 ttl=255 time=0.113 ms 64 bytes from 192.168.3.200: icmp_seq=3 ttl=255 time=0.115 ms 64 bytes from 192.168.3.200: icmp_seq=4 ttl=255 time=0.114 ms 64 bytes from 192.168.3.200: icmp_seq=5 ttl=255 time=0.117 ms 64 bytes from 192.168.3.200: icmp_seq=6 ttl=255 time=0.118 ms PING 192.168.3.201 (192.168.3.201) from 192.168.3.200 : 56(84) bytes of data.
From 192.168.3.200: icmp_seq=1 Destination Host Unreachable From 192.168.3.200 icmp_seq=1 Destination Host Unreachable From 192.168.3.200 icmp_seq=2 Destination Host Unreachable From 192.168.3.200 icmp_seq=3 Destination Host Unreachable From 192.168.3.200 icmp_seq=4 Destination Host Unreachable From 192.168.3.200 icmp_seq=5 Destination Host Unreachable
PING 10.0.40.2 (10.0.40.2) from 10.0.40.2 : 56(84) bytes of data. 64 bytes from 10.0.40.2: icmp_seq=1 ttl=255 time=0.137 ms 64 bytes from 10.0.40.2: icmp_seq=2 ttl=255 time=0.119 ms 64 bytes from 10.0.40.2: icmp_seq=3 ttl=255 time=0.113 ms 64 bytes from 10.0.40.2: icmp_seq=4 ttl=255 time=0.115 ms 64 bytes from 10.0.40.2: icmp_seq=5 ttl=255 time=0.117 ms PING 10.0.40.1 (10.0.40.1) from 10.0.40.2 : 56(84) bytes of data.
From 10.0.40.2: icmp_seq=1 Destination Host Unreachable From 10.0.40.2 icmp_seq=1 Destination Host Unreachable From 10.0.40.2 icmp_seq=2 Destination Host Unreachable From 10.0.40.2 icmp_seq=3 Destination Host Unreachable
Kernal IP Routing Table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.40.0 0.0.0.0 255.255.254.0 U 0 0 0 eth1 192.168.0.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 0.0.0.0 10.0.40.1 0.0.0.0 UG 0 0 0 eth1 __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
On Tue, 25 Jun 2002, Steve Palmer wrote:
Sorry about the delay, i've been busy with a few things. Anyway heres the info:
eth0 Link encap:Ethernet HWaddr 00:00:E8:8B:7E:66 inet addr:192.168.3.200 Bcast:192.168.3.255 Mask:255.255.252.0
OKish.
eth1 Link encap:Ethernet HWaddr 00:90:27:73:DB:FC inet addr:10.0.40.2 Bcast:10.0.41.255 Mask:255.255.254.0
OK. Who chose these subnet masks, btw?
PING 192.168.3.200 (192.168.3.200) from 192.168.3.200 : 56(84) bytes of data. 64 bytes from 192.168.3.200: icmp_seq=1 ttl=255 time=0.180 ms
Proves that eth0 interface is working, but proves nothing about routing to 192.168.0.0/255.255.252.0 network.
PING 192.168.3.201 (192.168.3.201) from 192.168.3.200 : 56(84) bytes of data. From 192.168.3.200: icmp_seq=1 Destination Host Unreachable
Suggests a dead host. A routing problem would show up as "connect: Network is unreachable"
PING 10.0.40.2 (10.0.40.2) from 10.0.40.2 : 56(84) bytes of data. 64 bytes from 10.0.40.2: icmp_seq=1 ttl=255 time=0.137 ms
Again, proves that eth1 is working but doesn't say anything about state of routing to 10.0.40.0/255.255.254.0
PING 10.0.40.1 (10.0.40.1) from 10.0.40.2 : 56(84) bytes of data. From 10.0.40.2: icmp_seq=1 Destination Host Unreachable
Suggests a dead host, as before.
Kernal IP Routing Table Destination Gateway Genmask Flags Iface 10.0.40.0 0.0.0.0 255.255.254.0 U eth1 192.168.0.0 0.0.0.0 255.255.252.0 U eth0 0.0.0.0 10.0.40.1 0.0.0.0 UG eth1
Routing looks OK, assuming that 10.0.40.1 is the IP address of your default gateway. Are you *sure* that you have the physical network cables plugged in the right way round (as in eth0->192.168.0.0 network, eth1->10.0.40.0 network)? Are you also sure that the hosts you are pinging (192.168.3.201 and 10.0.40.1) are alive and able to communicate with the rest of the network? You could try running tcpdump -i eth0 -n and tcpdump -i eth1 -n to observe traffic coming to both network cards. This should show you if you have got the wires mixed up. As a final check: do you have any firewalling (ipchains/iptables) rules set up? Michael Brown http://www.fensystems.co.uk -- Fen Systems: Linux made easy for schools
the 255.255.252.0 subnet was designated by RM when
they installed the network some years ago. The other
one is designated by EMBC who provide the internet
access - they gave us a subnet mask range of
255.255.25** **= 2-5 with a range of ips from
10.0.40.2-254 with the intention of us switching over
to their network and having the computers directly
hooked in - fat chance! that gives us very little
control thus we are using a proxy..
As we requested 10.0.40.2 gets redirected to an
external ip address for means to host our own website
or email. 10.0.40.1 is the ip of the cisco leased line
router which has a 2mb capacity.
As mentioned earlier, i'm going to go and have a look
at removing the acction nic, and try just running off
the integrated intel nic on the internal network. That
nic incidentially has no means in which to disable it
via the bios nor a jumper setting on the mobo..
--- Michael Brown
Sorry about the delay, i've been busy with a few things. Anyway heres the info:
eth0 Link encap:Ethernet HWaddr 00:00:E8:8B:7E:66 inet addr:192.168.3.200 Bcast:192.168.3.255 Mask:255.255.252.0
OKish.
eth1 Link encap:Ethernet HWaddr 00:90:27:73:DB:FC inet addr:10.0.40.2 Bcast:10.0.41.255 Mask:255.255.254.0
OK. Who chose these subnet masks, btw?
PING 192.168.3.200 (192.168.3.200) from 192.168.3.200 : 56(84) bytes of data. 64 bytes from 192.168.3.200: icmp_seq=1 ttl=255 time=0.180 ms
Proves that eth0 interface is working, but proves nothing about routing to 192.168.0.0/255.255.252.0 network.
PING 192.168.3.201 (192.168.3.201) from 192.168.3.200 : 56(84) bytes of data. From 192.168.3.200: icmp_seq=1 Destination Host Unreachable
Suggests a dead host. A routing problem would show up as "connect: Network is unreachable"
PING 10.0.40.2 (10.0.40.2) from 10.0.40.2 : 56(84) bytes of data. 64 bytes from 10.0.40.2: icmp_seq=1 ttl=255 time=0.137 ms
Again, proves that eth1 is working but doesn't say anything about state of routing to 10.0.40.0/255.255.254.0
PING 10.0.40.1 (10.0.40.1) from 10.0.40.2 : 56(84) bytes of data. From 10.0.40.2: icmp_seq=1 Destination Host Unreachable
Suggests a dead host, as before.
Kernal IP Routing Table Destination Gateway Genmask Flags Iface 10.0.40.0 0.0.0.0 255.255.254.0 U eth1 192.168.0.0 0.0.0.0 255.255.252.0 U eth0 0.0.0.0 10.0.40.1 0.0.0.0 UG eth1
Routing looks OK, assuming that 10.0.40.1 is the IP address of your default gateway.
Are you *sure* that you have the physical network cables plugged in the right way round (as in eth0->192.168.0.0 network, eth1->10.0.40.0 network)? Are you also sure that the hosts you are pinging (192.168.3.201 and 10.0.40.1) are alive and able to communicate with the rest of the network?
You could try running
tcpdump -i eth0 -n
and
tcpdump -i eth1 -n
to observe traffic coming to both network cards. This should show you if you have got the wires mixed up.
As a final check: do you have any firewalling (ipchains/iptables) rules set up?
Michael Brown http://www.fensystems.co.uk -- Fen Systems: Linux made easy for schools
-- To unsubscribe, e-mail: suse-linux-uk-schools-unsubscribe@suse.com For additional commands, e-mail: suse-linux-uk-schools-help@suse.com
__________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
On Tue, 25 Jun 2002, Steve Palmer wrote:
the 255.255.252.0 subnet was designated by RM when they installed the network some years ago. The other one is designated by EMBC who provide the internet access - they gave us a subnet mask range of 255.255.25** **= 2-5 with a range of ips from 10.0.40.2-254 with the intention of us switching over to their network and having the computers directly hooked in - fat chance! that gives us very little control thus we are using a proxy..
I think you may have misread the information they sent you (or, equally possibly, they miswrote it!). Firstly, only 255.255.255.252, 255.255.255.254 and 255.255.255.255 are valid subnet masks within that range. Secondly you cannot have a "subnet mask range" on a network. A very brief explanation of subnet masks: All machines on the same network must have the same network address. The network address is obtained by binary ANDing the IP address with the subnet mask. Thus, an IP address 192.168.3.200 with a subnet mask of 255.255.252.0 has a network address of 192.168.0.0: 192.168.3.200 = 11000000.10101000.00000011.11001000 255.255.252.0 = 11111111.11111111.11111100.00000000 192.168.0.0 = 11000000.10101000.00000000.00000000 Similarly, 192.168.2.47/255.255.252.0 would have a network address of 192.168.0.0: 192.168.2.47 = 11000000.10101000.00000010.00101111 255.255.252.0 = 11111111.11111111.11111100.00000000 192.168.0.0 = 11000000.10101000.00000000.00000000 and so would be part of the same network. The broadcast address is (conventionally) obtained by binary ORing the network address with the inverse of the subnet mask; equivalently ORing an IP address with the inverse of the subnet mask. Hence the broadcast address for 192.168.0.0/255.255.252.0 is 192.168.3.255: 192.168.0.0 = 11000000.10101000.00000000.00000000 NOT 255.255.252.2 = 00000000.00000000.00000011.11111111 192.168.3.255 = 11000000.10101000.00000011.11111111 You can see from this that in order for all hosts on a network to have the same network and broadcast addresses, they must at least all have the same subnet mask. If the range of IP addresses they gave you was, as you say, 10.0.40.2-10.0.40.254 then this would *suggest* a "classical" subnet mask of 255.255.255.0, with 10.0.40.1 being the default gateway. No guarantee, but that would be my initial assumption. Michael
the 255.255.252.0 subnet was designated by RM when they installed the network some years ago. The other one is designated by EMBC who provide the internet access - they gave us a subnet mask range of 255.255.25** **= 2-5 with a range of ips from
The netmask would be one of 255.255.252.0, 255.255.254 or 255.255.255.0 Looks like someone somewhere, didn't understand how netmasks work.
10.0.40.2-254 with the intention of us switching over
If that is the range then the right net mask would be 255.255.255.0 (broadcast 10.0.40.255) With a netmask of 255.255.254.0 the range would be 10.0.40.2 - 10.0.41.254 (broadcast 10.0.41.255) and with 255.255.252.0 the range would be 10.0.40.2i - 10.0.43.254 (broadcast 10.0.43.255).
to their network and having the computers directly hooked in - fat chance! that gives us very little control thus we are using a proxy..
It is quite possible to insert a machine in between a RBC router and a LAN. I have just such a setup here. -- Mark Evans St. Peter's CofE High School Phone: +44 1392 204764 X109 Fax: +44 1392 204763
On Tue, 25 Jun 2002, Steve Palmer wrote:
Sorry about the delay, i've been busy with a few things. Anyway heres the info:
eth0 Link encap:Ethernet HWaddr 00:00:E8:8B:7E:66 inet addr:192.168.3.200 Bcast:192.168.3.255 Mask:255.255.252.0
OKish.
eth1 Link encap:Ethernet HWaddr 00:90:27:73:DB:FC inet addr:10.0.40.2 Bcast:10.0.41.255 Mask:255.255.254.0
OK. Who chose these subnet masks, btw?
PING 192.168.3.200 (192.168.3.200) from 192.168.3.200 : 56(84) bytes of data. 64 bytes from 192.168.3.200: icmp_seq=1 ttl=255 time=0.180 ms
Proves that eth0 interface is working, but proves nothing about routing to 192.168.0.0/255.255.252.0 network.
Not quite it shows that there is a driver loaded which is happy with the hardware. This will work even if nothing is plugged in, since the kernel sends this kind of thing through the loopback interface anyway.
Are you *sure* that you have the physical network cables plugged in the right way round (as in eth0->192.168.0.0 network, eth1->10.0.40.0 network)? Are you also sure that the hosts you are pinging (192.168.3.201 and 10.0.40.1) are alive and able to communicate with the rest of the network?
You could try running
tcpdump -i eth0 -n
and
tcpdump -i eth1 -n
to observe traffic coming to both network cards. This should show you if you have got the wires mixed up.
Probably best to use "tcpdump -i ethX -n |less" otherwise they may simply get things scrolling faster than can be read.
On Wed, 26 Jun 2002, Mark Evans wrote:
PING 192.168.3.200 (192.168.3.200) from 192.168.3.200 : 56(84) bytes of data. 64 bytes from 192.168.3.200: icmp_seq=1 ttl=255 time=0.180 ms Proves that eth0 interface is working, but proves nothing about routing to 192.168.0.0/255.255.252.0 network. Not quite it shows that there is a driver loaded which is happy with the hardware. This will work even if nothing is plugged in, since the kernel sends this kind of thing through the loopback interface anyway.
Depends how pedantic you want to be about the definition of the word "interface". :-) Michael
On Wed, 26 Jun 2002, Mark Evans wrote:
PING 192.168.3.200 (192.168.3.200) from 192.168.3.200 : 56(84) bytes of data. 64 bytes from 192.168.3.200: icmp_seq=1 ttl=255 time=0.180 ms Proves that eth0 interface is working, but proves nothing about routing to 192.168.0.0/255.255.252.0 network. Not quite it shows that there is a driver loaded which is happy with the hardware. This will work even if nothing is plugged in, since the kernel sends this kind of thing through the loopback interface anyway.
Depends how pedantic you want to be about the definition of the word "interface". :-)
The practical upshot is that you can get a machine with a broken NIC which can quite happily ping itself. If you are really unlucky the link LEDs will come on too. -- Mark Evans St. Peter's CofE High School Phone: +44 1392 204764 X109 Fax: +44 1392 204763
Sorry about the delay, i've been busy with a few things. Anyway heres the info:
eth0 Link encap:Ethernet HWaddr 00:00:E8:8B:7E:66
inet addr:192.168.3.200 Bcast:192.168.3.255 Mask:255.255.252.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:691566 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:7 Base address:0xf000
eth1 Link encap:Ethernet HWaddr 00:90:27:73:DB:FC
inet addr:10.0.40.2 Bcast:10.0.41.255 Mask:255.255.254.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:64 errors:0 dropped:0 overruns:0 frame:0
TX packets:33 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:1386 (1.3 Kb) Interrupt:5 Base address:0x1060 Memory:fa104000-fa104038
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:205 errors:0 dropped:0 overruns:0 frame:0 TX packets:205 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:20696 (20.2 Kb) TX bytes:20696 (20.2 Kb)
All that's really needed is the ip address, netmask and broadcast. The rest simply serves to confuse. (No point listing lo either.)
PING 192.168.3.200 (192.168.3.200) from 192.168.3.200 : 56(84) bytes of data. 64 bytes from 192.168.3.200: icmp_seq=1 ttl=255 time=0.180 ms 64 bytes from 192.168.3.200: icmp_seq=2 ttl=255 time=0.113 ms 64 bytes from 192.168.3.200: icmp_seq=3 ttl=255 time=0.115 ms 64 bytes from 192.168.3.200: icmp_seq=4 ttl=255 time=0.114 ms 64 bytes from 192.168.3.200: icmp_seq=5 ttl=255 time=0.117 ms 64 bytes from 192.168.3.200: icmp_seq=6 ttl=255 time=0.118 ms
There is little point with this, since it will use the loopback interface anyway.
PING 192.168.3.201 (192.168.3.201) from 192.168.3.200 : 56(84) bytes of data.
From 192.168.3.200: icmp_seq=1 Destination Host Unreachable From 192.168.3.200 icmp_seq=1 Destination Host Unreachable From 192.168.3.200 icmp_seq=2 Destination Host Unreachable From 192.168.3.200 icmp_seq=3 Destination Host Unreachable From 192.168.3.200 icmp_seq=4 Destination Host Unreachable From 192.168.3.200 icmp_seq=5 Destination Host Unreachable
PING 10.0.40.2 (10.0.40.2) from 10.0.40.2 : 56(84) bytes of data. 64 bytes from 10.0.40.2: icmp_seq=1 ttl=255 time=0.137 ms 64 bytes from 10.0.40.2: icmp_seq=2 ttl=255 time=0.119 ms 64 bytes from 10.0.40.2: icmp_seq=3 ttl=255 time=0.113 ms 64 bytes from 10.0.40.2: icmp_seq=4 ttl=255 time=0.115 ms 64 bytes from 10.0.40.2: icmp_seq=5 ttl=255 time=0.117 ms
Ditto
PING 10.0.40.1 (10.0.40.1) from 10.0.40.2 : 56(84) bytes of data.
From 10.0.40.2: icmp_seq=1 Destination Host Unreachable From 10.0.40.2 icmp_seq=1 Destination Host Unreachable From 10.0.40.2 icmp_seq=2 Destination Host Unreachable From 10.0.40.2 icmp_seq=3 Destination Host Unreachable
Kernal IP Routing Table
Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.40.0 0.0.0.0 255.255.254.0 U 0 0 0 eth1 192.168.0.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 0.0.0.0 10.0.40.1 0.0.0.0 UG 0 0 0 eth1
Presumably 192.168.0.0/255.255.252.0 and 10.0.40.0/255.255.254.0 are physically separate ethernet segments. You are absolutly sure you have the leads the right way around? Try the pings to 192.168.3.201 and 10.0.40.1 with the leads swapped. Also if possible try pinging from 10.3.40.1 to 10.3.40.2 and from 192.168.3.200 to 192.168.3.201 -- Mark Evans St. Peter's CofE High School Phone: +44 1392 204764 X109 Fax: +44 1392 204763
participants (3)
-
Mark Evans -
Michael Brown -
Steve Palmer