It's more of a theoretical question but I can't seem to find the answer anywhere.
In a network built only using switches are packet collisions possible?
Using switches only decreases collision probability, except in case there's a microsegmentation, where each computer has its own port and you have a connection without collisions. This is because in this way you have a point to point full duplex connection between nodes and there's a collision impossibility.
Of course. Imagine a network of 100 computers connected via dedicated links to a switch. If 99 of them are sending packets at top speed to the other 1, collisions are guaranteed to occur.
Related
I would have a question regarding physical problem detection in a link with ping.
If we have a fiber or cable which has a problem and generate some CRC errors on the frame (visible with switch or router interface statistics), it's possible all ping pass because of the default small icmp packet size and statistically fewer possibilities of error. First, can you confirm this ?
Also, my second question, if I ping with a large size like 65000 bytes, one ping will generate approximately 65000 / 1500(mtu) = 43 frames, as ip framgents, then the statistics to get packet loss (because normally if one ip fragment is lost the entire ip packet is lost) with large ping is clearly higher ? Is this assumption is true ?
The global question is, with large ping, could we easier detect a physical problem on a link ?
A link problem is a layer 1 or 2 problem. ping is a layer 3 tool, if you use it for diagnosis you might get completely unexpected results. Port counters are much more precise in diagnosing link problems.
That said, it's quite possible that packet loss for small ping packets is low while real traffic is impacted more severely.
In addition to cable problems - that you'll need to repair - and a statistically random loss of packets there are also some configuration problems that can lead to CRC errors.
Most common in 10/100 Mbit networks is a duplex mismatch where one side uses half-duplex (HDX) transmission with CSMA/CD while the other one uses full-duplex (FDX) - once real data is transmitted, the HDX side will detect collisions, late collisions and possibly jabber while the FDX side will detect FCS errors. Throughput is very low, put ping with its low bandwidth usually works.
Duplex mismatches happen most often when one side is forced to full duplex, thus deactivating auto-negotiation and the other side defaults to half duplex.
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.
One of my networks course projects has to do with 802.11 protocol.
Me and my parther thought about exploring the "hidden terminal" problem, simulating it.
We've set up a private network. We have 2 wireless terminals that will attempt to send a file
to a 3rd terminal that is connected to the router via ethernet. RTS/CTS will be disabled.
To compare results, we'd like to measure the number of packet collisions that occured during the transfer so as to conclude that is due to RTS being disabled.
We've read that it is imposible to measure packet collisions as it is basically noise. We'll have to make do with counting the packets that didnt recieve an "ACK". Basically, the number of retransmitions.
How can we do that?
I suggested that instead of sending a file, we could make the 2 wireless terminals ping the 3rd terminal continually. The ping feature automatically counts the ping packets that didnt recieve the "pong". Do you think its a viable approach?
Thank you very much.
No, you'll get incorrect results. Ping is an application, i.e. working at application (highest) level of the network. 802.11 protocol operates at MAC layer - there are at least 2 layers separating between ping and 802.11. Whatever retransmissions happen at MAC layer - they are hidden by the layers above it. You'll see failure in ping only if all the retransmissions initiated by lower levels have failed.
You need to work on the same level that you're investigating - in your case it's the MAC layer. You can use a sniffer (google for it) to get the statistics you want.
I'd like to garner fellow SO'ers experience with regards to the issue of UDP packet loss (or drop-out).
Initially my understanding is that given direct point to point connections where the NICs are connected via a crossover cable and ample buffer on the NICs and timely processing of said buffers, that there 'should' be no packet loss or packet ordering issues. I believe this is also the case given one good/high-end switch in between the points.
Excluding the above scenario, what is the expected average UDP packet loss over a LAN
What scenarios cause UDP packet ordering issues?
No idea on the UDP packetloss on average LANs. I assume reasonably low on modern switched networks, otherwise your LAN or endpoints are too highly loaded. :)
The re-ordering is probably easiest to achieve when routes are brought up and down; say, one of the switches in your organization is under enough load that re-organizing the tree makes sense and traffic is sent through different switches. More likely is your ISP's peers coming and going, or reaching traffic limits, and the priority of packets through them changes -- old packets were in flight on the heavy-loaded network, new packets are in flight on the lighter-loaded network, and they arrive out of order.
I too am looking for an expected average. I found that from a direct link (PC to PC) packet loss occurs very rarely, although it definitely occurs. Availability was something like 99.9% at 1 kB packets # 50 Hz.
I have seen reordering just by sending and receiving on the same network interface.
I concluded that this occurs because each packet is handled asynchronously so that there is a chance of a newly arrived packet being processed before packets received prior to the newly received one.
On my basic gigabit switched LAN I get zero packet loss at even 50,000 packets per second, with FreeBSD, Solaris or Linux.
However Windows is something quite special, I easily see packet loss on exactly the same hardware at low speeds such as 10,000 per second. This is mainly due to buffer overflow between WinSock and the NIC, if you drive the packets faster you lose more, if you space out the packets you drop less.
There is no magical number, my situation is probably worse due to Broadcom having terrible Windows drivers.
You can easily see packet ordering issues, however it is almost always only the last two packets switched. This is an artifact of how switches function.
Interestingly what you haven't mentioned in Wi-Fi, radio signals are highly subject to interference and environmental conditions.
I know how to scan subnets in c++...I also know how to find geo location (altough it's not 100%)...But does anyone have an idea how can i find the closest ip addresses to mine ?
Ex one neighbor is 100 meters from me and another one is 50 and if they are both connected to the internet, i should get the ip of the second which is 50 meters away from me.
Is there any possible way to implement this via programming language ?
Forget it. The structure of how ISPs work and allocate their IP's will make this entirely impossible in 99.999999999% of all cases.
The kind of geolocation by IP address you mention - by checking against databases of IP addresses, and by analyzing the route points of the IP - will work on a city level if you're lucky.
The only reliable means of geo-location down to a city borough or even block is a new set of technologies that for example query Wi-Fi hotspots around the user's computer, and compare them with a list of known Wi-Fi hotspots and their locations. See for example yesterday's question about Geolocation in HTML 5.
There is no way to triangulate other users' positions from that, and thank god for that!
IP geolocation only locates the ISP. It cannot locate the actual host.
The answer is no, you cannot find out what your neighbour's IP address is! How would you know if your neighbour is connected to the same ISP as yours? Again, a dangerous assumption, sure, geolocation may work but not 100% reliable...
They may be connected to Mars Inc ISP for all I care, as there is something fishy about your question - why do you want to know? for D-o-S attacks, hacking...
Hope this helps,
Best regards,
Tom.
If you're on cable, the bandwidth is shared by everyone using the cable. If you could tap the cable on the other side of your modem, you could see traffic of other people on the same segment. This is changing as DOCSIS 2 and 3 are rolled out, which provide PKI-based AES encryption.
If you're on wireless (WiFi, WiMax, Cellular), you may be able to pull the signals of other people. Limiting factors include 1. encryption (some have been broken) 2. Signal strength (Some technologies use directional antennas)
Obviously neither of these work if your neighbour is not using the same ISP.
yes there is..
1) You should measure distance in hops on routers.. So for example person on your subnet is one hop away, and person on your isp is 2 hops away..
if you are on windows you can measure hops by lines produced by traceroute app (through cmd in win+R) on unix you can run tracert app
2) If your geoip can give you approx geo location, you can measure distance between two gps locations. This will however not be very reliable as they cannot know exact location. But it might help if the IPs are more than 3 hops away..
Hops in traceroute program are measurement of TTL property in IGMP protocol. If TTL (Time to live) exceeds some point, router sends back answer that the destination has not been reached. This way you try first with TTL = 1, than TTL = 2, than TTL = 3, and so on.. If you dont want to program tracert program again, just use the command line execution function in your favorite programming language :)
Note that this is not not reliable on measure of distance between IPs as if your neighbor has different ISP than is yours, the distance to neighbor after him will be smaller than to him.
3) To measure distance of the closest networks, you might detect strength of wifi networks. if you know which wifi network belongs to whom, you might know the distance.
Note that if you already know IPs of your neighbors, you probably know also how far they are :)
If you are doing just network scan on the college campus or something like that you might detect more useful information about computers using nmap, but use it on your risk as you might get expelled, or you might get some sanctions from your ISP.