On Tue, Apr 04, 2006 at 08:24:38PM +0200, Matteo Beccati wrote:
> Hi,
>
> I've recently switched kernel on my NetBSD 3.0 development server to be
> able to evaluate XEN. I've been able to get it running having dom0 on a
> raidframe mirrored root fs, thanks to the great how-tos. I've managed to
> install another NetBSD 3.0 as domU booting with the INSTALL_XENU kernel
> and installed installing from cdrom.
>
> The domU seems perfectly working, but I'm unable to have a working
> network configuration. If I try to ping any machine in the bridged
> network I receive DUP! answers, but the same doesn't happen when trying
I don't get duplicate replies in my setup.
> to reach an external IP (outside of my wireless router, which also acts
> as a dhcp server). I'm also able to resolve IPs, but the whole thing
> stops when trying to make TCP connections anywhere.
>
> From what I was able to see connections remain in SYN_SENT state. Here
> are some ifconfig/brconfig output:
>
> dom0
> ----
> # ifconfig -a
> ste0:
> flags=8b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
> address: 00:05:5d:e9:f4:50
> media: Ethernet autoselect (100baseTX full-duplex)
> status: active
> inet 192.168.1.100 netmask 0xffffff00 broadcast 192.168.1.255
> inet6 fe80::205:5dff:fee9:f450%ste0 prefixlen 64 scopeid 0x1
> lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 33192
> inet 127.0.0.1 netmask 0xff000000
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
> bridge0: flags=41<UP,RUNNING> mtu 1500
> xvif1.0:
> flags=8963<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,SIMPLEX,MULTICAST>
> mtu 1500
> address: ab:00:00:51:02:f1
> inet6 fe80::205:5dff:fee9:f450%xvif1.0 prefixlen 64 scopeid 0x4
>
> # brconfig -a
> bridge0: flags=41<UP,RUNNING>
> Configuration:
> priority 32768 hellotime 2 fwddelay 15 maxage 20
> ipfilter disabled flags 0x0
> Interfaces:
> xvif1.0 flags=3<LEARNING,DISCOVER>
> port 4 priority 128
> ste0 flags=3<LEARNING,DISCOVER>
> port 1 priority 128
> Address cache (max cache: 100, timeout: 1200):
> 00:0f:3d:09:72:91 ste0 780 flags=0<>
> 00:13:d4:88:8e:50 ste0 181 flags=0<>
> ab:00:00:50:02:f1 xvif1.0 166 flags=0<>
>
>
> domU
> ----
> # ifconfig -a
> lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 33192
> inet 127.0.0.1 netmask 0xff000000
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
> xennet0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST>
> mtu 1500
> address: ab:00:00:50:02:f1
> inet 192.168.1.121 netmask 0xffffff00 broadcast 192.168.1.255
> inet6 fe80::d41d:8cd9:8f00:b204%xennet0 prefixlen 64 scopeid 0x2
>
>
> Netstat and tcpdump of a smtp connection from domU to dom0:
>
> Active Internet connections
> Proto Recv-Q Send-Q Local Address Foreign Address State
> tcp 0 0 192.168.1.121.65519 192.168.1.100.smtp SYN_SENT
>
> # tcpdump port smtp &
> [1] 623
> # tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on xennet0, link-type EN10MB (Ethernet), capture size 96 bytes
> # telnet 192.168.1.100 25
> Trying 192.168.1.100...
> 20:20:03.930140 IP 192.168.1.121.65517 > 192.168.1.100.smtp: S
> 1411259275:1411259275(0) win 32768 <mss 1460,nop,wscale
> 0,sackOK,nop,nop,nop,nop,timestamp 0 0>
> 20:20:03.932114 IP 192.168.1.100.smtp > 192.168.1.121.65517: S
> 760749685:760749685(0) ack 1411259276 win 32768 <mss 1460,nop,wscale
> 0,nop,nop,timestamp 0 0,sackOK,nop,nop>
> 20:20:03.932136 IP 192.168.1.100.smtp > 192.168.1.121.65517: S
> 760749685:760749685(0) ack 1411259276 win 32768 <mss 1460,nop,wscale
> 0,nop,nop,timestamp 0 0,sackOK,nop,nop>
> 20:20:06.920894 IP 192.168.1.100.smtp > 192.168.1.121.65517: S
> 760749685:760749685(0) ack 1411259276 win 32768 <mss 1460,nop,wscale
> 0,nop,nop,timestamp 6 0,sackOK,nop,nop>
> 20:20:06.921531 IP 192.168.1.100.smtp > 192.168.1.121.65517: S
> 760749685:760749685(0) ack 1411259276 win 32768 <mss 1460,nop,wscale
> 0,nop,nop,timestamp 6 0,sackOK,nop,nop>
>
>
> Could you please advise?
Some more investigation would be appreciated. Verify that the packets
are flowing to the right place at all tcpdump-able interfaces, (the -e
flag will be useful). Also check for appropriate entries in the ARP
tables of the various machines.
I'd venture a guess that the Xen (virtual) machines are at most
only half of this problem.
Jonathan Kollasch
Attachment:
pgpwlpb0wWhBx.pgp
Description: PGP signature