I've searched for some information about frame structure in wifi and ethernet in the Data Link layer and found out that the two frames look quite different.
I am wondering if there is some method in the router that converts wifi frame to ethernet frame in a such network where wireless network is connected to wired network, like WLAN.
Since I'm really new to this field, I may have some misunderstanding issues. Thank you.
Connecting different or similar networks on the data link layer (L2) is done by a network bridge - you extract relevant data from an ingress frame (esp. source and destination MAC addresses), create a new frame for egress and copy the relevant data into it.
A bridge also examines each frame's source MAC address to learn where each node is located, so it only copies a frame to the other side when its destination is located there.
However, a router works on the network layer (L3): it forwards by IP destination address between IP networks/subnets. It uses data link layer (L2) encapsulation for reaching the next hop but doesn't convert anything. (It removes the encapsulating frame from a received packet, decides where to forward the packet, and then creates a new frame for that packet.)
You might be referring to a consumer-grade Wi-Fi router which effectively contains a NAT router, an Ethernet switch, a wireless access point (mostly bridged), DHCP and DNS servers, etc, blurring the distinction between all those functions.
Related
I found that it is possible to do so by MAC spoofing. Apart from spoofing, is it possible? If so, in what instances is this possible?
A switch learns unicast MAC addresses into its source address table or CAM table by inspecting each frame's source address. A MAC address association already present on another switch port is moved to the current frame's ingress port.
In no case does a properly working switch associate multiple ports with the same MAC. Accordingly, a frame addressed to a specific MAC address is always forwarded out of the last switch port that has received a frame from that address. If the associated port changes rapidly it's somewhat random where a frame destined for that MAC address ends up.
Some managed switches track the learning behavior and report flapping/duplicate MACs when they change port association repeatedly in a short time period. There may also be some contingency scheme for where to forward frames to such an address.
boiz and girlz
I`ve been learning networking for a couple of days, namely about TCP/ip and OSI levels.
And i have a question:
When a frame arives in my LAN from the Internet, it will be decapsulated, so that a router can understand whom he should deliver it to, but doesnt it mean that that frame will no longer contain a Physical level, which wont let it get to its destination? (I can suppose, that after decapsulation that frame will be once again incapsulated on a router, so that it can arrive the destination with Physical level)
As far as i understand, Physical level is a way to transfer frames.
One more thing: "Why does everyone use the 'Packet Loss', when there should be 'Frame Loss(NOT RELATED TO FPS)'?"
//Just want to find out what i`ve missed and missunderstood.
Thanks in advance.
It's called packet loss because it's experienced at the network level (i.e. IP level). What hosts see is just an IP packet disappearing somewhere on the path.
There are actually two way a packet can be lost:
The frame can be lost in transmission at the data link level (for instance, the frame couldn't be transmitted on WiFi successfully because of interference).
The packet could be dropped at the network level (for instance, an IP router is experiencing congestion because the downstream link has insufficient bandwidth).
I understand that it's different than a hub in that instead of packets being broadcasted to all devices connected to the device, it knows exactly who requested the packet by looking at the MAC layer.
However, is it still possible to use a packet sniffer like Wireshark to intercept packets meant for other users of the switch? Or is this only a problem with ethernet hubs that doesn't affect switches due to the nature of how a switch works?
On a slightly off topic side note, what exactly is classified as a LAN? For example, imagine two separate ethernet switches are hooked up to a router. Would each switch be considered a separate LAN? What is the significance of having multiple LAN's within the same network?
it knows exactly who requested the packet by looking at the MAC layer.
More exactly, the switch uses the MAC destination address to forward a frame to the port associated with that address. Addresses are automatically learned by looking at the MAC source address on received frames.
A switch is stateless, ie. is has no memory who requested which data. A layer-2 switch also has no understanding of IP packets, addresses or protocols. All a basic switch does is learn source addresses and forward by destination address.
is it still possible to use a packet sniffer like Wireshark to intercept packets meant for other users of the switch?
Yes. You'll need a managed switch supporting port mirroring or SPANning. This doesn't intercept frames, it just copies them to the mirror port. If you need to actually intercept frames you have to put your interceptor in between the nodes (physically or logically).
With a repeater hub, every bit is repeated to every node in the collision domain, making monitoring effortless.
what exactly is classified as a LAN?
This depends on who you ask and on the context. A LAN can be a layer-1 segment/bus aka collision domain (obsolete), a layer-2 segment (broadcast domain), a layer-3 subnet (mostly identical with an L2 segment) or a complete local network installation (when contrasted with SAN or WAN).
Adding to #Zac67:
Regarding this question:
is it still possible to use a packet sniffer like Wireshark to
intercept packets meant for other users of the switch?
There are also active ways in which you can trick the Switch into sending you data that is meant for other machines. By exploiting the Switch's mechanism, one can send a frame with a spoofed source MAC, and then the Switch will transfer frames destined to this MAC - to the sender's port (until someone else sends a frame with that MAC address).
This video discusses this in detail:
https://www.youtube.com/watch?v=YVcBShtWFmo&list=PL9lx0DXCC4BMS7dB7vsrKI5wzFyVIk2Kg&index=18
In general, I recommend the following video that explains this in detail and in a visual way:
https://www.youtube.com/watch?v=Youk8eUjkgQ&list=PL9lx0DXCC4BMS7dB7vsrKI5wzFyVIk2Kg&index=17
what exactly is classified as a LAN?
So indeed this is one of the least-well-defined terms in Computer Networks. With regards to the Data Link Layer, a LAN can be defined as a segment, that is - a broadcast domain. In this case, two devices are regarded as part of the same segment iff they are one hop away from one another - that is, they can switch frames in the second layer.
Consider the scenario where i have a switch which is connected to multiple end devices say X, Y, Z where X is in Vlan_X and Y is in Vlan_Y and Z is in Vlan_Z.
This switch is connected to external network via a Router for routing the data. Also here each Vlan is designated with a unique IP as each Vlan represents a subnet.
Now both X and Y sends a TCP/UDP request over the network, which is routed through Router.
My question is how does the router identify the MAC address of X and Y when routing back replies for them ?
Since the line between the Router and Switch is Trunk enabled, how does Router add the correct Vlan ID in the 802.1q corresponding to X or Y ?
Thanks
Charan
Ignore the existence of the vlan's for a moment - assume you have three separate devices
switch_VX , switch_VY and switch_VZ with the hosts X,Y,Z connected to them.
Now assume that your router has a distinct ethernet cable to each switch.
On your router you are going to have three different ethernet ports.
eth_VX , eth_VY, eth_VZ
In this setup it should be obvious how it works .
Each switch has it's own Layer 3 protocol address subnet for any protocols you are using (IPv4, IPv6, AppleTalk, IPX etc)
The router needs a configuration on each interface that has an address from the same address range that the switch is using.
Then the router gets to the host by looking at it's protocol address , looks for the interface that matches, and then uses the right protocol->mac translation mechanism to talk to the end host.
For IPv4, that means the router looks in its routing table, finds eth_??, and then goes looking in the ARP table for the MAC address of the host it's looking for.
Each host is configured with an address from the subnet that's on the switch it's using, and each host is configured to use the address of the router as its default gateway.
Logically that's exactly how it works - always.
However, confining people to use separate sets of switches for each subnet is not efficient. Requiring a separate ethernet cable, and port on the router for each switch isn't efficient. It gets even more costly when you want to do a proper service and add redundant cables and routers etc..
So the manufacturers changed the physical topology a bit, and moved some of the physical stuff to software configured instead. However the devices are still doing exactly the same job.
So instead of separate switches you have separate vlans on the device (or set of devices).
In the explanation above replace switch_VX with switch_vlan_X. The VLAN configuration on the switch creates effectively a completely seperate switch. It runs its own MAC Address Table, it's got its own copy of spanning-tree running. Internally inside the switch it has to record the VLANID inside each ethernet frame - so that it makes sure that it never gets sent out the wrong ports. The switch adds the VLANID when it receives a frame, and strips it off before it sends it out. So the end hosts have no idea that it's happening. It's all hidden.
So that removes the multiple switches, and we can configure our vlans on one switch.
But we still have multiple cables to our router. So let's fix that by configuring the switch engine to treat the port connected to the router as special. Instead of stripping off the VLANID for all frames - let's instead send the frames up to the router with the VLANID still on them. We'll need to agree on a common format for the frames, so the routers know where to look. 802.1Q is the industry standard, but there are some other options out there. Most vendors call the port a ''trunk'' port when it is configured to leave the VLANID in place.
Now the router is getting a stream of frames on a single interface but they have VLAN identifiers in there that need to be removed. Let's get the router to do that in software.
So in the description above, instead of different ethernet interfaces ; we'll have a software interface that understands VLANs. Replace all mentions of eth_VX with eth_vlan_X .
Now the router knows when it gets a frame that is part of VLAN X, that it is associated with the interface eth_vlan_x , and it can remove the VLANID and process it appropriately.
If the router wants to send a frame out the interface eth_vlan_x, it knows that it needs to insert the VLANID X into every fraame.
So we started with a logical setup, and changed the physical layout to be more flexible and more efficient. However, logically it is absolutely no different to the setup that uses independent separate devices.
Usually, a switch can populate its MAC address table automatically by
learning the source MAC addresses of incoming frames on each port.
I found the above sentence in the following reference:
04-Layer 2 - LAN Switching Configuration Guide
Why doesn't a switch use the destination MAC address of outgoing frames for MAC learning?
I think it's useful for preventing flooding in some situation which I have.
Why doesn't a switch use the destination MAC addresses of outgoing frames for MAC learning.
Short answer: Because it's pointless to learn from destination mac-addresses
Long answer:
A switch learns two things from the source mac-address when an ethernet frame is sent:
The value of the mac-address of the ethernet NIC attached that that cable
The number of the port which has the aforementioned mac-address
Destination mac-addresses don't provide useful information for a switch to learn from. When a PC sends an ethernet frame somewhere, the switch must deliver to that destination mac-address. Learning a mac-addresses' existence and location coincidental to the delivery event is a broken algorithm.