I have been very interested in networking for quite a while, and I have been wondering this question. I've been thinking about this in complete binary, meaning how does a 0 of a data packet not get interfered by a 1? For example, if two data packets are somehow sent at the same time, how do they not merge if one packet is (of course not this short) 101101 and another is 011010? How does it now become 111111 and mess everything up? This also brings up how the validation of a packet header is used, as that I am also confused about too. Is it just based on how instant these packets of data are sent and that it's almost impossible for multiple to send at the same time? I hope this isn't too confusing, but I would be happy if someone could broadly explain this. Thank you
Switch – How Do Data Packets Travel Without Merging?
ethernetlayer1protocol-theoryswitchtransport-protocol
Related Solutions
Responding to individual concerns in the post...
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 switchNote 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 1Any layer 3 switch should do... Cisco, Juniper, and Brocades all could perform this kind of function.
Great topic. I'd like to preface my answers with some relevant information, then answer your questions as you've asked. "Roaming" is defined as a wireless client migrating from one access point to another. "Seamless" roaming (aka Fast Roaming, aka Zero Handoff, aka IEEE 802.11r) is defined as a wireless client migrating from one base station to another in a fast, seamless, and "secure" manner.
Now to your questions. You asked, "I expect that somehow the new AP must inform the old one the station has roamed successfully and I suspect it must be done with packets sent through the switch. I really wanted to know: How It's done in practice?". Answer: The new AP does not inform the old ap that the station has roamed successfully. In fact, the two access points do not communicate to eachother at all. Even if they were the same model, they don't communicate to eachother. A wireless network designed as described above is not capable of "fast roaming", just "roaming". A real-world test to prove this to yourself is to connect a wireless VOIP phone to the wireless network, then have a phone conversation on it while roaming. You will hear a signifigant interruption in your conversation. Fast roaming would be achieved with another wireless design using a wireless controller (or a bridge). But your question is, "How is it done in practice" ("it" being how the communication occurs for a successful wireless client migration from one ap to another). Here's how it happens in the network you have designed, which is a normal SOHO network. The client is already connected to an access point. As it physically moves, the client wirelessly probes and finds that another access point also has the BSSID it uses AND has a stronger wireless signal (aka RSSI value) than the one it's currently connected to. Before we continue, let's state one fact. A wireless client can only be associated to one access point at a time. So knowing this, it must "disassociate" from the one it's connected to now before it can "associate" to the stronger one. So the wireless client sends it's current access point a "disassociation request" (aka Disassociation Frame) and disconnects from it. Then, the wireless client connects to the new access point by going through its association and authentication process. Once the wireless client is accepted onto the new access point, that access point communicates to the switch that the mac address can now be found on this switchport. The switch updates its mac address table and moves the wireless client's mac from the old access point's switchport (in the table) to the new switchport belonging to the new ap. At this point, the wireless client begins network communication. All of that was done and the two ap's did not communicate to eachother at all.
Your second question is: (translated) What would those packets look like? Answer: On your wireless client, load the latest version of Wireshark and begin a packet capture before you roam. After you roam, stop the capture. You can analyze your traffic to whatever degree you are comfortable with. NOTE: It would be best to make sure you have the latest wireless "driver" on your device first. You mentioned that you tried sniffing on the switch and saw nothing. You now know that to see the migration, you need to sniff on your wlan adapter.
Your last question is: "I read a CISCO networking book about this topic, but It only contains a recommendation about this process, and It says implementation depends on the manufacturer. But what if the APs made by different manufacturer?". Answer: Cisco is correct. The implementation does depend on the manufacturer. Each manufacturer thinks they have a better way for a wireless access point to handle clients. As such, they program their devices in their engineering vision. So if the ap's are made by a different manufacturer, that's OK. Here's why. The access points themselves do not have discussions with eachother in any way, no matter if they're "autonomous ap's" (like the ones you setup in your network) or "thin ap's" that are directed by a controller. So in your scenario, having two different ap manufacturer's is OK because both MUST follow IEEE standards when communicating with the wireless client(s) and the switch.
SOURCES CITED:
WIFI ROAMING ANALYSIS: http://www.revolutionwifi.net/revolutionwifi/2011/12/wi-fi-roaming-analysis-part-1.html
802.11 ASSOCIATION PROCESS EXPLAINED: https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/802.11_Association_process_explained
Best Answer
You are describing a problem called collision. There are different network media and protocols that are subject to collision, and the protocols must have a method to detect when that happens. Your question is really too broad to go into details, and those will vary with the medium and protocol, but I will give you some information.
The original ethernet was on a shared medium (coax cable) where more than one host could send at the same time, and is uses CSMA/CD (Carrier Sense with Multiple Access using Collision Detection). A host needs to listen to the medium to see if it is free before sending, but that doesn't guarantee that there will be no collision because it takes a finite amount of time for a signal to cross the medium. The ethernet hosts will detect a collision and send a jamming signal, back off a random amount of time, and try to resend. (Switched ethernet has eliminated collisions for all practical purposes.)
Wi-Fi also uses a shared medium, so it is subject to collisions, and it uses CSMA/CA (Carrier Sense with Multiple Access using Collision Avoidance), but that doesn't mean that it can entirely avoid collisions.