Sorry, this is a basic question, but I was wondering what will happen in this case? Firstly, is the case below valid example?
Lets say I have 100 servers configured to be in same subnet. I want each of these servers to be able to communicate with one other. Let's say these servers are connected to some network switches. As an example --
---- Switch 4 --- Server 3
/ /
/ -------------/
--- Switch 3 /
/ /
/ /
Server1 -- Switch 1 -- Switch 2 -- Server 2.
Based on what I read online, if the servers are within the same subnet, then there is no routing involved. The packets from server 1 are sent over the ethernet interface which says it belongs to this subnet and at the ethernet transport layer, and the frames are sent with the destination Mac set.
So, for the above diagram, if Server 1 wants to send a packet to Server 3, then it will determine that the packet needs to be sent down the interface that is associated with Switch 1. When Switch 1 tries to decide where to forward the packet, it realizes that frames with this particular MAC address should be forwarded to Switch 3 (not switch 2). Switch 3 then forwards to Switch 4 and Switch 4 then delivers it to Server 3.
Furthermore, my understanding is that, at the layer 2, no sophisticated routing algorithm is used by Switch 1 to decide whether it should send to Switch 2 or Switch 3. It is based on a dumb MAC table that tells it whether it has ever seen this MAC or Switch 2 or 3 and forwards accordingly.
Is my understanding above correct? If so, then what I fail to understand is this --
How is the above MAC based routing within same subnet, any better than using a layer 3 routing protocol like OSPF or LSP that seems to be a lot more smarter about routing efficiently.
If no routing algorithms are used, how will it realize that it is better to go via Switch 2 to reach Server 3 than use Switch 3?
If no routing is present the path to the switch will be determine by its mac address. Server 3 must have 2 network cards (2 MACs' 2 IPS), one connected to switch4 and switch2. When you send a package you use the IP address, then an ARP broadcast will be made to get the MAC address of the device, once you have it then you create the packet with the appropriate headers (layer 2 Mac, layer3 IP).
If you have a routing protocol and instead of switches you have routers, different methods of cost can be taken into consideration to determine the fastest route. For example hoops and speed. You can even force the route via one path no mater what is the best one.
BONUS: If your switches have STP (spanning tree protocol) and have multiple connections between them, then they will determine the fastest route of connection between switches and have redundancy in case of one link fails. In this example the route may change on the diagram that you posted. But remember switches are connected between them with more than one connection 2 or more for each one of them.
Related
I have a network analyzer written in C that sniffs the packages that transit from a specific network card (something like Wireshark but way simpler)
I have implemented a function where, given the position in memory of the first bit of the packet, shifting my pointer, I can extract information as the IP source and destination. For instance, shifting my pointer from the first bit.
For example, I can read layer 2 moving the pointer of 8 octets to find the MAC destination according to the position described here https://en.wikipedia.org/wiki/Ethernet_frame.
I'm able to do the same thing for the layer 3 and 4 with the TCP protocol (and others) following the table below
Now I would like to read if the packet is using TLS and the port it's using.
For the port, I can't find the position inside the packet.
About the TLS, I've checked with Wireshark and it seems that TLS is always described in the packet with the HEX code 0303 and it's inside the Application layer.
I would like to know if there's a standard encapsulation in the application layer to read information such as Transport Layer Security.
tHANKS
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.
I'm currently for a side project trying to setup a VPN with 2 linux box doing the encryption/decryption.
At the moment, I work on layer 3 with the linux framework xfrm (IP packets from host 1 are transformed into ESP when passing through the first box before being sent to host 2, decryption being done on the second box).
I'd like to act directly on layer 2 so I can remove the IP address of my boxes. I think I can do that by setting up ethernet bridges on each box, using netfilters hooks to redirect frames to a socket where a userspace program would do the encryption of the ethernet frames payload (transform the IP packets into ESP).
|Host 1|==|Ethernet Bridge|==Router --- (network not secure) --- Router==|Ethernet Bridge|==|Host 2|
Problem I have with this implementation lies in throughput as I think all these actions would greatly reduce it. Are there other ways I could implement what I'm looking for ?
Layer-2 only works from host-to-host (your router is just a host to layer-2) on a LAN. layer-2, including layer-2 encryption, does not cross a layer-3 device, e.g. router. MACsec (IEEE 802.1AE) is used for layer-2 encryption.
Layer-3 is used to connect LANs, and if you want end-to-end encryption from one LAN to another LAN, you need to encrypt on a layer higher than layer-2. Routers strip layer-2 frames from the packets, switch the packets, then create a new frame for the next hop. The next hop may not use MAC addresses; PPP is common for ISP connections, it doesn't use MAC addresses, and the frames are very different than ethernet. Unless you control all the links between the LANs, you need to encrypt at a high layer.
You're right, deploying a layer 2 VPN is costly (in the sense that you have to pay for internet bandwidth) and most of the time useless, since there are few applications that won't work without being on the same LAN.
What you will get with a layer 2 VPN is mostly broadcasts, things like SMB out-of-the-box name resolution (does not apply if you have to connect to an AD server or have a WINS server), DLNA, SPX/IPX or LAN-only games will work seamlessly, on the other hand your perception on having to relay lots of possibly useless information will also be correct.
Maybe the solution you're looking for is to use ebtables , which is a layer 2 firewall akin to iptables relating to layer 3 in such way that you can drop some packets while accepting others before relaying it over VPN/internet/etc.
PPP just one layer 2 protocol, there's nothing special about it, some VPN gateway use it (namely PPtP VPNs), others don't.
I ask myself that for some days now, and couldn't find a clear answer.
Imagine a network with several rooms, each room with it's own (Layer 2) Switch.
Those are then connected in star topology to another switch which is then connected to the router.
All Clients get IPs from the same range, all clients are in the same subnet and in the same VLAN.
Do you know a way how to determine, which client is connected to which switch, without involving the switch. E.g only with technologies and mechanisms taking place on the client.
The goal would be to be able to draw automated maps of the client distribution in the network, but, as I said, without involving the switch (for example access it's API or somethign like that).
Regards
Me
I am afraid that you are right: In general, in a "normal" Network (which means: In a Network with just Standard Switches and Routers), there is no way to do so.
Only if the Switches were managed, you could write a script which polls the arp-tables from the Switches, but of course this doesn't work with unmanaged Switches.
I realised that there is no way to do this.
The problem is, that a normal network switch, which works on Layer 2 of the OSI model, is not "visible" for tools like traceroute or such.
If you want to traceroute to, lets say: google.com, your traceroute application sends a packet with a TTL of 1 to your default gateway. Your default gateway then decreases the TTL and discards the package, because it has reached a TTL of 0.
Because of that, it answers to your computer and your computer can record, from where it received the first answer.
It then sends again a package to google.com, but this time with a TTL of 2, and the process begins from start.
Now you can't do with switches what you can do with routers, because (normal layer 2) switches do not know about IP...
Cisco offers a layer2 traceroute utility, but this is limited to the cisco ecosystem and only works with cisco hardware.
So, I fear the answer is, that it is not possible in general.
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.