Los teléfonos en algunos conmutadores no pueden completar el proceso DHCP

Antecedentes

Tengo un servidor DHCP de Windows (Server 2008 R2) distribuyendo direcciones para varios ámbitos. Uno de esos ámbitos es para algunos teléfonos IP Mitel. Los teléfonos están configurados para usar la opción 125 de dhcp para obtener información de configuración. Cuando se inicia un teléfono, no sabe qué vlan usar, por lo que solo obtiene el vlan predeterminado (sin etiquetar) de cualquier puerto al que esté conectado. El servidor dhcp le da una respuesta que incluye información de la opción 125, y el teléfono puede leer qué vlan debería usar de esta respuesta. Luego, el teléfono libera su dirección original y solicita un nuevo contrato de arrendamiento de dhcp con la etiqueta vlan correcta. Los teléfonos también suelen tener computadoras conectadas a un puerto de paso. Los paquetes de las computadoras nunca se etiquetan, por lo que las PC permanecerán en el vlan original (sin etiquetar) para el puerto. Esto ha funcionado para nosotros por años.

Problema y síntomas

En algún lugar en las últimas semanas, algo cambió, y no estoy seguro de qué. Los teléfonos continuarán funcionando mientras no se reinicien, lo que significa que las solicitudes de renovación de dhcp deben procesarse correctamente. Los teléfonos conectados a ciertos interruptores pueden incluso sobrevivir un reinicio. Sin embargo, los teléfonos conectados a otros conmutadores no completarán el proceso cuando se reinicien. Todos nuestros teléfonos utilizan PoE respaldado por un UPS, por lo que ha pasado mucho tiempo desde que se reiniciaron. Esto significa que no tengo idea de cuándo apareció el problema por primera vez. Lo que sí sé es que un teléfono falló cuando se reinició ayer, y al solucionarlo hoy, reiniciamos el armario del interruptor. Ahora ninguno de los teléfonos en ese conmutador funciona (afortunadamente sigue siendo un número pequeño). También sé que las cosas estaban funcionando a fines de enero,

Cuando veo un teléfono arrancar, puedo ver que obtiene con éxito la primera dirección. Luego lee con éxito la información de la opción 125, establece la etiqueta vlan correcta y libera la concesión de IP original. Incluso puede recibir y aceptar una oferta en el vlan correcto del servidor . Sin embargo, ahí es donde se detienen las cosas. El teléfono tiene un mensaje en la pantalla que dice " DHCP: Offer 2 ACC", pero el servidor DHCP de Windows no ha registrado el contrato de arrendamiento y el teléfono nunca se mueve. Solo puedo adivinar que el paquete SOLICITUD DHCP nunca llega al servidor de Windows, por lo que el teléfono está esperando el ACK final de Windows que está bien continuar.

Solución alterna

Finalmente pude hacer que un teléfono volviera a funcionar. Para hacerlo, primero tuve que desconectar la computadora. Luego configuré el puerto del conmutador del teléfono para que no esté etiquetado en el teléfono vlan, sin membresía en el PC vlan. El teléfono ahora se reiniciará correctamente. En este punto, puedo volver a poner la configuración del puerto del conmutador donde debería estar, y mientras nadie intente llamar a ese número mientras restablezco el puerto, el teléfono nunca pierde el ritmo. Entonces puedo volver a conectar la computadora. Obviamente, ese no es un proceso ideal, aunque dado que los teléfonos se reinician tan raramente, podré usarlo para que la gente vuelva a trabajar hasta que pueda encontrar la causa raíz. Las oficinas están cerradas ahora durante la semana, por lo que este problema se permitirá durante el fin de semana (no tengo llaves para oficinas individuales donde están los teléfonos).

Este teléfono que arreglé es el teléfono de servicio en la sala de servidores, conectado directamente a nuestro conmutador central. Es posible que el problema sea un problema con el enrutamiento o el procesamiento de etiquetas en el conmutador central, de modo que la solución alternativa no sea efectiva en las oficinas remotas donde los paquetes pasan primero (etiquetados por) otros conmutadores, pero me sorprenderá mucho si eso sucede, dado que sé que debe estar procesando las renovaciones de dhcp y las conversaciones telefónicas reales correctamente.

Un giro es que dejar el puerto etiquetado en la PC vlan significa que el teléfono falla con el mensaje " DHCP: Offer 1 ACC". Necesito eliminar esa vlan por completo para que esto tenga éxito.

Nota: ahora he confirmado que la solución es efectiva en edificios remotos. Esto me lleva a sospechar que mis dispositivos de alguna manera no están asignados a la vlan correcta. El hecho de que experimenté el problema en mi conmutador central y que ocurrió en varios lugares de la red aproximadamente al mismo tiempo, indica que el conmutador central puede ser el problema. Sin nada específico que ver, estoy programando una ventana de mantenimiento cerca del final de la semana para reiniciar el interruptor. También puedo actualizar el firmware.

Ambiente

