Can’t ping eth1 via eth0

By Posted on

Can’t ping eth1 via eth0 – A server stack is the collection of software that forms the operational infrastructure on a given machine. In a computing context, a stack is an ordered pile. A server stack is one type of solution stack — an ordered selection of software that makes it possible to complete a particular task. Like in this post about Can’t ping eth1 via eth0 was one problem in server stack that need for a solution. Below are some tips in manage your linux server when you find problem about linux, networking, centos, linux-networking, .

I have two virtual machines with CentOS 7 installed.
Each VM has two NICs and two IP addresses.

ip configuration of VM1:

    eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:16:3e:0b:03:33 brd ff:ff:ff:ff:ff:ff
    inet 172.255.255.5/30 brd 172.255.255.7 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::4f07:27f6:5839:d257/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
    eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:16:3e:4b:2f:58 brd ff:ff:ff:ff:ff:ff
    inet 10.11.111.254/21 brd 10.11.111.255 scope global noprefixroute eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::d64c:aeee:1111:16d5/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

route of VM1:

10.11.104.0/21 dev eth1 proto kernel scope link src 10.111.111.254 metric 101
172.255.255.4/30 dev eth0 proto kernel scope link src 172.255.255.5 metric 100

ip configuration of VM2:

   eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:16:3e:7a:3c:e7 brd ff:ff:ff:ff:ff:ff
    inet 172.255.255.6/30 brd 172.255.255.7 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::35e3:6bb7:918e:6bca/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
   eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:16:3e:25:38:9a brd ff:ff:ff:ff:ff:ff
    inet 10.10.1.210/24 brd 10.10.1.255 scope global noprefixroute eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::5ec3:f912:51a5:761c/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

route of VM2:

10.10.1.0/24 dev eth1 proto kernel scope link src 10.10.1.210 metric 101
172.255.255.4/30 dev eth0 proto kernel scope link src 172.255.255.6 metric 100

I can ping from VM1(172.255.255.5,10.11.111.254) to 172.255.255.6 and can ping from VM2(172.255.255.6, 10.10.1.210) to 172.255.255.5.

The problem is, I want to ping from VM1(172.255.255.5,10.11.111.254) to 10.10.1.210, so I add a route in VM1

ip route add 10.10.1.210 via 172.255.255.6

so the route of VM1 is:

10.10.1.210 via 172.255.255.6 dev eth0
10.11.104.0/21 dev eth1 proto kernel scope link src 10.111.111.254 metric 101
172.255.255.4/30 dev eth0 proto kernel scope link src 172.255.255.5 metric 100

But I still can’t ping from VM1 to 10.10.1.210.

So, where am I wrong?

By the way, I have disabled SELinux and firewalld on all my machines.

  1. ip route get 10.10.1.210:

    10.10.1.210 via 172.255.255.6 dev eth0 src 172.255.255.5
    cache

  2. tcpdump -e -nn -i eth0 ‘icmp’ on VM1:

    20:47:00.147549 fa:16:3e:0b:03:33 > fa:16:3e:7a:3c:e7, ethertype IPv4 (0x0800), length 98: 172.255.255.5 > 10.10.1.210: ICMP echo request, id 4116, seq 48, length 64
    20:47:01.147541 fa:16:3e:0b:03:33 > fa:16:3e:7a:3c:e7, ethertype IPv4 (0x0800), length 98: 172.255.255.5 > 10.10.1.210: ICMP echo request, id 4116, seq 49, length 64
    20:47:02.147543 fa:16:3e:0b:03:33 > fa:16:3e:7a:3c:e7, ethertype IPv4 (0x0800), length 98: 172.255.255.5 > 10.10.1.210: ICMP echo request, id 4116, seq 50, length 64
    20:47:03.147551 fa:16:3e:0b:03:33 > fa:16:3e:7a:3c:e7, ethertype IPv4 (0x0800), length 98: 172.255.255.5 > 10.10.1.210: ICMP echo request, id 4116, seq 51, length 64

  3. VM1, iptables-save -c :

    *security
