ADSL

Problemas al configurar ADSL2+ para router Cisco

BocaDePez 18 septiembre 2009 10:11

⋮

Hola,

Recientemente hemos adquirido una conexión ADSL2+ con Teléfonica, y estamos teniendo problemas al configurar dicha conexión con un router Cisco 870. Por supuesto, Telefónica no da soporte técnico para dicho router, y ya han probado que la lína funciona bien. Hemos configurado el router por PPoE con el usuario y password habitual que Telefónica nos da, además de introducir la IP fija y de fijar los valores VPI: 8 y VCI: 32.

Desde la configuración, no podemos acceder a todas las páginas web. Muchas de las páginas producen un 'time out'. Después de unos 60 segundos, el navegador indica que la página web no ha podido ser detectada. Hemos probado con diferentes navegadores (IE y Firefox), pero el problema continua.

Hemos leído varios artículos en los que indica que puede ser problema de las MUT. Pero ya hemos probado con varias, y si éxito. Hemos confirmado que el DNS funciona bien, porque resuelve bien los nombres. Hemos probado con varias DNS primaria y secundaria de Teléfonica y también otros operadores. Hemos probado introducir en el navegador direcciones IP de una página web concreta, pero tampoco funciona. Lo curioso es que podemos hacer un ping a esa dirección IP sin ningún problema desde el mismo ordenador. No entiendo que podamos hacer ping a una dirección IP, pero no navegar a la página web bajo la misma IP.

Podemos acceder a google.com sin ningún problema, google maps tambien. Pero no podemos navegar a www.yahoo.com o www.cisco.com por poner algún ejemplo.

Tenéis algún consejo que podamos seguir? Alguno habéis tenido problemas similares con routers Cisco? Tenemos que seleccionar quizás otro encapsulamiento?

bleeder 18 septiembre 2009 10:48

⋮

Lo que tienes que preguntar es si llamas a telefonica es si tu ip es fija o dinámica

Si es fija, pregunta si es fija por pppoe, en este caso se configura el router como una ip dinámica con lo cual el MTU es 1454 y no hace falta ponerle ninguna ip la obtiene por DHCP.

Si usa la RFC1483 entonces hay que usar otro MTU.

✖

bleeder 18 septiembre 2009 11:00

⋮

Creo que si es la RFC1483 al no llevar cabecera ppp se queda el MTU en 1472

BocaDePez 18 septiembre 2009 13:13

⋮

Si esta navegando (aunque sea mal) no es un problema de RFC o PPPoE. Las configuraciones con PPPoE son iguales independientemente de que la direccion asignada sea estatica o dinamica.

Pego aqui una plantilla para un 837 con PPPoE, me supongo que no debe ser muy diferente a la del 870

!Según el segmento de red de la LAN del cliente hay que cambiar:
!access-list 120 permit ip 192.168.1.0 0.0.0.255 any
!
!Según el dir.IP que hay que grabar en el router hay que cambiar:
!interface Ethernet0
! ip address 192.168.1.1 255.255.255.0
!
!*****INICIO CONFIGURACIÓN******
!
!Datos generales
!---------------
no service pad
service tcp-keepalives-in
service timestamps debug datetime
service timestamps log datetime
scheduler max-task-time 5000
no service password-encryption
!
ip subnet-zero
no ip source-route
no ip domain lookup
no ip bootp server
!
boot system flash
logging queue-limit 100
logging buffered 8192 debugging
!
!
!Asignar un nombre al router
!---------------------------
hostname cisco837
!
!
!Config.LAN IP/MASK de router
!----------------------------
interface Ethernet0
ip address 192.168.1.1 255.255.255.0
no ip redirects
no ip proxy-arp
ip nat inside
no cdp enable
hold-queue 100 out
no shutdown
!
!
!COnfig.WAN ATM/ADSL
!-------------------
interface ATM0
no ip address
no atm ilmi-keepalive
dsl operating-mode ansi-dmt
no shutdown
!
interface ATM0.1 point-to-point
pvc 8/32
encapsulation aal5snap
pppoe-client dial-pool-number 1
!
!
!Config.cliente PPPoE
!--------------------
vpdn enable
!
vpdn-group pppoe
request-dialin
protocol pppoe
!
interface Dialer0
ip address negotiated
no ip redirects
no ip proxy-arp
ip mtu 1492
ip nat outside
encapsulation ppp
dialer pool 1
no cdp enable
ppp authentication pap callin
ppp pap sent-username adslppp@telefonicanetpa password adslppp
!
!
!Definir lista de acceso
!Necesario para definir NAT
!-----------------------------
no access-list 120
access-list 120 permit ip 192.168.1.0 0.0.0.255 any
no cdp run
!
!
!Definir NAT
!-----------
ip nat translation tcp-timeout 900
ip nat translation udp-timeout 15
ip nat translation dns-timeout 10
ip nat translation icmp-timeout 10
ip nat inside source list 120 interface Dialer0 overload
ip classless
ip route 0.0.0.0 0.0.0.0 Dialer0

