26
There are tools like WANem which allow you to simulate WAN links by artificially causing arbitrary delay and loss rates on a link. WANem works at a relatively high-level; you won't see physical errors on the link but packets will be dropped. It can be deployed on commodity hardware.
I know there are a few other tools which serve similar purposes but I can't ...
15
However, when I move to the remote location, even though the wifi signal strength is either 3/4 or 4/4 bars, the packet loss is massive, and the latency varies wildly where for a stretch it will report pings of about 50ms, but then will drop to 800+ and about 10% are just timed out packets altogether.
if the signal strength is good, why would this distance ...
12
Wireless video cameras cause about the worse interference. You don't need other 802.11 devices or access points to cause trouble as microwave ovens, some DECT phones, bluetooth, etc. can all run into the 2.4GHz band. Line-of-sight isn't the only way you can "see" other devices competing for your channel. Wireless is a shared-medium, so even with other ...
12
On Cisco devices, you can use Cisco IP SLA. You need to first configure and enable it, and then monitor the results.
Steps:
1. ip sla monitor operation-number
2. type echo protocol ipIcmpEcho {destination-ip-address | destination-hostname} [source-ipaddr {ip-address | hostname} | source-interface interface-name]
3. frequency seconds
4. ip sla monitor ...
12
To add to the previous answer:
A "Cumulative ACK" implies that all the bytes sent by the sender (so far) have been received correctly by the receiver. In order words, when the sender receives an ACK with sequence number n, the receiver is telling the sender that it has received every byte up to and including n-1 and it is expecting byte n next.
In "...
11
I'm wondering why packets don't enter in the queue at all before being dropped.
Because they were errors: 8097 input errors, 7120 CRC, 894 frame It will not queue a packet that wasn't received properly -- or wasn't received completely (input queue is in software, you can still overrun the hardware queue, which you cannot change)
11
There can be several things going on - the most common would be the use of TCP Fast Retransmission which is a mechanism by which a receiver can indicate that it has seen a gap in the received sequence numbers that implies the loss of one or more packets in transit. The repeated acknowledgements at the last known value before the gap signal which packets the ...
10
I am looking for a technology to achieve TCP connection fault tolerance with the help of two links between hosts and without time delays for route failure detection. Something like this:
link1 packet1copy1->
--------------------------
packet1-> / \ packet1copy1/...
9
The issue: Customers can experience total packet loss for 10s, 30s and more. This brings the TCP connection delivering the prices to a halt, thus rendering the website useless. All connectivity from the data center to the peering points have been sized correctly, and have capacity to spare.
It has been asserted that this is commonplace in public ...
9
One way to do this is ICMP Timestamp, which is milliseconds from midnight UTC. It has the added benefit that you don't necessarily need to control both ends, as long as the far-end is not firewalled, there is good chance it'll work.
However, to have reliable one-way measurements, you need reliably same time in both ends. As ICMP timestamp only have ...
8
Interface Internal-Data0/0 "", is up, line protocol is up
2749335943 input errors, 0 CRC, 0 frame, 2749335943 overrun, 0 ignored, 0 abort
^^^^^^^^^^^^^^^^^^
0 output errors, 0 collisions, 0 interface resets
You show overruns on the InternalData interfaces, so you are dropping traffic through the ...
8
There are many causes for this type of behavior, and one of them is what is called the hidden node problem. This is a very common problem that is often overlooked (in my experience).
The use of a range extender can often create a situation where this problem occurs and can reduce the effectiveness of some of the solutions to the hidden node problem. In ...
7
A wireless network is only a single, shared medium with a limited total bandwidth. The more clients compete for bandwidth the smaller each slice gets.
Additionally, the simple presence of clients consumes bandwidth = air time. It's not much per client but it sums up.
Also, more clients also mean more potential senders, so that collisions become more likely....
6
Self-interference is an identity issue within mesh wireless networks, primarily with pre 802.11b wireless networks. The standards prior to 802.11n required only 3 non-overlapping channels of the 2.4GHz band. In large mesh deployments you would have multiple cells conflicting with one another and reporting back to the primary host controller.
802.11n ...
6
So first of all show fabric utilization all shows fabric utilization, not CPU utilization. Fabric doesn't have CPU component per se, and you can go all up to 100% of fabric utilization without any adverse effects similar to what CPU causes when nearing to the full load.
Next, the WS-X6548-GE-TX is 8Gbit/s card, so "old" fabric attached LC with 8Gbit/s ...
6
On juniper hardware you can use the RPM service to get those measurements. The service can be configured to monitor specific interfaces which will help with the 'per-link' requirement.
6
However, when we run the same WinMTR tool to our gateway, we receive a 0% packet loss on the gateway, but as of last test a 9% packet loss on the router...
[snip]
... I'm not entirely sure how to process this information...
You've misunderstood how WinMTR should be used; this is a common problem. The first line you should look at in any mtr output is ...
6
Because everyone is competing for airtime. It's the same reason traffic slows down on a highway as more cars travel on it.
BTW 802.11 uses CDMA/CA That's collision avoidance, not collision detection (Ethernet).
5
WANem is great, like Jeremy said. Other interesting tools are netem or dummynet.
See the following examples with netem:
# tc qdisc change dev eth0 root netem loss 0.1%
# tc qdisc change dev eth0 root netem delay 100ms 10ms 25%
You can grab more informations on the netem page or on this excellent SO answer.
5
Both are possible. If no units are mentioned, I would assume it means
(# packets lost)/(# packet sent).
Often, this ratio will be given as a percentage.
When 'packet loss rate' is meant as a rate per unit of time, that unit of time should be specified.
5
Total Packet loss for 10-30 seconds is surely caused by other factors than lost packets somewhere on Internet. A lost tcp packet would normally generate a retransmit within ~10-100ms. Congested links would not block all traffic for such a long time period.
A congested link will normally not make a router choose an alternate route unless link state is lost, ...
5
There are a number of possibilities here, not limited to, but including:
The CPE's CPU is maxing out. (CPE=Customer Premesis Device)
Check the specifications for the router you are using to make sure it can support the level of traffic you're trying to push. Try and graph the CPE's CPU if you are unsure.
Bufferbloat in your ISP
If your ISP has configured ...
5
Found the solution to my own question with the help and hint from @Guy Harris.
The kernel was dropping packets due to that the buffer tcpdump uses got overfull when capturing whole TCP packets.
From tcpdump man page:
packets dropped by kernel (this is the number of packets that were dropped, due to a lack of buffer space, by the packet capture mechanism ...
5
The Selective ACK Option can specify more than one "block" of received traffic. Here is what the option looks like on the wire (taken from RFC 2018, Section 3):
+--------+--------+
| Kind=5 | Length |
+--------+--------+--------+--------+
| Left Edge of 1st Block |
+--------+--------+--------+----...
5
All links introduce latency. It's a trivial amount when passing traffic over a 2M Ethernet patch cable but it's substantial on a trans-Pacific circuit.
Some links also have packet loss. It might be a function of the link being congested or there could be a physical issue like a flaky cable, RF interference on a wireless link or other anomalies. This is ...
5
If a wireless network has collision detection and avoidance, how comes the network slows down if more clients connect to it?
To begin with I wanted to note that 802.11 makes use of collision avoidance, but not detection. These are two entirely different processes.
As for why an 802.11 network slows down if there are more clients, there are two primary ...
5
From Cisco tech note:
The ASA interface error counter "overrun" tracks the number of times
that a packet was received on the network interface, but there was no
available space in the interface FIFO queue to store the packet. Thus,
the packet was dropped. The value of this counter can be seen with the
show interface command.
4
If you receive a packet on frequency X, you can't also transmit the same info on that same frequency. So you need to wait. that's why if you use the newer 802.11 protocol's who use more then one frequency you are going to have less interference(its not really interference its more like a busy phone line :P).
A side from Co-Channel interference(http://www....
4
Etherate enables you to measure throughput, latency and packet (frame) loss down at layer 2 directly over Ethernet (which sounds like what you are looking for). It doesn’t measure jitter at present but it will do in the future.
Using it you can generate layer 2 Ethernet traffic in a controlled manner which you can measure.
You can specify traffic flow ...
4
Check out Y.1731 protocol (or IEEE 802.1ag, or OAM). It's fairly easy to implement in software (I'm guessing that's what you're aiming at), and it's supported by all the physical network elements.
There is a very naive
open-source Y.1731 implementation in C, which you can look at.
Please note that Y.1731 is not designed to cross physical network boundary (...
Only top voted, non community-wiki answers of a minimum length are eligible
