docs/user-guide/port-status-update-debugging.rst

   1 Debugging Netvirt/Networking-odl Port Status Update
   2 ===================================================
   3
   4 .. contents:: Table of Contents
   5    :depth: 2
   6
   7 Recent versions of Opendaylight Netvirt support dynamic update of Neutron port status via
   8 websocket and the networking-odl ML2 plugin knows how to take advantage of this feature.
   9 The following is a basic description of the internals of this feature followed by a guide
  10 for how to debug it.
  11
  12 How Port Status Update Works
  13 ----------------------------
  14
  15 When Neutron/networking-odl boots it registers a websocket based subscription to all neutron
  16 ports in the ODL operational yang model.  Once this websocket subscription is connected,
  17 networking-odl receives json based notifications for every time Netvirt changes the status of
  18 a port. Note that for now this only happens at the time of port binding, if a port should go
  19 down, e.g., the VM crashes, Netvirt will not update the port status.
  20
  21 Note that a failure of port status update is not the only error that can cause a port to not
  22 transition to ACTIVE. Neutron uses a mechanism called provisioning-blocks to make sure two
  23 things happen before a port is transitioned to ACTIVE:
  24
  25 - Port status update to ACTIVE
  26 - DHCP provisioning by the DHCP agent
  27
  28 If the DHCP provisioning does not succeed, e.g., if the dhcp agent is down, the port will not
  29 transition to active. In order to determine if DHCP provisioning worked look for *either* of
  30 the following two lines in the neutron logs:
  31
  32   ``Provisioning for port <uuid of port> completed by entity DHCP.``
  33
  34   ``Provisioning complete for port <uuid of port> triggered by entity DHCP.``
  35
  36 How to Debug Port Status
  37 ------------------------
  38
  39 **1) BEFORE YOU GET STARTED, SET THE LOG LEVELS**
  40
  41 Neutron logs need to be set to debug. You can do this by having “debug = True” in your
  42 neutron.conf, generally under /etc/neutron.
  43
  44 The following ODL component log levels need to be set in
  45 <your karaf installation>/etc/org.ops4j.pax.logging.cfg:
  46
  47 ::
  48
  49   log4j2.logger.npcl.level = TRACE
  50   log4j2.logger.npcl.name =org.opendaylight.netvirt.neutronvpn.NeutronPortChangeListener
  51   log4j2.logger.nu.level = DEBUG
  52   log4j2.logger.nu.name =org.opendaylight.netvirt.neutronvpn.api.utils.NeutronUtils
  53   log4j2.logger.oisah.level = INFO
  54   log4j2.logger.oisah.name =org.opendaylight.genius.interfacemanager.renderer.ovs.statehelpers.OvsInterfaceStateAddHelper
  55
  56 **2) Check that the websocket is connected**
  57
  58 Websocket connection status is logged in the neutron logs. Check that this line is the last
  59 websocket status logged before your port was created:
  60
  61   ``websocket transition to status ODL_WEBSOCKET_CONNECTED``
  62
  63 Note: The connection can disconnect but should reconnect so you can have multiple lines like
  64 this in the log with different statuses. You can now follow the transitions in this case.
  65
  66 If the websocket is not connected, either something is wrong with your deployment or ODL is
  67 not running. It may be worth checking if a firewall is blocking the websocket port which is
  68 8185 by default but may be custom configured in a file called 10-rest-connector.xml under
  69 your karaf installation.
  70
  71 **3) Check whether networking-odl received the port status update**
  72
  73 All port status notifications are logged in the neutron logs like this:
  74
  75   ``Update port for port id <uuid of port> <ACTIVE|DOWN>``
  76
  77 Note that for VM ports Netvirt will initially report that the port is DOWN until the basic
  78 flows are configured.
  79
  80 If there is no log line like this reporting your port is ACTIVE it is best to…
  81
  82 **4) Check whether Netvirt transitioned the port to ACTIVE**
  83
  84 Look for the following in karaf.log:
  85
  86   ``writePortStatus: operational port status for <uuid of port> set to <ACTIVE|DOWN>``
  87
  88 Again, remember that for VM ports the port is initially reported as DOWN and soon after as ACTIVE.
  89
  90 If this log line is missing…
  91
  92 **5) Check whether the Neutron port was received by Netvirt**
  93
  94   ``Adding Port : key: <iid of the port, including uuid>, value=<dump of the port>``
  95
  96 If this line is missing it means that something is wrong with the REST communication between
  97 networking-odl and ODL.
  98
  99 If this line is present but the line from (4) is not, it probably means that the southbound OpenFlow
 100 Port Status event was never received. Now…
 101
 102 **6) Check whether the Genius operational port status was created**
 103
 104 Check for this:
 105
 106   ``Adding Interface State to Oper DS for interface <tap interface name>``
 107
 108 The tap interface name is the word “tap-” followed by the initial 7 characters of the neutron port’s
 109 UUID. If this line is missing, you have confirmed that the southbound port was never received via
 110 openflowplugin. This could mean that the switch is not connected or perhaps the VM never booted.
 111
 112 **7) Something deeper is wrong**
 113
 114 Although unlikely, if you will have made it this far and still have no answer, something much deeper
 115 is wrong and a more serious debugging effort is required.