[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-users] Packets droped by Dom0


  • To: <xen-users@xxxxxxxxxxxxxxxxxxx>
  • From: "Guillaume S" <drgkill@xxxxxxxxx>
  • Date: Sat, 17 Apr 2010 00:12:31 +0200
  • Delivery-date: Sun, 18 Apr 2010 08:36:39 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=xFZWklk9aLI2Wk8GM1TiUq4w59xCC8sysWvX1KCdeMA4lNnPBOVDnxBd3u3qhO1/Ng OycPxRWAusOPknlGPTngzxPuDyhY+2pVrmDoqNbyRuBMeaQ/BHn7UWrkihu/VDQQ2ufQ O5VpEqwBXVCVhBlOY8Tcu9jCd2GYhKXNWprJg=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>
  • Thread-index: AcrciM+Y5gzMSTfnQ3S+Pnl9UIOQ4QBJyV8gAABy2cA=

Erratum ...
The arg to pass to the kernel is 
ipv6.disable=1 

And NOT disable.ipv6=1.

-----Message d'origine-----
De : Guillaume S [mailto:drgkill@xxxxxxxxx] 
Envoyà : samedi 17 avril 2010 00:08
à : xen-users@xxxxxxxxxxxxxxxxxxx
Objet : RE: [Xen-users] Packets droped by Dom0

The problem is definitely solved disabling ipv6 at boot time by passing this 
command to the kernel at boot time (arg passed into the bootloader):
"disable.ipv6=1"

And by disabling it via sysctl : 
Into /etc/sysctl.conf :
net.ipv6.conf.all.disable_ipv6=1

And there the problem is definitely solved. 
Some kernel are set with build-in IPv6 driver and so, trying to disable it into 
modprobe.d/blacklist is inefficient because there is no IPv6 modules.
And for whom who do not want to reboot it's a pitty because the sysctl command 
is not enough.

For some guy's it'll be only a workaround because disabling IPv6 is not always 
what we want.
Finally, I'll be interested in how to sharply disable the multicast ICMPv6 
announcement.

-----Message d'origine-----
De : Thomas Halinka [mailto:lists@xxxxxxxxx] 
Envoyà : jeudi 15 avril 2010 12:46
à : Guillaume S
Objet : Re: [Xen-users] Packets droped by Dom0

