[StSphinx]

Доброго времени суток, коллеги!

Экспериментирую с IOS SLB с целью обеспечения балансировки нагрузки на узлы CCM кластера, ну и с целью

повышения отказоустойчивости.

Конфигурация следующая:

 

Cisco IOS Software, s3223_rp Software (s3223_rp-ADVENTERPRISEK9_WAN-M), Version 12.2(33)SXH6,

железо Cisco 6509, Sup32,

 

ip slb serverfarm CCMSERVERS
nat server
failaction purge
!
real 10.245.183.100
  maxconns 1000
  faildetect numconns 1 numclients 1
  retry 120
  inservice
!
real 10.245.183.101
  maxconns 1000
  faildetect numconns 1 numclients 1
  retry 120
  inservice
!
ip slb vserver CCMCLUSTER-TCP
virtual 192.168.3.10 tcp 0
serverfarm CCMSERVERS
sticky 600
idle 240
inservice
!
ip slb vserver CCMCLUSTER-UDP
virtual 192.168.3.10 udp 5060
serverfarm CCMSERVERS
sticky 300
inservice

 

Реалы подняты на виртуалке.

При тестировании, с TCP проблем нет - отключаем один реал, SYN после некотрого тайемаута идет на второй и в целом отказ узла практически незаметен.

С UDP лыжи не едут. Отключаем один их реалов, но пакеты продолжают упорно сыпаться на него:

c65k-sup32-core#sh ip slb connections

vserver         prot client                real                  state     nat
-------------------------------------------------------------------------------
CCMCLUSTER-UDP  UDP  192.168.102.199:5060  10.245.183.101        ESTAB     S

и что интересно, state - ESTAB, хотя узел молчит. Глюк IOS'a?

И можно ли вообще обесечить при помощи SLB банасировку+отказоустойчивость UDP-based сервисов?

ip slb probe пробовал... IOS почему-то выбирается для тестов source интерфейс из другого vrf, соотв. проку от такого probe - ноль.