[ovs-discuss] packet loss in RSPAN trafic

Philippe Gautier p.gautier.philippe at gmail.com
Mon Feb 2 23:51:00 UTC 2015


It seems to be a MTU issue. Only tcp segments which lenght equal to 1484
are dropped (gre packet are 1484 + 38 = 1522)

I tried to increase MTU with no success.

ip link set eth0 mtu 1535

ip l show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1535 qdisc pfifo_fast master
ovs-system state UP mode DEFAULT group default qlen 1000
    link/ether 54:04:a6:76:0b:cf brd ff:ff:ff:ff:ff:ff

What is the correct procedure to set up MTU ?

2015-02-03 0:08 GMT+01:00 Philippe Gautier <p.gautier.philippe at gmail.com>:

>  ip neigh show
> 192.168.42.151 dev br0 lladdr c0:3f:d5:60:3c:67 PERMANENT
> 192.168.42.2 dev br0 lladdr 7c:03:d8:81:2a:94 PERMANENT
>
> Same observations with static arp entries. I tried to export traffic to
> different ip address. I do not think it is related to arp table because my
> gateway is 192.168.42.2. If gre traffic was dropped because of arp latency
> real should have also be dropped ...
>
>
>
> 2015-02-01 22:46 GMT+01:00 Ben Pfaff <blp at nicira.com>:
>
>> On Sat, Jan 31, 2015 at 03:41:13PM +0100, Philippe Gautier wrote:
>> > I detect packet loss when I analyse GRE traffic sended by RSPAN. Is
>> there a
>> > default sampling parameter when configuring port mirroring ?
>>
>> No, mirroring should copy all packets.
>>
>> > Test platform and scenario:
>> >
>> > Two KVM virtual hosts (port internet2, internet3) hosted on a physical
>> host
>> > (port br0 and eth0). Trafic is sended through the gre interface to a
>> remote
>> > host. The gre trafic is sended through eth0 physical interface.
>> >
>> > When I generate a trafic between a vm and an internet host (In my case
>> > google server) I capture real and RSPAN trafic on eth0 interface.
>>
>> It looks like the first packet is getting mirrored but a number of
>> packets after that are getting dropped, and that then after some time
>> the mirroring picks up again.  I wonder whether this is caused by ARP.
>> I believe that one valid way to do ARP is to queue the first packet to a
>> destination while waiting for an ARP response but drop later packets to
>> that destination until the ARP response arrives.  That would explain
>> this behavior.  So: does it help to add a static ARP entry for your
>> tunnel destination?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20150203/9195a442/attachment-0002.html>


More information about the discuss mailing list