Adding this here just to memorize this good and very often unused keystrokes.Think that each person working with cli at least 1 hour a day should know this rather than moving the arrows 🙂
CTRL + B – Move the cursor left
CTRL + F – Move the cursor right
CTRL + A – Move the cursor to beginning of line
CTRL + E – Move the cursor to the end of the line
CTRL + W – Erase the preceding word
CTRL + U – Erase from cursor to beginning of the line
CTRL + K – Erase from cursor to end of the line
CTRL + Y – Paste erased text
CTRL + P – View the previous command (cursor up)
CTRL + N – Vie the next command (cursor down)
Would like to recommend a great book for Linux newbies who would like to learn a bit more :
How Linux Works: What Every Superuser Should Know
Just finished the TCP course from INE :
CCIE R&S: Understanding Transmission Control Protocol (TCP)
Really recommend this to anyone who is interested in a bit deeper dive of how TCP works, great quality content, Keith Bogart is doing amazing job as instructor !
Some TCP facts which I didn’t mentioned in my previous post :
- Before TCP connection is established TCP goes through the following steps:
- Closed Initial State
- Active Open (APP notifies the CPU and requests for service time) – client side
- Transmission Control Block setup process – CPU creates TCB to keep track of each new TCP connection – for each TCP session we create a new TCB with unique identifier (socket – SRC IP; SRC TCP Port; DST IP; DST TCP Port)
- Initial sequence number will be random to prevent attacks on TCP
- When TCB is ready we are sending SYN(x random Seq# number) – this is called a Syn Sent State
- Receiving Syn(y random seq# number from server) + ACK (seq# x + 1)
- Sending ACK(seq# y+1) for that
- TCP Client side state changes to Established
This is Active Open – TCB creation process, initiated only per need of client.
Also we have Passive Open (server – listening process)
- The initial state – closed
- TCB creates partiality filled socket – so called unspecified passive open
- From server is listening on specific port, when receives a SYN from client
- Changes the state to Syn Received
- Then responds with ACK and state changes to Established
A bit about Nagle :
- On by default on most of operating systems
- When congestion occurs might be harmful – Storage vendors advising to disable it
- Basically what Nagle does after getting the CPU time is gathers the data from Buffer and stores it – doesn’t send anything until we have a bytes on a flight = unacknowledged bytes
- If yes it will keep storing until his he has those unack bytes, after receiving ACKs for them it will send out multiple segments which we collected from buffer.
MSS VS MTU
TCP checks the MTU and configures MSS accordingly. If we have a jumbo MTU 9216 MSS will be 9216 – 20 (IP Header) – 20 TCP header.
Relative Sequence Number in Wireshark and Subdisector
- Wireshark by default shows not the real sequence numbers but the relative ones – this can be changed in menu
- When troubleshooting HTTP long responds – be aware that by default Allow subdisector to reassemble TCP stream in Wireshark is enabled – which could bring a lot of confusion as it reasembles the packets and wait of full web page load, instead of getting the picture in 1ms you can see it wireshark as getting in 30 seconds, despite that there was no problem at all. Recomending to view a video on this : Wireshark Tutorial Series #2. Tips and tricks used by insiders and veterans
- Built to count the bytes in segment
- When segment sent only with ACK without the data you might see that seq# is not incrementing – as there is nothing to count
- Also it might increment even while empty – this called phantom byte – add +1 to seq#
About the Missed ACKs
- Not each sent segment will receive an ACK for it – might be we will be acking each 5 segments
- RTO – Re-transmission timeout value – depends on RTT, also so called SRTT Smooth RTT – when we are comparing multiple RTT values and taking the average.
- Why TCP is reliable ? Because before and after sending the Segment it puts it into the Re-transmission Queue and only after receiving an ACK it removes the segment from there.
- Duplicate ACKs are appearing after one of the segments has been delivered but other one was lost – then we are repeating the last ACKed segment – selective repeat here comes into play with option field which helps to retransmit only what is missing.
Sliding Window Rules :
- Bytes sent and acknowledged – removing from retransmission queue.
- Bytes sent but not yet acknowledged
- Bytes not yet sent for which receiver is ready – usable window
- Bytes not sent and receiver is not ready to receive them
- No priorities here, just flagging the segment about it’s urgency – TCP does nothing special here, only allows to upper layer APP to identify the urgent packet.
- So no VIP delivery from the TCP side.
- Urgent pointer field points to the first byte of non urgent data.
Old known stuff, probably for everybody who is somehow related to networking, but anyway, putting it here too.
IEEE 802.3x – Wikipedia link
If QoS is enabled and you like to prioritize the traffic, flow control needs to be disabled,as it doesn’t care about any higher level prioritization, just when ingress traffic is coming in faster than receiver can accept it, flow control will kick in and send pause frames until the ingress-egress rate will be equalized or ingress rate is lower than egress of that interface.
A bit more info from Dell FTOS 9 documentation about flow control :
I would use it only for storage – for example iscsi traffic, in separated network, then it won’t do any harm.. probably 🙂
But of course no way of using it on trunk links, other switch facing links and etc.
Installing – Let’s use Debian based manager :
Apt-get install open-iscsi
Apt-get install iperf
Apt-get install nload
Scanning for targets :
Iscsiadmin -m discovery -t st -p target_ip
Iscsiadm -m node -u
Iscsiadm -m node –login
Check if you see the object :
New disk should appear in dev – like sdx \–sdx1
How to partition (if wasn’t partitioned yet)
Connecting the drive to system
Mount /dev/sdc1 /mnt
Creating big file with random data :
Dd if=/dev/urandom of=rnd.20G count=1024 bs=20M
Also you can check the copy speed live via rsync (when copying from mount location to mount for example) –
rsync –progress source destination
Live interface monitoring can be done via
nload – same like top but for nics
And at the end if you’d like to check what is the performance of network(without storage) – connect second host to same switch and run iperf
Iperf -s (on servers side)
Iperf -c x.x.x.x -d (-D option for simultaneous bi-directional bandwidth measurement)
While the transmission speeds are advancing – totally delays are dominated by propagation delay which is bound to the speed of light.
End to end delay is the time from when we sent the first bit of the first line until last bit arrives to destination.
Basically everything can be determined except queuing delay – it’s an unpredictable variable.