Monday, 7 September 2020

TCP headers

The TCP headers must be able to perform all of the tasks above. We have already explained when and where some of the headers are used, but there are still other areas that we haven't touched very deeply at. Below you see an image of the complete set of TCP headers. It is formatted in 32 bit words per row, as you can see.

 

TCP HEADER

Source port - bit 0 - 15. This is the source port of the packet. The source port was originally bound directly to a process on the sending system. Today, we use a hash between the IP addresses, and both the destination and source ports to achieve this uniqueness that we can bind to a single application or program.

 

Destination port - bit 16 - 31. This is the destination port of the TCP packet. Just as with the source port, this was originally bound directly to a process on the receiving system. Today, a hash is used instead, which allows us to have more open connections at the same time. When a packet is received, the destination and source ports are reversed in the reply back to the originally sending host, so that destination port is now source port, and source port is destination port.

 

Sequence Number - bit 32 - 63. The sequence number field is used to set a number on each TCP packet so that the TCP stream can be properly sequenced (e.g., the packets winds up in the correct order). The Sequence number is then returned in the ACK field to ackonowledge that the packet was properly received.

 

Acknowledgment Number - bit 64 - 95. This field is used when we acknowledge a specific packet a host has received. For example, we receive a packet with one Sequence number set, and if everything is okey with the packet, we reply with an ACK packet with the Acknowledgment number set to the same as the original Sequence number.

 

Data Offset - bit 96 - 99. This field indicates how long the TCP header is, and where the Data part of the packet actually starts. It is set with 4 bits, and measures the TCP header in 32 bit words. The header should always end at an even 32 bit boundary, even with different options set. This is possible thanks to the Padding field at the very end of the TCP header.

 

Reserved - bit 100 - 103. These bits are reserved for future usage. In RFC 793 this also included the CWR and ECE bits. According to RFC 793 bit 100-105 (i.e., this and the CWR and ECE fields) must be set to zero to be fully compliant. Later on, when we started introducing ECN, this caused a lot of troubles because a lot of Internet appliances such as firewalls and routers dropped packets with them set. This is still true as of writing this.

 

CWR - bit 104. This bit was added in RFC 3268 and is used by ECN. CWR stands for Congestion Window Reduced, and is used by the data sending part to inform the receiving part that the congestion window has been reduced. When the congestion window is reduced, we send less data per timeunit, to be able to cope with the total network load.

 

ECE - bit 105. This bit was also added with RFC 3268 and is used by ECN. ECE stands for ECN Echo. It is used by the TCP/IP stack on the receiver host to let the sending host know that it has received an CE packet. The same thing applies here, as for the CWR bit, it was originally a part of the reserved field and because of this, some networking appliances will simply drop the packet if these fields contain anything else than zeroes. This is actually still true for a lot of appliances unfortunately.

 

URG - bit 106. This field tells us if we should use the Urgent Pointer field or not. If set to 0, do not use Urgent Pointer, if set to 1, do use Urgent pointer.

 

ACK - bit 107. This bit is set to a packet to indicate that this is in reply to another packet that we received, and that contained data. An Acknowledgment packet is always sent to indicate that we have actually received a packet, and that it contained no errors. If this bit is set, the original data sender will check the Acknowledgment Number to see which packet is actually acknowledged, and then dump it from the buffers.

 

PSH - bit 108. The PUSH flag is used to tell the TCP protocol on any intermediate hosts to send the data on to the actual user, including the TCP implementation on the receiving host. This will push all data through, unregardless of where or how much of the TCP Window that has been pushed through yet.

 

RST - bit 109. The RESET flag is set to tell the other end to tear down the TCP connection. This is done in a couple of different scenarios, the main reasons being that the connection has crashed for some reason, if the connection does not exist, or if the packet is wrong in some way.

 

SYN - bit 110. The SYN (or Synchronize sequence numbers) is used during the initial establishment of a connection. It is set in two instances of the connection, the initial packet that opens the connection, and the reply SYN/ACK packet. It should never be used outside of those instances.

 

