Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I created a very standard Xen-4.0 domU with network-bridge configuration. However, no packets get out from the virtual machine to the network which bridge (peth0) is attached to. From guest I can ping the hypervisor, but can't ping anything outside it.

IP addresses:

  • x.x.x.121 -- hypervisor buddha
  • x.x.x.162 -- virutal machine, xen6

What is happening? It is a very standard network configuration. With another hypervisor exactly same configuration works (same OS, same versions, same config), but with other box it doesn't.

Symptoms look similar to this, however, my network configuration seems to look fine. Any ideas?

xen6:~$ ping -c 1 x.x.x.121
PING x.x.x.121 (x.x.x.121) 56(84) bytes of data.
64 bytes from x.x.x.121: icmp_req=1 ttl=64 time=0.093 ms

--- x.x.x.121 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.093/0.093/0.093/0.000 ms
buddha$ sed -n '/^[^#].*\(\(network\)\|\(vif\)\)/p' xend-config.sxp
(network-script network-bridge)
(vif-script vif-bridge)
buddha# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:30:48:5a:05:fa  
          inet addr:x.x.x.121  Bcast:x.x.x.255  Mask:255.255.255.0
          inet6 addr: fe80::230:48ff:fe5a:5fa/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6082 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1138 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:573467 (560.0 KiB)  TX bytes:230756 (225.3 KiB)

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:26 errors:0 dropped:0 overruns:0 frame:0
          TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2428 (2.3 KiB)  TX bytes:2428 (2.3 KiB)

peth0     Link encap:Ethernet  HWaddr 00:30:48:5a:05:fa  
          inet6 addr: fe80::230:48ff:fe5a:5fa/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:6218 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1141 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:693978 (677.7 KiB)  TX bytes:235320 (229.8 KiB)
          Interrupt:26 

vif1.0    Link encap:Ethernet  HWaddr fe:ff:ff:ff:ff:ff  
          inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:3 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4369 errors:0 dropped:43 overruns:0 carrier:0
          collisions:0 txqueuelen:32 
          RX bytes:84 (84.0 B)  TX bytes:487332 (475.9 KiB)
buddha# xm network-list xen6
Idx BE     MAC Addr.     handle state evt-ch tx-/rx-ring-ref BE-path
0   0  00:16:3E:F3:0F:D9    0     4      15    769  /768     /local/domain/0/backend/vif/1/0

buddha# brctl show
bridge name bridge id       STP enabled interfaces
eth0        8000.0030485a05fa   no      peth0
                                        vif1.0
xen6# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:16:3e:f3:0f:d9  
          inet addr:x.x.x.162  Bcast:x.x.x.255  Mask:255.255.255.0
          inet6 addr: fe80::216:3eff:fef3:fd9/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6870 errors:0 dropped:0 overruns:0 frame:0
          TX packets:209 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:628821 (614.0 KiB)  TX bytes:31636 (30.8 KiB)
          Interrupt:17 

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:1 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:80 (80.0 B)  TX bytes:80 (80.0 B)
xen6:~$ ping -c 1 x.x.x.121
PING x.x.x.121 (x.x.x.121) 56(84) bytes of data.
64 bytes from x.x.x.121: icmp_req=1 ttl=64 time=0.081 ms

--- x.x.x.121 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.081/0.081/0.081/0.000 ms

Here is the ethernet controller:

02:05.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 10)
    Subsystem: Super Micro Computer Inc Device 1648
    Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 26
    Memory at fc9f0000 (64-bit, non-prefetchable) [size=64K]
    Expansion ROM at  [disabled]
    Capabilities: [40] PCI-X non-bridge device
    Capabilities: [48] Power Management version 2
    Capabilities: [50] Vital Product Data
    Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
    Kernel driver in use: tg3

I read somewhere (can't recall where) that IPMI creates issues with networking. So I disabled IPMI.

motiejus@buddha> uname -a
Linux buddha 2.6.32-5-xen-amd64 #1 SMP Mon Jan 16 20:48:30 UTC 2012 x86_64 GNU/Linux
motiejus@buddha> lsb_release -a
Distributor ID: Debian
Description:    Debian GNU/Linux 6.0.4 (squeeze)
Release:    6.0.4
Codename:   squeeze

Update from pastebin-data (routing info and ping-results):

Xen6:
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface  
x.x.x.0    0.0.0.0         255.255.255.0   U         0 0          0 eth0   
0.0.0.0         x.x.x.1    0.0.0.0         UG        0 0          0 eth0   

Buddha:
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface    
x.x.x.0    0.0.0.0         255.255.255.0   U         0 0          0 eth0     
0.0.0.0         x.x.x.1    0.0.0.0         UG        0 0          0 eth0     

xen6:~$ ping -c1 x.x.x.1
PING x.x.x.1 (x.x.x.1) 56(84) bytes of data.

--- x.x.x.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

buddha# tcpdump -nni eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode                    
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes                      
22:51:01.977068 IP x.x.x.162 > x.x.x.1: ICMP echo request, id 2632, seq 1, length 64

However, x.x.x.1 does not receive the ICMP request.

buddha# ping -c1 x.x.x.1
PING x.x.x.1 (x.x.x.1) 56(84) bytes of data.         
64 bytes from x.x.x.1: icmp_req=1 ttl=255 time=0.403 ms   

--- x.x.x.1 ping statistics ---                           
1 packets transmitted, 1 received, 0% packet loss, time 0ms    
rtt min/avg/max/mdev = 0.403/0.403/0.403/0.000 ms 
share|improve this question
    
I put the info of your comments into your question. So basically the ping from the DomU seems to go out (through the bridge to the physical interface), but no reply comes in. Is your DomUs MAC-adress used elsewhere in the network? –  Nils Mar 17 '12 at 21:26
    
@Nills thanks for editing the post! According to tcpdump on buddha, it comes out through the interface, but on the target host it doesn't come in. Seems like packet is stuck in the NIC itself somehow. No other host is using the same MAC (according to arping). I would suspect ethernet drivers.. Will search for them. –  Motiejus Jakštys Mar 17 '12 at 22:01
    
Looks exactly like this. I once managed to boot Xen, and hypervisor had no access to the internet, but guest did. However, the workaround is for BCM5708, and my card is BCM5707. My card uses tg3, and the one mentioned in thread is bnx2. There is no such thing as "management firmware" in BCM5707. Disabling IPMI does not help. –  Motiejus Jakštys Mar 18 '12 at 15:10
    
@Nils please post this as an answer so I can upvote it. That's correct! –  Motiejus Jakštys Mar 19 '12 at 16:41
    
Great. Did they tell it anyone?-( –  Nils Mar 19 '12 at 21:52

2 Answers 2

up vote 1 down vote accepted

Is "MAC based" security activated by your network department? This sounds to me as if only the first outgoing MAC on the physical line is being accepted.

share|improve this answer

As I remember my problem was the same. Turning on the arp cache solved my problem, might work for you as well.

Insert these lines to /etc/sysctl.conf:

net.ipv4.ip_forward = 1
net.ipv4.conf.eth0.proxy_arp = 1

I use a routed network so there is no peth0, maybe you need to enable it:

net.ipv4.conf.peth0.proxy_arp = 1
share|improve this answer
    
but first try command: "arp" in Dom0 and DomU and if you don't see the remote end ip and MAC pair, this is the problem. –  Dankó Dávid May 28 '13 at 23:34

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.