Fallo conexion segmentos de red

Pues no sale nada por pantalla despues de poner ese comando.

Cual puede ser la solucion?


"Guillermo Roldan" escribió en
el mensaje news:
Mostrar la cita

Ejecuta el siguiente comando en el servidor SQL, y dinos que te devuelve:

netstat -an | find "LISTENING" | find "1433"

Es para descartar si buscamos el problema dentro o fuera del servidor...


"Alfonso" wrote:

> Pues no me conecta a ese puerto y el firewall de windows esta

desactivado.
Mostrar la cita

> Lo extraño que desde una red si lo haga y desde otra no cuando todo pasa
> atraves del mismo interface de red.
>
> Gracias por responder tan rapido
>
> "Guillermo Roldan" escribió

en
Mostrar la cita

> el mensaje news:
> > Hola Alfonso,
> >
> > Desde uno de los clientes que no puedes conectarte, y suponiendo que

se
Mostrar la cita

> > trata de una instancia por defecto, utilizando el protocolo TCP/IP y

el
Mostrar la cita

> > puerto TCP por defecto:
> >
> > telnet 192.168.0.2 1433
> >
> > Si la pantalla se queda como "esperando", el puerto está a la escucha

y tu
Mostrar la cita

> > equipo cliente tiene conectividad física para abrir un socket con tu
> servidor
> > SQL Server.
> >
> > Si no es así, planteate la existencia de algún firewall, o puede que

tu
Mostrar la cita

> > máquina sea un cluster de SQL y haya sufrido algún cambio y/o adición

de
Mostrar la cita

> > dirección IP (mira el visor de sucesos y el ErrorLog de SQL Server, en
> busca
> > de algún error sobre alguna IP o interfaz... quizás haya que tocar
> registro).
> >
> > Saludos,
> > Guillermo
> >
> >
> > "Alfonso" wrote:
> >
> > > Saludos, tengo un fallo en la conexión a mi base de datos SQL Server
> 2000
> > > que me trae de cabeza. En mi red hay 3 segmentos de red debido

nuestra
Mostrar la cita

> VPN.
> > > El problema esta en que las conexiones a la base de datos fuera del
> segmento
> > > de red del servidor a este se hacen correctamente. Pero los que se
> quieren
> > > conectar al servidor que están en su mismo segmento de red no pueden
> > > hacerlo. Ejemplo para aclararlo:
> > >
> > > BBDD esta en 192.168.0.2
> > > Todos los que se quieren conectar desde 192.168.1.X y 192.168.2.X

puede
Mostrar la cita

> > > hacerlo.
> > > Todos los que se quieren conectar desde 192.168.0.X no pueden

hacerlo.
Mostrar la cita

> > >
> > > Alguien sabe que puede pasar?
> > >
> > > Gracias por adelantado.
> > >
> > >
> > >
>
>
>

Ejecuta el comando siguiente:

netstat -an

y mira en qué direcciones IP está escuchando SQL Server, tanto el puerto
TCP-1433 como el UDP-1434.

Es posible que no esté escuchando en la dirección que deseas. Por ejemplo,
hace un mes, después de cambiar la IP de un cluster de SQL con el CDROM de
instalación de SQL Server (como debe hacerse en un cluster), al arrancar SQL
funcionaba bien pero no estaba escuchando en la dirección IP nueva. La
conexión a SQL Server si era posible por named pipes y shared memory, pero no
lo era por TCP/IP. En este caso, hubo que modificar el registro de Windows,
ya que quedó en una clave del registro la dirección IP antigua, y hasta que
no se corrigió manualmente, no se levantó el puerto TCP sobre esa IP. Hay un
documento en la Web de Microsoft, acerca de la desintalación manual de SQL
Server, que indica las ramas del registro utilizadas por el producto.

Otra prueba que puedes hacer, es desde un cliente, conectarte utilizando
named pipes. Para esto puedes utilizar la "Herramienta de red de cliente" de
SQL Server en uno de los PCs, para forzar que la conexión sea a través de
named pipes, y conectarte a continuación con el Analizador de Consultas o el
Administrador Corporativo (creo que hay algunos drivers que sólo funcionan
con la conectividad de TCP/IP y no con Named Pipes, al menos, tuvimos
problemas por ello con una aplicación Java hace unos meses).

Por cierto ¿tienes Windows 2003 en el servidor? ¿qué service pack de SQL
Server estás utilizando? En una instalación de SQL Server 2000 sobre Windows
2003 los puertos TCP y UDP no se levantan salvo que tengas Service Pack 3 ó
superior (ahora dudo si con el SP2 vale... pero creo que no, que 3 o 4)

Comprueba esto y dinos algo.

Saludos,
Guillermo

