| View previous topic :: View next topic |
| Author |
Message |
matrix47
n00b
Joined: 20 Jan 2008
Posts: 21
Location: Moscow, Russia
|
 Posted: Tue Oct 16, 2012 7:24 am Post subject: [SOLVED] xen + bridge - strange networking problem |
 |
|
Hello!
I'm trying to configure networking for my xen domU client (windows 7).
The configuration is done via bridging. Here's related /etc/conf.d/net lines:
| Code: | rc_net_br0_need="net.eth1"
config_eth1="null"
bridge_br0="eth1"
brctl_br0="setfd 0 sethello 0 stp off"
config_br0="192.168.47.1/24" |
Here's the networking line in xen vm config file:
| Code: | | vif = ['bridge=br0, mac=B7:3A:C7:72:A6:0E, model=virtio' ] |
After vm starts, I have the following bridge configuration:
| Code: | bridge name bridge id STP enabled interfaces
br0 8000.56c7c4f08bfb no eth1
vif1.0 |
Here's ifconfig after start:
| Code: | br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.47.1 netmask 255.255.255.0 broadcast 192.168.47.255
inet6 fe80::54c7:c4ff:fef0:8bfb prefixlen 64 scopeid 0x20<link>
ether 56:c7:c4:f0:8b:fb txqueuelen 0 (Ethernet)
RX packets 26 bytes 3979 (3.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 516 bytes 77703 (75.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether bc:5f:f4:46:54:0e txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 17
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 16436
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 0 (Local Loopback)
RX packets 3908 bytes 7422222 (7.0 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3908 bytes 7422222 (7.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
vif1.0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::fcff:ffff:feff:ffff prefixlen 64 scopeid 0x20<link>
ether fe:ff:ff:ff:ff:ff txqueuelen 32 (Ethernet)
RX packets 443 bytes 17103 (16.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 387 bytes 34136 (33.3 KiB)
TX errors 0 dropped 1 overruns 0 carrier 0 collisions 0
|
I configure domU client statically as 192.168.47.3/24 with default gw 192.168.47.1
The problem is - no communication between dom0 and domU.
| Code: | ping 192.168.47.3
PING 192.168.47.3 (192.168.47.3) 56(84) bytes of data.
From 192.168.47.1: icmp_seq=1 Destination Host Unreachable
From 192.168.47.1: icmp_seq=2 Destination Host Unreachable
From 192.168.47.1: icmp_seq=3 Destination Host Unreachable
From 192.168.47.1: icmp_seq=4 Destination Host Unreachable
From 192.168.47.1: icmp_seq=5 Destination Host Unreachable
From 192.168.47.1: icmp_seq=6 Destination Host Unreachable
|
But let's look here while pinging:
| Code: | tcpdump -i vif1.0
tcpdump: WARNING: vif1.0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vif1.0, link-type EN10MB (Ethernet), capture size 65535 bytes
00:16:53.512712 ARP, Request who-has 192.168.47.3 tell 192.168.47.1, length 28
00:16:53.512890 ARP, Reply 192.168.47.3 is-at b7:3a:c7:72:a6:0e (oui Unknown), length 28
00:16:55.508975 ARP, Request who-has 192.168.47.3 tell 192.168.47.1, length 28
00:16:55.509143 ARP, Reply 192.168.47.3 is-at b7:3a:c7:72:a6:0e (oui Unknown), length 28
00:16:56.489083 IP 192.168.47.1.17500 > 192.168.47.255.17500: UDP, length 109
00:16:56.510705 ARP, Request who-has 192.168.47.3 tell 192.168.47.1, length 28
00:16:56.510834 ARP, Reply 192.168.47.3 is-at b7:3a:c7:72:a6:0e (oui Unknown), length 28
00:16:57.512705 ARP, Request who-has 192.168.47.3 tell 192.168.47.1, length 28
00:16:57.512886 ARP, Reply 192.168.47.3 is-at b7:3a:c7:72:a6:0e (oui Unknown), length 28
|
So, the VM even answeres the arp request, but it somewhy doesn't get to br0.
Here's what happens when pinging 192.168.47.1 from domU:
| Code: | tcpdump -i vif1.0
tcpdump: WARNING: vif1.0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vif1.0, link-type EN10MB (Ethernet), capture size 65535 bytes
00:18:30.199322 ARP, Request who-has 192.168.47.1 (56:c7:c4:f0:8b:fb (oui Unknown)) tell 192.168.47.3, length 28
00:18:31.213358 ARP, Request who-has 192.168.47.1 (56:c7:c4:f0:8b:fb (oui Unknown)) tell 192.168.47.3, length 28
|
So, again. We see activity on vif1.0, but br0 doesn't see it.
I've played with all the settings in /proc/sys/net/ipv4/conf/{br0,vif1.0}/ - nothing helps.
I would be very grateful for any suggestions why this strange behavior happens. I killed more than 4 hours already on this thing, I can't even see google search results anymore.
By the way: this is happening with GPLpv drivers installed in domU. The same thing was happening before installation of drivers with tap1.0 device instead of vif1.0.
Thanks in advance!
_________________
May the force be with you!
Last edited by matrix47 on Thu Jan 03, 2013 1:39 am; edited 1 time in total |
|
| Back to top |
|
 |
matrix47
n00b
Joined: 20 Jan 2008
Posts: 21
Location: Moscow, Russia
|
| Posted: Tue Oct 16, 2012 7:25 am Post subject: |
|
|
maybe that will be important:
I'm running gentoo-sources-3.6.2, xen-4.1.2
_________________
May the force be with you! |
|
| Back to top |
|
|
matrix47
n00b
Joined: 20 Jan 2008
Posts: 21
Location: Moscow, Russia
|
| Posted: Tue Oct 16, 2012 7:31 am Post subject: |
|
|
one more thing:
on eth0 I have a real cable to another PC that is configured statically 192.168.47.2/24
and this PC reaches br0 address without any problems (and vice-versa)
so the problem is not on the bridge side, as it seems
_________________
May the force be with you! |
|
| Back to top |
|
|
matrix47
n00b
Joined: 20 Jan 2008
Posts: 21
Location: Moscow, Russia
|
| Posted: Thu Jan 03, 2013 1:41 am Post subject: |
|
|
the problem was apparently in a bad mac address for the VM network interface
when I changed that to a value from some actual old network adapter, it worked
the initial value was generated by http://www.miniwebtool.com/mac-address-generator/ - didn't suspect the problem could come from that.
_________________
May the force be with you! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
