I want to ask question about the Ethernet Switches , lets consider a switch with 8 ports only , and I want to set up a local are network of 8 PCs, if I want each PC to communicate with each other, and I plug in the whole PCs with the switch and turned it on , How does the switch will initially know the mac address of each PC network card ? I think there must be a memory in the switch that should inform the switch how to transmit the frames from PC x to the others PCs and PC y to the others and so on .
Can you please clarify this point .
It is very simple.
Because the ethernet frames have 48 bit address fields, it is obvious that switch should know the MAC address of the destination PC.
For this ,switch uses address resolution protocol. When a sender wants to send data to a receiver with given IP address but does not know its MAC address, it is used.
In this, the table stored inside switch is checked for the IP address. If one of the entries match, then the switch forwards the frame to the port mentioned in the table. If it does not, it broadcasts a request message that asks every host who has this IP?.
The host on the LAN will respond if the IP address given in the request message matches its IP address and will send a unicast reply to the switch informing its MAC address. Then switch updates the table and sends the frame on appropriate port.
Related
I want to send data(I think I can achieve it sending http requests) between two ESP's that are connected to the same LAN. I don't want to use one as an access point! I have one esp that is acting as a homekit device, and I want to send data(for example, sensor readings) to it from another esp. I've seen many tutorials where one device is acting as an access point, but that's not what I need. I also don't really need to access the esp data directly from my laptop, so I believe I don't need the html page. I would appreciate any help, code, or any existing tutorials, because I didn't find a single one.
Configuring one ESP as an AP is only done for convenience. You can configure both of them in STA (station) mode and they will connect to, e.g. your phone hotspot or your wifi router.
Connected to the same hotspot, they are on the same network, and they will be able to communicate with each other (unless the hotspot is configured to not allow this ... ). The tricky part will most likely be for the "client" to determine the IP address of the "server" in order to create the connection.
If you have admin access to the hotspot, you can cheat and hard code the IP addresses (assuming that the hotspot will assign the same IP address to the device the next time it sees it.)
It's also not difficult to use mdns (aka bonjour), which allows a network device to assign itself a local hostname. So you can name one ESP ("myserver") which allows the ESP running the client code to connect to "http://myserver.local"
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.
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.
Im new to the networking world and I'm trying to use wireshark to get a hang of how packets are sent from my machine etc. Hence this question might be a dumb one.
When I open the wireshark packet analyzer GUI (on windows 7) there is a source and destination column. It shows packets where source IP is not mine and the destination IP is not mine either. Why is this happening? My network interface card should be receiving and sending only packets addressed to/sent from my IP address, right?
(attaching a screenshot. My IP address is 10.177.255.186)
Thanks.
On a small LAN all packets are generally broadcast to everyone. By broadcast I mean that the data is physically sent to everyone. When received the network interface determines if the packet was sent to you by looking at the address.
Using Wireshark your network interface can be set into promiscuous mode which means that all packets are captured and sent from the network interface to the CPU. This allows programs like Wireshark to record all those packets and not just the ones addressed for your computer.
Edit: However the packets don't have to be sent to all computers. A hub can be used to connect multiple computers together and acts as just a repeater meaning all packets are always sent everywhere (except on the wire where the packet came from). A switch however is similar but smarter.
If three computers A, B and C are connected to a switch and A sends a packet to B then the packet will first arrive at the switch. If the switch knows what wire B is connected to then it will only send it down that wire. If it doesn't know it sends it everywhere and later if B replies to A the switch will figure out what wire B is on. This means that C will generally never get to see any of the messages sent between A and B once the switch knows what wires A and B are on.
Hello Networking Gurus,
I have a question about IP duplication and how this impact the associated switches (layer 2). Sorry, I don't have any resources available to test this. It would be great if someone can shed some lights of their experience on this.
If I have two servers (Linux), say A & B, serving exactly same contents and for some reason they both are assigned same IP address. To be more specific, if A already has an address IP.100 and B has another address IP.200. Now at this point everything seems working and the switch has proper MAC addresses stored. If, later, B also gets the address IP.100, how would this affect the switch's ARP cache? When B gets the new address I assume it broadcasts ARP? to inform the associated switch.
So the question is, Does the switch stores both machines' entries? or overwrites the existing with new? Is there any standard behaviour or proprietary switches reacts differently?
If a client, with no ARP cache, tries to connect to IP.100, which machine would it be forwarded to? A or B or none? If A OR B, can I say from client point-of-view, that there's no outage? (Assume this is a static website, with no login sessions etc)
Feel free to point any relevant documentation.
Thank you in advance.
In theory, you shouldn’t have two hosts talking on the same IP, unless they are participating in routing. Eg any-cast. As things will break.
Each host will have its own MAC address. If the switch is only doing layer two forwarding, then the switch only keeps track of MAC addresses. It is the end hosts or routers that track ARP entries.
If you move IP 100 to B, then the hosts will update their own ARP table.
But if A and B have 100 at the same time, this will cause issues.
Switch will not see any IP's and do not have arp cache for forwarding packets , it will had only mac address table map macs to ports and macs in your case will be unique
I actually think this is how multicast works.
Hosts obtain a multicast address and all of the devices share that same multicast address.
A switch will gather collections of Mac addresses to that same multicast in it's mac table.
I could be wrong though....Still learning.