Service IP health status for remote GSLB slave

Community Forum Forums Thunder and AX Series General Service IP health status for remote GSLB slave

This topic contains 1 reply, has 1 voice, and was last updated by avatar wkucardinal 3 months, 1 week ago.

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #13912
    avatar
    wkucardinal
    Member

    Hi –

    This is probably a stupid question, but I have a configuration of master > slave for our GSLB configuration. We do both GSLB and SLB on each device (different datacenters) as most people do.

    We do not do any health monitoring at the GSLB level specifically. We want to rely on the up/down status of the VIP itself. Here is our example configuration:

    DR SLB:

    slb server test 1.2.3.4
    health-check-disable
    port 80 tcp
    exit
    slb service-group test-80 tcp
    member test 80
    exit
    exit
    slb virtual-server testdr-vip 11.11.11.11
    port 80 http
    service-group test-80
    source-nat auto
    exit

    Production SLB:
    slb server test 1.2.3.4
    health-check-disable
    port 80 tcp
    exit
    slb service-group test-80 tcp
    member test 80
    exit
    exit
    slb virtual-server testpd-vip 10.10.10.11
    port 80 http
    service-group test-80
    source-nat auto
    exit
    gslb service-ip testpd-vip 10.10.10.11
    port 80 tcp
    exit
    gslb service-ip testpd-vip 11.11.11.11
    port 80 tcp
    exit
    gslb zone test.dns.com
    service 53 test (<– we aren’t doing any special monitoring at GSLb level so we just use 53 to signify DNS)
    dns-a-record testpd-vip static
    dns-a-record testdr-vip static
    exit

    Now what we have configured is two different SLB/GSLB nodes, each in different datacenters, running two different VIPs. I have the GSLB on my master server (production) with the service-ips configured and the service records. I see that this data is replicated to the GSLB slave device.

    I also see that if I lose the production VIP for some reason the service-ip also goes down. This is by design. HOWEVER, if the DR VIP goes down, the master GSLB server never detects it. Strangely this behavior is only seen on our DMZ environment, so I suspect there may be a firewall issue in play.

    In our internal environment the behavior is that the VIP is disabled both ways, as it should be.

    Would there be a communications requirement between the DMZs for this to work? The production GSLB can contact DR but that is not true in reverse.

    • This topic was modified 3 months, 1 week ago by avatar wkucardinal.
    #13932
    avatar
    wkucardinal
    Member

    Another interesting potential factor:

    ICMP is completely blocked in the DR domain in this scenario. You cannot ping from anywhere to a VIP in that network. However, what confuses me about this is if that is the case why wouldn’t the master automatically mark any VIP/serviceip down that resides in the DR network when it cannot ping it?

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.

Comments are closed.