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-268 ovsdb <p>When using Openstack and 3 node ODL cluster, with one ODL to handle neutron requests and the other two members as Managers in the OVS of Openstack. There were repeated warning messages in karf.log of one of the nodes</p> <p>ogress.<br/> 2016-01-20 19:28:49,585 | WARN | pool-32-thread-1 | LLDPDiscoveryUtils | 271 - org.opendaylight.openflowplugin.applications.topology-lldp-discovery - 0.2.0.SNAPSHOT | SECURITY ALERT: there is probably a LLDP spoofing attack in progress.<br/> 2016-01-20 19:28:54,582 | WARN | pool-32-thread-1 | LLDPDiscoveryUtils | 271 - org.opendaylight.openflowplugin.applications.topology-lldp-discovery - 0.2.0.SNAPSHOT | SECURITY ALERT: there is probably a LLDP spoofing attack in progress.<br/> 2016-01-20 19:28:54,592 | WARN | pool-32-thread-1 | LLDPDiscoveryUtils | 271 - org.opendaylight.openflowplugin.applications.topology-lldp-discovery - 0.2.0.SNAPSHOT | SECURITY ALERT: there is probably a LLDP spoofing attack in progress.<br/> 2016-01-20 19:28:59,583 | WARN | pool-32-thread-1 | LLDPDiscoveryUtils | 271 - org.opendaylight.openflowplugin.applications.topology-lldp-discovery - 0.2.0.SNAPSHOT | SECURITY ALERT: there is probably a LLDP spoofing attack in progress.<br/> 2016-01-20 19:28:59,584 | WARN | pool-32-thread-1 | LLDPDiscoveryUtils | 271 - org.opendaylight.openflowplugin.applications.topology-lldp-discovery - 0.2.0.SNAPSHOT | SECURITY ALERT: there is probably a LLDP spoofing attack in progress.</p> <p>Operating System: All<br/> Platform: All</p> OVSDB-268

LLDP Spoofing attack warning when using Openstack with ODL Cluster (both features)

