This is entirely normal behaviour with a duplex mismatch.
Why was only downstream affected and not upstream?
Since the computer is operating in full duplex mode, it isn't utilizing CSMA-CD. This means it doesn't check if the medium is idle before it transmits, nor will it perceive any data it receives while transmitting as a collision. As such, the ...
As far as I understand, CSMA/CD is an access method to place Ethernet
frames on the wires in computer networks.
Not quite. CSMA/CD is a method (algorithm) for gaining access to media in a multi-access environment. The original Ethernet was half-duplex, meaning all stations used the same channel (circuit) for sending and receiving. CSMA/CD is used to ...
For 10BASE-T and 100BASE-TX, the MDI side (NICs, routers) transmits on pairs 1-2 and receives on 3-6. On the MDI-X side (hubs, switches) the pairs are swapped. In general, concentrators use MDI-X pinout while edge devices (from the L2 segment perspective) use MDI pinout.
Whether the link uses full or half duplex doesn't matter.
Auto negotiation takes only ...
the CCNA guide states that the CSMA/CD protocol is used to stop
devices on the same medium e.g. same wire like on a bus network
transmitting simultaneously to avoid collisions.
That really isn't correct. the CD part is Collision Detection. CSMA/CA (CA for collision avoidance) is used by other protocols, like Wi-Fi, is to try to avoid collisions.
A hub ...
100BASE-T (fast ethernet over 2 wire pairs) is full duplex, meaning 100Mbit per direction, simultaneously.
It is possible to configure a 100Mbit network interface in half duplex, meaning that the total bandwidth available for send+receive is 100Mbit (as opposed to 200Mbit for full duplex)
This (autonegotiation) is explained in various sections of the IEEE 802.3 specifications.
Auto-MDIX is mostly a function of gigabit interfaces being able to TX and RX on all four pairs. I don't recall this being part of 802.3, but the logic for it (looking for carrier signal, and/or link pulses) is simple enough that anything capable of gig will support it.
Time division duplex (TDD) concerns at least a 2 way communication. For example, a discussion is taking place between two people, say a and b, a talks whilst b listens, then b talks whilst a listens. A and b can't talk at the same time, hence timely divided and both share a time unit. Full duplex can be imagined as if both a and b talk and listen at the same ...
If you're asking about ethernet duplex, then the full- or half-duplex nature of a given link is negotiated when the link comes up, or alternatively set in configuration. (See autonegotiation at Wikipedia).
All full-duplex ethernet links are capable of working in half-duplex, and will do so when connected to a half-duplex device. (Presuming correct ...
Half-duplex mode in Ethernet still uses 2 pairs. The difference to full-duplex is that it only uses one pair at a time.
Half-duplex mode with twisted pair cables only exists because of hubs:
Reason for half-duplex mode in Ethernet?
half-duplex mode support in Ethernet chipsets was crucial in case either a network hub (hub is internally a single wire) or ...
You seem to understand CSMA/CD quite well - but before describing how things work in a switched environment, I'd like to break it down for other readers who might not know.
CSMA/CD stands for
with Collision Detection
When multiple devices are all sharing a network cable, usually only one at a time can transmit. This used to be ...
I always thought it didnt because they're on separate wires on each port on the hub, and the hub forwards all frames onto all interfaces by default,
Hubs don't work with complete frames, they work at a lower level than that. When data starts arriving on one port it immediately starts being sent out on the other ports, there are no buffers (though there will ...
The router/switch you are plugging into should negotiate with the card. If you are plugging into a managed switch, you will likely be able to hard code the port's speed/duplex. In a Cisco device this would look like so:
Switch# conf t
Switch(config)# int fa0/0
Switch(config)# speed 10
Switch(config)# duplex half
If the TCP was tested, there are a lot of things you can't control or even to imagine. The difference in downstream/upstream could be easily caused by NIC internal priority settings, buffers for RX/TX and essentially low-level settings that dictate how to handle RX and TX traffic.
'sh controllers' should report any simultaneous RX and TX condition as ...
In a hub, all the ports are electrically connected, and only one device at a time can talk on the wire. If more then one device talks at the same time, it creates a collision, so hub ports are all half-duplex.
In a switch, each port is isolated, and traffic from one port is selectively sent to other ports, so there are no collisions in the switch. Unlike a ...
The mode/speed is configured on the switch port! So you could have 12 ports in half-duplex(for devices that don't support full-duplex) and 12 ports in full-duplex. On the assumption that you're on a physical "star topology", those in "half" won't disrupt the others.
Have you tried simply plugging it in?
Many, even most, (but not all) gigabit ports will negotiate down there.
If the one you have won't, buy a small switch that will (look for specs like 10/100/1000 for the port speeds), and put it between slow old device and the rest of the network.
Alternatively, put a new(er) network card in the device.
Half duplex can not send and receive at the same time. It also has algorithms to detect and handle collisions (CSMA-CD). Think of it like a walkie talkie or a CB radio, only on a network.
Full duplex can send and receive at the same time. Think of it as a telephone.
One issue that can arise is sometimes you will see a 100 Mbps half duplex connection which ...
The "persistent strategy" that you mention seems to be related to the concept of "freezing" during the backoff. Overall, 802.11 channel access can be described in the following steps -
1/ Check if the channel is idle. Wait for an additional DIFS to see if the channel is still idle. Then transmit.
2/ If the channel is found to be busy, enter backoff. The ...
In order to be able to read the destination MAC address and then make a decision on which port(s) the packet needs to be sent to, the switch needs to be able to buffer the incoming packets.
Of course, there are lots of clever ways designed to minimize this buffering to maximize the throughput of the switch ports. But these ways are all internal to the ...
I have done this several times (connecting 10M devices to 1G ports) and what I can tell is there is no rule for it, that could tell us in advance whether it will work or not. In theory, it should work, but some devices simply can't negotiate with the switch (or the switch with the device), which means that you will have to force the speed/duplex, just like ...
Half duplex means that transmission is possible in both directions, but only one of the devices can successfully transmit at a time.
Full duplex means that transmission is possible in both directions at the same time.
But if you are asking on a networking site about full duplex and half duplex you are probably asking about the terms in the context of ...
Half-duplex is used to describe communication where only... one side can talk at a time. Once one side has finished transmitting its data, the other side can respond. Only one node can talk at a time. If both try to talk at the same time, a collision will occur on the network. As you can understand, this method of communication is not very efficient and ...
There are basically two ways to close a TCP connection between host A and B:
The proper way: A is sending a FIN, telling that it would not send new TCP segments anymore. It will continue sending ACKs though. The connection is half closed and can stay like this forever. When B has finished sending data, he can close his part of the connection with a FIN too. ...
Client then does what it's instructed to do... normally there are limits in place to deal with so called "embryonic connection" as half open connection state is normally achieved when negotiating connection .
Without limits and timeouts endpoint is exposed to SYN flood DoS attack.
You could read on RFC 793 , page 33 , about " Half-Open Connections and Other ...