HDLC Bad FCS (8) on Primary D-channel of span X

[Alberto Ribagorda]

Hola a todos,

He buscado respuesta a este problema sin llegar a encontrarlo. A ver si aquí podemos encontrar respuesta al misterio. Tengo 2 servidores, cada uno con 2 TE420P. Ambos servidores son exactamente iguales (hardware y software). Aleatoriamente, en el archivo messages de Asterisk de ambos servidores me aparece el error "HDLC Bad FCS (8) on Primary D-channel of span X" donde X es un span de los 8 que hay en cada servidor. Dicho error aparece de 6 a 8 veces por día. 

De todos los primarios activos que hay en este momento (4 por servidor), el error se presenta en 7 de ellos, que son del mismo operador. El otro primario activo que no presenta error nunca pertenece a un operador diferente.

¿Sabéis por donde pueden ir los problemas?.

Muchas gracias.

Saludos,

Alberto

[Fernando Villares]

me solia pasar en maquinas antiguas eso cuando el reloj perdia sincronia cada tanto tiempo...estas usando que distro de linux? usas el irq balance para q balancee entre los cores de tu maquina?

--
Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)
Normas de la lista Asterisk-ES: http://comunidad.asterisk-es.org/index.php?title=Lista:normas-asterisk-es
---
Has recibido este mensaje porque estás suscrito al grupo "asterisk-es" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a asterisk-es...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a aster...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/asterisk-es?hl=es.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

[Alberto Ribagorda]

Son HP DL380 con Ubuntu 10.04, asi que antiguas no. Lo que me tiene mosqueado es que el primario que es del otro operador no presente errores nunca.

Con respecto al irqbalance, no lo estamos usando. Hasta ahora, y tenemos muchos servidores con tarjetas de primarios en clientes, no lo hemos considerado necesario, es la primera vez que nos aparece este error.

[Fernando Villares]

y las versiones de dahdi y kernels te fijaste que no este publicado algun bug sobre la sincro ...porque te esta dropeando paquetes de control del canal D ...cuando eso pasa normalmente en ese momento te corta las comunicaciones por 1 momento o te da artefactos de sonido....o en el peor de los casos se resetean los canales B...era muy molesto y era siempre error de drivers o de config en mis casos

[Elio Rojano]

El 4 de marzo de 2013 10:04, Alberto Ribagorda <ariba...@gmail.com> escribió:

Hola a todos,

He buscado respuesta a este problema sin llegar a encontrarlo.

Creo que poco has buscado, ya que ese mensaje es uno de los errores más antiguos y comunes que existen en el mundo hardware de Asterisk.

El motivo es sencillo: el "crc" de la trama del primario no es correcto, esto es: tu señal del primario llega al Asterisk modificada de cuando salió del proveedor. ¿porqué? Ahí es donde viene los motivos típicos:

- Que la tarjeta pierda interrupciones, por lo que no procesa todos los bits de las tramas E1 y pierde información.

- Que haya algún problema físico con el cableado que va del PTR a la tarjeta (vamos a suponer que desde la central al PTR está probado por el operador y la señal es correcta).

¿Qué provoca este error?

- Microcortes de audio en TODOS los canales de ese primario.

- Pérdida del sincronismo y caídas aleatorias del primario cuando la pérdida afecta a ciertas tramas especiales (trama 0)

¿Cómo se soluciona?

- Configurando bien las IRQs de las tarjetas en la BIOS.

- Si son PCIe, revisar que la IRQ no comparte con dispositivos importantes (VGA, Network, etc.)

- Comprobando que las interrupciones están balanceadas correctamente entre los nucleos de los procesadores.

  cat /proc/interrupts

  apt-get install irqbalance

- ...

 

--

Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)
Normas de la lista Asterisk-ES: http://comunidad.asterisk-es.org/index.php?title=Lista:normas-asterisk-es
---
Has recibido este mensaje porque estás suscrito al grupo "asterisk-es" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a asterisk-es...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a aster...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/asterisk-es?hl=es.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

--
Página web: http://www.sinologic.net/

Twitter: http://twitter.com/hellc2

LinkedIn: http://es.linkedin.com/in/rojano

[Alberto Ribagorda]

Mas que no buscar, creo que lo que pasa es que no he sabido buscar ;)

Son PCIe. En los servidores, además de las 2 tarjetas de primario, tenemos una tarjeta TCE400P de transcoding

No están compartiendo interrupciones, os añado la salida del comando:

cat /proc/interrupts

           CPU0       CPU1       CPU2       CPU3

  0:         71          0          0          0   IO-APIC-edge      timer

  1:          0          0          0          8   IO-APIC-edge      i8042

  2:          0          0          0          0    XT-PIC-XT        cascade

  8:          0          0          0          0   IO-APIC-edge      rtc0

 12:          0          0          0        131   IO-APIC-edge      i8042

 17:          0        429          0          0   IO-APIC-fasteoi   uhci_hcd:usb6, hpilo

 20:          0          0          0          0   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2

 22:          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:usb4

 23:          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:usb3, uhci_hcd:usb5

 24:          0          0 2024898829          0   IO-APIC-fasteoi   tce4000

 30:          0 2967169834          0          0   IO-APIC-fasteoi   wct4xxp

 31:          0 2967280879          0          0   IO-APIC-fasteoi   wct4xxp

 63:          0   17697052          0          0   PCI-MSI-edge      cciss0

 65:          0          0 1873014095          0   PCI-MSI-edge      eth0-0

 66:          0          0 2327569909          0   PCI-MSI-edge      eth0-1

 67:          0          0          0 1930897663   PCI-MSI-edge      eth0-2

 68:          0          0          0 1641190782   PCI-MSI-edge      eth0-3

 69: 2003121799          0          0          0   PCI-MSI-edge      eth0-4

 74:          0          0          1          0   PCI-MSI-edge      eth1-0

 75:          0          0          0          0   PCI-MSI-edge      eth1-1

 76:          0          0          0          0   PCI-MSI-edge      eth1-2

 77:          0          0          0          0   PCI-MSI-edge      eth1-3

 78:          0          0          0          0   PCI-MSI-edge      eth1-4

 83:          1          0          0          0   PCI-MSI-edge      eth2-0

 84:          0          0          0          0   PCI-MSI-edge      eth2-1

 85:          0          0          0          0   PCI-MSI-edge      eth2-2

 86:          0          0          0          0   PCI-MSI-edge      eth2-3

 87:          0          0          0          0   PCI-MSI-edge      eth2-4

 92:       1211          0          0          0   PCI-MSI-edge      eth3-0

 93:          0       1733          0          0   PCI-MSI-edge      eth3-1

 94:          0     227424          0          0   PCI-MSI-edge      eth3-2

 95:          0          0     390136          0   PCI-MSI-edge      eth3-3

 96:          0          0     237190          0   PCI-MSI-edge      eth3-4

NMI:          0          0          0          0   Non-maskable interrupts

LOC: 2889267283 2889267241 2889267214 2889267187   Local timer interrupts

SPU:          0          0          0          0   Spurious interrupts

PMI:          0          0          0          0   Performance monitoring interrupts

PND:          0          0          0          0   Performance pending work

RES:    3516961    1328858    1510373    1238076   Rescheduling interrupts

CAL:      67361      58550      57073      62137   Function call interrupts

TLB:   37259366   34627869   50003456   52559478   TLB shootdowns

TRM:          0          0          0          0   Thermal event interrupts

THR:          0          0          0          0   Threshold APIC interrupts

MCE:          0          0          0          0   Machine check exceptions

MCP:      38525      38525      38525      38525   Machine check polls

ERR:          3

MIS:          0

Echaré un vistazo al irqbalance.

[Elio Rojano]

Por lo que veo, muchos interfaces de red que consumen interrupciones para tan pocos núcleos.

Comprueba las irq hardware con lspci -vb

[Pablo Umanzor]

hiciste un loop en la puerta de los primarios donde te aparece el error?


http://kb.digium.com/articles/Configuration/How-do-I-run-a-pattern-loopback-test-on-a-Digium-E1-T1-card

mejor aun, cambiaste el primario del otro proveedor donde todo va bien
y lo pusiste en un puerto donde te aparecen los mensajes


El día 4 de marzo de 2013 06:04, Alberto Ribagorda
<ariba...@gmail.com> escribió:

[Alberto Ribagorda]

Son servidores con servicio 24x7 que además están, evidentemente, en el cliente, asi que cualquier operación debe hacerse con mucho tacto. 

Para la pregunta que hacía Elio, comparten irq hardware (la 10) con la placa RAID y con una de las controladoras ethernet, aunque tenía entendido que en PCIe eso no era importante.

Con respecto irbalance, ¿como es de fiable?. Porque he leído que en algunos casos estropeaba más que arreglaba.