"Alfonso" wrote:

Mostrar la cita

Pues no sale nada por pantalla despues de poner ese comando.

Cual puede ser la solucion?


"Guillermo Roldan" escribió en
el mensaje news:
> Ejecuta el siguiente comando en el servidor SQL, y dinos que te devuelve:
>
> netstat -an | find "LISTENING" | find "1433"
>
> Es para descartar si buscamos el problema dentro o fuera del servidor...
>
>
> "Alfonso" wrote:
>
> > Pues no me conecta a ese puerto y el firewall de windows esta
desactivado.
> > Lo extraño que desde una red si lo haga y desde otra no cuando todo pasa
> > atraves del mismo interface de red.
> >
> > Gracias por responder tan rapido
> >
> > "Guillermo Roldan" escribió
en
> > el mensaje news:
> > > Hola Alfonso,
> > >
> > > Desde uno de los clientes que no puedes conectarte, y suponiendo que
se
> > > trata de una instancia por defecto, utilizando el protocolo TCP/IP y
el
> > > puerto TCP por defecto:
> > >
> > > telnet 192.168.0.2 1433
> > >
> > > Si la pantalla se queda como "esperando", el puerto está a la escucha
y tu
> > > equipo cliente tiene conectividad física para abrir un socket con tu
> > servidor
> > > SQL Server.
> > >
> > > Si no es así, planteate la existencia de algún firewall, o puede que
tu
> > > máquina sea un cluster de SQL y haya sufrido algún cambio y/o adición
de
> > > dirección IP (mira el visor de sucesos y el ErrorLog de SQL Server, en
> > busca
> > > de algún error sobre alguna IP o interfaz... quizás haya que tocar
> > registro).
> > >
> > > Saludos,
> > > Guillermo
> > >
> > >
> > > "Alfonso" wrote:
> > >
> > > > Saludos, tengo un fallo en la conexión a mi base de datos SQL Server
> > 2000
> > > > que me trae de cabeza. En mi red hay 3 segmentos de red debido
nuestra
> > VPN.
> > > > El problema esta en que las conexiones a la base de datos fuera del
> > segmento
> > > > de red del servidor a este se hacen correctamente. Pero los que se
> > quieren
> > > > conectar al servidor que están en su mismo segmento de red no pueden
> > > > hacerlo. Ejemplo para aclararlo:
> > > >
> > > > BBDD esta en 192.168.0.2
> > > > Todos los que se quieren conectar desde 192.168.1.X y 192.168.2.X
puede
> > > > hacerlo.
> > > > Todos los que se quieren conectar desde 192.168.0.X no pueden
hacerlo.
> > > >
> > > > Alguien sabe que puede pasar?
> > > >
> > > > Gracias por adelantado.
> > > >
> > > >
> > > >
> >
> >
> >

Aparece el puerto UDP 1434 pero no el TCP 1433.

De nuevo muchas gracias por responder tan pronto.

"Guillermo Roldan" escribió en
el mensaje news:
Mostrar la cita

Ejecuta el comando siguiente:

netstat -an

y mira en qué direcciones IP está escuchando SQL Server, tanto el puerto
TCP-1433 como el UDP-1434.

Es posible que no esté escuchando en la dirección que deseas. Por ejemplo,
hace un mes, después de cambiar la IP de un cluster de SQL con el CDROM de
instalación de SQL Server (como debe hacerse en un cluster), al arrancar

SQL
Mostrar la cita

funcionaba bien pero no estaba escuchando en la dirección IP nueva. La
conexión a SQL Server si era posible por named pipes y shared memory, pero

no
Mostrar la cita

lo era por TCP/IP. En este caso, hubo que modificar el registro de

Windows,
Mostrar la cita

ya que quedó en una clave del registro la dirección IP antigua, y hasta

que
Mostrar la cita

no se corrigió manualmente, no se levantó el puerto TCP sobre esa IP. Hay

un
Mostrar la cita

documento en la Web de Microsoft, acerca de la desintalación manual de SQL
Server, que indica las ramas del registro utilizadas por el producto.

Otra prueba que puedes hacer, es desde un cliente, conectarte utilizando
named pipes. Para esto puedes utilizar la "Herramienta de red de cliente"

de
Mostrar la cita

SQL Server en uno de los PCs, para forzar que la conexión sea a través de
named pipes, y conectarte a continuación con el Analizador de Consultas o

el
Mostrar la cita

Administrador Corporativo (creo que hay algunos drivers que sólo funcionan
con la conectividad de TCP/IP y no con Named Pipes, al menos, tuvimos
problemas por ello con una aplicación Java hace unos meses).

Por cierto ¿tienes Windows 2003 en el servidor? ¿qué service pack de SQL
Server estás utilizando? En una instalación de SQL Server 2000 sobre

Windows
Mostrar la cita

2003 los puertos TCP y UDP no se levantan salvo que tengas Service Pack 3

ó
Mostrar la cita

superior (ahora dudo si con el SP2 vale... pero creo que no, que 3 o 4)

Comprueba esto y dinos algo.

Saludos,
Guillermo

"Alfonso" wrote:

> Pues no sale nada por pantalla despues de poner ese comando.
>
> Cual puede ser la solucion?
>
>
> "Guillermo Roldan" escribió

en
Mostrar la cita

> el mensaje news:
> > Ejecuta el siguiente comando en el servidor SQL, y dinos que te

devuelve:
Mostrar la cita

> >
> > netstat -an | find "LISTENING" | find "1433"
> >
> > Es para descartar si buscamos el problema dentro o fuera del

servidor...
Mostrar la cita

> >
> >
> > "Alfonso" wrote:
> >
> > > Pues no me conecta a ese puerto y el firewall de windows esta
> desactivado.
> > > Lo extraño que desde una red si lo haga y desde otra no cuando todo

pasa
Mostrar la cita

> > > atraves del mismo interface de red.
> > >
> > > Gracias por responder tan rapido
> > >
> > > "Guillermo Roldan"

escribió
Mostrar la cita

> en
> > > el mensaje

news:
Mostrar la cita

> > > > Hola Alfonso,
> > > >
> > > > Desde uno de los clientes que no puedes conectarte, y suponiendo

que
Mostrar la cita

> se
> > > > trata de una instancia por defecto, utilizando el protocolo TCP/IP

y
Mostrar la cita

> el
> > > > puerto TCP por defecto:
> > > >
> > > > telnet 192.168.0.2 1433
> > > >
> > > > Si la pantalla se queda como "esperando", el puerto está a la

escucha
Mostrar la cita

> y tu
> > > > equipo cliente tiene conectividad física para abrir un socket con

tu
Mostrar la cita

> > > servidor
> > > > SQL Server.
> > > >
> > > > Si no es así, planteate la existencia de algún firewall, o puede

que
Mostrar la cita

> tu
> > > > máquina sea un cluster de SQL y haya sufrido algún cambio y/o

adición
Mostrar la cita

> de
> > > > dirección IP (mira el visor de sucesos y el ErrorLog de SQL

Server, en
Mostrar la cita

> > > busca
> > > > de algún error sobre alguna IP o interfaz... quizás haya que tocar
> > > registro).
> > > >
> > > > Saludos,
> > > > Guillermo
> > > >
> > > >
> > > > "Alfonso" wrote:
> > > >
> > > > > Saludos, tengo un fallo en la conexión a mi base de datos SQL

Server
Mostrar la cita

> > > 2000
> > > > > que me trae de cabeza. En mi red hay 3 segmentos de red debido
> nuestra
> > > VPN.
> > > > > El problema esta en que las conexiones a la base de datos fuera

del
Mostrar la cita

> > > segmento
> > > > > de red del servidor a este se hacen correctamente. Pero los que

se
Mostrar la cita

> > > quieren
> > > > > conectar al servidor que están en su mismo segmento de red no

pueden
Mostrar la cita

> > > > > hacerlo. Ejemplo para aclararlo:
> > > > >
> > > > > BBDD esta en 192.168.0.2
> > > > > Todos los que se quieren conectar desde 192.168.1.X y

192.168.2.X
Mostrar la cita

> puede
> > > > > hacerlo.
> > > > > Todos los que se quieren conectar desde 192.168.0.X no pueden
> hacerlo.
> > > > >
> > > > > Alguien sabe que puede pasar?
> > > > >
> > > > > Gracias por adelantado.
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>
>
>

¿y seguro que SQL Server está escuchando en el puerto TCP 1433?

En el servidor, puedes utilizar la "Herramienta de red del servidor" para
comprobar en qué puerto TCP está escuchando cada una de tus instancias.

¿Has conseguido conectarte a través de named pipes?



"Alfonso" wrote:

Mostrar la cita

Aparece el puerto UDP 1434 pero no el TCP 1433.

De nuevo muchas gracias por responder tan pronto.