Am Donnerstag, den 15.04.2010, 12:22 +0200 schrieb Guillaume S:
> Dear,
> 
>  
> 
> I got a real strange problem with my Xen installation.
> 
> When I setup a DomU with an interface with a public IP, packets are
> droped by dom0 â
> 
>  
> 
> I got a bridged configuration with VLANs :
> 
>  
> 
> # brctl show
> 
> bridge name     bridge id               STP enabled     interfaces
> 
> tmpbridge               8000.000000000000       no
> 
> xlan.20         8000.feffffffffff       no              eth1.20
> 
> xlan.30         8000.feffffffffff       no              GEV1lan
> 
>                                                         NSlan
> 
>                                                         OmegaBlog1lan
> 
>                                                         RMlan
> 
>                                                         SFlan
> 
>                                                         eth1.30
> 
> xwan            8000.0026b9835a88       no              peth0
> 
>                                                         testWan
> 
>  
> 
>  
> 
> # ip add sh dev xwan
> 
> 6: xwan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UNKNOWN
> 
>     link/ether 00:26:b9:83:5a:88 brd ff:ff:ff:ff:ff:ff
> 
>     inet 78.24.xx.yy/26 brd 78.24.xx.yy scope global xwan
> 
>     inet6 fe80::226:b9ff:fe83:5a88/64 scope link
> 
>        valid_lft forever preferred_lft forever
> 
>  
> 
> -When I try to ping my domU I get huge amount of packet loss:
> 
> # ping 78.24.xx.zz
> 
> PING 78.24.xx.zz (78.24.xx.zz) 56(84) bytes of data.
> 
> 64 bytes from 78.24.xx.zz: icmp_seq=1 ttl=128 time=5.69 ms
> 
> ^C
> 
> --- 78.24.xx.zz ping statistics ---
> 
> 5 packets transmitted, 1 received, 80% packet loss, time 4026ms
> 
> rtt min/avg/max/mdev = 5.690/5.690/5.690/0.000 ms
> 
>  
> 
>  
> 
> Monitoring the xwan bridge :
> 
> # tcpdump -n -e -ttt -i xwan icmp
> 
> tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
> 
> listening on xwan, link-type EN10MB (Ethernet), capture size 96 bytes
> 
> â
> 
>  
> 
> 00:00:01.006698 00:26:b9:83:5a:88 > 00:16:3e:52:89:d2, ethertype IPv4
> (0x0800), length 98: 78.24.130.200 > 78.24.130.204: ICMP echo request,
> id 60001, seq 304, length 64
> 
> 00:00:01.000464 00:26:b9:83:5a:88 > 00:16:3e:52:89:d2, ethertype IPv4
> (0x0800), length 98: 78.24.130.200 > 78.24.130.204: ICMP echo request,
> id 60001, seq 305, length 64
> 
> 00:00:01.008578 00:26:b9:83:5a:88 > 00:16:3e:52:89:d2, ethertype IPv4
> (0x0800), length 98: 78.24.130.200 > 78.24.130.204: ICMP echo request,
> id 60001, seq 306, length 64
> 
> 00:00:01.008262 00:26:b9:83:5a:88 > 00:16:3e:52:89:d2, ethertype IPv4
> (0x0800), length 98: 78.24.130.200 > 78.24.130.204: ICMP echo request,
> id 60001, seq 307, length 64
> 
> 00:00:01.009170 00:26:b9:83:5a:88 > 00:16:3e:52:89:d2, ethertype IPv4
> (0x0800), length 98: 78.24.130.200 > 78.24.130.204: ICMP echo request,
> id 60001, seq 308, length 64
> 
> 00:00:00.000642 00:16:3e:52:89:d2 > 00:26:b9:83:5a:88, ethertype IPv4
> (0x0800), length 98: 78.24.130.204 > 78.24.130.200: ICMP echo reply,
> id 60001, seq 308, length 64Ã Sometime an echo reply â
> 
> 00:00:00.999149 00:26:b9:83:5a:88 > 00:16:3e:52:89:d2, ethertype IPv4
> (0x0800), length 98: 78.24.130.200 > 78.24.130.204: ICMP echo request,
> id 60001, seq 309, length 64
> 
> 00:00:01.000767 00:26:b9:83:5a:88 > 00:16:3e:52:89:d2, ethertype IPv4
> (0x0800), length 98: 78.24.130.200 > 78.24.130.204: ICMP echo request,
> id 60001, seq 310, length 64
> 
> 00:00:01.000895 00:26:b9:83:5a:88 > 00:16:3e:52:89:d2, ethertype IPv4
> (0x0800), length 98: 78.24.130.200 > 78.24.130.204: ICMP echo request,
> id 60001, seq 311, length 64
> 
> 00:00:00.999157 00:26:b9:83:5a:88 > 00:16:3e:52:89:d2, ethertype IPv4
> (0x0800), length 98: 78.24.130.200 > 78.24.130.204: ICMP echo request,
> id 60001, seq 312, length 64
> 
>  
> 
>  
> 
> - Iptables settings looks fine :
> 
>  
> 
> # iptables -L
> 
......
> 
>  
> 
> I did notice something weird : Lots of multicast ICMPv6 packets sent :
> 
>  
> 
> # tcpdump -n -e -ttt -i BurdaWan
> 
> tcpdump: WARNING: BurdaWan: no IPv4 address assigned
> 
> tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
> 
> listening on BurdaWan, link-type EN10MB (Ethernet), capture size 96
> bytes
> 
.......
> â
> 
>  
> 
>  
> 
> If someone could help me on this it would be MUCH appreciated !

Is IPv6 enabled?

        # lsmod | grep v6
        ipv6                  289352  38
        
Blacklist the Module

  # echo "blacklist ipv6" >> /etc/modprobe.d/blacklist

and unload or reboot...

> 
>  
> 
> Thanks by advance,
> 
>  
> 
> Guillaume S.
> 
cu,

thomas

 
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users





_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.