https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/OVSDB-13 ovsdb <p>The Neutron OF 1.3 provider sets the max length for LLDP packets to 56 bytes <span class="error">&#91;1&#93;</span>. This results in truncated LLDP packets in OF packet-in messages. As a result LLDPDiscovery will be unable to parse the packets completely (out of bounds exception), and will drop them.</p> <p><span class="error">&#91;1&#93;</span> <a href="https://git.opendaylight.org/gerrit/gitweb?p=ovsdb.git;a=blob;f=neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF13ProviderManager.java;h=1f864e0d78b84208172c32f7fdadb54c1e6b3605;hb=HEAD#l1853" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/gitweb?p=ovsdb.git;a=blob;f=neutron/src/main/java/org/opendaylight/ovsdb/neutron/provider/OF13ProviderManager.java;h=1f864e0d78b84208172c32f7fdadb54c1e6b3605;hb=HEAD#l1853</a></p> <p>Operating System: All<br/> Platform: All</p> OVSDB-13

Neutron OF1.3 provider truncates LLDP packets

Bug Resolved Done Unassigned Zoltan Lajos Kis Tue, 6 May 2014 13:34:17 +0000 Thu, 3 May 2018 15:29:56 +0000 Sun, 18 May 2014 15:59:25 +0000 unspecified API 0 2 <p>For reference, here is an LLDP message I'm seeing, so I guess the default miss-send-len of 128 "ought to be enough for anybody":</p> <p>LLDP, length 93: openflow:112670452143181</p> <p>0x0000: 0180 c200 000e 6679 2246 d44d 88cc 0207 ......fy"F.M....<br/> 0x0010: 0466 7922 46d4 4d04 0907 6666 6666 6666 .fy"F.M...ffffff<br/> 0x0020: 6665 0602 0078 0a18 6f70 656e 666c 6f77 fe...x..openflow<br/> 0x0030: 3a31 3132 3637 3034 3532 3134 3331 3831 :112670452143181<br/> 0x0040: fe27 0026 e100 6f70 656e 666c 6f77 3a31 .'.&amp;..openflow:1<br/> 0x0050: 3132 3637 3034 3532 3134 3331 3831 3a34 12670452143181:4<br/> 0x0060: 3239 3439 3637 3239 3400 00</p> <p>Resolved with patch as soon as it merges <a href="https://git.opendaylight.org/gerrit/7144" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/7144</a></p> <p>Here is the datapath output after adjusting the length to 5bytes.<br/> &#8212;<br/> 2014-05-17T22:37:56.146Z|01262|vconn|DBG|tcp:172.16.86.1:6633: received: OFPST_FLOW request (OF1.3) (xid=0x1): table=0 dl_type=0x88cc<br/> 2014-05-17T22:37:56.146Z|01263|vconn|DBG|tcp:172.16.86.1:6633: sent (Success): OFPST_FLOW reply (OF1.3) (xid=0x1):<br/> 2014-05-17T22:37:56.146Z|01264|vconn|DBG|tcp:172.16.86.1:6633: received: OFPST_FLOW request (OF1.3) (xid=0x5): <br/> 2014-05-17T22:37:56.146Z|01265|vconn|DBG|tcp:172.16.86.1:6633: sent (Success): OFPST_FLOW reply (OF1.3) (xid=0x5):<br/> 2014-05-17T22:37:56.146Z|01266|vconn|DBG|tcp:172.16.86.1:6633: received: OFPT_FLOW_MOD (OF1.3) (xid=0x4): ADD dl_type=0x88cc send_flow_rem actions=CONTROLLER:5<br/> 2014-05-17T22:37:56.147Z|01267|poll_loop|DBG|wakeup due to 0-ms timeout at ofproto/ofproto-dpif.c:1595 (0% CPU usage)<br/> 2014-05-17T22:37:56.246Z|01268|poll_loop|DBG|wakeup due to 99-ms timeout at vswitchd/bridge.c:2289 (0% CPU usage)<br/> 2014-05-17T22:37:56.471Z|01269|poll_loop|DBG|wakeup due to 225-ms timeout at ofproto/in-band.c:410 (0% CPU usage)<br/> 2014-05-17T22:37:56.597Z|01270|poll_loop|DBG|wakeup due to 126-ms timeout at ofproto/ofproto-dpif.c:1057 (0% CPU usage)<br/> 2014-05-17T22:37:56.597Z|01271|netlink_socket|DBG|nl_sock_send__ (Success): nl(len:24, type=28(ovs_flow), flags=305<span class="error">&#91;REQUEST&#93;</span><span class="error">&#91;ACK&#93;</span><span class="error">&#91;DUMP&#93;</span>, seq=d6, pid=15344,genl(cmd=3,version=1)<br/> 2014-05-17T22:37:56.597Z|01272|dpif|DBG|system@ovs-system: flow_dump_start success<br/> 2014-05-17T22:37:56.597Z|01273|netlink_socket|DBG|nl_sock_recv__ (Success): nl(len:20, type=3(done), flags=2<span class="error">&#91;MULTI&#93;</span>, seq=d6, pid=15344 done(0)</p> <p>Thanks for reporting this Zoltan,<br/> -Brent</p> <p>I'm not sure I get this. The max_length should be increased; or even set to 0xffff, as there is no point in buffering the LLDP packets anyway.</p> <p>By setting max_length to five you only get the first five bytes of the packet.</p> <p>Yeah you're right, i was misreading the spec. I deleted the whole line and set the buffer to 0. Feel free to patch or add a specific method with a buffer if you need payload.<br/> Later,<br/> -Brent</p> <p>I thought it was topology discovery that needed the body of LLDP messages - to correlate ports for the topology.</p> <p>If there is no need for that, what's the point of this flow entry at all?</p> Development External issue ID 958 External issue URL Rank 0|i0203z: