1

I have a linux machine running under CentOS with 2 ISP. My rollover ISP channel script try to determine when we at secondary ISP channel is there a primary ISP channel get up and vice versa when need to change from primary to secondary. Normal thing.

To do this i want to ping from interface which now is not default gateway.

My 2 ifaces is eth1 is primary and eth2 secondary.

When we at eth1 for example and want to check is there internet on eth2. Eth2 is in up state.

ping -I eth2 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 1.2.3.4 eth2: 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
15 packets transmitted, 0 received, 100% packet loss, time 14173ms

But my running tcpdump shows that packets are sent and delivered to server, but some reasons don't seen by ping utility. Why is that i have no idea? What may be cause?

tcpdump:

17:36:42.191153 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    1.2.3.4 > 8.8.8.8: ICMP echo request, id 44138, seq 1, length 64
17:36:42.235899 IP (tos 0x0, ttl 59, id 30465, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 1.2.3.4: ICMP echo reply, id 44138, seq 1, length 64
17:36:43.190616 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    1.2.3.4 > 8.8.8.8: ICMP echo request, id 44138, seq 2, length 64
17:36:43.235363 IP (tos 0x0, ttl 59, id 31136, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 1.2.3.4: ICMP echo reply, id 44138, seq 2, length 64
17:36:44.190575 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    1.2.3.4 > 8.8.8.8: ICMP echo request, id 44138, seq 3, length 64
17:36:44.235346 IP (tos 0x0, ttl 59, id 32083, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 1.2.3.4: ICMP echo reply, id 44138, seq 3, length 64
17:36:45.190554 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    1.2.3.4 > 8.8.8.8: ICMP echo request, id 44138, seq 4, length 64
17:36:45.235368 IP (tos 0x0, ttl 59, id 32355, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 1.2.3.4: ICMP echo reply, id 44138, seq 4, length 64

netstat -rn shows that eth2 not default gateway sure, but it eth1.

4
  • 2
    What does head /proc/sys/net/ipv4/conf/*/rp_filter say?
    – kasperd
    Jun 11, 2017 at 18:01
  • head /proc/sys/net/ipv4/conf/*/rp_filter ==> /proc/sys/net/ipv4/conf/all/rp_filter <== 0 ==> /proc/sys/net/ipv4/conf/default/rp_filter <== 1 ==> /proc/sys/net/ipv4/conf/eth0/rp_filter <== 1 ==> /proc/sys/net/ipv4/conf/eth1/rp_filter <== 1 ==> /proc/sys/net/ipv4/conf/eth2/rp_filter <== 1 ==> /proc/sys/net/ipv4/conf/lo/rp_filter <== 1 ==> /proc/sys/net/ipv4/conf/ppp0/rp_filter <== 1 ==> /proc/sys/net/ipv4/conf/tun0/rp_filter <== 1 ==> /proc/sys/net/ipv4/conf/tun1/rp_filter <== 1
    – user419775
    Jun 11, 2017 at 18:38
  • kasperd hit the answer right there...your machine has reverse path filtering enabled, which causes it to verify that traffic it receives on an interface is reachable from that interface. But you used ping -I eth2 to bypass the system routing tables, so when the ICMP reply arrives at eth2 from 8.8.8.8, the kernel doesn't see how eth2 can reach 8.8.8.8, and discards the traffic.... Jun 12, 2017 at 2:14
  • @kasperd exact! It is this one! Thank you. link p.s. can't vote for your comment due to low rep seems.
    – user419775
    Jun 12, 2017 at 20:28

1 Answer 1

0

ICMP packets generated by ping may be filtered out by over zealous firewall on the path. traceoute may help to locate such problem.

2
  • i have completely disable iptables, but the same problem had. tcpdump shows that packets returned from 8.8.8.8 (to what i tracerouting) 8.8.8.8 > 1.2.3.4: ICMP 8.8.8.8 udp port 33491 unreachable, length 68 IP (tos 0x80, ttl 14, id 40213, offset 0, flags [none], proto UDP (17), length 60) 1.2.3.4.49505 > 8.8.8.8.33491: UDP, length 32
    – user419775
    Jun 11, 2017 at 19:47
  • Packets arrived at server, but maybe it look into route table and check if they comes not from default gateway then they rejected? Or else, no idea. Because when i replace default gateway by eth2 device all is good, i see responses.
    – user419775
    Jun 11, 2017 at 19:51

You must log in to answer this question.