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.

Basic Routing - vlan - connected

This is an extension to my previous vlan posts.

Basic Routing on Multilayer Switch - Connected Network - No VLAN
Basic Routing on Multilayer Switch 2 - Connected Network - No VLAN

We keep 3 networks and do intervlan routing with Multilayer switch as below:

Topology

Keep the following picture as a reference while reading the info for better understanding.

Reference Topology

Task Breakup

1. Configure IP Addresses of Laptops
2. Create VLANs on Switch
3. Assign VLANs to Interfaces on Switch
4. Configure IP Addresses to VLAN on Switch
5. View VLAN Information
6. Enabling Routing
7. Validation
8. Alternate Topology

1. Configure IP Addresses of Laptops

PC Name	IP Address	Subnet Mask	Default Gateway
Inside1-1	172.16.0.11	255.255.0.0	172.16.0.1
Inside1-2	172.16.0.12	255.255.0.0	172.16.0.1
Inside2-1	10.0.0.11	255.0.0.0	10.0.0.1
Inside2-2	10.0.0.12	255.0.0.0	10.0.0.1
Outside	5.0.0.11	255.0.0.0	5.0.0.1

Click Laptop -> Desktop -> IP Configuration

IP Address Configuration - Outside Laptop

2. Create VLANs on Switch

As a good convention, we create VLANs and assign names to them

routing(config)#vlan 172
routing(config-vlan)#name vlan-172
routing(config-vlan)#exit
routing(config)#vlan 10
routing(config-vlan)#name vlan-10
routing(config-vlan)#exit
routing(config)#vlan 5
routing(config-vlan)#name vlan-5
routing(config-vlan)#exit

3. Assign VLANs to Interfaces on Switch

PC Name	IP Address	Subnet Mask	Default Gateway	Switchport interface	VLAN ID
Inside1-1	172.16.0.11	255.255.0.0	172.16.0.1	gig 1/0/1	VLAN 172
Inside1-2	172.16.0.12	255.255.0.0	172.16.0.1	gig 1/0/2	VLAN 172
Inside2-1	10.0.0.11	255.0.0.0	10.0.0.1	gig 1/0/11	VLAN 10
Inside2-2	10.0.0.12	255.0.0.0	10.0.0.1	gig 1/0/12	VLAN 10
Outside	5.0.0.11	255.0.0.0	5.0.0.1	gig 1/0/5	VLAN 5

routing(config)#int gig 1/0/1
routing(config-if)#switchport mode access
routing(config-if)#switchport access vlan 172
routing(config-if)#exit
routing(config)#int gig 1/0/2
routing(config-if)#switchport mode access
routing(config-if)#switchport access vlan 172

routing(config)#int gig 1/0/11
routing(config-if)#switchport mode access
routing(config-if)#switchport access vlan 10
routing(config-if)#exit
routing(config)#int gig 1/0/12
routing(config-if)#switchport mode access
routing(config-if)#switchport access vlan 10
routing(config-if)#exit

routing(config)#int gig 1/0/5
routing(config-if)#switchport mode access
routing(config-if)#switchport access vlan 5
routing(config-if)#exit

4. Configure IP Addresses to VLAN on Switch

VLAN ID	VLAN Name	VLAN IP Address
172	vlan-172	172.16.0.1
10	vlan-10	10.0.0.1
5	vlan-5	5.0.0.1

routing(config)#int vlan 172
routing(config-if)#ip address 172.16.0.1 255.255.0.0
routing(config-if)#no shut
routing(config-if)#exit
routing(config)#int vlan 10
routing(config-if)#ip address 10.0.0.1 255.0.0.0
routing(config-if)#no shut
routing(config-if)#exit
routing(config)#int vlan 5
routing(config-if)#ip address 5.0.0.1 255.0.0.0
routing(config-if)#no shut
routing(config-if)#exit

5. View VLAN Information

The following show commands gives an overview of what VLANs are assigned to which interfaces and the IP Address of VLANs

routing#show vlan br

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Gig1/0/3, Gig1/0/4, Gig1/0/6, Gig1/0/7
                                                Gig1/0/8, Gig1/0/9, Gig1/0/10, Gig1/0/13
                                                Gig1/0/14, Gig1/0/15, Gig1/0/16, Gig1/0/17
                                                Gig1/0/18, Gig1/0/19, Gig1/0/20, Gig1/0/21
                                                Gig1/0/22, Gig1/0/23, Gig1/0/24, Gig1/1/1
                                                Gig1/1/2, Gig1/1/3, Gig1/1/4
5    vlan-5                           active    Gig1/0/5
10   vlan-10                          active    Gig1/0/11, Gig1/0/12
172  vlan-172                         active    Gig1/0/1, Gig1/0/2
1002 fddi-default                     active    
1003 token-ring-default               active    
1004 fddinet-default                  active    
1005 trnet-default                    active 


