OpenVZ Forum


Home » General » Support » eth0 dies when using openVZ kernel.
eth0 dies when using openVZ kernel. [message #27096] Sat, 09 February 2008 06:32 Go to next message
thorpe is currently offline  thorpe
Messages: 16
Registered: February 2008
Location: Sydney - Australia
Junior Member
Bit of a strange one this, I'm not even sure where to start looking.

I'm using Debian Etch.

I've installed the openVZ kernel by following this guide on there site. All went smoothly. I boot into the new kernel, no problems, check ifconfig and I see...

eth0      Link encap:Ethernet  HWaddr 00:08:A1:03:F1:14  
          inet addr:192.168.10.2  Bcast:192.168.10.255  Mask:255.255.255.0
          inet6 addr: fe80::208:a1ff:fe03:f114/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:27 errors:4 dropped:0 overruns:0 frame:0
          TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2972 (2.9 KiB)  TX bytes:3031 (2.9 KiB)
          Interrupt:185 Base address:0xe800 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:560 (560.0 b)  TX bytes:560 (560.0 b)

venet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Lovelly.

I then try to apt-get install the user-level tools and find out my connection has died. I try to ping another machine I have at 192.168.10.1, no response. I check ifconfig again, looks fine.

I reboot again into the openVZ kernel, ping 192.168.10.1 it responds. I ping it a few more times and after the third I onbce again get no response.

I then try to compile my own kernel following this guide ( I use my working .config file + make the changes suggested), I boot into it, same deal. I seem to have a network connection for about 10 seconds then it just dies.

I'm really not sure where to even start looking for any error messages. Anyone got any ideas?
Re: eth0 dies when using openVZ kernel. [message #27107 is a reply to message #27096] Sat, 09 February 2008 20:12 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
Hi,

- Any strange messages in logs or dmesg?
- Could you please use for example "tcpdump" utility to analyse packets behavior?
- Please check arp or route table when you loose the connection.
- By the way can you please try "/etc/init.d/vz stop"?
Re: eth0 dies when using openVZ kernel. [message #27918 is a reply to message #27096] Mon, 03 March 2008 08:43 Go to previous messageGo to next message
thorpe is currently offline  thorpe
Messages: 16
Registered: February 2008
Location: Sydney - Australia
Junior Member
This still isn't working. eth0 just drops off the face of the earcth after about a minute. yet if a look at ifconfig it all looks normal.

route comes up blank after eth0 dies.

Ive got no idea where to start looking, here is a cat of /var/log/messages from the time I boot into the vz kernal till the time I need to reboot back into my normal working kernel.

Anyone got any ideas? Or can recommend some vitualization that I might be able to get working?

[code]
Mar 3 19:16:46 oblivion kernel: Linux version 2.6.18-ovz-028stab051.1 () (tsd@debian.systs.org) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 Fri Dec 7 19:42:24 CET 2007
Mar 3 19:16:46 oblivion kernel: BIOS-provided physical RAM map:
Mar 3 19:16:46 oblivion kernel: BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
Mar 3 19:16:46 oblivion kernel: BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
Mar 3 19:16:46 oblivion kernel: BIOS-e820: 0000000000100000 - 000000001ff77000 (usable)
Mar 3 19:16:46 oblivion kernel: BIOS-e820: 000000001ff77000 - 000000001ff79000 (ACPI NVS)
Mar 3 19:16:46 oblivion kernel: BIOS-e820: 000000001ff79000 - 0000000020000000 (reserved)
Mar 3 19:16:46 oblivion kernel: BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
Mar 3 19:16:46 oblivion kernel: BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved)
Mar 3 19:16:46 oblivion kernel: BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
Mar 3 19:16:46 oblivion kernel: 0MB HIGHMEM available.
Mar 3 19:16:46 oblivion kernel: 511MB LOWMEM available.
Mar 3 19:16:46 oblivion kernel: found SMP MP-table at 000fe710
Mar 3 19:16:46 oblivion kernel: DMI 2.3 present.
Mar 3 19:16:46 oblivion kernel: ACPI: PM-Timer IO Port: 0x808
Mar 3 19:16:46 oblivion kernel: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Mar 3 19:16:46 oblivion kernel: Processor #0 15:2 APIC version 20
Mar 3 19:16:46 oblivion kernel: ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] disabled)
Mar 3 19:16:46 oblivion kernel: ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
Mar 3 19:16:46 oblivion kernel: IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
Mar 3 19:16:46 oblivion kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
Mar 3 19:16:46 oblivion kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Mar 3 19:16:46 oblivion kernel: Enabling APIC mode: Flat. Using 1 I/O APICs
Mar 3 19:16:46 oblivion kernel: Using ACPI (MADT) for SMP configuration information
Mar 3 19:16:46 oblivion kernel: Allocating PCI resources starting at 30000000 (gap: 20000000:dec00000)
Mar 3 19:16:46 oblivion kernel: Detected 2254.151 MHz processor.
Mar 3 19:16:46 oblivion kernel: Built 1 zonelists. Total pages: 130935
Mar 3 19:16:46 oblivion kernel: Kernel command line: root=/dev/hda9 ro
Mar 3 19:16:46 oblivion kernel: Enabling fast FPU save and restore... done.
Mar 3 19:16:46 oblivion kernel: Enabling unmasked SIMD FPU exception support... done.
Mar 3 19:16:46 oblivion kernel: Initializing CPU#0
Mar 3 19:16:46 oblivion kernel: CPU 0 irqstacks, hard=c05bf000 soft=c05be000
Mar 3 19:16:46 oblivion kernel: PID hash table entries: 2048 (order: 11, 8192 bytes)
Mar 3 19:16:46 oblivion kernel: Console: colour VGA+ 80x25
Mar 3 19:16:46 oblivion kernel: Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Mar 3 19:16:46 oblivion kernel: Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Mar 3 19:16:46 oblivion kernel: Memory: 510144k/523740k available (3475k kernel code, 13056k reserved, 1083k data, 272k init, 0k highmem)
Mar 3 19:16:46 oblivion kernel: Checking if this processor honours the WP bit even in supervisor mode... Ok.
Mar 3 19:16:46 oblivion kernel: Calibrating delay using timer specific routine.. 4509.75 BogoMIPS (lpj=2254879)
Mar 3 19:16:46 oblivion kernel: Mount-cache hash table entries: 512
Mar 3 19:16:46 oblivion kernel: CPU: Trace cache: 12K uops, L1 D cache: 8K
Mar 3 19:16:46 oblivion kernel: CPU: L2 cache: 512K
Mar 3 19:16:46 oblivion kernel: Intel machine check architecture supported.
Mar 3 19:16:46 oblivion kernel: Intel machine check reporting enabled on CPU#0.
Mar 3 19:16:46 oblivion kernel: CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
Mar 3 19:16:46 oblivion kernel: CPU0: Thermal monitoring enabled
Mar 3 19:16:46 oblivion kernel: Compat vDSO mapped to ffffe000.
Mar 3 19:16:46 oblivion kernel: CPU: Intel(R) Pentium(R) 4 CPU 2.26GHz stepping 04
Mar 3 19:16:46 oblivion kernel: Checking 'hlt' instruction... OK.
Mar 3 19:16:46 oblivion kernel: ACPI: Core revision 20060707
Mar 3 19:16:46 oblivion kernel: Page beancounter hash is 32768 entries.
Mar 3 19:16:46 oblivion kernel: ENABLING IO-APIC IRQs
Mar 3 19:16:46 oblivion kernel: ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
Mar 3 19:16:46 oblivion kernel: checking if image is initramfs... it is
Mar 3 19:16:46 oblivion kernel: Freeing initrd memory: 2715k freed
Mar 3 19:16:46 oblivion kernel: NET: Registered protocol family 16
Mar 3 19:16:46 oblivion kernel: ACPI: bus type pci registered
Mar 3 19:16:46 oblivion kernel: PCI: PCI BIOS revision 2.10 entry at 0xfbeae, last bus=2
Mar 3 19:16:46 oblivion kernel: PCI: Using configuration type 1
Mar 3 19:16:46 oblivion kernel: Setting up standard PCI resources
Mar 3 19:16:46 oblivion kernel: ACPI: Interpreter enabled
Mar 3 19:16:46 oblivion kernel: ACPI: Using IOAPIC for interrupt routing
Mar 3 19:16:46 oblivion kernel: ACPI: PCI Root Bridge [PCI0] (0000:00)
Mar 3 19:16:46 oblivion kernel: ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
Mar 3 19:16:46 oblivion kernel: PCI quirk: region 0800-087f claimed by ICH4 ACPI/GPIO/TCO
Mar 3 19:16:46 oblivion kernel: PCI quirk: region 0880-08bf claimed by ICH4 GPIO
Mar 3 19:16:46 oblivion kernel: PCI: Transparent bridge - 0000:00:1e.0
Mar 3 19:16:46 oblivion kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs *3 4 5 6 7 9 10 11 12 15)
Mar 3 19:16:46 oblivion kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 15)
Mar 3 19:16:46 oblivion kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11 12 15)
Mar 3 19:16:46 oblivion kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11 12 15)
Mar 3 19:16:46 oblivion kernel: ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled.
Mar 3 19:16:46 oblivion kernel: ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled.
Mar 3 19:16:46 oblivion kernel: ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled.
Mar 3 19:16:46 oblivion kernel: ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 *9 10 11 12 15)
Mar 3 19:16:46 oblivion kernel: SCSI subsystem initialized
Mar 3 19:16:46 oblivion kernel: PCI: Using ACPI for IRQ routing
Mar 3 19:16:46 oblivion kernel: PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
Mar 3 19:16:46 oblivion kernel: PCI: Bridge: 0000:00:01.0
Mar 3 19:16:46 oblivion kernel: IO window: disabled.
Mar 3 19:16:46 oblivion kernel: MEM window: fb000000-fdffffff
Mar 3 19:16:46 oblivion kernel: PREFETCH window: e0000000-efffffff
Mar 3 19:16:46 oblivion kernel: PCI: Bridge: 0000:00:1e.0
Mar 3 19:16:46 oblivion kernel: IO window: e000-efff
Mar 3 19:16:46 oblivion kernel: MEM window: fe100000-fe2fffff
Mar 3 19:16:46 oblivion kernel: PREFETCH window: 30000000-300fffff
Mar 3 19:16:46 oblivion kernel: NET: Registered protocol family 2
Mar 3 19:16:46 oblivion kernel: IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
Mar 3 19:16:46 oblivion kernel: TCP established hash table entries: 16384 (order: 4, 65536 bytes)
Mar 3 19:16:46 oblivion kernel: TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
Mar 3 19:16:46 oblivion kernel: TCP: Hash tables configured (established 16384 bind 8192)
Mar 3 19:16:46 oblivion kernel: TCP reno registered
Mar 3 19:16:46 oblivion kernel: Simple Boot Flag at 0x7a set to 0x80
Mar 3 19:16:46 oblivion kernel: VFS: Disk quotas dquot_6.5.1
Mar 3 19:16:46 oblivion kernel: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Mar 3 19:16:46 oblivion kernel: Initializing Cryptographic API
Mar 3 19:16:46 oblivion kernel: io scheduler noop registered
Mar 3 19:16:46 oblivion kernel: io scheduler anticipatory registered
Mar 3 19:16:46 oblivion kernel: io scheduler deadline registered
Mar 3 19:16:46 oblivion kernel: io scheduler cfq registered (default)
Mar 3 19:16:46 oblivion kernel: pci_hotplug: PCI Hot Plug PCI Core version: 0.5
Mar 3 19:16:46 oblivion kernel: Real Time Clock Driver v1.12ac
Mar 3 19:16:46 oblivion kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
Mar 3 19:16:46 oblivion kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Mar 3 19:16:46 oblivion kernel: RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
Mar 3 19:16:46 oblivion kernel: Compaq SMART2 Driver (v 2.6.0)
Mar 3 19:16:46 oblivion kernel: HP CISS Driver (v 3.6.10)
Mar 3 19:16:46 oblivion kernel: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
Mar 3 19:16:46 oblivion kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Mar 3 19:16:46 oblivion kernel: ICH2: IDE controller at PCI slot 0000:00:1f.1
Mar 3 19:16:46 oblivion kernel: ICH2: chipset revision 4
Mar 3 19:16:46 oblivion kernel: ICH2: not 100%% native mode: will probe irqs later
Mar 3 19:16:46 oblivion kernel: ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
Mar 3 19:16:46 oblivion kernel: ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
Mar 3 19:16:46 oblivion kernel: hda: WDC WD800BB-75CAA0, ATA DISK drive
Mar 3 19:16:46 oblivion kernel: hdb: ST3320620A, ATA DISK drive
Mar 3 19:16:46 oblivion kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Mar 3 19:16:46 obl
...

