Asymmetric communication from ms-sql-m protocol from an SQL Cluster

We are installing an application that requires access to the ms-sql-m
protocol (UDP/1434) as well as the data port (TCP/1433). The SQL Server
we are using is part of an N+1 cluster. The issue is that when we try
to communicate to the node instance xxx.xxx.123.226 recieve the
ms-sql-m response from the physical device ip xxx.xxx.123.222 causing
an asymmetric IP communication and the response appears to be dropped
by the request as one might expect. This causing our installation to
fail.
Has anyone run into this issue before, no of a common misconfiguration
in clustering services that leads to this, or aware of any documented
bug?
Thanks in advance for you posts.
Actually, this is typical of MS cluster applications. The response comes
back from the underlying NIC address, not the cluster virtual address. It
ain't a bug, it's a feature. Or at least it has always operated this way
and could therefore be considered a standard.
Sorry this isn't the answer you were looking for, but it is the way the
system actually works.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
<ddnash@.gmail.com> wrote in message
news:1165524543.657106.172130@.79g2000cws.googlegro ups.com...
> We are installing an application that requires access to the ms-sql-m
> protocol (UDP/1434) as well as the data port (TCP/1433). The SQL Server
> we are using is part of an N+1 cluster. The issue is that when we try
> to communicate to the node instance xxx.xxx.123.226 recieve the
> ms-sql-m response from the physical device ip xxx.xxx.123.222 causing
> an asymmetric IP communication and the response appears to be dropped
> by the request as one might expect. This causing our installation to
> fail.
> Has anyone run into this issue before, no of a common misconfiguration
> in clustering services that leads to this, or aware of any documented
> bug?
>
> Thanks in advance for you posts.
>
|||I found the following article that does acknowledge the issue and
states that MS has chosen not to address it at this point, but there
are a couple of workarounds.
http://blogs.msdn.com/sql_protocols/archive/2006/02/27/539706.aspx
Thanks for the post.
Geoff N. Hiten wrote:[vbcol=seagreen]
> Actually, this is typical of MS cluster applications. The response comes
> back from the underlying NIC address, not the cluster virtual address. It
> ain't a bug, it's a feature. Or at least it has always operated this way
> and could therefore be considered a standard.
> Sorry this isn't the answer you were looking for, but it is the way the
> system actually works.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
> <ddnash@.gmail.com> wrote in message
> news:1165524543.657106.172130@.79g2000cws.googlegro ups.com...
sql