"Guillermo Roldan" escribió en
el mensaje news:
> Ejecuta el comando siguiente:
>
> netstat -an
>
> y mira en qué direcciones IP está escuchando SQL Server, tanto el puerto
> TCP-1433 como el UDP-1434.
>
> Es posible que no esté escuchando en la dirección que deseas. Por ejemplo,
> hace un mes, después de cambiar la IP de un cluster de SQL con el CDROM de
> instalación de SQL Server (como debe hacerse en un cluster), al arrancar
SQL
> funcionaba bien pero no estaba escuchando en la dirección IP nueva. La
> conexión a SQL Server si era posible por named pipes y shared memory, pero
no
> lo era por TCP/IP. En este caso, hubo que modificar el registro de
Windows,
> ya que quedó en una clave del registro la dirección IP antigua, y hasta
que
> no se corrigió manualmente, no se levantó el puerto TCP sobre esa IP. Hay
un
> documento en la Web de Microsoft, acerca de la desintalación manual de SQL
> Server, que indica las ramas del registro utilizadas por el producto.
>
> Otra prueba que puedes hacer, es desde un cliente, conectarte utilizando
> named pipes. Para esto puedes utilizar la "Herramienta de red de cliente"
de
> SQL Server en uno de los PCs, para forzar que la conexión sea a través de
> named pipes, y conectarte a continuación con el Analizador de Consultas o
el
> Administrador Corporativo (creo que hay algunos drivers que sólo funcionan
> con la conectividad de TCP/IP y no con Named Pipes, al menos, tuvimos
> problemas por ello con una aplicación Java hace unos meses).
>
> Por cierto ¿tienes Windows 2003 en el servidor? ¿qué service pack de SQL
> Server estás utilizando? En una instalación de SQL Server 2000 sobre
Windows
> 2003 los puertos TCP y UDP no se levantan salvo que tengas Service Pack 3
ó
> superior (ahora dudo si con el SP2 vale... pero creo que no, que 3 o 4)
>
> Comprueba esto y dinos algo.
>
> Saludos,
> Guillermo
>
> "Alfonso" wrote:
>
> > Pues no sale nada por pantalla despues de poner ese comando.
> >
> > Cual puede ser la solucion?
> >
> >
> > "Guillermo Roldan" escribió
en
> > el mensaje news:
> > > Ejecuta el siguiente comando en el servidor SQL, y dinos que te
devuelve:
> > >
> > > netstat -an | find "LISTENING" | find "1433"
> > >
> > > Es para descartar si buscamos el problema dentro o fuera del
servidor...
> > >
> > >
> > > "Alfonso" wrote:
> > >
> > > > Pues no me conecta a ese puerto y el firewall de windows esta
> > desactivado.
> > > > Lo extraño que desde una red si lo haga y desde otra no cuando todo
pasa
> > > > atraves del mismo interface de red.
> > > >
> > > > Gracias por responder tan rapido
> > > >
> > > > "Guillermo Roldan"
escribió
> > en
> > > > el mensaje
news:
> > > > > Hola Alfonso,
> > > > >
> > > > > Desde uno de los clientes que no puedes conectarte, y suponiendo
que
> > se
> > > > > trata de una instancia por defecto, utilizando el protocolo TCP/IP
y
> > el
> > > > > puerto TCP por defecto:
> > > > >
> > > > > telnet 192.168.0.2 1433
> > > > >
> > > > > Si la pantalla se queda como "esperando", el puerto está a la
escucha
> > y tu
> > > > > equipo cliente tiene conectividad física para abrir un socket con
tu
> > > > servidor
> > > > > SQL Server.
> > > > >
> > > > > Si no es así, planteate la existencia de algún firewall, o puede
que
> > tu
> > > > > máquina sea un cluster de SQL y haya sufrido algún cambio y/o
adición
> > de
> > > > > dirección IP (mira el visor de sucesos y el ErrorLog de SQL
Server, en
> > > > busca
> > > > > de algún error sobre alguna IP o interfaz... quizás haya que tocar
> > > > registro).
> > > > >
> > > > > Saludos,
> > > > > Guillermo
> > > > >
> > > > >
> > > > > "Alfonso" wrote:
> > > > >
> > > > > > Saludos, tengo un fallo en la conexión a mi base de datos SQL
Server
> > > > 2000
> > > > > > que me trae de cabeza. En mi red hay 3 segmentos de red debido
> > nuestra
> > > > VPN.
> > > > > > El problema esta en que las conexiones a la base de datos fuera
del
> > > > segmento
> > > > > > de red del servidor a este se hacen correctamente. Pero los que
se
> > > > quieren
> > > > > > conectar al servidor que están en su mismo segmento de red no
pueden
> > > > > > hacerlo. Ejemplo para aclararlo:
> > > > > >
> > > > > > BBDD esta en 192.168.0.2
> > > > > > Todos los que se quieren conectar desde 192.168.1.X y
192.168.2.X
> > puede
> > > > > > hacerlo.
> > > > > > Todos los que se quieren conectar desde 192.168.0.X no pueden
> > hacerlo.
> > > > > >
> > > > > > Alguien sabe que puede pasar?
> > > > > >
> > > > > > Gracias por adelantado.
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> >
> >
> >
>