✖

BocaDePez 18 septiembre 2009 13:34

⋮

Por probar no pasa nada, que pruebe a cambiar el mtu 1454.

Si no funciona seguro que tiene que ser algo de rutas, prueba a hacer un tracert a www.yahoo.com

Has probado otro router de algun amigo?

BocaDePez 21 septiembre 2009 10:53

⋮

cuanta tonteria te responden u_u, lo primero que has de averiguar es si el router cisco es compatible con adsl2+, porque yo he montado bastantes de esos y nunca he visto ninguno que lo sea, ademas tienes la interfaz atm0 en ansi-dmt, como mucho si pruebas a ponerlo en auto quiza te funciona, pero ya te digo que dudo mucho que ese router soporte adsl2+

✖

BocaDePez 21 septiembre 2009 10:56

⋮

ah, y las pruebas de conectividad teniendo un router cisco no se hacen nunca con un navegador, se hacen desde el mismo ping del router, si no sabeis que es y como funciona un cisco, no lo compreis, y no, yo tampoco se bien como funciona, solo se 4 cosas basicas

BocaDePez 21 septiembre 2009 11:28

⋮

¿Qué tendrá que ver el tipo de sincronización? Si el router solo fuese ADSL y no ADSL2+, el DSLAM tiene que ser compatible hacia atrás.

Además, te ha dicho que sincroniza y conecta. Ya ha establecido la sesión PPP, y le responden los pings. Eso ya es capa 3.

Además te ha dicho que www.google.com sí que les funciona. Eso ya es capa 7. Las tonterías quizás las digas tú. ;)

✖

BocaDePez 21 septiembre 2009 12:32

⋮

el dslam aunque sea capaz de funcionar en adsl y adsl2+ puede estar configurado para funcionar solo con adsl2+ ( me ha pasado ya en un par de averias de bancos con routers cisco 870 , el qual solo acepta adsl, y se ha tenido que llamar ahora no recuerdo si al csd o a otro departamento para que cambien la configuracion del puerto dslam a adsl o adsl/adsl2+ )

y repito y me reafirmo en que cualquier prueba de conectividad se hace con el propio router, yo no se, y tu tampoco sabes, como tienen la instalacion de red en esa empresa, quiza tengan un segundo adsl y los pings salgan por el, quiza tengan un firewall fisico, quiza ... quiza ... quiza ..., si nisiquiera sabemos si las pruebas las realizan con un pc conectado directo al router o conectado a la red, el router podria estar funcionando perfectamente pero no funcionar por culpa de un problema de la red interna, por eso los pings siempre se han de hacer desde el propio router

por cierto, que solo ha dicho que le responde al ping, no ha dicho que el router este sincronizado, y como he dicho antes, ni tu ni yo sabemos bajo que condiciones esta haciendo las pruebas, y tal y como pone en la pagina web de cisco, si no es un cisco 876 no le va a funcionar bajo adsl2+

✖

BocaDePez 21 septiembre 2009 12:36

⋮

tendrias que revisar esto cisco.com/c/en/us/td/docs/ios/12_4t/12_4…/annexm.html , especificamente la parte del dsl operating-mode

BocaDePez 21 septiembre 2009 12:54

⋮

Si alguien pone un Cisco es porque tiene un mínimo de idea sobre este tema. Creer tú que el PC responde a los pings porque "quizás" esté saliendo por otro router de otra línea, es rizar el rizo. No creo que el tío fuese tan tonto.

Ahora bien, cierto que no ha dicho si tiene algún elemento intermedio entre el PC y el router. Si hay problemas de MTU, creo que todo administrador de red sabe (o debería saber) que eso se diagnostica mandando paquetes ICMP con la bandera de no permitir fragmentado, desde 1500 y tirando hacia abajo hasta que se determina cual es la MTU (o MSS) que causa el cuello de botella.

Lo lógico es que sea la persona que abrió el hilo quien siga comentando qué topología tiene y qué pruebas ha hecho desde el viernes.

SuPRiMaZo 21 septiembre 2009 11:55

⋮

Totalmente de acuerdo con lo comentado por bocadepez situado justo encima mia...

Sincronizado y con PPP, y este hombre nos habla de si el CPE es compatible con ADSL2+... Es maravilloso que plantees algo como que puede ser que el CPE no soporte determinada tecnología, ahora bien, cagarla diciendo que lo que comentan más arriba son tonterías cuando tu estás haciendo una distinción (DE FUNCIONALIDAD) entre ADSL y ADSL2+...