Bug Resolved Done Anil Vishnoi Venkatrangan Govindarajan Thu, 21 Jan 2016 00:44:32 +0000 Thu, 11 Feb 2016 03:24:56 +0000 Thu, 11 Feb 2016 03:24:56 +0000 unspecified openstack.net-virt 0 2 <p>Used stable/beryllium code</p> <p>Anil, any idea what this lldp spoofing warning is? Is this a new feature?</p> <p>Sam,<br/> I think there was a security vulnerability fix related to LLDP spoofing went in openflowplugin (a while back) and that fix is probably determining that LLDP spoof is happening. </p> <p>Venkat, i never seen it in my environment, can you dump the rules on the OVS switches and see if there is drop rule installed or not.</p> <p>venkat, i tried this locally with the same setup as yours and i am not seeing this issue. Can you please dump the output of "ovs-vsctl show" on all the nodes + flows installed on all the bridges on these nodes.</p> <p>Anil,<br/> Reted today also with the below setup</p> <p> ODL1 -&gt; Neutron Requests<br/> ODL2/ODL3 for handling the OVS/Openflow</p> <p> Still only ODL3 has the warning.</p> <p>ovs-vsctl show </p> <p>control node:<br/> ubuntu@odl-os-control-node:~/devstack$ sudo ovs-vsctl show<br/> 7379aa64-0416-45e2-9531-351397cc742a<br/> Manager "tcp:11.12.13.5:6640"<br/> is_connected: true<br/> Manager "tcp:11.12.13.4:6640"<br/> is_connected: true<br/> Bridge br-ex<br/> Controller "tcp:11.12.13.5:6653"<br/> is_connected: true<br/> Controller "tcp:11.12.13.4:6653"<br/> is_connected: true<br/> fail_mode: secure<br/> Port br-ex<br/> Interface br-ex<br/> type: internal<br/> Port "eth2"<br/> Interface "eth2"<br/> Port patch-int<br/> Interface patch-int<br/> type: patch<br/> options: </p> {peer=patch-ext}<br/> Bridge br-int<br/> Controller "tcp:11.12.13.5:6653"<br/> is_connected: true<br/> Controller "tcp:11.12.13.4:6653"<br/> is_connected: true<br/> fail_mode: secure<br/> Port "vxlan-12.14.16.3"<br/> Interface "vxlan-12.14.16.3"<br/> type: vxlan<br/> options: {key=flow, local_ip="12.14.16.2", remote_ip="12.14.16.3"}<br/> Port "tap1b35eb29-c3"<br/> Interface "tap1b35eb29-c3"<br/> Port br-int<br/> Interface br-int<br/> type: internal<br/> Port "tapc741c740-b3"<br/> Interface "tapc741c740-b3"<br/> Port "tap92b1f549-b3"<br/> Interface "tap92b1f549-b3"<br/> type: internal<br/> Port patch-ext<br/> Interface patch-ext<br/> type: patch<br/> options: {peer=patch-int}<br/> Port "tapf58200cd-00"<br/> Interface "tapf58200cd-00"<br/> type: internal<br/> ovs_version: "2.3.2"<br/> <br/> <br/> compute node:<br/> ubuntu@odl-os-compute-node:~/devstack$ sudo ovs-vsctl show<br/> bf460c25-5849-4874-9758-4fcbafbf9f5e<br/> Manager "tcp:11.12.13.5:6640"<br/> is_connected: true<br/> Manager "tcp:11.12.13.4:6640"<br/> is_connected: true<br/> Bridge br-ex<br/> Controller "tcp:11.12.13.5:6653"<br/> is_connected: true<br/> Controller "tcp:11.12.13.4:6653"<br/> is_connected: true<br/> fail_mode: secure<br/> Port "eth2"<br/> Interface "eth2"<br/> Port br-ex<br/> Interface br-ex<br/> type: internal<br/> Port patch-int<br/> Interface patch-int<br/> type: patch<br/> options: {peer=patch-ext} <p> Bridge br-int<br/> Controller "tcp:11.12.13.4:6653"<br/> is_connected: true<br/> Controller "tcp:11.12.13.5:6653"<br/> is_connected: true<br/> fail_mode: secure<br/> Port br-int<br/> Interface br-int<br/> type: internal<br/> Port "tapfe0a3251-16"<br/> Interface "tapfe0a3251-16"<br/> Port patch-ext<br/> Interface patch-ext<br/> type: patch<br/> options: </p> {peer=patch-int} <p> Port "tap547166bc-d8"<br/> Interface "tap547166bc-d8"<br/> Port "vxlan-12.14.16.2"<br/> Interface "vxlan-12.14.16.2"<br/> type: vxlan<br/> options: </p> {key=flow, local_ip="12.14.16.3", remote_ip="12.14.16.2"} <p> ovs_version: "2.3.2"</p> <p>Control Node<br/> br-int lldp flows</p> <p> cookie=0x0, duration=3298.189s, table=0, n_packets=908, n_bytes=101696, dl_type=0x88cc actions=CONTROLLER:65535</p> <p>br-ex<br/> ubuntu@odl-os-control-node:~/devstack$ sudo ovs-ofctl dump-flows br-ex -OOpenflow13<br/> OFPST_FLOW reply (OF1.3) (xid=0x2):<br/> cookie=0x0, duration=3374.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL<br/> cookie=0x0, duration=3374.887s, table=0, n_packets=1070, n_bytes=119710, dl_type=0x88cc actions=CONTROLLER:65535</p> <p>Compute Node </p> <p>br-ex has no flows installed. br-int has the lldp flows as needed</p> <p>Other clues:</p> <p> Always happens in ODL3 when ODL2 and ODL3 are used as OVS Managers and Controllers for testing. the warning occurs every second.</p> <p>ODL3 is the owner for all the entities, I think since br-ex is connected to public network, Maybe that is causing this error.<br/> {<br/> "entity-owners": {<br/> "entity-type": [<br/> {<br/> "type": "ovsdb",<br/> "entity": [<br/> {<br/> "id": "/network-topology:network-topology/network-topology:topology<span class="error">&#91;network-topology:topology-id=&#39;ovsdb:1&#39;&#93;</span>/network-topology:node<span class="error">&#91;network-topology:node-id=&#39;ovsdb://uuid/7379aa64-0416-45e2-9531-351397cc742a&#39;&#93;</span>",<br/> "candidate": [<br/> </p> { "name": "member-3" } <p>,</p> { "name": "member-2" } <p> ],<br/> "owner": "member-3"<br/> },<br/> {<br/> "id": "/network-topology:network-topology/network-topology:topology<span class="error">&#91;network-topology:topology-id=&#39;ovsdb:1&#39;&#93;</span>/network-topology:node<span class="error">&#91;network-topology:node-id=&#39;ovsdb://uuid/bf460c25-5849-4874-9758-4fcbafbf9f5e&#39;&#93;</span>",<br/> "candidate": [<br/> </p> { "name": "member-3" } <p>,</p> { "name": "member-2" } <p> ],<br/> "owner": "member-3"<br/> }<br/> ]<br/> },<br/> {<br/> "type": "ovsdb-netvirt-provider",<br/> "entity": [<br/> {<br/> "id": "/general-entity:entity<span class="error">&#91;general-entity:name=&#39;ovsdb-netvirt-provider&#39;&#93;</span>",<br/> "candidate": [<br/> </p> { "name": "member-3" } <p>,<br/> </p> { "name": "member-2" } <p>,</p> { "name": "member-1" } <p> ],<br/> "owner": "member-3"<br/> }<br/> ]<br/> },<br/> {<br/> "type": "openflow",<br/> "entity": [<br/> {<br/> "id": "/general-entity:entity<span class="error">&#91;general-entity:name=&#39;openflow:49213346451329&#39;&#93;</span>",<br/> "candidate": [<br/> </p> { "name": "member-3" } <p>,</p> { "name": "member-2" } <p> ],<br/> "owner": "member-3"<br/> },<br/> {<br/> "id": "/general-entity:entity<span class="error">&#91;general-entity:name=&#39;openflow:86756597698629&#39;&#93;</span>",<br/> "candidate": [<br/> </p> { "name": "member-3" } <p>,</p> { "name": "member-2" } <p> ],<br/> "owner": "member-3"<br/> },<br/> {<br/> "id": "/general-entity:entity<span class="error">&#91;general-entity:name=&#39;openflow:49213351373018&#39;&#93;</span>",<br/> "candidate": [<br/> </p> { "name": "member-3" } <p>,</p> { "name": "member-2" } <p> ],<br/> "owner": "member-3"<br/> },<br/> </p> { "id": "/general-entity:entity[general-entity:name='openflow:82054700722251']", "owner": "" } <p>,<br/> {<br/> "id": "/general-entity:entity<span class="error">&#91;general-entity:name=&#39;openflow:217913872071744&#39;&#93;</span>",<br/> "candidate": [<br/> </p> { "name": "member-3" } <p>,</p> { "name": "member-2" } <p> ],<br/> "owner": "member-3"<br/> },</p> { "id": "/general-entity:entity[general-entity:name='openflow:90510897257539']", "owner": "" } <p> ]<br/> },<br/> {<br/> "type": "ovsdb-southbound-provider",<br/> "entity": [<br/> {<br/> "id": "/general-entity:entity<span class="error">&#91;general-entity:name=&#39;ovsdb-southbound-provider&#39;&#93;</span>",<br/> "candidate": [<br/> </p> { "name": "member-3" } <p>,<br/> </p> { "name": "member-2" } <p>,</p> { "name": "member-1" } <p> ],<br/> "owner": "member-3"<br/> }<br/> ]<br/> }<br/> ]<br/> }<br/> }</p> <p>(In reply to Venkatrangan Govindarajan from comment #8)<br/> &gt; Compute Node <br/> &gt; <br/> &gt; br-ex has no flows installed. br-int has the lldp flows as needed</p> <p>Will need to add this as a seperate bug</p> <p>In clustered environment, if two devices are owner by two different controller, LLDP packet sent by one controller node will go to another controller node through it's connected device. Currently we have a fix for security vulnerability fix that check if that LLDP packet was send by the same controller node and if not, it will spit the warning message reported in this bug. In 3 node cluster that's a very valid scenario, because different devices are connected to different controller node, but because of the existing security fix, it will spit warning message because that packet was not sent by the same controller. This requires a fix at the openflowplugin application level and it's not an easy fix from security perspective.</p> <p>Net-virt don't usse any of the topology information because it's end host based solution, so we don't really want lldp speaker to send lldp packets to the switch. I disabled the lldp speaker for net-virt using the following patch</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/34420/1" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/34420/1</a></p> Development External issue ID 5040 External issue URL Priority Rank 0|i021on: