Re: Weird routing issue
> "Tarragon" == Tarragon Allen <[EMAIL PROTECTED]> writes: Tarragon> It must be an arp issue. Tarragon> Either a switch is impeding arp (via a VLAN or locking Tarragon> of ports or similar) or the bridging equipment is just Tarragon> not bridging for machines other than the one that is Tarragon> working. From your original email you indicated an arp Tarragon> response on the machine that worked (.8). Have you tried Tarragon> putting in a static arp entry on the machine to .5 on Tarragon> .7? ie: Tarragon> # arp -s 192.168.0.5 0:50:73:68:a4:22 Tarragon> See if you get any pings... Been there, done that. No response. :-(. Tarragon> PS: a note regarding switches locking ports : sometimes Tarragon> switches will lock down a port if they see the IP Tarragon> address change, this is a security mode that is usually Tarragon> off by default and is only available on fairly Tarragon> intelligent switches. I just thought I'd raise it as it Tarragon> might be relevant. Doesn't seem to be the case. All the switches were powered off and reset. The connection between 192.168.0.7 and the microwave is more complicated then what I stated before, it is more like: 192.168.0.7 --> hub --> switch --> optic fiber --> switch --> microwave link --> 192.168.0.5 So I guess anything along this relatively complicated path could be messing it up. At one stage we bypassed the initial hub and plugged directly into the switch, but it didn't help. -- Brian May <[EMAIL PROTECTED]>
Re: Weird routing issue
On Thursday 25 March 2004 14:10, Brian May wrote: > > "Michael" == Michael Loftis <[EMAIL PROTECTED]> writes: > > Michael> netstat -rn output on the box (.7?) having issues. > > # netstat -rn | grep '^192\.168\.0' > 192.168.0.0 0.0.0.0 255.255.255.0 U40 0 0 eth0 > 192.168.0.0 192.168.0.8 255.255.0.0 UG 40 0 0 eth0 > Hmmm... Actually it would have to be more complicated then that as it > seems to be sensitive to the Ethernet adaptor (or address), otherwise > it would work after changing the IP address. I had to also route via > the other system too. It must be an arp issue. Either a switch is impeding arp (via a VLAN or locking of ports or similar) or the bridging equipment is just not bridging for machines other than the one that is working. From your original email you indicated an arp response on the machine that worked (.8). Have you tried putting in a static arp entry on the machine to .5 on .7? ie: # arp -s 192.168.0.5 0:50:73:68:a4:22 See if you get any pings... t PS: a note regarding switches locking ports : sometimes switches will lock down a port if they see the IP address change, this is a security mode that is usually off by default and is only available on fairly intelligent switches. I just thought I'd raise it as it might be relevant. -- GPG: http://n12turbo.com/tarragon/public.key
Re: Weird routing issue
> "Tarragon" == Tarragon Allen <[EMAIL PROTECTED]> writes: Tarragon> It must be an arp issue. Tarragon> Either a switch is impeding arp (via a VLAN or locking Tarragon> of ports or similar) or the bridging equipment is just Tarragon> not bridging for machines other than the one that is Tarragon> working. From your original email you indicated an arp Tarragon> response on the machine that worked (.8). Have you tried Tarragon> putting in a static arp entry on the machine to .5 on Tarragon> .7? ie: Tarragon> # arp -s 192.168.0.5 0:50:73:68:a4:22 Tarragon> See if you get any pings... Been there, done that. No response. :-(. Tarragon> PS: a note regarding switches locking ports : sometimes Tarragon> switches will lock down a port if they see the IP Tarragon> address change, this is a security mode that is usually Tarragon> off by default and is only available on fairly Tarragon> intelligent switches. I just thought I'd raise it as it Tarragon> might be relevant. Doesn't seem to be the case. All the switches were powered off and reset. The connection between 192.168.0.7 and the microwave is more complicated then what I stated before, it is more like: 192.168.0.7 --> hub --> switch --> optic fiber --> switch --> microwave link --> 192.168.0.5 So I guess anything along this relatively complicated path could be messing it up. At one stage we bypassed the initial hub and plugged directly into the switch, but it didn't help. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Weird routing issue
> "Michael" == Michael Loftis <[EMAIL PROTECTED]> writes: Michael> netstat -rn output on the box (.7?) having issues. # netstat -rn | grep '^192\.168\.0' 192.168.0.0 0.0.0.0 255.255.255.0 U40 0 0 eth0 192.168.0.0 192.168.0.8 255.255.0.0 UG 40 0 0 eth0 default route: 0.0.0.0 220.244.151.9 0.0.0.0 UG 40 0 0 eth1 I believe the first one should get used in favour of others. There are no other routes for 192.168.0.* Obviously this was different when I was routing via 192.168.0.8. Michael> sounds like you have a more specific route going on or Not that I can see... Michael> something similar. does .5 hear the ARP requests when .7 I can't check easily this aspect :-(. (No Linux computers on this end of the network). It looks like this will be the next step... Michael> makes them? if so, does it respond? is .5 and .7 set Michael> with the CORRECT netmask on the(eth0?) interface in Michael> question? The netmask looks good to me on the local computers: # ip address show eth0 2: eth0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:40:f4:2b:71:c6 brd ff:ff:ff:ff:ff:ff inet 192.168.0.7/24 brd 192.168.0.255 scope global eth0 inet 192.168.0.3/24 brd 192.168.0.255 scope global secondary eth0:1 # ip address show eth0 2: eth0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:40:05:a3:65:5b brd ff:ff:ff:ff:ff:ff inet 192.168.0.8/24 brd 192.168.0.255 scope global eth0 inet 220.244.190.30/29 brd 220.244.190.39 scope global eth0:1 inet 220.244.190.34/29 brd 220.244.190.39 scope global eth0:2 inet 220.244.190.33/29 brd 220.244.190.39 scope global secondary eth0:3 inet 220.244.190.35/29 brd 220.244.190.39 scope global secondary eth0:4 I can't imagine the netmask being wrong on 192.168.0.5, but can't check right now, either. Hmmm... Actually it would have to be more complicated then that as it seems to be sensitive to the Ethernet adaptor (or address), otherwise it would work after changing the IP address. I had to also route via the other system too. For this theory to be correct, 192.168.0.5, 192.168.0.8 and 192.168.0.10, would have to be inside the netmask, but not 192.168.0.7. Hmmm... Now I try it, not even 192.168.0.10 works anymore, not even under the conditions as before. I hate networks that change! -- Brian May <[EMAIL PROTECTED]>
Re: Weird routing issue
On Thursday 25 March 2004 14:10, Brian May wrote: > > "Michael" == Michael Loftis <[EMAIL PROTECTED]> writes: > > Michael> netstat -rn output on the box (.7?) having issues. > > # netstat -rn | grep '^192\.168\.0' > 192.168.0.0 0.0.0.0 255.255.255.0 U40 0 0 eth0 > 192.168.0.0 192.168.0.8 255.255.0.0 UG 40 0 0 eth0 > Hmmm... Actually it would have to be more complicated then that as it > seems to be sensitive to the Ethernet adaptor (or address), otherwise > it would work after changing the IP address. I had to also route via > the other system too. It must be an arp issue. Either a switch is impeding arp (via a VLAN or locking of ports or similar) or the bridging equipment is just not bridging for machines other than the one that is working. From your original email you indicated an arp response on the machine that worked (.8). Have you tried putting in a static arp entry on the machine to .5 on .7? ie: # arp -s 192.168.0.5 0:50:73:68:a4:22 See if you get any pings... t PS: a note regarding switches locking ports : sometimes switches will lock down a port if they see the IP address change, this is a security mode that is usually off by default and is only available on fairly intelligent switches. I just thought I'd raise it as it might be relevant. -- GPG: http://n12turbo.com/tarragon/public.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Weird routing issue
> "Michael" == Michael Loftis <[EMAIL PROTECTED]> writes: Michael> netstat -rn output on the box (.7?) having issues. # netstat -rn | grep '^192\.168\.0' 192.168.0.0 0.0.0.0 255.255.255.0 U40 0 0 eth0 192.168.0.0 192.168.0.8 255.255.0.0 UG 40 0 0 eth0 default route: 0.0.0.0 220.244.151.9 0.0.0.0 UG 40 0 0 eth1 I believe the first one should get used in favour of others. There are no other routes for 192.168.0.* Obviously this was different when I was routing via 192.168.0.8. Michael> sounds like you have a more specific route going on or Not that I can see... Michael> something similar. does .5 hear the ARP requests when .7 I can't check easily this aspect :-(. (No Linux computers on this end of the network). It looks like this will be the next step... Michael> makes them? if so, does it respond? is .5 and .7 set Michael> with the CORRECT netmask on the(eth0?) interface in Michael> question? The netmask looks good to me on the local computers: # ip address show eth0 2: eth0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:40:f4:2b:71:c6 brd ff:ff:ff:ff:ff:ff inet 192.168.0.7/24 brd 192.168.0.255 scope global eth0 inet 192.168.0.3/24 brd 192.168.0.255 scope global secondary eth0:1 # ip address show eth0 2: eth0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:40:05:a3:65:5b brd ff:ff:ff:ff:ff:ff inet 192.168.0.8/24 brd 192.168.0.255 scope global eth0 inet 220.244.190.30/29 brd 220.244.190.39 scope global eth0:1 inet 220.244.190.34/29 brd 220.244.190.39 scope global eth0:2 inet 220.244.190.33/29 brd 220.244.190.39 scope global secondary eth0:3 inet 220.244.190.35/29 brd 220.244.190.39 scope global secondary eth0:4 I can't imagine the netmask being wrong on 192.168.0.5, but can't check right now, either. Hmmm... Actually it would have to be more complicated then that as it seems to be sensitive to the Ethernet adaptor (or address), otherwise it would work after changing the IP address. I had to also route via the other system too. For this theory to be correct, 192.168.0.5, 192.168.0.8 and 192.168.0.10, would have to be inside the netmask, but not 192.168.0.7. Hmmm... Now I try it, not even 192.168.0.10 works anymore, not even under the conditions as before. I hate networks that change! -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Weird routing issue
netstat -rn output on the box (.7?) having issues. sounds like you have a more specific route going on or something similar. does .5 hear the ARP requests when .7 makes them? if so, does it respond? is .5 and .7 set with the CORRECT netmask on the(eth0?) interface in question? --On Thursday, March 25, 2004 10:35 +1100 Brian May <[EMAIL PROTECTED]> wrote: Hello, I have an issue with the following network? Is anyone able to help diagnose the problem? If so, your help is appreciated. NETWORK BACKGROUND: Network structure is (or so I have been told): 192.168.0.8 | |--- microwave (bridge) 192.168.0.5 192.168.0.7 | | 192.168.0.2 | 192.168.0.7 and 192.168.0.8 are connected via ethernet (192.168.0.0/24), and there is also a microwave (bridge) on this ethernet. The two machines on the left are Linux machines, I have no access to the network on this right. The microwave bridge is dumb, and I have been told been told it doesn't filter any packets. The only relevant routes on both 192.168.0.7 and 192.168.0.8 are: 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.8 and: 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.7 All tcpdumps are with the options "host 192.168.0.5 -en". Not only does this display Ethernet addresses, but also eliminates delays due to DNS lookups. I have experimented with more relaxed rules, but haven't yet found any evidence that the "host 192.168.0.5" is eliminating anything but unrelated packets. 192.168.0.2 is an obsolete CISCO router that forwards everything to 192.168.0.5. I doubt it significant in anyway to the following tests. WHAT WORKS: I can ping 192.168.0.7 to 192.168.0.8 and vice versa. From 192.168.0.8 I can ping 168.160.0.5. I can see both request and response packets on both computers via tcpdump (which would imply a hub is used, not a switch): 13:48:24.136037 0:50:73:68:a4:22 0:40:5:a3:65:5b 0800 98: 192.168.0.5 > 192.168.0.8: icmp: echo reply (DF) 13:48:25.132962 0:40:5:a3:65:5b 0:50:73:68:a4:22 0800 98: 192.168.0.8 > 192.168.0.5: icmp: echo request (DF) (please ignore the cut© error - the request did come before the reply). 0:50:73:68:a4:22 is 192.168.0.5 0:40:5:a3:65:5b is 192.168.0.8 0:40:f4:2b:71:c6 is 192.168.0.7 If I delete the arp address of 192.168.0.5 on 192.168.0.8, it will request it again and obtain the new value: 06:19:09.916894 0:40:5:a3:65:5b ff:ff:ff:ff:ff:ff 0806 60: arp who-has 192.168.0.5 tell 192.168.0.8 06:19:09.920115 0:50:73:68:a4:22 0:40:5:a3:65:5b 0806 60: arp reply 192.168.0.5 is-at 0:50:73:68:a4:22 06:19:09.920195 0:40:5:a3:65:5b 0:50:73:68:a4:22 0800 98: 192.168.0.8 > 192.168.0.5: icmp: echo request (DF) 06:19:09.922964 0:50:73:68:a4:22 0:40:5:a3:65:5b 0800 98: 192.168.0.5 > 192.168.0.8: icmp: echo reply (DF) WHAT DOES NOT WORK: If I try to ping 192.168.0.5 from 192.168.0.7, all I get is arp requests (visible to both computers), but not any responses. 05:13:28.096711 0:40:f4:2b:71:c6 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.0.5 tell 192.168.0.7 05:13:29.091531 0:40:f4:2b:71:c6 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.0.5 tell 192.168.0.7 05:13:30.091451 0:40:f4:2b:71:c6 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.0.5 tell 192.168.0.7 05:13:31.091510 0:40:f4:2b:71:c6 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.0.5 tell 192.168.0.7 05:13:32.091303 0:40:f4:2b:71:c6 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.0.5 tell 192.168.0.7 05:13:33.091227 0:40:f4:2b:71:c6 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.0.5 tell 192.168.0.7 If I change the IP address of 192.168.0.7 to 192.168.0.10, it still doesn't work (similar to above but with different IP address). If I route packets from 192.168.0.7 via 192.168.0.8, it doesn't work 05:24:25.789560 0:40:f4:2b:71:c6 0:40:5:a3:65:5b 0800 98: 192.168.0.7 > 192.168.0.5: icmp: echo request (DF) 05:24:25.789779 0:40:5:a3:65:5b 0:50:73:68:a4:22 0800 98: 192.168.0.7 > 192.168.0.5: icmp: echo request (DF) 05:24:26.781299 0:40:f4:2b:71:c6 0:40:5:a3:65:5b 0800 98: 192.168.0.7 > 192.168.0.5: icmp: echo request (DF) 05:24:26.781457 0:40:5:a3:65:5b 0:50:73:68:a4:22 0800 98: 192.168.0.7 > 192.168.0.5: icmp: echo request (DF) WORKAROUND: If, however, I do *both* of the above, i.e. use 192.168.0.10 *and* route packets via 192.168.0.8, it *does* work: 05:46:59.236156 0:40:f4:2b:71:c6 0:40:5:a3:65:5b 0800 98: 192.168.0.10 > 192.168.0.5: icmp: echo request (DF) 05:46:59.236376 0:40:5:a3:65:5b 0:50:73:68:a4:22 0800 98: 192.168.0.10 > 192.168.0.5: icmp: echo request (DF) 05:46:59.238722 0:50:73:68:a4:22 0:40:5:a3:65:5b 0800 98: 192.168.0.5 > 192.168.0.10: icmp: echo reply (DF) 05:46:59.238903 0:40:5:a3:65:5b 0:40:f4:2b:71:c6 0800 98: 192.168.0.5 > 192.168.0.10: icmp: echo reply (DF) OTHER FACTORS: Other factors which might be important but could be misleading: * "It was working yesterday". * From other sysadmin: "All I did was delete some (not-related) routes to obsolete CISCO router that isn't used anymore (192.168.0.
Re: Weird routing issue
netstat -rn output on the box (.7?) having issues. sounds like you have a more specific route going on or something similar. does .5 hear the ARP requests when .7 makes them? if so, does it respond? is .5 and .7 set with the CORRECT netmask on the(eth0?) interface in question? --On Thursday, March 25, 2004 10:35 +1100 Brian May <[EMAIL PROTECTED]> wrote: Hello, I have an issue with the following network? Is anyone able to help diagnose the problem? If so, your help is appreciated. NETWORK BACKGROUND: Network structure is (or so I have been told): 192.168.0.8 | |--- microwave (bridge) 192.168.0.5 192.168.0.7 | | 192.168.0.2 | 192.168.0.7 and 192.168.0.8 are connected via ethernet (192.168.0.0/24), and there is also a microwave (bridge) on this ethernet. The two machines on the left are Linux machines, I have no access to the network on this right. The microwave bridge is dumb, and I have been told been told it doesn't filter any packets. The only relevant routes on both 192.168.0.7 and 192.168.0.8 are: 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.8 and: 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.7 All tcpdumps are with the options "host 192.168.0.5 -en". Not only does this display Ethernet addresses, but also eliminates delays due to DNS lookups. I have experimented with more relaxed rules, but haven't yet found any evidence that the "host 192.168.0.5" is eliminating anything but unrelated packets. 192.168.0.2 is an obsolete CISCO router that forwards everything to 192.168.0.5. I doubt it significant in anyway to the following tests. WHAT WORKS: I can ping 192.168.0.7 to 192.168.0.8 and vice versa. From 192.168.0.8 I can ping 168.160.0.5. I can see both request and response packets on both computers via tcpdump (which would imply a hub is used, not a switch): 13:48:24.136037 0:50:73:68:a4:22 0:40:5:a3:65:5b 0800 98: 192.168.0.5 > 192.168.0.8: icmp: echo reply (DF) 13:48:25.132962 0:40:5:a3:65:5b 0:50:73:68:a4:22 0800 98: 192.168.0.8 > 192.168.0.5: icmp: echo request (DF) (please ignore the cut© error - the request did come before the reply). 0:50:73:68:a4:22 is 192.168.0.5 0:40:5:a3:65:5b is 192.168.0.8 0:40:f4:2b:71:c6 is 192.168.0.7 If I delete the arp address of 192.168.0.5 on 192.168.0.8, it will request it again and obtain the new value: 06:19:09.916894 0:40:5:a3:65:5b ff:ff:ff:ff:ff:ff 0806 60: arp who-has 192.168.0.5 tell 192.168.0.8 06:19:09.920115 0:50:73:68:a4:22 0:40:5:a3:65:5b 0806 60: arp reply 192.168.0.5 is-at 0:50:73:68:a4:22 06:19:09.920195 0:40:5:a3:65:5b 0:50:73:68:a4:22 0800 98: 192.168.0.8 > 192.168.0.5: icmp: echo request (DF) 06:19:09.922964 0:50:73:68:a4:22 0:40:5:a3:65:5b 0800 98: 192.168.0.5 > 192.168.0.8: icmp: echo reply (DF) WHAT DOES NOT WORK: If I try to ping 192.168.0.5 from 192.168.0.7, all I get is arp requests (visible to both computers), but not any responses. 05:13:28.096711 0:40:f4:2b:71:c6 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.0.5 tell 192.168.0.7 05:13:29.091531 0:40:f4:2b:71:c6 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.0.5 tell 192.168.0.7 05:13:30.091451 0:40:f4:2b:71:c6 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.0.5 tell 192.168.0.7 05:13:31.091510 0:40:f4:2b:71:c6 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.0.5 tell 192.168.0.7 05:13:32.091303 0:40:f4:2b:71:c6 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.0.5 tell 192.168.0.7 05:13:33.091227 0:40:f4:2b:71:c6 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.0.5 tell 192.168.0.7 If I change the IP address of 192.168.0.7 to 192.168.0.10, it still doesn't work (similar to above but with different IP address). If I route packets from 192.168.0.7 via 192.168.0.8, it doesn't work 05:24:25.789560 0:40:f4:2b:71:c6 0:40:5:a3:65:5b 0800 98: 192.168.0.7 > 192.168.0.5: icmp: echo request (DF) 05:24:25.789779 0:40:5:a3:65:5b 0:50:73:68:a4:22 0800 98: 192.168.0.7 > 192.168.0.5: icmp: echo request (DF) 05:24:26.781299 0:40:f4:2b:71:c6 0:40:5:a3:65:5b 0800 98: 192.168.0.7 > 192.168.0.5: icmp: echo request (DF) 05:24:26.781457 0:40:5:a3:65:5b 0:50:73:68:a4:22 0800 98: 192.168.0.7 > 192.168.0.5: icmp: echo request (DF) WORKAROUND: If, however, I do *both* of the above, i.e. use 192.168.0.10 *and* route packets via 192.168.0.8, it *does* work: 05:46:59.236156 0:40:f4:2b:71:c6 0:40:5:a3:65:5b 0800 98: 192.168.0.10 > 192.168.0.5: icmp: echo request (DF) 05:46:59.236376 0:40:5:a3:65:5b 0:50:73:68:a4:22 0800 98: 192.168.0.10 > 192.168.0.5: icmp: echo request (DF) 05:46:59.238722 0:50:73:68:a4:22 0:40:5:a3:65:5b 0800 98: 192.168.0.5 > 192.168.0.10: icmp: echo reply (DF) 05:46:59.238903 0:40:5:a3:65:5b 0:40:f4:2b:71:c6 0800 98: 192.168.0.5 > 192.168.0.10: icmp: echo reply (DF) OTHER FACTORS: Other factors which might be important but could be misleading: * "It was working yesterday". * From other sysadmin: "All I did was delete some (not-related) routes to obsolete CISCO router that isn't used anymore