:INPUT ACCEPT [5440:12841065]
:FORWARD ACCEPT [2:144]
:OUTPUT ACCEPT [28968:2491805]
COMMIT
# Completed on Mon May 20 20:48:08 2019
# Generated by iptables-save v1.4.21 on Mon May 20 20:48:08 2019
*raw
:PREROUTING ACCEPT [5456:12843525]
:OUTPUT ACCEPT [28969:2491905]
COMMIT
# Completed on Mon May 20 20:48:08 2019
# Generated by iptables-save v1.4.21 on Mon May 20 20:48:08 2019
*mangle
:PREROUTING ACCEPT [5456:12843525]
:INPUT ACCEPT [5440:12841065]
:FORWARD ACCEPT [2:144]
:OUTPUT ACCEPT [28969:2491905]
:POSTROUTING ACCEPT [28970:2491949]
COMMIT
# Completed on Mon May 20 20:48:08 2019
# Generated by iptables-save v1.4.21 on Mon May 20 20:48:08 2019
*filter
:INPUT ACCEPT [5440:12841065]
:FORWARD ACCEPT [2:144]
:OUTPUT ACCEPT [28968:2491805]
COMMIT
# Completed on Mon May 20 20:48:08 2019
# Generated by iptables-save v1.4.21 on Mon May 20 20:48:08 2019
*nat
:PREROUTING ACCEPT [41:6031]
:INPUT ACCEPT [26:3643]
:OUTPUT ACCEPT [196:139164]
:POSTROUTING ACCEPT [197:139236]
COMMIT
# Completed on Mon May 20 20:48:08 2019```

  4. VM2, iptables-save -c :

    *nat
:PREROUTING ACCEPT [151:139500]
:INPUT ACCEPT [136:137067]
:OUTPUT ACCEPT [126:76110]
:POSTROUTING ACCEPT [126:76110]
COMMIT
# Completed on Mon May 20 20:51:19 2019
# Generated by iptables-save v1.4.21 on Mon May 20 20:51:19 2019
*filter
:INPUT ACCEPT [22121:14364143]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [21468:1823390]
COMMIT
# Completed on Mon May 20 20:51:19 2019```

  5. tcpdump -e -nn -i eth0 ‘icmp’ on VM2

    20:53:50.348475 fa:16:3e:0b:03:33 > fa:16:3e:7a:3c:e7, ethertype IPv4 (0x0800), length 98: 172.255.255.5 > 10.10.1.210: ICMP echo request, id 4116, seq 459, length 64
    20:53:50.348501 fa:16:3e:7a:3c:e7 > fa:16:3e:0b:03:33, ethertype IPv4 (0x0800), length 98: 10.10.1.210 > 172.255.255.5: ICMP echo reply, id 4116, seq 459, length 64
    20:53:51.348443 fa:16:3e:0b:03:33 > fa:16:3e:7a:3c:e7, ethertype IPv4 (0x0800), length 98: 172.255.255.5 > 10.10.1.210: ICMP echo request, id 4116, seq 460, length 64
    20:53:51.348501 fa:16:3e:7a:3c:e7 > fa:16:3e:0b:03:33, ethertype IPv4 (0x0800), length 98: 10.10.1.210 > 172.255.255.5: ICMP echo reply, id 4116, seq 460, length 64
    20:53:52.348432 fa:16:3e:0b:03:33 > fa:16:3e:7a:3c:e7, ethertype IPv4 (0x0800), length 98: 172.255.255.5 > 10.10.1.210: ICMP echo request, id 4116, seq 461, length 64
    20:53:52.348456 fa:16:3e:7a:3c:e7 > fa:16:3e:0b:03:33, ethertype IPv4 (0x0800), length 98: 10.10.1.210 > 172.255.255.5: ICMP echo reply, id 4116, seq 461, length 64

Steps to troubleshoot.

  1. Check the actual routes. On VM1 run ip route get 10.10.1.210. It should return valid route.
  2. Your setup doesn’t require enabled forwarding in the current state.
  3. Run the tcpdump -ni eth0 'icmp' on VM1. You should see outgoing icmp echo requests. If you don’t see them, then they are either filtered or routed through other interface.
  4. Anyway check the firewall with command iptables-save -c.
  5. Run the tcpdump -ni eth0 'icmp' on VM2. Do you see incoming icmp echo request and outgoing icmp echo reply?

If the steps above haven’t helped, paste the outputs of commands from them into the question, and I’ll extend the answer.

Related posts:

Leave a Reply

Your email address will not be published. Required fields are marked *