routing#show ip int br
Interface              IP-Address      OK? Method Status                Protocol 
GigabitEthernet1/0/1   unassigned      YES NVRAM  up                    up 
GigabitEthernet1/0/2   unassigned      YES NVRAM  up                    up 
............
...........
GigabitEthernet1/1/3   unassigned      YES NVRAM  down                  down 
GigabitEthernet1/1/4   unassigned      YES NVRAM  down                  down 
Vlan1                  unassigned      YES NVRAM  administratively down down 
Vlan5                  5.0.0.1         YES manual up                    up 
Vlan10                 10.0.0.1        YES manual up                    up 
Vlan172                172.16.0.1      YES manual up                    up

6. Enabling Routing

Routing might be already enabled. It doesn't hurt to enable one more time.

routing#conf t
routing(config)#ip routing
routing(config)#exit

In the show command, if Connected Network information is shown, it means routing is enabled.

routing#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

C    5.0.0.0/8 is directly connected, Vlan5
C    10.0.0.0/8 is directly connected, Vlan10
C    172.16.0.0/16 is directly connected, Vlan172

7. Validation

Issue ping from any Laptop to any Laptop, it will be success.

Successful ping from Inside2-1 to Outside

Successful ping from Outside to Inside1-1

8. Alternate Topology

If there is no multilayer switch and we use Router, our topology has to be like this.  We will not be using VLANs.  All the laptops that are earlier connected to same VLAN, will be connected to a hub here.

TCP open connection with scapy

Today, I am going to try to create TCP 3-way connection with the help of scapy and iperf.  The full wireshark capture is

TCP 3-way Connection

192.168.1.10 (client: port 40508: scapy) ------->> 192.168.1.200 (server: port 5000: iperf)

As we donot have a conventional TCP client program running on the client side.  Whenever server sends SYN-ACK packet to client, the kernel on the client responds with Reset TCP connection.  To avoid this, we should place a rule in IPTables, to drop any Reset's packets initiated from client side.  This can be done using the following command on the client side:

# iptables -A OUTPUT -p tcp --tcp-flags RST RST -s 192.168.1.10 -j DROP

On the server side, we create a server listening on port 5000, using 

# iperf -s -p 5000
------------------------------------------------------------
Server listening on TCP port 5000
TCP window size: 85.3 KByte (default)
------------------------------------------------------------

In another session, observe that the output of netstat command, its in listen state

# netstat -na | grep 5000
tcp        0      0 0.0.0.0:5000            0.0.0.0:*               LISTEN

On the client side, we open scapy session, send a TCP SYN packet and receive the response.  sr1 implies send (ip/SYN) and wait till ONE response is received.

# scapy
INFO: Can't import python gnuplot wrapper . Won't be able to plot.
INFO: Can't import PyX. Won't be able to use psdump() or pdfdump().
INFO: Can't import python Crypto lib. Won't be able to decrypt WEP.
INFO: Can't import python Crypto lib. Disabled certificate manipulation tools
Welcome to Scapy (2.2.0)
>>>
>>> ip=IP(src="192.168.1.10",dst="192.168.1.200")
>>> SYN=TCP(sport=40508,dport=5000,flags="S",seq=0)
>>> SYNACK=sr1(ip/SYN)
Begin emission:
.......Finished to send 1 packets.
.*
Received 9 packets, got 1 answers, remaining 0 packets

Netstat on the server side, the state would have been

# netstat -na | grep 5000
tcp        0      0 0.0.0.0:5000            0.0.0.0:*               LISTEN
tcp        0      0 192.168.1.200:5000      192.168.1.10:40508      SYN_RECV

Now, on the client, we create and send the 3rd handshake message ACK to complete the TCP connection. This has to be sent as quick as possible, because there is a chance that the server may have timed out and dropped the TCP connection.

>>> ACK=TCP(sport=40508,dport=5000,flags="A",seq=SYNACK.ack+1,ack=SYNACK.seq+1)
>>> send(ip/ACK)
.
Sent 1 packets.

Netstat shows that the TCP connection is established.

# netstat -na | grep 5000
tcp        0      0 0.0.0.0:5000            0.0.0.0:*               LISTEN
tcp        0      0 192.168.1.200:5000      192.168.1.10:40508      ESTABLISHED

DHCP Broadcast - Notes

In my last post on DHCP, DHCP Offer and DHCP ACK were unicast frames.

DHCP Unicast Flag

In the Bootp Flags, the broadcast bit is set to 0(means unicast).  It means DHCP Client tells that it is expecting unicast responses from DHCP server.  So, the reply from DHCP server(DHCP Offer and DHCP ACK) will have Unicast MAC and IP Addresses. 

On a linux machine, this can be seen using command 'dhclient eth0'

Broadcast

There are cases when they will be broadcast.  From linux machine, we can use 'dhclient -B eth0' to request Broadcast responses.  Most of the times, DHCP starts from DHCP Offer, instead of Discovery.  So, by googling I found that we had to release the existing IP address for the transaction to happen from Discovery.  Like this

# dhclient -r  eth0
# dhclient -B  eth0

DHCP Broadcast

Observe that the Bootp flag here is '1'(means Broadcast flag set).  Client is asking the server to give broadcast responses.  Therefore, the DHCP Offer and ACK from the server has broadcast MAC and IP addresses.