[ovs-discuss] Missing Flows

ananthan ananthannair935 at gmail.com
Thu Oct 17 12:35:22 UTC 2013


Thanks Reid,
I forgot to mention that its an openstack deployment.
Its the openstack agent that created custom flows but failed to create for
the other interface resulting in traffic drop.
Fixed by generating custom flows for other interface also.



On Wed, Oct 16, 2013 at 6:36 AM, Reid Price <rprice at nicira.com> wrote:

> A few quick comments:
>
> 1) You say there are no custom flows, but your ofctl dump flows
> show custom flows.  In particular, I see 'drop' flows on both that
> appear to have been used in the last second before you dumped.
>
> 2) A common misconception is that tcpdump <bridgename> is
> dumping traffic on 'the bridge' in some sense.  That is - that every
> packet which enters through any port would appear.  This is not
> the case.  tcpdump works on interfaces, not bridges.  There *is*
> a guaranteed 'internal' interface for each bridge that has the same
> name as that bridge, and in the absence of other flows, the NORMAL
> action would usually allow you to see broadcast traffic (such as
> when learning unicast or receiving broadcast and handling with the
> NORMAL action), as well as traffic destined for the internal port, if it
> was assigned an IP.  In the case of actions that do not include the
> internal port, you will not see any traffic when tcpdumping.
>
> Hope that helps to clarify your question a little, didn't read through
> all of the details to map ports.
>
> Also, take a look at
>
>
> http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=FAQ;hb=HEAD
>
> Under heading
>
> Q: I have a sophisticated network setup involving Open vSwitch, VMs or
>    multiple hosts, and other components.  The behavior isn't what I
>    expect.  Help!
>
> try some of the debugging tips there and include the output.  It
> looked like your traffic would be dropped if you didn't have a VLAN.
>
>   -Reid
>
>
> On Tue, Oct 15, 2013 at 1:08 PM, ananthan <ananthannair935 at gmail.com>wrote:
>
>> *I have vm connected to linux bridge which  is then connected to ovs
>> bridge using veth pairs *qvocb9f0e52-99(ovs end) and qvbcb9f0e52-99
>> (native bridge end)
>> *
>> *
>> qvocb9f0e52-99 is then connected to br-int .*
>> *
>> br-int has one of the veth pair connected ie int-br-eth0 and other end
>> phy-br-eth0 to br-eth0 on which physical nic eth0 is connected.
>>
>>
>> When i make ping request from vm, through tcpdump i can see ARP Request
>> reaching till phy-br-eth0,but not on br-eth0 on which eth0 is bridged.
>> What could be the reason for ARP request not reaching bridge but reached
>> one of its port.There is no custom flows nor controller.
>>
>>
>> *ovs-vsctl show *
>> *
>> *
>> 214b7f68-53cb-46fb-bf23-f5a07a94918e
>>     Bridge br-int
>>         Port br-int
>>             Interface br-int
>>                 type: internal
>>         Port "qvocb9f0e52-99"
>>             tag: 2
>>             Interface "qvocb9f0e52-99"
>>            Port "tapd488bc55-0a"
>>             tag: 1
>>             Interface "tapd488bc55-0a"
>>                 type: internal
>>         Port "int-br-eth0"
>>             Interface "int-br-eth0"
>>         Port "int-br-eth1"
>>             Interface "int-br-eth1"
>>     Bridge "br-eth0"
>>         Port "eth0"
>>             Interface "eth0"
>>         Port "br-eth0"
>>             Interface "br-eth0"
>>                 type: internal
>>         Port "phy-br-eth0"
>>             Interface "phy-br-eth0"
>>
>>     ovs_version: "1.11.0
>>
>> *brctl show*
>> bridge name bridge id STP enabled interfaces
>> qbrcb9f0e52-99 8000.56479287f11a no qvbcb9f0e52-99
>>   tapcb9f0e52-99
>>
>>    1. *ovs-ofctl show br-int*
>>    2.
>>    3. OFPT_FEATURES_REPLY (xid=0x2): dpid:00006e733518ec4f
>>    4. n_tables:254, n_buffers:256
>>    5. capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS
>>    ARP_MATCH_IP
>>    6. actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC
>>    SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE
>>    7.  1(patch-tun): addr:c2:aa:e7:8a:de:16
>>    8.      config:     0
>>    9.      state:      0
>>    10.      speed: 0 Mbps now, 0 Mbps max
>>    11.  28(int-br-eth0): addr:02:a6:29:7d:32:5b
>>    12.      config:     0
>>    13.      state:      0
>>    14.      current:    10GB-FD COPPER
>>    15.      speed: 10000 Mbps now, 0 Mbps max
>>    16.
>>    17.  85(qvocb9f0e52-99): addr:f2:0e:47:69:c1:9c
>>    18.      config:     0
>>    19.      state:      0
>>    20.      current:    10GB-FD COPPER
>>    21.      speed: 10000 Mbps now, 0 Mbps max
>>    22.  88(int-br-eth1): addr:d2:c0:59:af:ec:6e
>>    23.      config:     0
>>    24.      state:      0
>>    25.      current:    10GB-FD COPPER
>>    26.      speed: 10000 Mbps now, 0 Mbps max
>>    27.  89(qvo2274f90e-c0): addr:ba:83:ad:81:16:b9
>>    28.      config:     0
>>    29.      state:      0
>>    30.      current:    10GB-FD COPPER
>>    31.      speed: 10000 Mbps now, 0 Mbps max
>>    32.  LOCAL(br-int): addr:6e:73:35:18:ec:4f
>>    33.      config:     0
>>    34.      state:      0
>>    35.      speed: 0 Mbps now, 0 Mbps max
>>    36. OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
>>
>>
>>    1. *ovs-ofctl dump-flows br-int*
>>       2.
>>       3. NXST_FLOW reply (xid=0x4):
>>       4.  cookie=0x0, duration=1617.947s, table=0, n_packets=11,
>>       n_bytes=2219, idle_age=1613, priority=2,in_port=88 actions=drop
>>       5.  cookie=0x0, duration=1621.55s, table=0, n_packets=4843,
>>       n_bytes=413077, idle_age=0, priority=1 actions=NORMAL
>>       6.  cookie=0x0, duration=1612.579s, table=0, n_packets=249,
>>       n_bytes=28580, idle_age=1, priority=3,in_port=88,vlan_tci=0x0000
>>       actions=mod_vlan_vid:1,NORMAL
>>
>>
>>
>>
>>    1. *ovs-ofctl show br-eth0*
>>    2. OFPT_FEATURES_REPLY (xid=0x2): dpid:000000219ba58aee
>>    3. n_tables:254, n_buffers:256
>>    4. capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS
>>    ARP_MATCH_IP
>>    5. actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC
>>    SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE
>>    6.  1(eth0): addr:00:21:9b:a5:8a:ee
>>    7.      config:     0
>>    8.      state:      0
>>    9.      current:    1GB-FD COPPER AUTO_NEG
>>    10.      advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD AUTO_NEG
>>    11.      supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER
>>    AUTO_NEG
>>    12.      speed: 1000 Mbps now, 1000 Mbps max
>>    13.  6(phy-br-eth0): addr:a2:ff:84:a3:d4:b7
>>    14.      config:     0
>>    15.      state:      0
>>    16.      current:    10GB-FD COPPER
>>    17.      speed: 10000 Mbps now, 0 Mbps max
>>    18.  LOCAL(br-eth0): addr:00:21:9b:a5:8a:ee
>>    19.      config:     0
>>    20.      state:      0
>>    21.      speed: 0 Mbps now, 0 Mbps max
>>    22. OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
>>
>>
>>    1. *ovs-ofctl dump-flows br-eth0*
>>       *
>>          1. NXST_FLOW reply (xid=0x4):
>>          2.  cookie=0x0, duration=256807.136s, table=0, n_packets=44085,
>>          n_bytes=5893825, idle_age=25758, hard_age=65534,
>>          priority=4,in_port=6,dl_vlan=3 actions=strip_vlan,NORMAL
>>          3.  cookie=0x0, duration=261909.4s, table=0, n_packets=22333,
>>          n_bytes=1932266, idle_age=1, hard_age=65534, priority=2,in_port=6
>>          actions=drop
>>          4.  cookie=0x0, duration=261913.987s, table=0,
>>          n_packets=4103801, n_bytes=436190650, idle_age=0, hard_age=65534,
>>          priority=1 actions=NORMAL
>>
>>          Any idea why ARP request can not reach br-eth0
>>
>>
>>          *
>>
>>
>> _______________________________________________
>> discuss mailing list
>> discuss at openvswitch.org
>> http://openvswitch.org/mailman/listinfo/discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20131017/38c51aec/attachment.html>


More information about the discuss mailing list