understanding network interface
Published: 2022-12-17 08:23:34

This post focuses on the very essential takeaways on linux network interfaces from my learnings. This comes handy when you are working with the ecosystem of Containers , Kubernetes (Azure Kubernetes Service, Amazon EKS) with a mix of WireGuard (Encryption) and Network Policy (Calico).

# What is Network Interface ?

A  **_network_**  **_interface_**  is a  **software**  **interface**  to a  **networking**  **hardware**.

A [network interface](https://www.howtouselinux.com/post/linux-command-find-network-interface) is how the kernel links up the software side of networking to the hardware side.

Linux kernel distinguishes between two types of network interfaces:  _physical_  and  _virtual_.

Physical network interface represents an actual network hardware device. This is typically  `eth0`  interface, which represents Ethernet network card.

Virtual network interface doesn’t represent any hardware device and is usually linked to one.

There are different kinds of virtual interfaces e.g. Loopback, bridges, VLANs, tunnel interfaces and so on but that is not discussed in this post.

The  **ifconfig or ip** commands allows us to configure network interfaces. This post uses  **ip**  command.

I have created an Amazon Linux instance of type  **t3.micro in AWS** and connected to it to take as a concrete example.

# Useful commands for dealing with Network Interfaces

**To show network interface information for all interfaces**

$ ip link show

![](https://miro.medium.com/max/1400/1*jtE6fhyDHy0oubUsOUyo9g.png)

This shows  **two**  network interfaces  **lo** and  **eth0 .** The second line for each interface shows the link layer adddress associated with the device.

The interface flags inside the <> are summarised as below.

**LOOPBACK**  — this interface does not communicate with other hosts. All packets sent through it will be returned

**UP**  — device is turned on and is ready to accept packets for transmission

**BROADCAST**  - has the facility to send packets to all hosts sharing the same link

**MULTICAST**  — indicating that the interface is aware of multicasting i.e. sending packets to some subset of neighbouring nodes

**To see the statistics of specific interface**

$ ip -s link show eth0

![](https://miro.medium.com/max/1400/1*ThgMsEmdtZZO4Azu0EUuUQ.png)

**[To show ip addresses assigned to interfaces](https://www.howtouselinux.com/post/check-ip-address-in-linux)**

$ ip address show   
or   
$ ip a  
or  
$ ip addr 

![](https://miro.medium.com/max/1400/1*iuXki2iypfRwnUNuMcvYuA.png)

**1 : lo**  : is having an IP address of  **127.0.0.01 (a.k.a localhost)**

**2: eth0** : shows IP of  **172.31.15.180**

This is the private IP assigned by AWS to an EC2 instance. This IP is obtained from the subnet  **172.31.0.0**/**20**  CIDR block in which the instance is launched.

**Create dummy interface**

A dummy interface is entirely virtual like, for example, the loopback interface. The dummy interface address look like a real address for local programs. The purpose of a dummy interface is to provide a device to route packets through without actually transmitting them. This is very handy when you want to simulate a network computing environment for testing purpose.

# create dummy interface  
sudo ip link add dummy1 type dummy# assign address to dummy interface   
sudo ip addr add 192.168.0.3/24 dev dummy1# make interface up   
ip link set dummy1 up

You will see that dummy interface is created and IP address is also assigned to that dummy interface.

Note that this IP address is entirely different — virtual than the subnet CIDR range is  _172.31.0.0/20_  provided by AWS and this could be any valid CIDR block.

![](https://miro.medium.com/max/1400/1*r78OKtcKbgbZ-pX7hSKwkQ.png)

![](https://miro.medium.com/max/1400/1*JFZ7FqapJqA_x3vn4Swctw.png)

# test the connectivity   
ping 192.168.0.3

![](https://miro.medium.com/max/1400/1*7pw76x9DPVU5npL8i1MQVw.png)

# Run HTTP server with new virtual IP

**Scenario**  1 : Run  _http server_  on port  _8000_  and serve the content from direcory  _/tmp_

python3 -m http.server 8000 --directory /tmp

![](https://miro.medium.com/max/1400/1*1CUWuAtcDud0d5JTyGtbsQ.png)

-   If you  **_curl_**  to public ip  **13.232.86.139:8000** you should receive HTTP 200 response as shown here.
-   Similarly  **_curl_**  to  _127.0.0.1_ also works !

![](https://miro.medium.com/max/1400/1*O_Xvwo51xrEs9LWPaqOLOg.png)

If you curl to the new network interface with IP  **192.168.0.3**  it also gives HTTP 200 reponse.

This works fine since the the traffic is accepted on all the network interfaces (0.0.0.0/0)on port 8000 of host !

![](https://miro.medium.com/max/1400/1*Xr77Bw-rg8qFVCuEY-jX0A.png)

**Scenario 2 : Run Python Server on the new IP address 192.168.0.3**

python3 -m http.server --bind 192.168.0.3 8000 --directory /tmp

![](https://miro.medium.com/max/1400/1*ap_Fqv8p6ludTKXyQ9QFAw.png)

Now the following result is seen

a)  _curl_  to public ip  _13.232.86.139_:_8000_  **does not work**

b)  _curl_  to  _127.0.0.01_:_8000_  **does not work**

c)  _curl_  to  _192.168.0.3_:_8000_  **Works**  !

![](https://miro.medium.com/max/1400/1*kRlnVfNJwBJDnHTAazeZ7g.png)

![](https://miro.medium.com/max/1400/1*Mcb9Nt8_oR-qSwxC5zIwoA.png)

This is as expected as the web server is now tied to only specific network interface IP i.e.  _192.168.0.3_  on port  _8000_  so any traffic which is not destined to new ip adresss will not be accepted by the HTTP server !

**To delete the network interfaces**

$ sudo ip link set dummy1 down  
$ sudo ip link del dummy1

![](https://miro.medium.com/max/1400/1*3FR72M2LRlEsu_sEp3LsvA.png)

This deletes the network interface  _dummy1_  as seen above.

That is all about this minimal know how on network interface.

I hope to build on this in my future posts.

Stay tuned !

reference:
https://askubuntu.com/questions/1443572/how-to-get-the-ip-address-without-ifconfig-or-ip-command-in-ubuntu