Nuestro interruptor central es un HP 5406zl. Este conmutador maneja el enrutamiento entre vlan. El servidor DHCP de Windows está conectado directamente al conmutador. Los conmutadores de punto final están conectados al conmutador central a través de SFP de fibra, y estos puertos están etiquetados para todos los vlans en ambos extremos. El conmutador central configura cada vlan con una ip helper-addressconfiguración que lo señala a nuestro servidor DHCP y una dhcp relay-option 82 replacelínea para que el servidor dhcp sepa qué alcance usar. Estas configuraciones, y las configuraciones de puertos en los conmutadores de punto final, no han cambiado en al menos 16 meses. Hemos tenido otro interruptor y reinicio de teléfono en ese momento.

La mayoría de nuestros interruptores de punto final son HP 2530 series. Estos interruptores parecen funcionar correctamente (los teléfonos en 3 2530 diferentes se han reiniciado correctamente hoy). Son los interruptores más antiguos los que tienen problemas. Tenemos un viejo 3Com 4200 y un 4210 que no funcionarán. El teléfono de servicio conectado directamente al interruptor central mencionado anteriormente tampoco funcionaría.

Pregunta

En este punto, mi mejor suposición es que una actualización de Windows en el servidor dhcp cambió el comportamiento, pero no puedo ver cómo. O posiblemente el conmutador central no esté manejando ese paquete de SOLICITUD correctamente, pero estoy seguro de que nada cambió allí, y no explica por qué solo se efectúan ciertos conmutadores de punto final. ¿Cómo puedo resolver este problema?

Actualizar:

Aquí hay un extracto de registro de dhcp de un teléfono fallido:

10,03 / 06 / 15,12: 40: 40, Asignar, 10.1.2.158`` 08000F197844`` 3189088995,0 ,,, 11,03 / 06 / 15,12: 40: 40, Renovar, 10.1.2.158, , 08000F197844`` 3189088995,0 ,,, 12,03 / 06 / 15,12: 40: 41, Release, 10.1.2.158`` 08000F197844`` 3189088995,0 ,,, 15,03 / 06 / 15,12: 40: 45, NACK, 10.1.2.154`` 08000F197844`` 0,6 ,,, 15,03 / 06 / 15,12: 40: 45, NACK, 10.1.2.154`` 08000F197844`` 0,6 ,,,

Las direcciones 10.xxx son el PC vlan (esa opción es anterior a mí en este lugar). Los teléfonos deberían tener ese tipo de dirección al principio, así que eso es de esperar Sin embargo, después del mensaje de lanzamiento, también espero encontrar una oferta para una dirección en el rango 192.168.16.x, porque puedo ver en el teléfono que se aceptó una oferta (a menos que esté malinterpretando "ACC"). Es interesante que nunca vea que el servidor intente emitir una dirección como esa, a pesar de que el teléfono cree que recibió una.

Consideré la idea de que hay un servidor dhcp falso en la red (entrega una dirección antes del servidor de Windows, pero sin las opciones dhcp que necesita el teléfono para continuar), pero eso no explica por qué los teléfonos funcionan si y solo si Elimino completamente cualquier ruta a la PC vlan. Lo probaré de todos modos por la mañana conectando mi computadora portátil a un puerto configurado para el teléfono vlan, pero si alguien más tiene una mejor explicación mientras tanto, me encantaría escucharla.

Aquí hay una copia de la configuración del interruptor:

http://pastebin.com/veXjCRXu

Solucioné el problema hoy eliminando la etiqueta vlan para el teléfono vlan en el puerto que se conecta a nuestro servidor dhcp. Es muy extraño para mí que funcionó, ya que otros sistemas que usan un esquema similar (también conocido como: SSID de Wifi que utilizan 802.1q) requieren la etiqueta o los clientes no pueden obtener direcciones. Funcionó, por lo que no miraré demasiado, pero me interesaría ver respuestas con teorías de por qué es así.

Debería considerar ejecutar una captura de paquetes a cada lado de los conmutadores problemáticos y luego revisar esto en Wireshark. Esto podrá decirle 1) si el tráfico está siendo interceptado por un servidor DHCP falso (basado en la dirección MAC) y 2) si algo se está destrozando o se cae (por ejemplo, tal vez necesite un relé DHCP). Esto puede requerir la duplicación de puertos, o el 3com puede admitir la captura directamente en el conmutador.

Si encuentra que este problema vuelve a aparecer, es posible que desee verificar el tamaño de su alcance DHCP y cuántos contratos de arrendamiento están en uso. Si los contratos de arrendamiento de DHCP antiguos no se destruyen, su servidor puede pensar que no quedan direcciones en el grupo y no puede asignar nuevas direcciones. Esto es cierto incluso si no hay dispositivos que respondan en la vlan. Si su alcance de DHCP es de 7 días, pueden pasar hasta 7 días antes de que pueda obtener un nuevo contrato de arrendamiento. Del mismo modo, cambiar su configuración resolvería el problema porque habría un nuevo rango de direcciones que podrían distribuirse, o podría eliminar las concesiones dependiendo de los cambios de configuración. Sugeriría establecer la duración del arrendamiento en algo muy bajo, como una hora para ese alcance si este es el caso.