Mailing List Archive

A better idea for aliased ports is to associate them with a
master port. If you have X aliased ports then you are generating
X + 1 healthchecks (if you could get them to work in your setup
that is :). This is not only an excessive load but also provides
a window during which 1 VIP may believe a real server is fine
while another knows it's failed a healthcheck.

If you associate the aliased port with a master port then it
just uses the current state of the master port without re-testing
the service's health. You can set it up using something like
the following fragment.

---
server port 1110
connection-log all
session-sync
tcp keepalive 5 3
tcp keepalive use-master-state
---

In this situation, port 1110 is an alias to 110 and is bound using
a "no port 110 translate" on the VIP. Works like a charm.


David
...


On 12/11/2004, at 4:48 AM, Michael Renner wrote:

> Hi,
>
> I currently have a "Many-to-one" setup [1] on a Foundry ServerIron XL
> running 07.4.00T12, with 2 virtual servers pointing to 3 real servers,
> but I'm not able to enable keepalive on the "aliased" port as
> suggested in the documentation [2].
>
[ ..... ]
>
> ---
>
> server port 53
> udp keepalive 3 2
>
> server port 153
> udp keepalive 3 2
> udp keepalive protocol 53
>
> server real www1 1.1.1.1
> port 153
> port 153 keepalive
> port dns
> port dns keepalive
> port dns addr_query "www.domain.com"
>
> [repeat for www2 and www3]
>
> server virtual a.ns.domain.com 1.2.1.1
> port dns
> bind dns www1 dns www2 dns www3 dns
>
> server virtual b.ns.domain.com 1.3.1.1
> port dns
> no port dns translate
> bind dns www1 153 www2 153 www3 153
>
> ---

David J. Hughes wrote:
>
> A better idea for aliased ports is to associate them with a
> master port. If you have X aliased ports then you are generating
> X + 1 healthchecks (if you could get them to work in your setup
> that is :). This is not only an excessive load but also provides
> a window during which 1 VIP may believe a real server is fine
> while another knows it's failed a healthcheck.

Ahhh, yeah, that would be great if it wasn't for strange limitations in
the foundry firmware. Quoting from the documentation [1]:

"You cannot base an alias port?s health on the health of a UDP port or a
port that is not well-known to the ServerIron."

Bummer. But since it's only DNS the "excessive" requests aren't really a
problem. About the window - oh well - something I've to live with I
guess ;).

Other than that my setup looks fine or is there still room for improvement?

[1]
http://www.foundrynet.com/services/documentation/siug/ServerIron_health_checks.html#55152

best regards,
Michael

On 12/11/2004, at 10:37 AM, Michael Renner wrote:

> Ahhh, yeah, that would be great if it wasn't for strange limitations
> in the foundry firmware. Quoting from the documentation [1]:
>
> "You cannot base an alias port?s health on the health of a UDP port or
> a port that is not well-known to the ServerIron."

Wow! I've seen some "odd" things on the SI's but that one just about
takes the cake. Logic, useability, and firmware development strategies
are obviously mutually exclusive :)



> Bummer. But since it's only DNS the "excessive" requests aren't really
> a problem. About the window - oh well - something I've to live with I
> guess ;).

We had about 20 port aliased VIPs (to handle legacy addresses and other
ugliness) and the "window" actually was a significant problem. Luckily
for us these were POP3 VIPs so I didn't find this issue about non-well
known tcp ports.

>
> Other than that my setup looks fine or is there still room for
> improvement?

Looks fine to me.


David
...

On 12/11/2004, at 11:01 AM, David J. Hughes wrote:

>> "You cannot base an alias port?s health on the health of a UDP port
>> or a port that is not well-known to the ServerIron."
>
> Wow! I've seen some "odd" things on the SI's but that one just about
> takes the cake. Logic, useability, and firmware development
> strategies are obviously mutually exclusive :)

It's not every day I reply to my own posts ;-)

But, on this "well known tcp port" business, I just remembered that
when we did our initial testing of using master-port configuration we
did it using dummy SMTP servers running on port 26 - and it worked just
fine. Now, TCP 26 doesn't appear to be too well known to me. That was
on a pair of SI-100's running WSR08100m. Might be worth actually
trying it before discarding the idea.


