Ethernet – Is Ethernet a broadcast or point-to-point protocol

broadcastethernetpoint-to-point

Theoretically speaking, as far as I know Ethernet was developed to be used as a broadcasting protocol and technology. I guess nowadays it is not being used this way. Since ALL the examples I see refer to point-to-point communication, I cannot comprehend how it is used for multicast communications.

I know that an example to Ethernet being used in broadcasting is DHCP Discovery message. However, I cannot think of it being used as a means to communication itself.

I can collaborate more if needed. Thank you for your help

Best Answer

Initially, Ethernet was based on broadcasting physical layer technology (bus network for 10BASE5/10BASE2 or with repeaters), but logically (layer 2), the protocol has always been MAC-based many-to-many - initially only by filtering on each NIC.

Modern networks don't use the broadcasting approach any more (for the past 15+ years) but MAC-based packet switching throughout.

Broadcasting and multicasting are done using special addresses that the switches recognize. The broadcast address is all-one FF:FF:FF-FF:FF:FF, and multicast addresses have the least significant bit in the first octet set to 1 (I/G bit). A broadcast frame is forwarded to all ports but the one it was received on. Multicasts are forwarded to subscribed ports. Switches without proper multicast support treat them like broadcasts or even as unlearned addresses, flooding them.

Ethernet's (non-ancient) physical layer protocols use point-to-point links, so that there are always exactly two ports in a link.

Regarding Path MTU Discovery

Ideally i would be relying on Path MTU discovery. But since the ethernet packets being generated are too large for any other machine to receive, there is no opportunity for IP Packet too big fragmentation messages to be returned

Based on your diagram, I agree that PMTUD cannot function between two different PCs in the same LAN segment; PCs do not generate ICMP Error messages required by PMTUD.

Jumbo frames

Some vendors (such as Cisco) have switch models which support ethernet payloads larger than 1500 bytes. Officially IEEE does not endorse this configuration, but the industry has valid needs to judiciously deviate from the original 1500 byte MTU. I have storage LAN / backup networks which leverage jumbo frame for good reason; however, I made sure that all MTUs matched inside the same vlan when I deployed jumbo frames.

Mismatched MTUs within a broadcast domain

The bottom line is that you should never have mismatched ethernet MTUs inside the same ethernet broadcast domain; if you do, it's a bug or configuration error. Regardless of bug or error, you have to solve these problems, sometimes manually.

All that discussion leads to the next question...

Why is there a spec that intentionally creates invalid ethernet frames?

I'm not sure that I agree... I don't see how the IEEE 802.3 series, or RFC 894 create invalid frames. Host implementations or host misconfigurations create invalid frames. To understand whether your implementation is following the spec, we need a lot more evidence...

This diagram is at least prima facie evidence that your MTUs are mismatched inside a broadcast domain...

+------------------+      +----------------+     +------------------+
| Realtek PCIe GBe |      | NetGear 10/100 |     | Realtek 10/100   |
|       (on-board) |      |     Switch     |     |     (on-board)   |
|                  |      +----------------+     |                  |
| Windows 7        |           ^    ^            |                  |
|                  |           |    |            |                  |
| 192.168.1.98/24  |-----------+    +------------| 192.168.1.10/24  |
| MTU = 1504 bytes |                             | MTU = 1500 bytes |
+------------------+                             +------------------+

How should an 802.3-compliant implementation respond to MTU mismatches?

What was it they [the writers of 'the spec'] expected people to do with devices that generate these too large packets?

MTU 1504 and MTU 1500 within the same broadcast domain is simply a misconfiguration; it should never be expected to work any more than mismatched IP netmasks, or mismatched IP subnets can be expected to work. Your company will have to knuckle-down and fix the root-cause of the MTU mismatches... at this time it's hard to say whether the root cause is user error, an implementation bug, or some combination of the above.

If the affected Windows machines are successfully logging into to an Active Directory Domain, one could write Windows login scripts to automatically fix MTU issues based on some well-constructed tests inside the domain login scripts (assuming the Domain Controller isn't part of the MTU issues).

If the machines are not logging into a domain, manual labor is another option.

Other possibilities to contain the damage

Use a layer3 switch^{Note 1} to build a custom vlan for anything that has broken MTUs and set the layer3 switch's ethernet MTU to match the broken machines; this relies on PMTUD to resolve MTU issues at the IP layer. Layer3 switches generate the ICMP errors required by PMTUD.

This option works best if you can re-address the broken machines with DHCP; and you can identify the broken machines by mac-address.

... why did they bump it up to 1504 bytes, and create invalid packets, in the first place?

Hard to say at this point

802.1ad vs 802.1q

How is IEEE 802.1ad (aka VLAN Tagging, QinQ) valid, when the packets are too large?

I haven't seen evidence so far that you're using QinQ; from the limited evidence I have seen so far, you're using simple 802.1q encapsulation, which should work correctly in Windows, assuming the NIC driver supports 802.1q encap.

End Notes:

^{Note 1}_{Any layer 3 switch should do... Cisco, Juniper, and Brocades all could perform this kind of function.}

Multicast vs Broadcast – Understanding Point-to-Point and Multiaccess Networks

When you discuss a point-to-point link, you are usually referring to a physical link that exists only between two devices.

A point-to-point transmission is a transmission from one device to a single other device. This may or may not cross point-to-point links, but that is not a requirement. A unicast is essentially the same idea in that it means the packet is addressed to a single recipient.

Contrast a broadcast or mutiaccess medium with the idea of a point-to-point link. A broadcast medium allows multiple devices on a single link. Each device looks at the destination address of a packet sent on the medium to see if it belongs to him. This doesn't directly relate to the 'cast designations since those are about how a packet is addressed rather than the medium on which it is sent.

The 'cast references refer to how the packet is addressed, not the medium on which the packet travels. A unicast is addressed to a single recipient, while a broadcast is addressed to every recipient. A multicast is addressed to every recipient which has subscribed to the multicast group (the destination address of the packet).