En nuestro caso, no hay PTR como tal. El operador entrega los primarios en un armario repartidor, ya que hay otros 40 primarios aprox.

[Fernando Villares]

moraleja siempre usar gateways externos....xD

[Elio Rojano]

El uso de gateways externos no tiene porqué solucionar el problema, tan solo complicaría más su detección.

¿en qué ayuda el uso de un gateway si el fallo está en el cableado que se utiliza para llevar la señal del primario?

¿y si el problema viene del lado del operador?

[Fernando Villares]

no coincido para nada, justamente muchas capacidades de debugging de un mediant o un tenor dx son muuucho mas poderosas IMHO q las de una placa para el user medio, no requieren que apagues la central ip o recargues modulos para cambiar una minima config o maniobrar sobre los canales, y lo mas importante, están normalmente homologadas por las empresas de telecomunicaciones lo que te ahora unas cuantas molestias cuando te peleas con ellos por problemas que sabes q son de ellos....

Just my 2 cents...

[Alberto Ribagorda]

En eso no coincido contigo Fernando, estoy más con Elio. Un gateway externo está bien para conectar Básicos, pero cuando necesitas conectar 8 primarios, te sale más caro el collar que el perro :D.

[Fernando Villares]

eh???? pero si no estabamos hablando de precios.....estabamos hablando y debatiendo con elio sobre en que ayudaria a encontrar la solucion o no ....ademas como solucion media hibrida tienes los redfones con lo mejor de las tarjetas pero afuera del server....y salen igual q una digium....y son iguales para el dbugging q una tarjeta...

si hablamos de precios ademas no los estas calculando bien porque no tienes en cuenta el csto indirecto de las bajadas programadas de servicios en un sistema tan critico en produccion como el que comentas...si le pones 1000 dolares por cada bajadita programada de 5 minutos con 5 bajadas de testing ya compraste el gateway!!! 

[Alberto Ribagorda]

Con primarios no tengo experiencia con Gateways (si tenemos algún Vegastream con RDSI), siempre montamos servidores + tarjetas, y jamás nos han dado problemas ( y hemos montado unos cuantos). La verdad es que este problema nos está trayendo de cabeza.

Lo que también nos ocurre es que en 2 de esos primarios (los 2 más usados) los 60 canales se acaban bloqueando. Cuando nos ocurre eso, en Asterisk no se ve nada, de echo el primario está levantado y no hay ningún canal activo, pero cuando el operador nos comenta que ve todos los canales bloqueados. La situación no se soluciona hasta que no reiniciamos la tarjeta.

Ya os digo que nos trae de cabeza, porque jamás nos hemos encontrado con ese problema en ninguna de nuestras instalaciones.

[Ronin ARG]

Tambien prefiero gateway externos, atas, todo lo que se interconecte por SIP.
Si tengo que montar 8 e1 sin dudas voy a elegir gw externos, ya que montar todo con placas tiene una mayor probabilidad de riesgo de fallos a nivel SO o software.
Si tenes un gateway externo lo comunicas por SIP y que el equipo haga su trabajo y el asterisk el suyo.
Perdon por el offtopic quisiera consultarles que experiencia han tenido con gateways sangoma?
Muchas gracias
Saludos.

[Fernando Villares]

todavia con vegastream nada...tendre que testearlos cuando me pidan algun proyecto 1ero...

[Ronin ARG]

estoy presentando un proyecto con ese equipo, si sale, paso el feedback

[Odicha]

Monta un servidor al lado del principal con una placa de primario y lo conectas al principal vía SIP o IAX. Así descartas la placa de primarios en concreto y cualquier tema relacionado con esa máquina. Lo de inactividad por tu lado y todos los canales bloqueados por el lado del operador suena a problema con el operador de los primarios, pero si no acotas y se lo das masticado te van a volver loco diciendo que el problema está de tu lado.

[Sir Brain Colward]

Coincido contigo. La capacidad de debug que da un gateway es mucho mayor, y el poder aislar la conexión PRI de la centralita para poder cambiar el servicio en caso necesario y sin tener que cortar el servicio o afectar al cliente no tiene precio. Trabajo con bastantes clientes que hacen y reciben llamadas 24x7 y cualquier corte es todo un dolor de cabeza de planificación. Si pones dos gateway paralelos y  puedes trabajar con uno mientras dejas el otro activo, es algo que a medio, largo plazo se agredece y se hace necesario.

A veces, invertir algo más de dinero nos evitará perder mucho más dinero después.

2013/3/7 Fernando Villares <fvil...@gmail.com>