Basic Demo of Default Gateway

I got a host having a IP Address 192.168.10.176.  We will see how it reacts when it wants to reach out to different IP Addresses.

IP Addresses within Network

In the above picture, whenever the host wants to reach to any IP Address within the network, it sends out ARP Request to resolve the MAC Address.  To demonstrate, we tried to ping 192.168.10.177, 192.168.10.178 and 192.168.10.190.  As I connect only *.177 PC there was reply from only that machine.  It is not important.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

# ping -c 1 192.168.10.177 PING 192.168.10.177 (192.168.10.177): 56 data bytes 64 bytes from 192.168.10.177: seq=0 ttl=64 time=0.724 ms --- 192.168.10.177 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.724/0.724/0.724 ms # # ping -c 1 192.168.10.178 PING 192.168.10.178 (192.168.10.178): 56 data bytes ^C --- 192.168.10.178 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss # ping -c 1 192.168.10.190 PING 192.168.10.190 (192.168.10.190): 56 data bytes ^C --- 192.168.10.190 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss #

 Analysing the following sniffer capture.

Note those ARP Requests that our host generates.  It requests MAC only for *.177, *.178 and *.190.  The conclusion is for all the IPs that are within the network host will directly requests for MAC addresses of those machines.

IP Address outside Network

I try to ping some IP Address outside its network that do not exist.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

# ping -c 1 192.168.10.200 PING 192.168.10.200 (192.168.10.200): 56 data bytes ^C --- 192.168.10.200 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss # ping -c 1 192.168.1.20 PING 192.168.1.20 (192.168.1.20): 56 data bytes ^C --- 192.168.1.20 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss # ping -c 1 1.3.2.4 PING 1.3.2.4 (1.3.2.4): 56 data bytes --- 1.3.2.4 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss #

As there are no hosts with those IPs, all pings fail.  Let us analyze the sniffer capture:

Here the host wanted to reach out to an IP Address that is not in its configured network interface.  The sequence of things that happened here:

1. Requests for the MAC Address of 'Default Gateway' that is configured(i.e. 192.168.1.177).
2. Host took note of the MAC address of gateway, say it gw-mac
3. Following packets destined to that IP address will have destination mac as gw-mac. Other elements like source mac, source IP and destination IP will be as usual 

The aim here is -- Host has to deliver the packet to the gateway that is capable of routing. That is why the destination mac is of the gateway's.  The gateway must be configured such that the packet is routing to its desired network.

Proxy ARP in Linux

In my previous post, you have seen how proxy arp was configured on cisco router.  Now, we do a demo on a linux machines FC19.

Briefly,

• Without proxyarp, Multihost will respond for all configured IPs
• With proxyarp, Multihost will respond for all connected network IPs(except the interface on which it receives arp request)

Here, I will discuss only about how multicast responds to ARP and not about Ping.  To simplify our explanation we use a tool 'arping'.  It is usually inbuilt in all machines.

Without proxyarp, Multihost will respond for all configured IPs

No proxyarp is enabled in Multihost.  'eth0' on Multihost will arp respond to its configured IP addresses '172.16.0.10' and '192.168.1.8'.  The way I use arping below to direct arp request is self-explanatory.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

[root@abc12end1 ~]$arping -I enp0s20u4 -f 172.16.0.10 ARPING 172.16.0.10 from 172.16.0.1 enp0s20u4 Unicast reply from 172.16.0.10 [00:FF:18:B4:CC:6F] 0.811ms Sent 1 probes (1 broadcast(s)) Received 1 response(s) [root@abc12end1 ~]$arping -I enp0s20u4 -f 192.168.1.8 ARPING 192.168.1.8 from 172.16.0.1 enp0s20u4 Unicast reply from 192.168.1.8 [00:FF:18:B4:CC:6F] 0.799ms Sent 1 probes (1 broadcast(s)) Received 1 response(s) [root@abc12end1 ~]$arping -I enp0s20u4 -f 192.168.1.1 ARPING 192.168.1.1 from 172.16.0.1 enp0s20u4 ^CSent 2 probes (2 broadcast(s)) Received 0 response(s)

Observe that I requested for 192.168.1.1 for which Multihost didn't respond.

With proxyarp, Multihost will respond for all connected network IPs


Now, I enable proxyarp using the following commands.

1 2 3 4 5 6 7 8 9 10 11 12 13

# cat /proc/sys/net/ipv4/conf/all/proxy_arp 0 # cat /proc/sys/net/ipv4/ip_forward 0 # echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp # echo 1 > /proc/sys/net/ipv4/ip_forward # cat /proc/sys/net/ipv4/conf/all/proxy_arp 1 # cat /proc/sys/net/ipv4/ip_forward 1

Now issue arp request for any of the IP address in 192.168.1.x network.  Irrespective of whether the host exists or not, eth0 will respond with its MAC address.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

[root@abc12end1 ~]$arping -I enp0s20u4 -f 192.168.1.8 ARPING 192.168.1.8 from 172.16.0.1 enp0s20u4 Unicast reply from 192.168.1.8 [00:FF:18:B4:CC:6F] 0.802ms Sent 1 probes (1 broadcast(s)) Received 1 response(s) [root@abc12end1 ~]$arping -I enp0s20u4 -f 192.168.1.1 ARPING 192.168.1.1 from 172.16.0.1 enp0s20u4 Unicast reply from 192.168.1.1 [00:FF:18:B4:CC:6F] 444.585ms Sent 1 probes (1 broadcast(s)) Received 1 response(s) [root@abc12end1 ~]$arping -I enp0s20u4 -f 192.168.1.2 ARPING 192.168.1.2 from 172.16.0.1 enp0s20u4 Unicast reply from 192.168.1.2 [00:FF:18:B4:CC:6F] 126.458ms Sent 1 probes (1 broadcast(s)) Received 1 response(s)