David
...

David J. Hughes wrote:
>
> On 12/11/2004, at 11:01 AM, David J. Hughes wrote:
>
>> Wow! I've seen some "odd" things on the SI's but that one just about
>> takes the cake. Logic, useability, and firmware development
>> strategies are obviously mutually exclusive :)
>
>
> It's not every day I reply to my own posts ;-)
>
> But, on this "well known tcp port" business, I just remembered that when
> we did our initial testing of using master-port configuration we did it
> using dummy SMTP servers running on port 26 - and it worked just fine.
> Now, TCP 26 doesn't appear to be too well known to me. That was on a
> pair of SI-100's running WSR08100m. Might be worth actually trying it
> before discarding the idea.

I think the "well-known" stuff is bullshit, they just didn't implement
it for UDP for reasons unbeknownst (doesn't appear in the tab completion
list of "udp keepalive", typing it in manually results in "Invalid input").

best regards,
michael

Have you first tried the following from the "server port 153" config, thereby setting 153 to be udp protocol dns?:


SSH@emvl-lab-lb01(config-port-153)#udp keepalive
DECIMAL Number
protocol protocol used for keepalive
SSH@emvl-lab-lb01(config-port-153)#udp keepalive proto
dns
SSH@emvl-lab-lb01(config-port-153)#udp keepalive proto dns

-----Original Message-----
From: foundry-nsp-bounces@puck.nether.net [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Michael Renner
Sent: Thursday, November 11, 2004 10:49 AM
To: foundry-nsp@puck.nether.net
Subject: [f-nsp] dns keepalive checks on "unknown" ports

Hi,

I currently have a "Many-to-one" setup [1] on a Foundry ServerIron XL running 07.4.00T12, with 2 virtual servers pointing to 3 real servers, but I'm not able to enable keepalive on the "aliased" port as suggested in the documentation [2].

SSH@sollbruchstelle(config-rs-www1)#port 153 addr_query "www.domain.com"
Invalid command, zone only applies to DNS port, not 153

Is this intended behaviour for alias ports when not using HTTP (since HTTP is IIRC the only protocol which supports Virtualhosts)?

Currently the foundry seems to do dns checks on the "real" and the "aliased"
port using the configured hostname (i see 2 queries every 3 seconds, opposed to 1 query every 3 seconds, when no alias port is used), deactivating both ports when the dns server is down.

[1]
http://www.foundrynet.com/services/documentation/siug/ServerIron_Server_Load_Balancing.html#22178
[2]
http://www.foundrynet.com/services/documentation/siug/ServerIron_health_checks.html#53798


Current setup looks something like that:

---

server port 53
udp keepalive 3 2

server port 153
udp keepalive 3 2
udp keepalive protocol 53

server real www1 1.1.1.1
port 153
port 153 keepalive
port dns
port dns keepalive
port dns addr_query "www.domain.com"

[repeat for www2 and www3]

server virtual a.ns.domain.com 1.2.1.1
port dns
bind dns www1 dns www2 dns www3 dns

server virtual b.ns.domain.com 1.3.1.1
port dns
no port dns translate
bind dns www1 153 www2 153 www3 153

---



--

best regards,
Michael Renner - Network services

Preisvergleich Internet Services AG
Obere Donaustra?e 63/2, A-1020 Wien
Tel: +43 1 5811609 80
Fax: +43 1 5811609 55
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

Cliff Fogle wrote:
> Have you first tried the following from the "server port 153" config, thereby setting 153 to be udp protocol dns?:
>
>
> SSH@emvl-lab-lb01(config-port-153)#udp keepalive
> DECIMAL Number
> protocol protocol used for keepalive
> SSH@emvl-lab-lb01(config-port-153)#udp keepalive proto
> dns
> SSH@emvl-lab-lb01(config-port-153)#udp keepalive proto dns

Yep, it's in the example I sent in the mail. Foundry simply doesn't
support using the state of the master port for UDP ports...

best regards,
michael