FIN - bit 111. The FIN bit indicates that the host that sent the FIN bit has no more data to send. When the other end sees the FIN bit, it will reply with a FIN/ACK. Once this is done, the host that originally sent the FIN bit can no longer send any data. However, the other end can continue to send data until it is finished, and will then send a FIN packet back, and wait for the final FIN/ACK, after which the connection is sent to a CLOSED state.

 

Window - bit 112 - 127. The Window field is used by the receiving host to tell the sender how much data the receiver permits at the moment. This is done by sending an ACK back, which contains the Sequence number that we want to acknowledge, and the Window field then contains the maximum accepted sequence numbers that the sending host can use before he receives the next ACK packet. The next ACK packetwill update accepted Window which the sender may use.

 

Checksum - bit 128 - 143. This field contains the checksum of the whole TCP header. It is a one's complement of the one's complement sum of each 16 bit word in the header. If the header does not end on a 16 bit boundary, the additional bits are set to zero. While the checksum is calculated, the checksum field is set to zero. The checksum also covers a 96 bit pseudoheader containing the Destination-, Source-address, protocol, and TCP length. This is for extra security.

 

Urgent Pointer - bit 144 - 159. This is a pointer that points to the end of the data which is considered urgent. If the connection has important data that should be processed as soon as possible by the receiving end, the sender can set the URG flag and set the Urgent pointer to indicate where the urgent data ends.

 

Options - bit 160 - **. The Options field is a variable length field and contains optional headers that we may want to use. Basically, this field contains 3 subfields at all times. An initial field tells us the length of the Options field, a second field tells us which options are used, and then we have the actual options. A complete listing of all the TCP Options can be found in TCP options.


 


Thursday, 13 August 2020

LOG ALL SESSION OUTPUT USING PUTTY

I use Putty for getting telnet and SSH connection to the devices under my administration.

For those who are unware of what Putty is - Putty is one of the best Telnet and SSH Client.

Every Network Engineer won't mind saving all the session output logs he has worked on .

The session logs are saved on your desktop disk.

There are many Advantage of SAVING ALL THE SESSION LOGS

+ You can refer to those sesssion in case you have to check some (some mistakes you made)

+ Evidence of the configuration and checks you performed.

+ many more

Lets Configure Putty to log all your session output

+ Open Putty

+ Session  -> Logging

+ Using Putty Parameters for log setting - 'E:\Puttylogs\&H-&Y&M&D-&T.log' which means'
 

&H = Hostname
&Y = Year
&M = Month
&D = Day
&T = Time



+ Then save this log settings to the Default setting 




Now every new Putty session logs output will be automatically save on the disk of your computer .

Saturday, 8 August 2020

Enabling SSH

 Troubleshoot Ticket 


Network Team uses telnet (port 23) to login in the device 10.1.1.1

Need to restrict the use of telnet since telnet is not secure ; session is not encrypted

Enable ssh (port 22) which is secure protocol and where the session is encrypted

Can be configured in working hours since no downtime is required 

========================================================

Lets open Putty and try to login via ssh to device 10.1.1.1

Here we can see we are getting error - Connection refused which means ssh is not enabled on the device

10.1.1.1 and to solve it we need to enable ssh 


Now lets try to login via telnet 


 

We are able to login via telnet !

 

So lets enable SSH 

Telnet session is insecure because the information is in the clear text 

For SSH session that is not the case , for ssh session the information is encrypted  .

To encrypt / decrypt any information or data we need to generate certain keys which are associated with the hostname and domain name . 

 So lets first configure a hostname and domain name for the device

R1(config)#hostname PUNE_ROUTER
PUNE_ROUTER(config)#
PUNE_ROUTER(config)#ip domain name amartechstuff.net
PUNE_ROUTER(config)#

Note:- I am just configuring a random domain name . If you are working in real environment your 

organization will have valid public domain name .

Now lets  move forward and generate crypto keys which will be used to encrypt / decrypt the information 

PUNE_ROUTER(config)#crypto key generate rsa
The name for the keys will be: PUNE_ROUTER.amartechstuff.net
Choose the size of the key modulus in the range of 360 to 4096 for your
  General Purpose Keys. Choosing a key modulus greater than 512 may take
  a few minutes.

How many bits in the modulus [512]: 1024
% Generating 1024 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 1 seconds)

