Назад | Перейти на главную страницу

ServerIronGT не может пинговать реальные серверы

У меня есть балансировщик нагрузки Foundry ServerIronGT, и я пытаюсь настроить на нем SLB. Я нашел в Интернете несколько примеров того, как действовать, но у меня возникла странная проблема.

Вот моя установка:

Internet Gateway ----> Dell Switch ----> Server 1      (50.50.50.210)
                                   ----> Server 2      (50.50.50.211)
                                   ----> Server 3      (50.50.50.212)
                                   ----> ServerIronGT  (50.50.50.220)

Я настроил свой IP-адрес ServerIron так, чтобы он соответствовал моему общедоступному диапазону IP-адресов, и я могу легко пинговать его из любого места внутри или за пределами моей сети. Я также могу пинговать все отдельные серверы изнутри или за пределами моей сети.

На этом этапе, когда я подключен к консоли ServerIron, я могу нормально пинговать свой шлюз и даже могу пинговать IP-адреса за пределами моей сети, например DNS-сервер Google.

У меня проблема в том, что мои серверы, подключенные к коммутатору Dell, могут нормально пинговать мой ServerIron, но ServerIron не может пинговать ни один из серверов. Итак, когда я настраиваю свой виртуальный сервер, он всегда отображается как неисправный, потому что он не может достичь моих реальных серверов.

Вот мой конфиг:

!Building configuration...
!Current configuration : 512 bytes
!
ver 10.2.01eTD2
!
module 1 bi-0-port-wsm6-management-module
module 2 bi-jc-16-port-gig-copper-module
module 3 bi-jc-8-port-gig-module
!
context default
!
aaa authentication web-server default local
enable super-user-password .....
no enable aaa console
hostname SI-GT
ip address 50.50.50.220 255.255.255.240
ip default-gateway 50.50.50.222
ip dns server-address 8.8.8.8
no telnet server
username admin password .....
no snmp-server
!
end

Вот мои результаты на ServerIron:

Sending 1, 16-byte ICMP Echo to 50.50.50.222, timeout 5000 msec, TTL 64
Type Control-c to abort
Reply from 50.50.50.222    : bytes=16 time=5ms TTL=64
Success rate is 100 percent (1/1), round-trip min/avg/max=5/5/5 ms.

Sending 1, 16-byte ICMP Echo to 50.50.50.210, timeout 5000 msec, TTL 64
Type Control-c to abort
Request timed out.
No reply from remote host.

Sending 1, 16-byte ICMP Echo to 8.8.8.8, timeout 5000 msec, TTL 64
Type Control-c to abort
Reply from 8.8.8.8         : bytes=16 time=24ms TTL=46
Success rate is 100 percent (1/1), round-trip min/avg/max=24/24/24 ms.

Вот мои результаты с моего сервера:

PING 50.50.50.220 (50.50.50.220) 56(84) bytes of data.
64 bytes from 50.50.50.220: icmp_seq=1 ttl=64 time=0.039 ms
64 bytes from 50.50.50.220: icmp_seq=2 ttl=64 time=0.044 ms
64 bytes from 50.50.50.220: icmp_seq=3 ttl=64 time=0.048 ms
64 bytes from 50.50.50.220: icmp_seq=4 ttl=64 time=0.045 ms
^C
--- 50.50.50.220 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.039/0.044/0.048/0.003 ms

Что мне не хватает? Спасибо.

Оказалось, что мои правила брандмауэра блокировали эхо-запросы ICMP и эхо-ответы, что не позволяло моему балансировщику нагрузки видеть мои серверы как живые. Теперь все хорошо.

На самом деле это еще более глупо. Когда я добавил IP-адрес VIP в качестве псевдонима обратной связи для моих серверов, я по ошибке установил маску подсети, чтобы включить всю подсеть, заставляя сервер отвечать на запрос ping самому себе, вместо того, чтобы возвращать их обратно в балансировщик нагрузки. Вы должны убедиться, что при настройке псевдонима loopback вы установили маску подсети / 32 (255.255.255.255), чтобы она реагировала только на этот конкретный IP-адрес.