Daniel Gerzo wrote: > Hello ???, > > Sunday, November 11, 2007, 9:57:00 PM, you wrote: > >> And only a problem if they show up on the same LAN, but - go figure - we had it >> happen on a 192 - internal subnet with just four machines, so... > >> Then there are ARP caches not cleared fast enough when you migrate IP's, faulty >> routers, hubs, cables, shit-storms on the channel from *other* boxen that block >> your packets...and so on... > >> None of which driver coders can do SQRT of FA about... > >> Let's find out what we actually have here... > >> 'More facts, please'.... > > OK let's see what can I provide: > > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ (2999.98-MHz K8-class CPU) > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > usable memory = 8543711232 (8147 MB) > avail memory = 8264265728 (7881 MB) > > FreeBSD web1.opensubtitles.org 7.0-BETA2 FreeBSD 7.0-BETA2 #0: Sun Nov 11 11:38:53 CET 2007 danger_at_detuxator:/usr/obj/usr/src/sys/web1 amd64 > ULE Scheduler, polling enabled, hz=1000. > Also: > options ACCEPT_FILTER_HTTP > options ACCEPT_FILTER_DATA > > > re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 > options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM> > ether 00:19:db:f8:cf:b1 > inet 78.46.35.175 netmask 0xffffffe0 broadcast 78.46.35.191 > media: Ethernet autoselect (100baseTX <full-duplex>) > status: active > > Other machine, same configuration besides: > > re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 > options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM> > ether 00:19:db:f8:c9:48 > inet 78.46.35.176 netmask 0xffffffe0 broadcast 78.46.35.191 > media: Ethernet autoselect (100baseTX <full-duplex>) > status: active > > There is another one, which is suffering this problem. > > I have the same hardware configuration on yet another one, but it > doesn't seem like to have these symtons, which is interesting: > > FreeBSD web3.opensubtitles.org 7.0-BETA2 FreeBSD 7.0-BETA2 #0: Fri Nov 9 09:38:49 CET 2007 root_at_detuxator:/usr/obj/usr/src/sys/web3 amd64 > > re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 > options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM> > ether 00:19:db:f8:c9:f6 > inet 78.46.35.174 netmask 0xffffffe0 broadcast 78.46.35.191 > media: Ethernet autoselect (100baseTX <full-duplex>) > status: active > > If you are interested in any other information, just ask me and I will > provide it. > Good start.. And interesting that ONE box does not exhibit the problem. Understand that the rackup is not within arm's length, What info can you get from the colo provider and/or inside analysis tools, and/or a looking glass as to how the boxen are; - cabled - switched - routed How are you arriving when ssh'ed in, and is there packet loss on *your* end or in between? Can you run tcpdump on several of the boxen's NIC's - offenders and proper - saved to file for Mark One eyeball scan, then grep of suspects? What about the arp & netstat reports? Any chance of duplicate MAC or IP addresses within your block or others in the same 'house' (it has been done...)? Are the netmasks as well as the IP's 'proper' *everywhere* on the subnet? Are there any tun/tap/bridge crittere about, as for virtualizers? NICS in promiscuous mode anywhere? What is in /var/log/messages? (redirect the console messages to a file in /var/log in /etc/syslog.conf and/or activate copy to /var/log/all.log if you haven't already done so. - you get the drift. BillReceived on Sun Nov 11 2007 - 20:49:14 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:21 UTC