Here 192.168.1.1 and 192.168.1.2 hosts do not exist.  But Multihost's eth0 responded with its MAC Address.

Proxy ARP in Packet Tracer

I believe the following diagram will give a brief idea about what Proxy ARP does.  By default all cisco routers will have proxy arp enabled over the interfaces.

Description

Typically, any interface having IP address 'IP1' after receiving an arp request(for IP1) it sends arp response with its MAC address.  

Suppose 'proxy arp' is enabled in any interface(say Gi0/1), and the other interfaces(Gi0/2, Gi0/3) of the network device are configured with other networks(IP2, IP3).  If Gi0/1 receives any arp request for any of the IP addresses in IP2 or IP3, Gi0/1 sends out ARP response with its own MAC Address.

'Proxy ARP' configuration gives the authority for that interface.

Demonstration

I picked a router with following interfaces and IP addresses.

Topology

Configurations in the router will be as follows:

1 2 3 4 5 6 7 8 9 10 11 12 13

Router(config)# Router(config)#int gigabitEthernet 0/0 Router(config-if)#ip address 192.168.0.1 255.255.255.0 Router(config-if)#no shut Router(config-if)#exit Router(config)#int gigabitEthernet 0/1 Router(config-if)#ip address 192.168.1.1 255.255.255.0 Router(config-if)#no shut Router(config-if)#exit Router(config)#int gigabitEthernet 0/2 Router(config-if)#ip address 192.168.2.1 255.255.255.0 Router(config-if)#no shut Router(config-if)#exit

If you observe, Laptop0 has subnet mask 255.0.0.0 while others have 255.255.255.0.   I did it for a reason.  If I ping to 192.168.2.x or 192.168.3.x from Laptop0, it initially generates ARP request for that particular IP address.  If I keep subnet as 255.255.255.0 and issue a ping to 192.168.2.x or 192.168.3.x, it will generate ARP for the default IP address configured.  Explanation of this needs a separate post which I am planning to do later.

For this post, just remember that with this configuration I will be able to generate ARP requests for 192.168.2.x or 192.168.3.x IP addresses.

C:\>arp -a
No ARP Entries Found

C:\>ping -n 1 192.168.0.1
Pinging 192.168.0.1 with 32 bytes of data:
Reply from 192.168.0.1: bytes=32 time<1ms TTL=255
Ping statistics for 192.168.0.1:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),

C:\>ping -n 1 192.168.1.1
Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time<1ms TTL=255
Ping statistics for 192.168.1.1:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),

C:\>ping -n 1 192.168.1.100
Pinging 192.168.1.100 with 32 bytes of data:
Request timed out.
Ping statistics for 192.168.1.100:
    Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

C:\>ping -n 1 192.168.1.101
Pinging 192.168.1.101 with 32 bytes of data:
Request timed out.
Ping statistics for 192.168.1.101:
    Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

C:\>ping -n 1 192.168.2.1

Pinging 192.168.2.1 with 32 bytes of data:

Request timed out.

Ping statistics for 192.168.2.1:

    Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

Initially we made sure ARP entries are not present.  We have issued ping to

• 192.168.0.1 (its own network on Gi 0/0)
• 192.168.1.1 and 192.168.1.100 (other interface's Gi0/1 network address) (Existing IP address)
• 192.168.1.101 (other interface's Gi0/1 network address) (This IP address not present)
• 192.168.2.1 (other interface's Gi0/2 network address) (Existing IP address)

When we look at arp entries:

1 2 3 4 5 6

C:\>arp -a Internet Address Physical Address Type 192.168.0.1 0040.0b1a.9a01 dynamic 192.168.1.1 0040.0b1a.9a01 dynamic 192.168.1.100 0040.0b1a.9a01 dynamic 192.168.1.101 0040.0b1a.9a01 dynamic

Line 3, its conventional arp response of Gi0/0 MAC address.
Line 4 and 5, Gi0/0 responded with its own MAC address for the network present in Gi0/1
Line 6, Irrespective whether the IP address exists or not, if it gets arp request for any of the IP address in 192.168.1.x network it responds with its own MAC address.

Bonus Tip

You must have noticed that I issued ping to 192.168.2.1 (Gi0/2), but the arp entry is not present.  This is because that operational status is down.  So, we placed a switch to make it 'up'.  Now proxy-arp works as usual.

Placed a switch to make Gig0/2 operational status 'up'

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

C:\>arp -a No ARP Entries Found C:\>ping 192.168.2.1 Pinging 192.168.2.1 with 32 bytes of data: Reply from 192.168.2.1: bytes=32 time=1ms TTL=255 Reply from 192.168.2.1: bytes=32 time<1ms TTL=255 Ping statistics for 192.168.2.1: Packets: Sent = 2, Received = 2, Lost = 0 (0% loss), C:\>ping 192.168.2.100 Pinging 192.168.2.100 with 32 bytes of data: Ping statistics for 192.168.2.100: Packets: Sent = 1, Received = 0, Lost = 1 (100% loss), C:\>arp -a Internet Address Physical Address Type 192.168.2.1 0040.0b1a.9a01 dynamic 192.168.2.100 0040.0b1a.9a01 dynamic