PUNE_ROUTER(config)#
*Aug  8 12:16:18.659: %SSH-5-ENABLED: SSH 1.99 has been enabled
PUNE_ROUTER(config)#^Z

You can see that the name of the key is PUNE_ROUTER.amartechstuff.net i.e 

hostname + domain name 

Lets see the key 

PUNE_ROUTER#sh ip ssh
SSH Enabled - version 1.99
Authentication timeout: 120 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size : 1024 bits
IOS Keys in SECSH format(ssh-rsa, base64 encoded):
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDfHDOhreEAVbaifqV56LS1qTGicGEC+2s0EqRwA4Ef
qIh8DS029RxkaLYll4iKlxkdJ6Qu/TphdbefEmpSidzVu+gJ80NUUxmlpiMGtF0SY5Yzd6VCsvyRFQo8
dwsdioq686NK+UpYGh46mM3GxP2cDKuvT7ytdDlBSgnsWKn04w==
PUNE_ROUTER#


Now the next and last step is to check and enable ssh under line vty 

line vty 0 4
 login local
 transport input telnet
line vty 5 15
 login local
 transport input telnet

Now we can see that telnet is configured .

Lets change it to ssh

PUNE_ROUTER#config
Configuring from terminal, memory, or network [terminal]?
Enter configuration commands, one per line.  End with CNTL/Z.
PUNE_ROUTER(config)#line vty 0 15
PUNE_ROUTER(config-line)#transport input ssh
PUNE_ROUTER(config-line)#^Z

Now lets check whether ssh is enabled or not 



 

 
https://networkengineerstuff.blogspot.com





Thursday, 6 August 2020

Using Straight Cable & Crossover Cable

Need to connect two devices !

But which Ethernet cable to use ?????

Straight Cable or Crossover Cable ????????

It may be confusing for many of us !!!!!

But Guys !!!! There is a simple method to figure it out !

Before that lets see what is Straight Cable and Crossover Cable

There are two standards adopted for Cabling EIA/TIA 568A & EIA/TIA 568B.

When you use single standard (either EIA/TIA 568A or EIA/TIA 568B) on both the end of cable then the resulting cable is STRAIGHT CABLE.


On the other hand if you use different cabling standard on the ends of cable then the resulting cable is CROSS CABLE



Now lets go back to our topic

Guys ! To figure out which cable to use

Always Remember

Same Devices - Use Crossover Cable

Different Devices - Use Straight Cable


So lets see which cable to use while connecting different Networking devices

1) Switch to Switch =  Crossover Cable

2) Router to Router =  Crossover Cable

3) Switch to Router =  Straight Cable

4) PC to PC =  Crossover Cable

5) Switch to PC = Straight Cable

6) Router to PC = Crossover Cable ( since they both have same components)

Thanks for Reading

amartechstuff

Monday, 3 August 2020

ADD YOUR OWN LOCAL PC IN GNS3 !! ITS EASY & SUPER COOL

Wondering how you could add your own local PC in GNS3 and use it !

Its easy and super cool !!!!!

Just Follow Below Steps


Part 1 – Need to create a Microsoft loopback adapter in our desktop.


⦁    Step 1 – Open hardware wizard

In cmd prompt type hdwwiz.exe and press enter.


Or start and search or hddwiz and click on same to open the hardware wizard



⦁    Step 2:- Enter into the setup of Hardware Wizard


⦁    Step 3:- Install the hardware (manually)


⦁    Step 4:- Select Network Adapters


⦁    Step 5:- Select Microsoft > Microsoft Loopback Adapter


⦁    Step 6:- Click Next


⦁    Step 7:-Click Finish to create Microsoft Loopback Adapter




Part 2 – Assign IP address to Microsoft loopback  adapter in our desktop.


⦁    Step 1 :-  Network and Sharing Center  Change adapter settings



⦁    Step 2:-Internet Protocol Version 4 (TCP/IPV4)



⦁    Step 3:-Assign the IP address


⦁    Step 4:- Verification


Part 3 – Adding our desktop in GNS3.


Cloud is our desktop










Once done !!!!!Now able to connect and ping



Thanks for Reading !!!!

AMARTECHSTUFF