unknown-dst is not used for Layer 2 BUM traffic

[Itamar Ofek]

In the HARDWARE_VTEP spec it is stated that:

The keyword unknown-dst is used as a special ``Ethernet
address’’ that indicates the locations to which packets in a
logical switch whose destination addresses do not otherwise
appear in Ucast_Macs_Remote (for unicast addresses) or
Mcast_Macs_Remote (for multicast addresses) should be sent.

Same for Ucast_Macs_Local and Mcast_Macs_Local.

This means that if a broadcast or unknown, mac (BUM) is to be sent to specific destination(s), then these destinations

Physical_Locator entry in the OVSDB need to be referenced by unknown-dst mac either in the Ucast_Macs_Remote or by Mcast_Macs_Remote.

Currently networking_l2gw, do not populate this entry in the OVSDB, leaving it up to the switch, to implement whatever behavior it chooses.

The hardware vtep switch should only act according to what it was instructed by the DB entries. Flooding will only happen on ports referenced by unknown-dst entry.

I would suggest to extend the l2-gateway-connection-create with --flood , defaults to true.
The implementation will insert an entry with unknown-dst in the Mcast_Macs_Remote and Ucast_Macs_Remote table , with a reference to the relevant Physical_Locator.

The HARDWARE_VTEP switch should translated this entry as an instruction to include this port for BUM

[Maruti Kamat (marutik)]

Is this duplicate of https://bugs.launchpad.net/networking-l2gw/+bug/1475251?

[Ofer Ben-Yacov (ofer-benyacov)]

no its not.

The other bug discuss if and how to prevent flooding of BUM packets on br-tun on the compute node.

This bug relates to information that should be inserted into the OVSDB to state if flooding should be done by the L2GW device in case of BUM packet or not, and the device should act accordingly.

[Ofer Ben-Yacov (ofer-benyacov)]

sorry, I was looking at another bug that involves BUM traffic.

It is the same issue.

[Itamar Ofek (itamar-ofek)]

Hi
Yes it is. I am looking into that and would be glad to assign it to me.

Regards

Itamar

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Maruti Kamat
Sent: Tuesday, 09 February, 2016 2:28 PM
To: Itamar Ofek
Subject: [Bug 1543559] Re: unknown-dst is not used for Layer 2 BUM traffic

Is this duplicate of https://bugs.launchpad.net/networking-
l2gw/+bug/1475251?

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1543559

Title:
  unknown-dst is not used for Layer 2 BUM traffic

Status in networking-l2gw:
  New

Bug description:
  In the HARDWARE_VTEP spec it is stated that:

  The keyword unknown-dst is used as a special ``Ethernet
  address’’ that indicates the locations to which packets in a
  logical switch whose destination addresses do not otherwise
  appear in Ucast_Macs_Remote (for unicast addresses) or
  Mcast_Macs_Remote (for multicast addresses) should be sent.

  Same for Ucast_Macs_Local and Mcast_Macs_Local.

  This means that if a broadcast or unknown, mac (BUM) is to be sent to
  specific destination(s), then these destinations

  Physical_Locator entry in the OVSDB need to be referenced by
  unknown-dst mac either in the Ucast_Macs_Remote or by
  Mcast_Macs_Remote.

  Currently networking_l2gw, do not populate this entry in the OVSDB,
  leaving it up to the switch, to implement whatever behavior it
  chooses.

  The hardware vtep switch should only act according to what it was
  instructed by the DB entries. Flooding will only happen on ports
  referenced by unknown-dst entry.

  I would suggest to extend the l2-gateway-connection-create with --flood , defaults to true.
  The implementation will insert an entry with unknown-dst in the Mcast_Macs_Remote and Ucast_Macs_Remote table , with a reference to the relevant Physical_Locator.

  The HARDWARE_VTEP switch should translated this entry as an
  instruction to include this port for BUM

To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-l2gw/+bug/1543559/+subscriptions

[Maruti Kamat (marutik)]

There is a review that fixes this problem. https://review.openstack.org/202495. Can you please check whether it will work for you?