Re: eth0 dies when using openVZ kernel. [message #27927 is a reply to message #27107] Mon, 03 March 2008 12:00 Go to previous messageGo to next message
den is currently offline  den
Messages: 494
Registered: December 2005
Senior Member
This looks like (somehow) that you/somebody has deleted the last address of the eth0 and add it again.

ifconfig is basically useless for an analisys. You should check routes configuration. The best thigh to do is to install iproute2 package and use 'ip' utility.

'ip route list table all' will give exact information about all tables and 'ip route get <ip_addr>' will help to understand what happens.

Basically, if you see packet drops, you should check the content of 'netstat -s'. Drops are not gone into void, they increase some counters and the exact counter name will help to understand what happens in the reality.

Regards,
Den
Re: eth0 dies when using openVZ kernel. [message #27954 is a reply to message #27927] Tue, 04 March 2008 05:23 Go to previous messageGo to next message
thorpe is currently offline  thorpe
Messages: 16
Registered: February 2008
Location: Sydney - Australia
Junior Member
Hopefully this will help you help me but I have no idea what any of this meens.

Here is the output of 'ip route list table all' from my working kernel (with network working)
192.168.10.0/24 dev eth0  proto kernel  scope link  src 192.168.10.2 
default via 192.168.10.1 dev eth0 
broadcast 127.255.255.255 dev lo  table 255  proto kernel  scope link  src 127.0.0.1 
broadcast 192.168.10.255 dev eth0  table 255  proto kernel  scope link  src 192.168.10.2 
local 192.168.10.2 dev eth0  table 255  proto kernel  scope host  src 192.168.10.2 
broadcast 192.168.10.0 dev eth0  table 255  proto kernel  scope link  src 192.168.10.2 
broadcast 127.0.0.0 dev lo  table 255  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.1 dev lo  table 255  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.0/8 dev lo  table 255  proto kernel  scope host  src 127.0.0.1 
local ::1 via :: dev lo  proto none  metric 0  mtu 16436 advmss 16376 hoplimit 4294967295
local fe80::208:a1ff:fe03:f114 via :: dev lo  proto none  metric 0  mtu 16436 advmss 16376 hoplimit 4294967295
fe80::/64 dev eth0  metric 256  expires 8532984sec mtu 1500 advmss 1440 hoplimit 4294967295
ff00::/8 dev eth0  metric 256  expires 8532984sec mtu 1500 advmss 1440 hoplimit 4294967295
unreachable default dev lo  proto none  metric -1  error -101 hoplimit 255

Now, here is the output of the same command using the ovz kernel.
192.168.10.0/24 dev eth0  proto kernel  scope link  src 192.168.10.2 
default via 192.168.10.1 dev eth0 
broadcast 127.255.255.255 dev lo  table 255  proto kernel  scope link  src 127.0.0.1 
broadcast 192.168.10.255 dev eth0  table 255  proto kernel  scope link  src 192.168.10.2 
local 192.168.10.2 dev eth0  table 255  proto kernel  scope host  src 192.168.10.2 
broadcast 192.168.10.0 dev eth0  table 255  proto kernel  scope link  src 192.168.10.2 
broadcast 127.0.0.0 dev lo  table 255  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.1 dev lo  table 255  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.0/8 dev lo  table 255  proto kernel  scope host  src 127.0.0.1 
local ::1 via :: dev lo  proto none  metric 0  mtu 16436 advmss 16376 hoplimit 4294967295
local fe80::208:a1ff:fe03:f114 via :: dev lo  proto none  metric 0  mtu 16436 advmss 16376 hoplimit 4294967295
fe80::/64 dev eth0  metric 256  expires 2133431sec mtu 1500 advmss 1440 hoplimit 4294967295
ff00::/8 dev eth0  metric 256  expires 2133431sec mtu 1500 advmss 1440 hoplimit 4294967295
unreachable default dev lo  proto none  metric -1  error -101 hoplimit 255

And here is the outpuit of 'netstat -s' from my working kernel.
Ip:
    36 total packets received
    0 forwarded
    0 incoming packets discarded
    36 incoming packets delivered
    36 requests sent out
Icmp:
    0 ICMP messages received
    0 input ICMP message failed.
    ICMP input histogram:
    0 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
Tcp:
    0 active connections openings
    0 passive connection openings
    0 failed connection attempts
    0 connection resets received
    0 connections established
    0 segments received
    0 segments send out
    0 segments retransmited
    0 bad segments received.
    0 resets sent
Udp:
    36 packets received
    0 packets to unknown port received.
    0 packet receive errors
    36 packets sent
TcpExt:
    0 packet headers predicted
    0 TCP data loss events

Finally, here is the output of the same command using the ovz kernel. This was ran after I ran 'ping -c 10 google.com' which ended up dying with 35% packet loss, after that I had no connection at all.
Ip:
    53 total packets received
    0 forwarded
    0 incoming packets discarded
    53 incoming packets delivered
    58 requests sent out
Icmp:
    9 ICMP messages received
    1 input ICMP message failed.
    ICMP input histogram:
        destination unreachable: 2
        echo replies: 7
    2 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
        destination unreachable: 2
Tcp:
    1 active connections openings
    0 passive connection openings
    1 failed connection attempts
    0 connection resets received
    0 connections established
    0 segments received
    1 segments send out
    1 segments retransmited
    0 bad segments received.
    0 resets sent
Udp:
    44 packets received
    0 packets to unknown port received.
    0 packet receive errors
    44 packets sent
TcpExt:
    0 packet headers predicted
    0 TCP data loss events
    1 other TCP timeouts

Im not sure what ip address to use with the suggested 'ip route get <ip_addr>' command as I really do not understand any of what is going on.

Am I seriosuly the only person this has happened too? I cannot find any information at all.

Thankyou very much for your time. I feel like an absolute newb again. Ive used Linux (Gentoo and now Debian) for around 4 years, just never had any network trouble.

[Updated on: Tue, 04 March 2008 05:26]

Report message to a moderator

Re: eth0 dies when using openVZ kernel. [message #27956 is a reply to message #27918] Tue, 04 March 2008 06:13 Go to previous messageGo to next message
den is currently offline  den
Messages: 494
Registered: December 2005
Senior Member
Basically, all this output is just routes in the slightly different format that one from 'route' utility. Linux uses 2 tables by default for routing:
- main and
- local.

The latter is used to determine the source address of the outgoing packet and to decide whether the packet is local.

'ip' interface is a bit never in respect to 'route' and is preferred for a lot of people, though it is not compatible with classical Unix one.

For the problem. According to the statitics present, you have 'destination unreachable' error.

So you have listed routing tables after the boot or when you see the problem? We need to see the latter. Additionally, could you share the result of 'ip route get <ip address you are trying to ping>' and 'arp -n' at the moment of the problem?
Re: eth0 dies when using openVZ kernel. [message #27957 is a reply to message #27956] Tue, 04 March 2008 07:24 Go to previous messageGo to next message
thorpe is currently offline  thorpe
Messages: 16
Registered: February 2008
Location: Sydney - Australia
Junior Member
Ok, thanks heaps for this. here is my routing tables list after the problem has occured (ie I have no connection).
192.168.10.0/24 dev eth0  proto kernel  scope link  src 192.168.10.2 
default via 192.168.10.1 dev eth0 
broadcast 127.255.255.255 dev lo  table 255  proto kernel  scope link  src 127.0.0.1 
broadcast 192.168.10.255 dev eth0  table 255  proto kernel  scope link  src 192.168.10.2 
local 192.168.10.2 dev eth0  table 255  proto kernel  scope host  src 192.168.10.2 
broadcast 192.168.10.0 dev eth0  table 255  proto kernel  scope link  src 192.168.10.2 
broadcast 127.0.0.0 dev lo  table 255  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.1 dev lo  table 255  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.0/8 dev lo  table 255  proto kernel  scope host  src 127.0.0.1 
local ::1 via :: dev lo  proto none  metric 0  mtu 16436 advmss 16376 hoplimit 4294967295
local fe80::208:a1ff:fe03:f114 via :: dev lo  proto none  metric 0  mtu 16436 advmss 16376 hoplimit 4294967295
fe80::/64 dev eth0  metric 256  expires 2133422sec mtu 1500 advmss 1440 hoplimit 4294967295
ff00::/8 dev eth0  metric 256  expires 2133422sec mtu 1500 advmss 1440 hoplimit 4294967295
unreachable default dev lo  proto none  metric -1  error -101 hoplimit 255

Here is the ouput of 'ip route get 72.14.207.99' (google's ip)
72.14.207.99 via 192.168.10.1 dev eth0  src 192.168.10.2 
    cache  mtu 1500 advmss 1460 hoplimit 64

And now, the output of 'arp -n'
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.10.1                     (incomplete)                              eth0


Hope this helps. Thanks again.
Re: eth0 dies when using openVZ kernel. [message #27958 is a reply to message #27957] Tue, 04 March 2008 08:04 Go to previous messageGo to next message
den is currently offline  den
Messages: 494
Registered: December 2005
Senior Member
ARP resolution does not work for the case.

Could you check with tcpdump that there is an outgoing ARP request?
tcpdump -ni eth0 arp
If you see the request and do not see a reply, then you should check that your router really send the reply packet, it is best to be done in the similar way from the other host in the network.
Re: eth0 dies when using openVZ kernel. [message #27960 is a reply to message #27958] Tue, 04 March 2008 08:52 Go to previous messageGo to next message
thorpe is currently offline  thorpe
Messages: 16
Registered: February 2008
Location: Sydney - Australia
Junior Member
Quote:

it is best to be done in the similar way from the other host in the network.


And how exactly would I do that?
Re: eth0 dies when using openVZ kernel. [message #27961 is a reply to message #27960] Tue, 04 March 2008 09:30 Go to previous messageGo to next message
thorpe is currently offline  thorpe
Messages: 16
Registered: February 2008
Location: Sydney - Australia
Junior Member
Also, do you think it might be worth my while trying another card?

I've got a spare here.
Re: eth0 dies when using openVZ kernel. [message #27965 is a reply to message #27961] Tue, 04 March 2008 11:22 Go to previous messageGo to next message
den is currently offline  den
Messages: 494
Registered: December 2005
Senior Member
basically, I do not have an answer for this.

We have heard about e1000 problems with 028stab053 kernel. Though, this can be unrelevant.

As for ARP, should should do the same
tcpdump -n arp
and check that you see both arp requests and arp reply for the case.
SOLVED [message #27982 is a reply to message #27965] Wed, 05 March 2008 04:07 Go to previous message
thorpe is currently offline  thorpe
Messages: 16
Registered: February 2008
Location: Sydney - Australia
Junior Member
Ok, I'm really not sure what the issue was, and to be honest no longer care.

I pulled my card out, replaced it with my spare D-Link RTL8139 and all is now working.

Thanks again for you help, now its time to go play with this thing. i'm sure I'll be back with more questions soon enough.
Previous Topic: Quota Problem
Next Topic: Internet access from VE (again)
Goto Forum:
  


Current Time: Mon Nov 04 14:29:33 GMT 2024

Total time taken to generate the page: 0.03694 seconds