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:

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

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

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

¿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:

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