one of two nic cards is not pingable on REDHAT, HP G5 SERVER

[Hanry Zhou]

On node B, there are 2 nic cards, and IP's are 10.100.200.81(eth1), and 10.100.216.81(eth2). After the configurations all being done, nobody can ping 10.100.200.81. For instance, on node A, I could not ping 10.100.200.81, however, I could ping all nodes in 200 segment from the node A.

I can ping 10.100.216.81 witout a problem. 10.100.216.1 is the default gateway.

Based on ifconfig eth1 on node A, this nic card seems UP, and configured correctly.

# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.100.216.1 0.0.0.0 UG 0 0 0 eth2
10.100.200.0 * 255.255.255.0 U 0 0 0 eth1
10.100.216.0 * 255.255.255.0 U 0 0 0 eth2
192.168.122.0 * 255.255.255.0 U 0 0 0 virbr0

# ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:17:A4:47:E1:78
inet addr:10.100.200.81 Bcast:10.100.200.255 Mask:255.255.255.0
inet6 addr: fe80::217:a4ff:fe47:e178/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9867 errors:0 dropped:428566 overruns:0 frame:0
TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5926159 (5.6 MiB) TX bytes:3087 (3.0 KiB)
Interrupt:17 Memory:fa000000-fa012800

[Patrick Wallek]

Can you ping anything on the 10.100.200 network from nodeB?  If not you may need to check your network configuration, cables, switch, etc.

[Matti_Kurkela]

You might want to start tcpdump on node B while pinging it on node A. You might see one of two scenarios:

1. the ping packets are reaching node B but the responses aren't getting back to node A for some reason, or
2. the ping packets aren't reaching node B at all for some reason.

You omitted some important information:

• Is the node A you're speaking of located in either network segment 10.100.200.* or 10.100.216.*, or in a completely different network segment?
• Does node A have just one NIC, or two or more NICs like node B? If it has more than one NIC, what does its routing table look like?

If node A has a NIC in the 10.100.200.* segment, it will attempt to use it to reach 10.100.200.81 unless overridden by its routing table. In this situation, only a network issue (e.g. a VLAN configuration error) in the 10.100.200.* segment should prevent node B from successfully answering the pings from node A.

But if node A does not have such a NIC, it must go through a gateway to reach 10.100.200.81. If the 10.100.200.* segment has a gateway to other segments, this will allow node B to receive pings from node A through eth1 - but in this situation, any answers to node A will be sent out through eth2, because the routing table of node B currently says so. This is asymmetric routing, which will not work if the network includes firewalls that do connection state tracking (i.e. any decent modern firewall). For example, if a firewall sees a ping reply going one way without first seeing a ping request going exactly the opposite way, it assumes foul play and drops the ping reply packet.

Side note:

On any host with multiple NICs in different network segments, it is important to understand the Reverse Path Filtering setting (net.ipv4.conf.*.rp_filter in /etc/sysctl.conf, or /proc/sys/net/ipv4/conf/*/rp_filter in /proc filesystem). In many modern Linux distributions, Reverse Path Filtering is enabled by default, and in some specific situations, you might want to switch it from strict to loose mode or disable it altogether - but please don't just disable it if you don't have a clear understanding on why your particular network set-up needs to have it disabled.

Here seems to be a concise explanation on how it works in general:

http://www.wlug.org.nz/ReversePathFiltering

The description of different rp_filter setting values can be found in Linux kernel documentation, e.g. here:

http://www.mjmwired.net/kernel/Documentation/networking/ip-sysctl.txt

In your situation, if node B sees incoming packets on eth1 with a non-10.100.200.* source address, the Reverse Path Filter could cause them to be ignored: "if the routing table is correct, there is no way packets from that source IP could have come in via eth1 unless some network UFO dropped them into that segment". Such rejected packets can optionally be logged as "martians".