networking:arp:about_arp
Differences
This shows you the differences between two versions of the page.
| networking:arp:about_arp [2021/01/07 09:41] – created peter | networking:arp:about_arp [2021/01/07 09:52] (current) – peter | ||
|---|---|---|---|
| Line 5: | Line 5: | ||
| Although computer programs use IP addresses to send and receive messages, the actual underlying communication always happens over the physical address. | Although computer programs use IP addresses to send and receive messages, the actual underlying communication always happens over the physical address. | ||
| - | Let’s first understand how communication happens over the wire. Let’s try pinging | + | Let’s first understand how communication happens over the wire. |
| + | |||
| + | Let’s try pinging | ||
| <code bash> | <code bash> | ||
| Line 37: | Line 39: | ||
| tcpdump: verbose output suppressed, use -v or -vv for full protocol decode | tcpdump: verbose output suppressed, use -v or -vv for full protocol decode | ||
| listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes | listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes | ||
| - | 21: | + | 21: |
| - | 21: | + | 21: |
| - | 21: | + | 21: |
| - | 21: | + | 21: |
| </ | </ | ||
| Line 46: | Line 48: | ||
| The output of tcpdump command is pretty straight forward. | The output of tcpdump command is pretty straight forward. | ||
| - | It shows a continues series of ICMP echo requests going out from our server (indicated by 10.12.2.73), and subsequent replies coming back from google (indicated by 8.8.8.8). | + | It shows a continues series of ICMP echo requests going out from our server (indicated by 192.168.1.2), and subsequent replies coming back from google (indicated by 8.8.8.8). |
| - | As 8.8.8.8 is not in the same network, the local server cannot reach there directly without a gateway. | + | As 8.8.8.8 is not in the same network, the local server cannot reach there directly without a gateway. |
| + | |||
| + | So the ping requests to 8.8.8.8 should flow via your gateway. | ||
| + | |||
| + | Gateway address can be found using the command **route -n**. | ||
| <code bash> | <code bash> | ||
| Line 59: | Line 65: | ||
| Kernel IP routing table | Kernel IP routing table | ||
| Destination | Destination | ||
| - | 0.0.0.0 | + | 0.0.0.0 |
| - | 10.12.2.0 | + | 192.168.1.0 |
| </ | </ | ||
| - | Our gateway here is 10.12.2.1. This is clearly indicated by the very first line in the above output. | + | <WRAP info> |
| + | **NOTE: | ||
| - | So even if we need to reach 8.8.8.8, we need to go via 10.12.2.1 (as it is our gateway). | + | This is clearly indicated by the very first line in the above output. |
| + | |||
| + | For reaching anywhere (indicated by 0.0.0.0), the packets should flow via the gateway address of 192.168.1.1. | ||
| + | |||
| + | So even if we need to reach 8.8.8.8, we need to go via 192.168.1.1 (as it is the gateway). | ||
| + | |||
| + | But why is tcpdump output not showing any trace of 192.168.1.1 (gateway)? | ||
| + | |||
| + | </ | ||
| <WRAP notice> | <WRAP notice> | ||
| - | Tcpdump is showing that the source address is 10.12.2.73 and destination is 8.8.8.8. | + | Tcpdump is showing that the source address is 192.168.1.2 and destination is 8.8.8.8. |
| - | As 8.8.8.8 is not part of our local network, we will have to go via our gateway address of 10.12.2.1. | + | As 8.8.8.8 is not part of our local network, we will have to go via our gateway address of 192.168.1.1. |
| - | So somewhere the destination address should be 10.12.2.1 right? | + | So somewhere the destination address should be 192.168.1.1 right? |
| - | Our ping is working perfectly. | + | Our ping is working perfectly. |
| + | |||
| + | But where the hell is the gateway address in the packet. | ||
| + | |||
| + | The packet is showing the destination address of 8.8.8.8. | ||
| + | |||
| + | But then how is it reaching the gateway? | ||
| This is exactly where physical addresses (MAC Addresses) steps in. | This is exactly where physical addresses (MAC Addresses) steps in. | ||
| Line 90: | Line 111: | ||
| tcpdump: verbose output suppressed, use -v or -vv for full protocol decode | tcpdump: verbose output suppressed, use -v or -vv for full protocol decode | ||
| listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes | listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes | ||
| - | 21: | + | 21: |
| 21: | 21: | ||
| - | 21: | + | 21: |
| 21: | 21: | ||
| </ | </ | ||
| - | This time along with the IP addresses, we are able to see physical addresses (mac addresses) as well in the output. | + | This time along with the IP addresses, we are able to see physical addresses (mac addresses) as well in the output. |
| + | |||
| + | Indicated by **12: | ||
| <code bash> | <code bash> | ||
| Line 106: | Line 129: | ||
| <code bash> | <code bash> | ||
| eth0 Link encap: | eth0 Link encap: | ||
| - | inet addr:10.12.2.73 | + | inet addr:192.168.1.2 Bcast:192.168.1.255 Mask: |
| inet6 addr: fe80:: | inet6 addr: fe80:: | ||
| UP BROADCAST RUNNING MULTICAST | UP BROADCAST RUNNING MULTICAST | ||
| Line 117: | Line 140: | ||
| From the above ifconfig command output, we can confirm that 12: | From the above ifconfig command output, we can confirm that 12: | ||
| - | But what is 12: | + | But what is 12: |
| + | |||
| + | We can use a command called **arp -n -a** to find out what is 12: | ||
| + | |||
| + | ARP stands for address resolution protocol. | ||
| + | |||
| + | So **arp -n -a** will show all the mac addresses and their equivalent IP addresses that our server is aware of. | ||
| <code bash> | <code bash> | ||
| Line 126: | Line 155: | ||
| <code bash> | <code bash> | ||
| - | ? (10.12.2.40) at 12: | + | ? (192.168.1.40) at 12: |
| ? (172.17.0.2) at 02: | ? (172.17.0.2) at 02: | ||
| - | ? (10.12.2.43) at 12: | + | ? (192.168.1.43) at 12: |
| - | ? (10.12.2.8) at 12: | + | ? (192.168.1.8) at 12: |
| - | ? (10.12.2.94) at 12: | + | ? (192.168.1.94) at 12: |
| - | ? (10.12.2.1) at 12: | + | ? (192.168.1.1) at 12: |
| </ | </ | ||
| - | 12: | + | 12: |
| - | MAC addresses (Physical addresses) are part of layer 2. IP addresses are part of layer 3 (source address). | + | So basically even if the destination IP address is 8.8.8.8, the destination mac address will always be of the gateway server. |
| + | |||
| + | MAC addresses (Physical addresses) are part of layer 2. | ||
| + | |||
| + | IP addresses are part of layer 3 (source address). | ||
| + | |||
| + | The content of layer 3 is encapsulated inside layer 2. | ||
| + | |||
| + | Layer 2 will have the source mac address of our server, and the destination mac address of the gateway. | ||
| + | |||
| + | Gateway will peal the physical layer 2, and as soon as it finds the destination as 8.8.8.8, it will forward that packet again to its gateway (i.e.: Our gateway will forward the packet to the next gateway, well depending upon the routes.). | ||
| This is how the packet travels and reaches its final destination of 8.8.8.8. | This is how the packet travels and reaches its final destination of 8.8.8.8. | ||
| Line 144: | Line 183: | ||
| {{: | {{: | ||
| - | Above shown diagram explains how a computer finds out the mac address associated with an IP address using Address Resolution Protocol. | + | Above shown diagram explains how a computer finds out the mac address associated with an IP address using Address Resolution Protocol. |
| + | |||
| + | This ARP request is a broadcast request. | ||
| - | This ARP request is a broadcast | + | Although every computer in the network receives that request. |
| - | Although every computer in the network recieves that request. | + | While responding back, it will send its own mac address. |
| - | While responding back, it will send its own mac address. | + | Below terms about ARP is worth noting: |
| * ARP Cache: After finding the MAC address associated with an IP, the computer stores it in a table for future reference. | * ARP Cache: After finding the MAC address associated with an IP, the computer stores it in a table for future reference. | ||
networking/arp/about_arp.1610012483.txt.gz · Last modified: 2021/01/07 09:41 by peter