En lo que al thread se refiere... ¿el autor del post ha puesto que valores de MTU ha usado?

✖

BocaDePez 21 septiembre 2009 13:15

⋮

esque todo lo de arriba es una tonteria cuando nisiquiera se sabe si sincroniza xDD

por cierto, antes de liarse a configurar el router le habeis borrado la configuracion que pudiera llevar por defecto?, habeis instalado la ultima ios o la que sea recomendada para funcionar con telefonica o adsl2+

✖

SuPRiMaZo 21 septiembre 2009 14:40

⋮

Pero como no va a sincronizar si está diciendo que hay determinadas IP's que responden a los pings y es más, dice que es capaz de navegar por google.com...

BocaDePez 21 septiembre 2009 18:04

⋮

habia un comando, creo recordar que era show ip-interface brief, ponlo y pega el resultado, lo siguiente seria que pegaras toda la configuracion, el problema es que no recuerdo exactamente como se hacia, puede que con show conf, pero no estoy seguro si dentro o fuera de conf t

✖

BocaDePez 16 diciembre 2009 18:23

⋮

Todos decis cosas correctas.

El 827 y eo 837 no son ADSL2+, solo si la DSLAM está configurada para ello te sincronizará, si no solo te parpadeará la luz de CD y no te hará nada más. El segundo problema -el dice que le funciona una página y otra no-- : Entiendo que no tienes en cache las págins que visitas no ...

Entra en el router y haz un ping extendido en el cual va a ir poniendo los paquetes que vas a enviar, de esa manera vas a confirmar si tienes o no un problema de MTU. Ejemplo: Si tú hace un ping a www.cisco.com, no te funcionará, no porque no funcione, si no porque no puede enviar echo-replys el equipo destino, ya que está capado. Lo mismo pasa con la MTU, no todos los equipos a los que accedes tienen la capacidad de enviar la trama como tu la necesitas, para ello has de cambiar la MTU. Esto también te puede pasar con túneles Vtun, GRE .... y en cambio navegar perfectamente. Prueba a realizar ping extendidos en el cual pongas el tamaño de paquete mayor a 1400 y menor a 1500, si te devuelve pings la ventana es correcta, si no te devuelve la ventana no es correcta, podrás buscar así el limite de MTU de tú dispositivo. Simplemente configuralo en el interfaz y ya lo has "apañado".

NOTA: he entrado para buscar info y solo me ha llamado la atención lo siguiente: NO HAY NI UNA RESPUESTA VALIDA QUE PUEDA AYUDAR AL QUE HA ABIERTO EL HILO, pero todo el mundo se mete con todo el mundo !!!!! No es más fácil responder lo que se pregunta e ignorar lo demás.

show ip int brief: Muestra el estado de cada interfaz, para tener un resultado optimo, es necesario adjuntar la conf del router, sin ese dato nos perderemos un poco.

ADSL y ADSL2+: En equipos compatibles el comando que debes usar es el siguiente: cisco.com/c/en/us/td/docs/ios/12_4t/12_4…/annexm.html

Por cierto descarta que el problema no sea de la MTU de tú tarjeta de red o del cable de red. También es posible que estés teniendo problemas a nivel Ethernet: para detectarlos, usa el comando show int eth ? o show int feth ? si ves paquetes droped el problema es tu tarjeta de red o la del router, para arreglarlo puede ser tan fácil como sincronizar en modo auto el interfaz o limitarlo desde el router y desde la interfaz del PC.

Si que he tenido problemas similares con routers Cisco e incluso con los blancos de Telefónica, pero el problema suele ser siempre la ETH del router y del PC o el cable. SUERTE

BocaDePez 9 octubre 2013 20:51

⋮

No se si llegare a tiempo pero se porque te pasa, tenia el mismo problema con todos mis routers de cisco.

el problema es realmente el MTU (Maxima unidad de trama) y el hechod e que no navegues en algunas paginas y otras si es porque una razon muy curiosa:

Los servidores web basados en Microchof (huy queria decir Microsoft, jejeje) en su inmenso EGO cambian la trama MTU (si como lo oís!!!!) Los servidores basados en Sun, Linux, etc no modifican la trama.

Esto me llevo un mes de locura y casi perder a clientes... pero te doy la solución:

Hay que poner en el interface ethernet de la LAN (o si esta por VLAN, en la VLAN de la parte de la LAN) el siguiente comando de cisco:

ip tcp adjust-mss 1460

Veras mas documentacion en:

cisco.com/c/en/us/obsolete/ios-nx-os-sof…-12-2-s.html

NOTA: Si ves que aun asi te sigue dando problemas ves bajando el valor de 1460 hacia bajo

✖

BocaDePez 4 diciembre 2013 23:56

⋮

fenómeno compañero... gracias