Uploaded image for project: 'netvirt'
  1. netvirt
  2. NETVIRT-205

Incorrect handling of ITM transport zones

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved
    • Resolution: Done
    • Boron
    • None
    • General
    • None
    • Operating System: All
      Platform: All

    • 6940

    Description

      Netvirt is mapping each neutron subnet to a genius ITM transport zone subnet.

      This subnet configuration:

      {
      "subnets": {
      "subnet": [

      { "uuid": "b4cfc309-f9dc-4b0b-9943-306252265d35", "network-id": "177bef73-514e-4922-990f-d7aba0f3b0f4", "name": "dovs-net-2", "tenant-id": "5d806f0e-e197-4a72-88e6-72b024fa5c97", "ip-version": "neutron-constants:ip-version-v4", "cidr": "10.0.0.0/24" }

      ,

      { "uuid": "7a843d7f-de78-4a01-b62e-c103ee90afb7", "network-id": "177bef73-514e-4922-990f-d7aba0f3b0f4", "name": "dovs-net-1", "tenant-id": "5d806f0e-e197-4a72-88e6-72b024fa5c97", "ip-version": "neutron-constants:ip-version-v4", "cidr": "10.0.1.0/24" }

      ]
      }
      }

      Results in this transport zone configuration (when each of two computes holds neutron ports belonging to each of the two neutron subnets):

      {
      "transport-zone": [
      {
      "zone-name": "177bef73-514e-4922-990f-d7aba0f3b0f4",
      "tunnel-type": "odl-interface:tunnel-type-vxlan",
      "subnets": [
      {
      "prefix": "10.0.1.0/24",
      "vteps": [

      { "dpn-id": 66551191337378, "portname": "tunnel_port", "ip-address": "172.17.0.3" }

      ,

      { "dpn-id": 180904321929475, "portname": "tunnel_port", "ip-address": "172.17.0.2" }

      ],
      "gateway-ip": "0.0.0.0",
      "vlan-id": 0
      },
      {
      "prefix": "10.0.0.0/24",
      "vteps": [

      { "dpn-id": 66551191337378, "portname": "tunnel_port", "ip-address": "172.17.0.3" }

      ,

      { "dpn-id": 180904321929475, "portname": "tunnel_port", "ip-address": "172.17.0.2" }

      ],
      "gateway-ip": "0.0.0.0",
      "vlan-id": 0
      }
      ]
      }
      ]
      }

      This is incorrect configuration, as the transport zone subnet relate to the provider subnets the TEPs belong to, and not to the any overlay subnet. As observed, the problem is that the same TEP could be configured multiple
      times on different transport zone subnets. This results on ITM
      getting confused and thinking that some TEPs are not longer needed and
      removing them, losing connectivity required between the computes.

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          People

            Unassigned Unassigned
            jaicaa Jaime CaamaƱo Ruiz
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: