Talk:Broadcast, unknown-unicast and multicast traffic

Hi @RoySmith,

Thank you for your feedback but I cannot understand what is the problem with my draft https://wiki.riteme.site/wiki/Draft:Broadcast,_Unknown-Unicast_and_Multicast. I've studied the subject and wrote the article (using also Cisco as a source), but I did not copy anything, and also the images are made by myself. So, do you think it is a problem to use Cisco material as a reference?

Giorgiavicari (talk) 12:34, 26 June 2018 (UTC)

Example Moved from page. 11:00, 8 September 2018 (UTC)

Example

Suppose that the HOST-A in Figure D does not know the MAC address of the HOST-B. As in traditional switched Ethernet networks, HOST-A uses the ARP protocol, sending a classic ARP request to the VTEP interface where the MAC destination broadcast address is ffff.ffff.ffff.

Figure D

In a non-VXLAN scenario, the ARP message would be conveyed by the switched Ethernet network to all the hosts of the same VLAN. In a VXLAN scenario, the ARP request message is encapsulated in a VXLAN package with VNI = 100 (VXLAN Network Identifier), source IP address of the VTEP-1 interface and destination IP address a preconfigured multicast address associated with the VXLAN segment identified by the VNI = 100.

The assumption here is that a multicast routing protocol is active within the IP network, and the VTEP interfaces are able to generate IGMP membership messages report to join / leave the multicast tree.

Although in theory it is possible to use any multicast routing protocol, in general the only protocol used in almost all practical applications is the PIM protocol and, since each VTEP can be both source and destination of multicast packets, it is convenient and recommended to use the PIM-BiDir model.

It should be noticed that it is not necessary to have a multicast tree for VXLAN, which could lead to serious problems of scalability, being VXLANs of the order of hundreds of thousands.

Multicast trees shared by multiple VXLANs can be used, however the traffic isolation between VXLANs is not affected because it depends exclusively on the value of the VNI. The drawback in using shared multicast trees is that BUM traffic can also get to VTEPs that do not host a particular VNI, resulting in waste of bandwidth.

Unknown unicast storm?

In my years, I've only once come across a storm scenario where unknown unicast was the problem, normally broadcast or multicast loops are the problem. One reference says (Juniper):

"Unknown unicast traffic consists of unicast packets with unknown destination MAC addresses. By default, the switch floods these unicast packets that traverse a VLAN to all interfaces that are members of that VLAN. Forwarding this type of traffic can create unnecessary traffic that leads to poor network performance or even a complete loss of network service. This flooding of packets is known as a traffic storm."

As much as I love Juniper, this is not what I call a storm. Unless someone says otherwise, I'd be tempted to change the section and explain that storms are normally only broadcast or multicast based. The only scenario where unknowns can be a problem is where large amounts of data is sent to a receiver that is unknown, and what's the point in doing that? You'll have to trick a computer into doing so. The one time I saw was a firewall that sent large amounts of logs to a fake MAC address since some nitwit programmed it to do so.

/Fredrik — Preceding unsigned comment added by Fb35523 (talk • contribs) 13:10, 5 March 2019 (UTC)