I don't know that much in detail how full-duplex works and I wonder if collisions can occur in them. Take a UTP cable for an example – are some cables within it reserved for data going one way and the other wires for data going the other way? Can two frames going in the same direction crash with each other?
Full-duplex collisions in wires
duplextransport-protocol
Related Solutions
The usual suspects in the case of autonegotiations are:
- bad cables
- bad ports, SFPs or NICs
- port configs (are they both set to auto and do they both list the 1000BASE-T FD ability?)
- bugs, compatibility or legacy issues
I would not recommend a fixed speed and duplex setting in this (or almost any) situation. The days of frequent autoneg issues and incompatible implementations are gone, on recent equipment such issues are very rare. If autoneg is not working, switching to a fixed setting is a workaround, hiding the underlying issue that causes the autonegotiation to fail. Not fixing this issue might allow it to bite you later.
Also, the probability of speed or duplex mismatches and the like is actually much higher in an environment with fixed settings, caused by left over settings when moving equipment around.
As an example, if in your case the cable is to blame, setting both sides to 1000 fixed could disable the link with the faulty cable completely. Autonegotation gracefully degrades you to 100. It is of course up to you or your monitoring equipment to detect and fix this.
Interesting blog post, with links some vendor recommendations: "EtherealMind on Autonegotiation"
First a word about:
I understand word persistent as following : no one else can occupy wire at the time of persistent connection. So this connection is only one-to-one. But this is not right. Persistent connection can be established while other packets are going through the same wire.
This is circuit-switched network vs packet-switching network
circuit-switched network
In such networks, a physical dedicated line is established between the two hosts who wants to communicate.
The better example is the first phone networks where human operators manually connect two phone lines to establish communications on request.
Latter human operators where replaced with mechanisms. The enterprise internal version of such mechanism is known as "PBX" (Private Branch eXchange).
In this case you actually have a physical connection that is maintained and nobody else can use any of the circuit during that time.
packet-switching network
IP networks are packet-switched networks. As you said many packets from several applications can flow on the wire at the same time, and for a single conversation, different packets can take different routes.
This allow better utilization of the link and more robust design (of course it has some drawbacks).
So at the IP layer there's no "connection" nor "session" established.
There's an emerging trend to identify flows and apply specific switching and / or routing rules to them, and a flow can for example correspond to a TCP session but this is not what we usually refer to when speaking about connection / session.
Connection
IP provide two main protocols (among others) to establish communication between two hosts : UDP and TCP.
UDP is connection-less. That means (quoted from Wikipedia) that "a message can be sent from one end point to another without prior arrangement. The device at one end of the communication transmits data addressed to the other, without first ensuring that the recipient is available and ready to receive the data".
TCP is connection-oriented. Before actually transmitting date, the two hosts talk to each other to check that they are both available and agree to exchange some kind of data (think of the preamble of a typical phone call). This connection is maintained until one host signal that it want to end it or after some time has passed without exchanging any data.
A VPN connection usually work the same way. Two hosts exchange some information (including which encryption protocol to use, some cryptography keys and user authentication mechanism etc...) and if bot agree on the terms, a connection is established and maintain. Usually some keep-alive packets are sent at regular interval to say "I'm still here, don't drop the connection".
Session
Sessions are established by applications. A session can correspond to a single TCP connection, but a session can use several different TCP connection or use UDP as the transport protocol.
A HTTP(s) session for example may use cookies to identify the user and can provide access to different resources (think about web banking).
A Voice Over IP (VOIP) phone call will use the SIP protocol. SIP means "Session Initiation Protocol" and it can run over UDP.
The exact mechanism of establishing / maintaining / closing a session depends on the applications used.
Best Answer
Full-duplex basically means communication can happen both ways, negating the possibility of a collision. The below diagram should make it a little more clear. One pair is designated a transmit pair, and the other a receive pair. In most environments now, it isn't even necessary to match up transmit/receive pairs, as MDIX handles that for you.
This doesn't eliminate the possibility of collisions on one side as a result of a configuration mistake, such as half-duplex on one side and full-duplex on the other. That's fairly common.
No, frames wait in a buffer until they can be transmitted across a link. One by one.