Проверка связи с виртуальным IP-адресом для кластера высокой доступности Linux из другой подсети не работает

Я установил кластер Linux с Corosync / Pacemaker, и два узла кластера находятся в одной подсети и имеют виртуальный IP-адрес. Для машин в одной подсети они могут успешно пропинговать виртуальный IP-адрес «135.121.192.104».

Однако, если я попытался выполнить эхо-запрос виртуального IP-адреса «135.121.192.104» с машины из другой подсети, он не ответил на мой эхо-запрос. Остальные машины находятся в подсети «135.121.196.x».

На моих машинах в файле ifcfg-eth0 есть следующая маска подсети:

NETMASK = 255.255.254.0

и ниже мои результаты для показа конфигурации crm:

[root@h-008 crm]# crm configure show
node h-008 \
        attributes standby="off"
node h-009 \
        attributes standby="off"
primitive GAXClusterIP ocf:heartbeat:IPaddr2 \
        params ip="135.121.192.104" cidr_netmask="23" \
        op monitor interval="30s" clusterip_hash="sourceip"
clone GAXClusterIP2 GAXClusterIP \
        meta globally-unique="true" clone-node-max="2"
property $id="cib-bootstrap-options" \
        dc-version="1.0.11-1554a83db0d3c3e546cfd3aaff6af1184f79ee87" \
        cluster-infrastructure="openais" \
        expected-quorum-votes="2" \
        no-quorum-policy="ignore" \
        stonith-enabled="false"
rsc_defaults $id="rsc-options" \
        resource-stickiness="100"

и вывод статуса crm_mon:

[root@h-009 crm]# crm_mon status --one-shot
non-option ARGV-elements: status
============
Last updated: Thu Jun 23 08:12:21 2011
Stack: openais
Current DC: h-008 - partition with quorum
Version: 1.0.11-1554a83db0d3c3e546cfd3aaff6af1184f79ee87
2 Nodes configured, 2 expected votes
1 Resources configured.
============

Online: [ h-008 h-009 ]

 Clone Set: GAXClusterIP2 (unique)
     GAXClusterIP:0     (ocf::heartbeat:IPaddr2):       Started h-008
     GAXClusterIP:1     (ocf::heartbeat:IPaddr2):       Started h-009

Я новичок в настройке кластера высокой доступности Linux и не могу определить основную причину проблемы. Есть ли какая-нибудь конфигурация, которую я могу проверить, чтобы диагностировать эту проблему?

Дополнительные комментарии:

Below is the output of "route -n"

[root@h-008 crm]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
135.121.192.0   0.0.0.0         255.255.254.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         135.121.192.1   0.0.0.0         UG    0      0        0 eth0

а ниже - выходные данные traceroute с кластерной машины на машину вне кластера:

[root@h-008 crm]# traceroute 135.121.196.122
traceroute to 135.121.196.122 (135.121.196.122), 30 hops max, 40 byte packets
 1  135.121.192.1 (135.121.192.1)  6.750 ms  6.967 ms  7.634 ms
 2  135.121.205.225 (135.121.205.225)  12.296 ms  14.385 ms  16.101 ms
 3  s2h-003.hpe.test.com (135.121.196.122)  0.172 ms  0.170 ms  0.170 ms

и ниже представлены выходные данные traceroute с машины вне кластера на виртуальный IP 135.121.192.104:

[root@s2h-003 ~]# traceroute 135.121.192.104
traceroute to 135.121.192.104 (135.121.192.104), 30 hops max, 40 byte packets
 1  135.121.196.1 (135.121.196.1)  10.558 ms  10.895 ms  11.556 ms
 2  135.121.205.226 (135.121.205.226)  11.016 ms  12.797 ms  14.152 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  *

но когда я попытался выполнить трассировку реального IP-адреса кластера для одного из узлов, трассировка прошла успешно, то есть:

[root@s2h-003 ~]# traceroute 135.121.192.102
traceroute to 135.121.192.102 (135.121.192.102), 30 hops max, 40 byte packets
 1  135.121.196.1 (135.121.196.1)  4.994 ms  5.315 ms  5.951 ms
 2  135.121.205.226 (135.121.205.226)  3.816 ms  6.016 ms  7.158 ms
 3  h-009.msite.pr.hpe.test.com (135.121.192.102)  0.236 ms  0.229 ms  0.216 ms