3:58 a.m.
Hello,
I have first a question (and then may be a problem), that I have difficulties to
understand and eventually to investigate.
On each of my guests VM, I see constantly a RX dropped number increasing , Even if the VM
does nothing !
ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.100.15 netmask 255.255.255.0 broadcast 192.168.100.255
inet6 fe80::5054:ff:fe36:ac80 prefixlen 64 scopeid 0x20<link>
ether 52:54:00:36:ac:80 txqueuelen 1000 (Ethernet)
RX packets 1966 bytes 122391 (119.5 KiB)
RX errors 0 dropped 1288 overruns 0 frame 0
TX packets 552 bytes 99939 (97.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 0 (Local Loopback)
RX packets 4 bytes 340 (340.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4 bytes 340 (340.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
(1) Is that a normal behaviour ?
(2) Could you give me some hints where/how to investigate
Here are a number of informations:
- The virsh LAN setup
- The VM XML description
- iptables-save on the hosts
- and then some packages version
Thanks in advance
Patrick
My setup is as follow:
An host running a Fedora 23 (minimal) and a VM guest running a Fedora 23
I have created 3 Networks ,
- 2 fully isolated ( mgt-private-lan and pre-private-lan)
- 1 Nat via the host NIC
Here after are the information related to the nat Network on which I have consistent
increase of RX Dropped Packets
virsh net-list
Name State Autostart Persistent
----------------------------------------------------------
mgt-private-lan active yes yes
nat-internet active yes yes
prd-private-lan active yes yes
virsh net-info nat-internet
Name: nat-internet
UUID: 4cff86b1-8e63-40be-ac9c-d3dcd405a9d3
Active: yes
Persistent: yes
Autostart: yes
Bridge: virbr1
virsh net-dumpxml nat-internet
<network connections='5'>
<name>nat-internet</name>
<uuid>4cff86b1-8e63-40be-ac9c-d3dcd405a9d3</uuid>
<forward dev='eth0' mode='nat'>
<nat>
<port start='1024' end='65535'/>
</nat>
<interface dev='eth0'/>
</forward>
<bridge name='virbr1' stp='on' delay='0'/>
<mac address='52:54:00:e4:ec:1b'/>
<domain name='nat-internet'/>
<ip address='192.168.100.1' netmask='255.255.255.0'>
<dhcp>
<range start='192.168.100.128' end='192.168.100.254'/>
</dhcp>
</ip>
</network>
here is the XML of the VM
[root@ks3 boot]# virsh dumpxml Network
<domain type='kvm' id='5'>
<name>Network</name>
<uuid>006ec4e9-028c-4fef-94ec-4e9efbab61ff</uuid>
<memory unit='KiB'>1048576</memory>
<currentMemory unit='KiB'>1048576</currentMemory>
<vcpu placement='static'>1</vcpu>
<resource>
<partition>/machine</partition>
</resource>
<os>
<type arch='x86_64' machine='pc-i440fx-2.4'>hvm</type>
<kernel>/var/lib/libvirt/boot/vmlinuz</kernel>
<initrd>/var/lib/libvirt/boot/initramfs.img</initrd>
<cmdline>root=/dev/vda selinux=0 audit=0 console=ttyS0 nosplash
quiet</cmdline>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
</features>
<cpu mode='custom' match='exact'>
<model fallback='allow'>SandyBridge</model>
</cpu>
<clock offset='utc'>
<timer name='rtc' tickpolicy='catchup'/>
<timer name='pit' tickpolicy='delay'/>
<timer name='hpet' present='no'/>
</clock>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<pm>
<suspend-to-mem enabled='no'/>
<suspend-to-disk enabled='no'/>
</pm>
<devices>
<emulator>/usr/bin/qemu-kvm</emulator>
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='none'
io='native'/>
<source dev='/dev/vault-storage/network-root'/>
<backingStore/>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x08' function='0x0'/>
</disk>
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='none'
io='native'/>
<source dev='/dev/vault-storage/network-bootswap'/>
<backingStore/>
<target dev='vdb' bus='virtio'/>
<alias name='virtio-disk1'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x09' function='0x0'/>
</disk>
<controller type='usb' index='0' model='ich9-ehci1'>
<alias name='usb'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x07' function='0x7'/>
</controller>
<controller type='usb' index='0' model='ich9-uhci1'>
<alias name='usb'/>
<master startport='0'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x07' function='0x0' multifunction='on'/>
</controller>
<controller type='usb' index='0' model='ich9-uhci2'>
<alias name='usb'/>
<master startport='2'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x07' function='0x1'/>
</controller>
<controller type='usb' index='0' model='ich9-uhci3'>
<alias name='usb'/>
<master startport='4'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x07' function='0x2'/>
</controller>
<controller type='pci' index='0' model='pci-root'>
<alias name='pci.0'/>
</controller>
<controller type='virtio-serial' index='0'>
<alias name='virtio-serial0'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x06' function='0x0'/>
</controller>
<interface type='network'>
<mac address='52:54:00:36:ac:80'/>
<source network='nat-internet' bridge='virbr1'/>
<target dev='vnet12'/>
<model type='virtio'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x03' function='0x0'/>
</interface>
<serial type='pty'>
<source path='/dev/pts/5'/>
<target port='0'/>
<alias name='serial0'/>
</serial>
<console type='pty' tty='/dev/pts/5'>
<source path='/dev/pts/5'/>
<target type='serial' port='0'/>
<alias name='serial0'/>
</console>
<channel type='unix'>
<source mode='bind'
path='/var/lib/libvirt/qemu/channel/target/Network.org.qemu.guest_agent.0'/>
<target type='virtio' name='org.qemu.guest_agent.0'
state='connected'/>
<alias name='channel0'/>
<address type='virtio-serial' controller='0' bus='0'
port='1'/>
</channel>
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
<graphics type='spice' port='5904' autoport='yes'
listen='127.0.0.1'>
<listen type='address' address='127.0.0.1'/>
</graphics>
<video>
<model type='cirrus' vram='16384' heads='1'/>
<alias name='video0'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x02' function='0x0'/>
</video>
<memballoon model='virtio'>
<alias name='balloon0'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x0a' function='0x0'/>
</memballoon>
</devices>
</domain>
iptables-save
# Generated by iptables-save v1.4.21 on Sat Jan 23 10:49:51 2016
*nat
:PREROUTING ACCEPT [14895:623423]
:INPUT ACCEPT [12645:432591]
:OUTPUT ACCEPT [123:8518]
:POSTROUTING ACCEPT [595:37490]
-A PREROUTING -d 151.80.45.157/32 -p tcp -m tcp --dport 6514 -j DNAT --to-destination
192.168.100.10:6514
-A PREROUTING -d 151.80.45.157/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination
192.168.100.12:80
-A PREROUTING -d 151.80.45.157/32 -p tcp -m tcp --dport 443 -j DNAT --to-destination
192.168.100.12:443
-A POSTROUTING -s 192.168.100.0/24 -d 224.0.0.0/24 -o eth0 -j RETURN
-A POSTROUTING -s 192.168.100.0/24 -d 255.255.255.255/32 -o eth0 -j RETURN
-A POSTROUTING -s 192.168.100.0/24 ! -d 192.168.100.0/24 -o eth0 -p tcp -j MASQUERADE
--to-ports 1024-65535
-A POSTROUTING -s 192.168.100.0/24 ! -d 192.168.100.0/24 -o eth0 -p udp -j MASQUERADE
--to-ports 1024-65535
-A POSTROUTING -s 192.168.100.0/24 ! -d 192.168.100.0/24 -o eth0 -j MASQUERADE
COMMIT
# Completed on Sat Jan 23 10:49:51 2016
# Generated by iptables-save v1.4.21 on Sat Jan 23 10:49:51 2016
*mangle
:PREROUTING ACCEPT [1212763:799851388]
:INPUT ACCEPT [169753:18403044]
:FORWARD ACCEPT [1043010:781448344]
:OUTPUT ACCEPT [123913:208199933]
:POSTROUTING ACCEPT [1166923:989648277]
-A POSTROUTING -o virbr1 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
-A POSTROUTING -o virbr3 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
-A POSTROUTING -o virbr2 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
COMMIT
# Completed on Sat Jan 23 10:49:51 2016
# Generated by iptables-save v1.4.21 on Sat Jan 23 10:49:51 2016
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [120960:207745702]
-A INPUT -i virbr1 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr1 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr1 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr1 -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -i virbr3 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr3 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr3 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr3 -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -i virbr2 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr2 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr2 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr2 -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -m string --string "GET /w00tw00t.at.ISC
.SANS." --algo bm --to 70 -j DROP
-A INPUT -m set --match-set banned src -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 23 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -d 192.168.100.12/32 -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A FORWARD -d 192.168.100.12/32 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A FORWARD -d 192.168.100.10/32 -p tcp -m state --state NEW -m tcp --dport 6514 -j ACCEPT
-A FORWARD -d 192.168.100.0/24 -i eth0 -o virbr1 -m conntrack --ctstate
RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.100.0/24 -i virbr1 -o eth0 -j ACCEPT
-A FORWARD -i virbr1 -o virbr1 -j ACCEPT
-A FORWARD -o virbr1 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr1 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr3 -o virbr3 -j ACCEPT
-A FORWARD -o virbr3 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr3 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr2 -o virbr2 -j ACCEPT
-A FORWARD -o virbr2 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr2 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -m set --match-set banned src -j DROP
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -o virbr1 -p udp -m udp --dport 68 -j ACCEPT
-A OUTPUT -o virbr3 -p udp -m udp --dport 68 -j ACCEPT
-A OUTPUT -o virbr2 -p udp -m udp --dport 68 -j ACCEPT
COMMIT
# Completed on Sat Jan 23 10:49:51 2016
rpm -qa | grep libvirt
libvirt-daemon-driver-nodedev-1.2.18.2-1.fc23.x86_64
libvirt-daemon-driver-storage-1.2.18.2-1.fc23.x86_64
libvirt-daemon-config-network-1.2.18.2-1.fc23.x86_64
libvirt-daemon-1.2.18.2-1.fc23.x86_64
libvirt-daemon-driver-secret-1.2.18.2-1.fc23.x86_64
libvirt-daemon-driver-network-1.2.18.2-1.fc23.x86_64
libvirt-daemon-driver-nwfilter-1.2.18.2-1.fc23.x86_64
libvirt-daemon-driver-qemu-1.2.18.2-1.fc23.x86_64
libvirt-daemon-kvm-1.2.18.2-1.fc23.x86_64
libvirt-client-1.2.18.2-1.fc23.x86_64
libvirt-daemon-driver-interface-1.2.18.2-1.fc23.x86_64
rpm -qa | grep qemu
qemu-common-2.4.1-5.fc23.x86_64
qemu-kvm-2.4.1-5.fc23.x86_64
qemu-img-2.4.1-5.fc23.x86_64
ipxe-roms-qemu-20150407-3.gitdc795b9f.fc23.noarch
libvirt-daemon-driver-qemu-1.2.18.2-1.fc23.x86_64
qemu-system-x86-2.4.1-5.fc23.x86_64
rpm -qa | grep kvm
qemu-kvm-2.4.1-5.fc23.x86_64
libvirt-daemon-kvm-1.2.18.2-1.fc23.x86_64
4:10 a.m.
Last, if in the VM I add “driver name = ‘emu’, after boot I have few dropped packets, but
then it doesn’t increase anymore !
<interface type='network'>
<mac address='52:54:00:36:ac:80'/>
<source network='nat-internet' bridge='virbr1'/>
<target dev='vnet12'/>
<model type='virtio’/>
<driver name=‘emu’/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x03' function='0x0'/>
</interface>
> On 23 Jan 2016, at 10:58, pichon <patrick(a)pichon.me> wrote:
>
> Hello,
>
> I have first a question (and then may be a problem), that I have difficulties to
understand and eventually to investigate.
>
> On each of my guests VM, I see constantly a RX dropped number increasing , Even if
the VM does nothing !
>
> ifconfig
> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
> inet 192.168.100.15 netmask 255.255.255.0 broadcast 192.168.100.255
> inet6 fe80::5054:ff:fe36:ac80 prefixlen 64 scopeid 0x20<link>
> ether 52:54:00:36:ac:80 txqueuelen 1000 (Ethernet)
> RX packets 1966 bytes 122391 (119.5 KiB)
> RX errors 0 dropped 1288 overruns 0 frame 0
> TX packets 552 bytes 99939 (97.5 KiB)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
>
> lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
> inet 127.0.0.1 netmask 255.0.0.0
> inet6 ::1 prefixlen 128 scopeid 0x10<host>
> loop txqueuelen 0 (Local Loopback)
> RX packets 4 bytes 340 (340.0 B)
> RX errors 0 dropped 0 overruns 0 frame 0
> TX packets 4 bytes 340 (340.0 B)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
>
>
>
> (1) Is that a normal behaviour ?
> (2) Could you give me some hints where/how to investigate
>
>
> Here are a number of informations:
>
> - The virsh LAN setup
> - The VM XML description
> - iptables-save on the hosts
> - and then some packages version
>
> Thanks in advance
> Patrick
>
>
>
> My setup is as follow:
>
> An host running a Fedora 23 (minimal) and a VM guest running a Fedora 23
>
> I have created 3 Networks ,
> - 2 fully isolated ( mgt-private-lan and pre-private-lan)
> - 1 Nat via the host NIC
>
> Here after are the information related to the nat Network on which I have consistent
increase of RX Dropped Packets
>
> virsh net-list
> Name State Autostart Persistent
> ----------------------------------------------------------
> mgt-private-lan active yes yes
> nat-internet active yes yes
> prd-private-lan active yes yes
>
>
> virsh net-info nat-internet
> Name: nat-internet
> UUID: 4cff86b1-8e63-40be-ac9c-d3dcd405a9d3
> Active: yes
> Persistent: yes
> Autostart: yes
> Bridge: virbr1
>
>
>
> virsh net-dumpxml nat-internet
> <network connections='5'>
> <name>nat-internet</name>
> <uuid>4cff86b1-8e63-40be-ac9c-d3dcd405a9d3</uuid>
> <forward dev='eth0' mode='nat'>
> <nat>
> <port start='1024' end='65535'/>
> </nat>
> <interface dev='eth0'/>
> </forward>
> <bridge name='virbr1' stp='on' delay='0'/>
> <mac address='52:54:00:e4:ec:1b'/>
> <domain name='nat-internet'/>
> <ip address='192.168.100.1' netmask='255.255.255.0'>
> <dhcp>
> <range start='192.168.100.128' end='192.168.100.254'/>
> </dhcp>
> </ip>
> </network>
>
>
>
>
> here is the XML of the VM
>
>
>
> [root@ks3 boot]# virsh dumpxml Network
> <domain type='kvm' id='5'>
> <name>Network</name>
> <uuid>006ec4e9-028c-4fef-94ec-4e9efbab61ff</uuid>
> <memory unit='KiB'>1048576</memory>
> <currentMemory unit='KiB'>1048576</currentMemory>
> <vcpu placement='static'>1</vcpu>
> <resource>
> <partition>/machine</partition>
> </resource>
> <os>
> <type arch='x86_64'
machine='pc-i440fx-2.4'>hvm</type>
> <kernel>/var/lib/libvirt/boot/vmlinuz</kernel>
> <initrd>/var/lib/libvirt/boot/initramfs.img</initrd>
> <cmdline>root=/dev/vda selinux=0 audit=0 console=ttyS0 nosplash
quiet</cmdline>
> <boot dev='hd'/>
> </os>
> <features>
> <acpi/>
> <apic/>
> </features>
> <cpu mode='custom' match='exact'>
> <model fallback='allow'>SandyBridge</model>
> </cpu>
> <clock offset='utc'>
> <timer name='rtc' tickpolicy='catchup'/>
> <timer name='pit' tickpolicy='delay'/>
> <timer name='hpet' present='no'/>
> </clock>
> <on_poweroff>destroy</on_poweroff>
> <on_reboot>restart</on_reboot>
> <on_crash>restart</on_crash>
> <pm>
> <suspend-to-mem enabled='no'/>
> <suspend-to-disk enabled='no'/>
> </pm>
> <devices>
> <emulator>/usr/bin/qemu-kvm</emulator>
> <disk type='block' device='disk'>
> <driver name='qemu' type='raw' cache='none'
io='native'/>
> <source dev='/dev/vault-storage/network-root'/>
> <backingStore/>
> <target dev='vda' bus='virtio'/>
> <alias name='virtio-disk0'/>
> <address type='pci' domain='0x0000' bus='0x00'
slot='0x08' function='0x0'/>
> </disk>
> <disk type='block' device='disk'>
> <driver name='qemu' type='raw' cache='none'
io='native'/>
> <source dev='/dev/vault-storage/network-bootswap'/>
> <backingStore/>
> <target dev='vdb' bus='virtio'/>
> <alias name='virtio-disk1'/>
> <address type='pci' domain='0x0000' bus='0x00'
slot='0x09' function='0x0'/>
> </disk>
> <controller type='usb' index='0'
model='ich9-ehci1'>
> <alias name='usb'/>
> <address type='pci' domain='0x0000' bus='0x00'
slot='0x07' function='0x7'/>
> </controller>
> <controller type='usb' index='0'
model='ich9-uhci1'>
> <alias name='usb'/>
> <master startport='0'/>
> <address type='pci' domain='0x0000' bus='0x00'
slot='0x07' function='0x0' multifunction='on'/>
> </controller>
> <controller type='usb' index='0'
model='ich9-uhci2'>
> <alias name='usb'/>
> <master startport='2'/>
> <address type='pci' domain='0x0000' bus='0x00'
slot='0x07' function='0x1'/>
> </controller>
> <controller type='usb' index='0'
model='ich9-uhci3'>
> <alias name='usb'/>
> <master startport='4'/>
> <address type='pci' domain='0x0000' bus='0x00'
slot='0x07' function='0x2'/>
> </controller>
> <controller type='pci' index='0' model='pci-root'>
> <alias name='pci.0'/>
> </controller>
> <controller type='virtio-serial' index='0'>
> <alias name='virtio-serial0'/>
> <address type='pci' domain='0x0000' bus='0x00'
slot='0x06' function='0x0'/>
> </controller>
> <interface type='network'>
> <mac address='52:54:00:36:ac:80'/>
> <source network='nat-internet' bridge='virbr1'/>
> <target dev='vnet12'/>
> <model type='virtio'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x03' function='0x0'/>
</interface>
> <serial type='pty'>
> <source path='/dev/pts/5'/>
> <target port='0'/>
> <alias name='serial0'/>
> </serial>
> <console type='pty' tty='/dev/pts/5'>
> <source path='/dev/pts/5'/>
> <target type='serial' port='0'/>
> <alias name='serial0'/>
> </console>
> <channel type='unix'>
> <source mode='bind'
path='/var/lib/libvirt/qemu/channel/target/Network.org.qemu.guest_agent.0'/>
> <target type='virtio' name='org.qemu.guest_agent.0'
state='connected'/>
> <alias name='channel0'/>
> <address type='virtio-serial' controller='0' bus='0'
port='1'/>
> </channel>
> <input type='mouse' bus='ps2'/>
> <input type='keyboard' bus='ps2'/>
> <graphics type='spice' port='5904' autoport='yes'
listen='127.0.0.1'>
> <listen type='address' address='127.0.0.1'/>
> </graphics>
> <video>
> <model type='cirrus' vram='16384' heads='1'/>
> <alias name='video0'/>
> <address type='pci' domain='0x0000' bus='0x00'
slot='0x02' function='0x0'/>
> </video>
> <memballoon model='virtio'>
> <alias name='balloon0'/>
> <address type='pci' domain='0x0000' bus='0x00'
slot='0x0a' function='0x0'/>
> </memballoon>
> </devices>
> </domain>
>
>
> iptables-save
> # Generated by iptables-save v1.4.21 on Sat Jan 23 10:49:51 2016
> *nat
> :PREROUTING ACCEPT [14895:623423]
> :INPUT ACCEPT [12645:432591]
> :OUTPUT ACCEPT [123:8518]
> :POSTROUTING ACCEPT [595:37490]
> -A PREROUTING -d 151.80.45.157/32 -p tcp -m tcp --dport 6514 -j DNAT --to-destination
192.168.100.10:6514
> -A PREROUTING -d 151.80.45.157/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination
192.168.100.12:80
> -A PREROUTING -d 151.80.45.157/32 -p tcp -m tcp --dport 443 -j DNAT --to-destination
192.168.100.12:443
> -A POSTROUTING -s 192.168.100.0/24 -d 224.0.0.0/24 -o eth0 -j RETURN
> -A POSTROUTING -s 192.168.100.0/24 -d 255.255.255.255/32 -o eth0 -j RETURN
> -A POSTROUTING -s 192.168.100.0/24 ! -d 192.168.100.0/24 -o eth0 -p tcp -j MASQUERADE
--to-ports 1024-65535
> -A POSTROUTING -s 192.168.100.0/24 ! -d 192.168.100.0/24 -o eth0 -p udp -j MASQUERADE
--to-ports 1024-65535
> -A POSTROUTING -s 192.168.100.0/24 ! -d 192.168.100.0/24 -o eth0 -j MASQUERADE
> COMMIT
> # Completed on Sat Jan 23 10:49:51 2016
> # Generated by iptables-save v1.4.21 on Sat Jan 23 10:49:51 2016
> *mangle
> :PREROUTING ACCEPT [1212763:799851388]
> :INPUT ACCEPT [169753:18403044]
> :FORWARD ACCEPT [1043010:781448344]
> :OUTPUT ACCEPT [123913:208199933]
> :POSTROUTING ACCEPT [1166923:989648277]
> -A POSTROUTING -o virbr1 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
> -A POSTROUTING -o virbr3 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
> -A POSTROUTING -o virbr2 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
> COMMIT
> # Completed on Sat Jan 23 10:49:51 2016
> # Generated by iptables-save v1.4.21 on Sat Jan 23 10:49:51 2016
> *filter
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [120960:207745702]
> -A INPUT -i virbr1 -p udp -m udp --dport 53 -j ACCEPT
> -A INPUT -i virbr1 -p tcp -m tcp --dport 53 -j ACCEPT
> -A INPUT -i virbr1 -p udp -m udp --dport 67 -j ACCEPT
> -A INPUT -i virbr1 -p tcp -m tcp --dport 67 -j ACCEPT
> -A INPUT -i virbr3 -p udp -m udp --dport 53 -j ACCEPT
> -A INPUT -i virbr3 -p tcp -m tcp --dport 53 -j ACCEPT
> -A INPUT -i virbr3 -p udp -m udp --dport 67 -j ACCEPT
> -A INPUT -i virbr3 -p tcp -m tcp --dport 67 -j ACCEPT
> -A INPUT -i virbr2 -p udp -m udp --dport 53 -j ACCEPT
> -A INPUT -i virbr2 -p tcp -m tcp --dport 53 -j ACCEPT
> -A INPUT -i virbr2 -p udp -m udp --dport 67 -j ACCEPT
> -A INPUT -i virbr2 -p tcp -m tcp --dport 67 -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 80 -m string --string "GET /w00tw00t.at.ISC
.SANS." --algo bm --to 70 -j DROP
> -A INPUT -m set --match-set banned src -j DROP
> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -p icmp -j ACCEPT
> -A INPUT -i lo -j ACCEPT
> -A INPUT -p tcp -m state --state NEW -m tcp --dport 23 -j ACCEPT
> -A INPUT -j REJECT --reject-with icmp-host-prohibited
> -A FORWARD -d 192.168.100.12/32 -p tcp -m state --state NEW -m tcp --dport 443 -j
ACCEPT
> -A FORWARD -d 192.168.100.12/32 -p tcp -m state --state NEW -m tcp --dport 80 -j
ACCEPT
> -A FORWARD -d 192.168.100.10/32 -p tcp -m state --state NEW -m tcp --dport 6514 -j
ACCEPT
> -A FORWARD -d 192.168.100.0/24 -i eth0 -o virbr1 -m conntrack --ctstate
RELATED,ESTABLISHED -j ACCEPT
> -A FORWARD -s 192.168.100.0/24 -i virbr1 -o eth0 -j ACCEPT
> -A FORWARD -i virbr1 -o virbr1 -j ACCEPT
> -A FORWARD -o virbr1 -j REJECT --reject-with icmp-port-unreachable
> -A FORWARD -i virbr1 -j REJECT --reject-with icmp-port-unreachable
> -A FORWARD -i virbr3 -o virbr3 -j ACCEPT
> -A FORWARD -o virbr3 -j REJECT --reject-with icmp-port-unreachable
> -A FORWARD -i virbr3 -j REJECT --reject-with icmp-port-unreachable
> -A FORWARD -i virbr2 -o virbr2 -j ACCEPT
> -A FORWARD -o virbr2 -j REJECT --reject-with icmp-port-unreachable
> -A FORWARD -i virbr2 -j REJECT --reject-with icmp-port-unreachable
> -A FORWARD -m set --match-set banned src -j DROP
> -A FORWARD -j REJECT --reject-with icmp-host-prohibited
> -A OUTPUT -o virbr1 -p udp -m udp --dport 68 -j ACCEPT
> -A OUTPUT -o virbr3 -p udp -m udp --dport 68 -j ACCEPT
> -A OUTPUT -o virbr2 -p udp -m udp --dport 68 -j ACCEPT
> COMMIT
> # Completed on Sat Jan 23 10:49:51 2016
>
>
>
> rpm -qa | grep libvirt
> libvirt-daemon-driver-nodedev-1.2.18.2-1.fc23.x86_64
> libvirt-daemon-driver-storage-1.2.18.2-1.fc23.x86_64
> libvirt-daemon-config-network-1.2.18.2-1.fc23.x86_64
> libvirt-daemon-1.2.18.2-1.fc23.x86_64
> libvirt-daemon-driver-secret-1.2.18.2-1.fc23.x86_64
> libvirt-daemon-driver-network-1.2.18.2-1.fc23.x86_64
> libvirt-daemon-driver-nwfilter-1.2.18.2-1.fc23.x86_64
> libvirt-daemon-driver-qemu-1.2.18.2-1.fc23.x86_64
> libvirt-daemon-kvm-1.2.18.2-1.fc23.x86_64
> libvirt-client-1.2.18.2-1.fc23.x86_64
> libvirt-daemon-driver-interface-1.2.18.2-1.fc23.x86_64
>
>
>
> rpm -qa | grep qemu
> qemu-common-2.4.1-5.fc23.x86_64
> qemu-kvm-2.4.1-5.fc23.x86_64
> qemu-img-2.4.1-5.fc23.x86_64
> ipxe-roms-qemu-20150407-3.gitdc795b9f.fc23.noarch
> libvirt-daemon-driver-qemu-1.2.18.2-1.fc23.x86_64
> qemu-system-x86-2.4.1-5.fc23.x86_64
>
>
> rpm -qa | grep kvm
> qemu-kvm-2.4.1-5.fc23.x86_64
> libvirt-daemon-kvm-1.2.18.2-1.fc23.x86_64
>
>
1:51 p.m.
pichon wrote:
Hello,
pichon wrote:
On each of my guests VM, I see constantly a RX dropped number
increasing
, Even if the VM does nothing !
I'm seeing the same phenomenon on one of our LANs (on another LAN, I
don't see it). My setup is with RHEL 7, and it is seen on both physical
and virtual servers. I don't see it on any RHEL 5 or 6 servers.
A strange observation: If I start tcpdump, the package drops stop.
(Setting the NIC in promisc mode does not have any impact; it has to be
tcpdump.)
I suspect that it has to do with this:
https://www.netiq.com/support/kb/doc.php?id=7007165
If this is the case, it's simply because recent kernels classify packets,
and then there's nothing to worry about.
- But Red Hat Support does not share that view. I have an open case with
Red Hat Support about it; lots of stuff has been tried, but we have yet
to reach a conclusion.
--
Troels
2:52 p.m.
Hello,
I’m using the Fedora 23 disturb, with recent kernel on all of my systems ( VMs and
Physicals), I see the rx packet dropped only on VMs when I disable the virtio-net driver ,
by adding driver name=‘emu’ in the XML.
But indeed if I started the tcpdump, the dropped stopped.
Patrick
On 26 Jan 2016, at 20:51, Troels Arvin <troels(a)arvin.dk>
wrote:
pichon wrote:
Hello,
pichon wrote:
> On each of my guests VM, I see constantly a RX dropped number increasing
> , Even if the VM does nothing !
I'm seeing the same phenomenon on one of our LANs (on another LAN, I
don't see it). My setup is with RHEL 7, and it is seen on both physical
and virtual servers. I don't see it on any RHEL 5 or 6 servers.
A strange observation: If I start tcpdump, the package drops stop.
(Setting the NIC in promisc mode does not have any impact; it has to be
tcpdump.)
I suspect that it has to do with this:
https://www.netiq.com/support/kb/doc.php?id=7007165
If this is the case, it's simply because recent kernels classify packets,
and then there's nothing to worry about.
- But Red Hat Support does not share that view. I have an open case with
Red Hat Support about it; lots of stuff has been tried, but we have yet
to reach a conclusion.
--
Troels
_______________________________________________
libvirt-users mailing list
libvirt-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users
3 p.m.
Hello,
For me it makes sense that the dropped stop when you are using tcpdump as you are indeed
takes those packets !
For me the main question, is why such traffic is going to the VM ?
Kind regards
Patrick
On 26 Jan 2016, at 20:51, Troels Arvin <troels(a)arvin.dk>
wrote:
pichon wrote:
Hello,
pichon wrote:
> On each of my guests VM, I see constantly a RX dropped number increasing
> , Even if the VM does nothing !
I'm seeing the same phenomenon on one of our LANs (on another LAN, I
don't see it). My setup is with RHEL 7, and it is seen on both physical
and virtual servers. I don't see it on any RHEL 5 or 6 servers.
A strange observation: If I start tcpdump, the package drops stop.
(Setting the NIC in promisc mode does not have any impact; it has to be
tcpdump.)
I suspect that it has to do with this:
https://www.netiq.com/support/kb/doc.php?id=7007165
If this is the case, it's simply because recent kernels classify packets,
and then there's nothing to worry about.
- But Red Hat Support does not share that view. I have an open case with
Red Hat Support about it; lots of stuff has been tried, but we have yet
to reach a conclusion.
--
Troels
_______________________________________________
libvirt-users mailing list
libvirt-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users
4:17 p.m.
Arvin,
Thanks a lot for pointing tcpdump.
What I have observe is that the packets which seems to be dropped are STP related
[root@network ~]# tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
23:15:37.967118 STP 802.1d, Config, Flags [none], bridge-id 8000.52:54:00:e4:ec:1b.8003,
length 35
23:15:39.967163 STP 802.1d, Config, Flags [none], bridge-id 8000.52:54:00:e4:ec:1b.8003,
length 35
23:15:41.967121 STP 802.1d, Config, Flags [none], bridge-id 8000.52:54:00:e4:ec:1b.8003,
length 35
23:15:43.967147 STP 802.1d, Config, Flags [none], bridge-id 8000.52:54:00:e4:ec:1b.8003,
length 35
23:15:45.967118 STP 802.1d, Config, Flags [none], bridge-id 8000.52:54:00:e4:ec:1b.8003,
length 35
23:15:47.967156 STP 802.1d, Config, Flags [none], bridge-id 8000.52:54:00:e4:ec:1b.8003,
length 35
23:15:49.967131 STP 802.1d, Config, Flags [none], bridge-id 8000.52:54:00:e4:ec:1b.8003,
length 35
23:15:51.967132 STP 802.1d, Config, Flags [none], bridge-id 8000.52:54:00:e4:ec:1b.8003,
length 35
23:15:53.967195 STP 802.1d, Config, Flags [none], bridge-id 8000.52:54:00:e4:ec:1b.8003,
length 35
23:15:55.967138 STP 802.1d, Config, Flags [none], bridge-id 8000.52:54:00:e4:ec:1b.8003,
length 35
23:15:57.967165 STP 802.1d, Config, Flags [none], bridge-id 8000.52:54:00:e4:ec:1b.8003,
length 35
Now, my main issue is that I observe those packets also in the disabled virtio-net driver
(with driver name=qemu), but in that case, no packets are dropped
So is that a different behaviour of the bvirtio-net when it is in Kernel mode and when it
is in User space ?
Patrick
On 26 Jan 2016, at 20:51, Troels Arvin <troels(a)arvin.dk>
wrote:
pichon wrote:
Hello,
pichon wrote:
> On each of my guests VM, I see constantly a RX dropped number increasing
> , Even if the VM does nothing !
I'm seeing the same phenomenon on one of our LANs (on another LAN, I
don't see it). My setup is with RHEL 7, and it is seen on both physical
and virtual servers. I don't see it on any RHEL 5 or 6 servers.
A strange observation: If I start tcpdump, the package drops stop.
(Setting the NIC in promisc mode does not have any impact; it has to be
tcpdump.)
I suspect that it has to do with this:
https://www.netiq.com/support/kb/doc.php?id=7007165
If this is the case, it's simply because recent kernels classify packets,
and then there's nothing to worry about.
- But Red Hat Support does not share that view. I have an open case with
Red Hat Support about it; lots of stuff has been tried, but we have yet
to reach a conclusion.
--
Troels
_______________________________________________
libvirt-users mailing list
libvirt-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users
3223
days inactive
3226
days old
5 comments
2 participants
participants (2)
-
pichon -
Troels Arvin