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

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.googlegroups.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:
> 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.googlegroups.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.
> >

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.googlegroups.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.../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 w
ay
> 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.googlegroups.com...

ASP.NET w/ SQL Server Sessions & Cluster Failover

Is there an elegant way to clear out the ADO connection pool used by the SQL
Server State Service following a cluster failover?
We are using a SQL Cluster to store both the ASP Session State database and
our application database.
When the SQL Server cluster is failed-over, any "pointers" to the live
connections stored in the connection pool are made invalid. When the
application tries to reference these "damaged" connections, it throws an
exception, and the pooling mechanism drops the bad connections from the
pool.
In our application, we are using a looping try/catch block to clear out the
bad connections from the pool following a failover, and the users typically
are not affected by the failover as a result of any exceptions in our
application code.
However, we don't have access to the source code for managing the ASPState
connections. It appears as though there is no mechanism for the ASPState
database to clear out the bad connections from the pool following a
failover, and thus the exceptions are affecting users.
Is SQL Server Session State Management even supposed to work with a SQL
Cluster?
Mike Olund
OpenRoad Communications
Same thing happens to us. We use ASP.Net connection pools very heavily and
they have some issues with bad connections after a failover. We also use a
try/catch to reconnect if there is a bad connection. If you find anything
else, please let me know.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"news.microsoft.com" <molund@.oroad.com> wrote in message
news:OeKzPeBREHA.568@.TK2MSFTNGP12.phx.gbl...
> Is there an elegant way to clear out the ADO connection pool used by the
SQL
> Server State Service following a cluster failover?
> We are using a SQL Cluster to store both the ASP Session State database
and
> our application database.
> When the SQL Server cluster is failed-over, any "pointers" to the live
> connections stored in the connection pool are made invalid. When the
> application tries to reference these "damaged" connections, it throws an
> exception, and the pooling mechanism drops the bad connections from the
> pool.
> In our application, we are using a looping try/catch block to clear out
the
> bad connections from the pool following a failover, and the users
typically
> are not affected by the failover as a result of any exceptions in our
> application code.
> However, we don't have access to the source code for managing the ASPState
> connections. It appears as though there is no mechanism for the ASPState
> database to clear out the bad connections from the pool following a
> failover, and thus the exceptions are affecting users.
> Is SQL Server Session State Management even supposed to work with a SQL
> Cluster?
> Mike Olund
> OpenRoad Communications
>
|||there is support in asp.net 2.0, the supported method in asp.net 1.1 is to
change the connection string (thus not reusing any old connections).
if you want an unsupported method, you can use reflection to call an
undocumented method.
(http://www.sys-con.com/dotnet/article.cfm?id=483)
-- bruce (sqlwork.com)
"news.microsoft.com" <molund@.oroad.com> wrote in message
news:OeKzPeBREHA.568@.TK2MSFTNGP12.phx.gbl...
> Is there an elegant way to clear out the ADO connection pool used by the
SQL
> Server State Service following a cluster failover?
> We are using a SQL Cluster to store both the ASP Session State database
and
> our application database.
> When the SQL Server cluster is failed-over, any "pointers" to the live
> connections stored in the connection pool are made invalid. When the
> application tries to reference these "damaged" connections, it throws an
> exception, and the pooling mechanism drops the bad connections from the
> pool.
> In our application, we are using a looping try/catch block to clear out
the
> bad connections from the pool following a failover, and the users
typically
> are not affected by the failover as a result of any exceptions in our
> application code.
> However, we don't have access to the source code for managing the ASPState
> connections. It appears as though there is no mechanism for the ASPState
> database to clear out the bad connections from the pool following a
> failover, and thus the exceptions are affecting users.
> Is SQL Server Session State Management even supposed to work with a SQL
> Cluster?
> Mike Olund
> OpenRoad Communications
>