Vlan Trunking - Cisco Vs Mikrotik

En el mundo de las redes no siempre se tiene la posibilidad de trabajar con hardware de un mismo vendedor, ya sea por disponibilidad del mismo o que sencillamente por relación costo/beneficio nos conviene crear ambientes donde interactuen dispositivos de distintas marcas.

Cuando esto sucede, es el deber del Ingeniero encargado del despliegue de la red, garantizar que los dispositivos inter-operen entre si correctamente. Esto no suele ser algo sencillo, especialmente porque muchas marcas tienden a agregar "extras" a los protocolos y estándares actualmente definidos, normalmente estos extras son propietarios y es entonces cuando comienzan los problemas.

Situación 

Se desea crear un enlace layer 2 entre un router y un switch por donde puedan circular tramas 802.1Q, es decir, en terminología Cisco, un "Trunk Port". Por otro lado, se tienen 3 enlaces a otro switch desde el mismo router, pero que no utilizan el protocolo 802.1Q (puertos en modo access).

 Equipos que intervienen:

Router: Mikrotik CCR1036-12G-4S corriendo RouterOS v6.20
Switch: Cisco 2960S-48LPS-L

Topologia:

Como se puede apreciar, tenemos un enlace troncal (las dos lineas representan dos interfaces unidas por medio de LACP) entre el router y un switch, del otro lado (a la izquierda), apreciamos que tenemos 3 enlaces entre el router y el switch, estos enlaces no son troncales (no se realiza marcaje de VLANs), sino que están en modo acceso.

En teoría esto es tan sencillo como configurar el switch de la izquierda con los 3 puertos en sus VLANs respectivas, el switch de la derecha con el puerto (port channel) en modo trunk y permitir el paso de las VLANs 100, 110 y 120. Del lado de Mikrotik basta con crear un bridge por cada VLAN, agregarle una dirección IP y agregar a este bridge todos los puertos que intervienen. La Configuración a continuación:

Configuración Switch de la derecha:

 interface GigabitEthernet1/0/51  
  switchport mode trunk  
  channel-protocol lacp  
  channel-group 1 mode active  
 !  
 interface GigabitEthernet1/0/52  
  switchport mode trunk  
  channel-protocol lacp  
  channel-group 1 mode active  
 !  

Configuracion Router:

 /interface bridge  
 add l2mtu=1590 name=BR-VLAN-100 priority=0x6000  
 add l2mtu=1590 name=BR-VLAN-110 priority=0x6000  
 add l2mtu=1590 name=BR-VLAN-120 priority=0x6000  
 /interface bridge port  
 add bridge=BR-VLAN-120 interface=VLAN-120  
 add bridge=BR-VLAN-100 interface=VLAN-100  
 add bridge=BR-VLAN-120 interface=ether3  
 add bridge=BR-VLAN-100 interface=ether1  
 add bridge=BR-VLAN-110 interface=ether2  
 add bridge=BR-VLAN-110 interface=VLAN-110  
 /interface bonding  
 add mode=802.3ad name=Ofc-Con slaves=sfp1,sfp2  
 /interface vlan  
 add interface=Ofc-Con name=VLAN-100 vlan-id=100  
 add interface=Ofc-Con name=VLAN-110 vlan-id=110  
 add interface=Ofc-Con name=VLAN-120 vlan-id=120  
 /ip address  
 add address=10.10.10.129/26 comment="INTERFAZ DE ACCESO USUARIOS-PC" interface=BR-VLAN-110 network=10.10.10.128  
 add address=10.10.10.193/26 comment="INTERFAZ DE ACCESO USUARIOS-WIFI" interface=BR-VLAN-120 network=10.10.10.192  
 add address=10.10.10.1/25 comment="INTERFAZ DE ACCESO A SERVIDORES, IMPRESORAS, ADMINISTRACION Y TELEFONOS" interface=BR-VLAN-100 network=10.10.10.0  

La configuración del switch de la izquierda la omito porque es muy obvia (configurar cada interfaz con switchport mode access, switchport access vlan XXX).

En teoría, esto debería de funcionar correctamente, pero no es así. Si colocaramos una PC en la VLAN 100 por medio del switch de la derecha y luego otra PC en la misma VLAN pero en el switch de la izquierda e hiciéramos un ping entre ellas, notaríamos que no tenemos conectividad.

Si revisamos los logs de ambos switches, observaríamos que todos los puertos que conectan al router estan bloqueados por "SPANNING-TREE INCONSISTENCIES".

¿Cual es la razón de esto?

Cisco, añade una extensión propietaria al protocolo spanning-tree que permite tener una instancia del mismo por cada VLAN, esto lo denominaron Per VLAN Spanning-tree (PVSTP) incluso el protocolo Rapid Spanning Tree funciona con este añadido (PVSTP+). Esto no es algo que se pueda desactivar, es decir no se puede tener el "spanning tree solo".

Mikrotik trabaja con STP y STP+ pero las versiones estandarizadas en los RFC. En conexiones a switches Cisco en modo access no hay problema con esto dado que existe una sola instancia de STP, sin embargo cuando se conecta un router MK y un switch Cisco en modo trunk el STP no funciona correctamente.

En este caso cuando el router recibe una BPDU PVST, no sabe que hacer con ella y sencillamente hace un flooding de la misma a todos los puertos que conforman el bridge que configuramos (en lugar de procesarla), el switch del lado izquierdo recibe esta BPDU y al ser un aparato Cisco detecta que la BPDU es para un puerto en modo Trunk no en modo access (como es el caso actual). Por esta razon decide bloquear el puerto arrojando el error antes mencionado. Lo mismo pasa en el sentido opuesto, el switch del lado derecho recibe una BPDU "tradicional" y decide entonces bloquear el puerto con el mismo error.

Solución 

Lo mas evidente seria desactivar STP (algo que de verdad nunca es recomendable), si bien Cisco no permite desactivar la extension "per vlan", y tampoco se puede realmente deshabilitar STP por cada puerto (desactivar el STP implica desactivarlo globalmente). Se puede utilizar un comando que filtra las BDPU de un puerto, es decir, evita que sean enviadas por ese puerto y evita que las recibidas en este sean procesadas.

El comando se debe aplicar directamente a la interfaz y es:

spanning-tree bpdufilter enable

Con esto logramos que todo funcione correctamente. 

Cisco 7940G y Asterisk - Parte 3

Ahora hablaremos de como asignar un logo al teléfono y luego la aplicación de directorio.

Asignación del logo

Esto es relativamente sencillo, primero, necesitan un logo que cumpla con las siguientes características:

1.- Formato BMP
2.- En escala de grises, indexado.
3.- Tamaño máximo 90x56 px.

El teléfono accede a este archivo por medio de HTTP, así que deben tener también un servidor HTTP, guardar el logo en este y colocar el URL de acceso del mismo de la siguiente forma, ya sea en el archivo SIPDefault.cnf o en el archivo de cada teléfono SIP.cnf:

logo_url: "URL del logo"

Por ejemplo, si el logo se encuentra en 192.168.0.1/asterisk/logo.bmp, deben colocar:

logo_url: "http://192.168.0.1/asterisk/logo.bmp"

Si por ejemplo poseen servidores de nombre (DNS) y 192.168.0.1 tiene asignado el registro "httpserver.dominiolocal.com" colocan:

logo_url: "http://httpserver.dominiolocal.com/asterisk/logo.bmp"

Es decir, colocal el FQDN en lugar de la IP, cabe acotar que el telefono solo descarga el logo cuando arranca, por ende si realizan algún cambio al mismo, para que se vea reflejado deberán reiniciar el teléfono (que si no lo había dicho antes, se puede realizar presionando las teclas settings + asterisco + 6).

Aplicación de directorio

Algo que me agrado mucho, es que los teléfonos 7940G permiten correr microaplicaciones escritas en xml, en este archivo PDF tienen una concisa guía de como escribir estas aplicaciones, en mi caso la aplicación de directorio funciona así:

1.- La aplicación XML en el teléfono se encarga de la presentación al usuario de un menú para poder realizar las búsquedas y luego mostrar los resultados obtenidos. La aplicación es accesible presionando la tecla "directory" en el teléfono y seleccionando "external directory".
2.- Si el usuario desea buscar algún contacto interno (extensión), selecciona la opción "directorio interno local. Se ejecuta un script PHP.
3.- Cuando el usuario desea buscar algún contacto externo, selecciona la opcion "buscar contacto", introduce los datos de este, la aplicación XML se encarga de pasar estos datos como una variable a un script PHP.
4.- Ambos scripts interactuan con una base de datos en MYSQL, los cuales generan una salida en formato XML que el teléfono interpreta para luego mostrar al usuario.

Para que el teléfono haga uso de esta aplicación deben incluir ya sea en el archivo SIPDefault.cnf o en el archivo individual de cada teléfono SIP.cnf, la siguiente linea:

directory_url: "URL del archivo xml principal"

Mismas reglas que con el logo, el teléfono accede al archivo XML es mediante HTTP.

Abajo encontraran los códigos fuentes de los archivos XML y PHP, esta aplicación es muy sencilla y la escribí leyendo la guía en PDF que deje mas arriba y unas cuantas guías de W3Schools

menu1.xml es el archivo al que accede el teléfono y se referencia en la linea "directory_url", este genera un menú con dos opciones, según la opción que se presione se llama un archivo XML (buscar_contacto.xml) que le indica al teléfono que debe recibir un parámetro por parte del usuario (introducido utilizando el teclado) y luego enviarlo a un script php (busqueda.php) que a su vez genera una salida XML para que el teléfono la interprete, o se ejecuta un script PHP (interno.php) que genera a su vez una salida en formato XML, que el teléfono interpreta y luego muestra al usuario. El diagrama de flujo a continuación debería de dejar todo mas claro:

menu1.xml

 <CiscoIPPhoneMenu>  
  <Prompt>Directorio Telefonico</Prompt>  
  <MenuItem>  
   <Name>Buscar un contacto</Name>  
   <URL>URL buscar_contacto.xml</URL>  
  </MenuItem>  
  <MenuItem>  
   <Name>Directorio Interno Local</Name>  
   <URL>URL interno.php</URL>  
  </MenuItem>  
 </CiscoIPPhoneMenu>  

buscar_contacto.xml

 <CiscoIPPhoneInput>  
  <Title>Directorio telefonico</Title>  
  <Prompt>Criterio de busqueda</Prompt>  
  <URL>URL busqueda.php</URL>  
  <InputItem>  
   <DisplayName>Nombre</DisplayName>  
   <QueryStringParam>nombre</QueryStringParam>  
   <InputFlags>U</InputFlags>  
  </InputItem>  
 </CiscoIPPhoneInput>  

interno.php

 <?php  
 header('Content-Type: text/xml');  
 #DATOS DE CONEXION A LA BASE DE DATOS  
 $mysql_conn = mysqli_connect("IP O FQDN","USUARIO","CONTRASEÑA","BASE DATOS");  
 #VALORES A BUSCAR  
 $resultado = mysqli_query($mysql_conn,"SELECT * FROM contactos WHERE tag = 'ext'ORDER BY nombres");  
     print ("<CiscoIPPhoneDirectory>\n");  
     print ("<Title>");  
     print ("Directorio Telefonico");  
     print ("</Title>\n");  
     print ("<Prompt>");  
     print ("Coincidencias");  
     print ("</Prompt>\n");  
     while($row = mysqli_fetch_array($resultado))  
     {  
         print ("<DirectoryEntry>\n");  
             print ("<Name>");  
             print ($row['nombres']);  
             print ("</Name>\n");  
             print ("<Telephone>");  
             print ($row['numero']);  
             print ("</Telephone>\n");  
         print ("</DirectoryEntry>\n");  
     }  
     print ("</CiscoIPPhoneDirectory>\n");  
 ?>  

busqueda.php

 <?php  
 header('Content-Type: text/xml');  
 #DATOS DE CONEXION A LA BASE DE DATOS  
 $mysql_conn = mysqli_connect("IP O FQDN","USUARIO","CONTRASEÑA","BASE DATOS");  
 #VALORES A BUSCAR  
 $NOM = $_GET["nombre"];  
 $resultado = mysqli_query($mysql_conn,"SELECT * FROM contactos WHERE ((nombres LIKE '%$NOM%') AND (tag !='ext')) ORDER BY nombres");  
 $total_resultado = mysqli_num_rows($resultado);  
 if($total_resultado == 0)  
 {  
     print ("\n");  
     print ("<CiscoIPPhoneText>\n");  
         print ("<Title>");  
         print ("Directorio Telefonico");  
         print ("</Title>\n");  
         print ("<Prompt>");  
         print ("No hay coincidencias");  
         print ("</Prompt>\n");  
     print ("</CiscoIPPhoneText>");  
     print ("\n");  
 }  
 else  
 {  
     print ("<CiscoIPPhoneDirectory>\n");  
     print ("<Title>");  
     print ("Directorio Telefonico");  
     print ("</Title>\n");  
     print ("<Prompt>");  
     print ("Coincidencias");  
     print ("</Prompt>\n");  
     while($row = mysqli_fetch_array($resultado))  
     {  
         print ("<DirectoryEntry>\n");  
             print ("<Name>");  
             print ($row['nombres']);  
             print ("</Name>\n");  
             print ("<Telephone>");  
             print ($row['numero']);  
             print ("</Telephone>\n");  
         print ("</DirectoryEntry>\n");  
     }  
     print ("</CiscoIPPhoneDirectory>\n");  
 }  
 ?>  

La base de datos en MySQL, contiene una sola tabla, que llamo directorio, esta tabla contiene 3 columnas: nombres (varchar 35), numero (varchar 15 y PK) y tag (varchar 3). Las dos primeras se explican solas, la ultima sin embargo la coloque para que sea fácil diferenciar de un contacto con varios números (ejemplo, extension local, celular, casa, etc.) Si se fijan en los scripts PHP notaran que en los queries utilizo este campo para distinguir que números mostrar.

Cisco 7940G y Asterisk - Parte 2

Continuando con la entrada anterior, en esta ocasión les mostrare como autoconfigurar los teléfonos IP utilizando ficheros cnf y el servidor tftp.

Los teléfonos 7940G, al arrancar luego de descargar las imágenes de software a utilizar (en caso de no tenerlas aun), también descargan una serie de archivos .cnf, estos archivos según su nombre y estructura le indican al teléfono como configurarse, que extensión utilizar, nombre a mostrar en pantalla, aplicaciones (escritas en XML) que el teléfono puede utilizar, etc. 

SIPDefault.cnf

Es el primero de estos archivos, este archivo es común para todos los teléfonos IP, se utiliza para configurar las opciones comunes de todos los teléfonos (ejemplo, hora, fecha, planes de discado, etc.). 

ejemplo de contenido:

 logo_url: "URL del logo a mostrar en la pantalla"  
 directory_url: "URL de la aplicacion de directorio"  
 dial_template: "archivo del plan de discado"  
 date_format: "D/M/Y"  
 sntp_server: "FQDN o IP de servidor sntp"  
 sntp_mode: "unicast"  
 time_format_24hr: "0"  
 time_zone: "EST"  
 dst_offset: "-00:30"  
 dst_start_month: "August"  

Los dos primeros items se utilizan para asignar el logo y aplicación de directorio al teléfono, luego hablare de esto, solo entiendan por ahora que el teléfono descarga via HTTP tanto el logo (en formato bmp) como la aplicación y esta ultima debe estar escrita en XML.

el dial_template indica el nombre del archivo que contiene el plan de discado por el cual se regirá el teléfono, mas abajo encontraran un ejemplo de este plan de discado, todas las demás opciones están puestas de esa forma para colocar el teléfono en la hora estándar de Venezuela que es UTC -4:30, de aquí lo único que deben de cambiar es el FQDN o IP del servidor SNTP (por Internet hay muchas, y si utilizan algún router con esta capacidad pueden utilizarlo a el también como servidor de hora).

Plan de discado 

El nombre de este archivo es indiferente (debe contener la extension xml al final), solo deben tener en cuenta que deben referenciarlo en el parámetro dial_template y lógicamente debe estar en el mismo directorio que todos los archivos de configuración (que al final debe ser el directorio al que se tiene acceso por tftp), al igual que en Asterisk donde existe un plan de discado que indica que hacer según el numero marcado, estos telefonos también pueden tener uno, este plan de discado permite manipular los dígitos marcados, asignarle tonos, invalidar ciertos números, etc...

 <DIALTEMPLATE>  
 <TEMPLATE MATCH="..."      TIMEOUT="2"/>  
     <TEMPLATE MATCH="9*"      TIMEOUT="2"/>  
     <TEMPLATE MATCH="\**"      TIMEOUT="2"/>  
     <TEMPLATE MATCH="04........."  REWRITE="904%1" TIMEOUT="0"/>  
     <TEMPLATE MATCH="02........."  REWRITE="902%1" TIMEOUT="0"/>  
     <TEMPLATE MATCH="2......"    REWRITE="2%1" TIMEOUT="0"/>  
 </DIALTEMPLATE>  

Este plan de discado se basa en el hecho de que en la empresa para realizar llamadas externas se marca primero 9, adicionalmente hay unas reglas de reescritura que utilizo para la integración con el directorio, si quieren pueden utilizar este mismo, provisto que donde vayan a implementar el telefono las extensiones internas tengan 3 dígitos y las llamadas externas comiencen siempre con un 9.

Archivos de configuración por teléfono 

Estos archivos permiten configurar individualmente cada teléfono, asignar una extensión, nombre de usuario, etc. Estos archivos tienen el formato SIP.cnf donde es la dirección mac en mayúsculas y sin separadores (ejemplo, sin ":", "." o "-") del teléfono que se debe configurar, por ejemplo asumiendo que la dirección mac del teléfono es  ca:da:11:22:33:44 el archivo de llamaria SIPCADA11223344.cnf

 proxy1_address: "FQDN o IP del proxy (Asterisk)"  
 line1_name: "nombre de la extensión"  
 line1_shortname: "Nombre a mostrar en la pantalla del teléfono"  
 line1_displayname: "Caller ID"  
 line1_authname: "usuario para autenticar"  
 line1_password: "contraseña"  
 nat_enable: "0"  
 proxy_register: "1"  

Todos los items se explican por si mismo, excepto quiza line1_authname, aqui deben colocar el nombre con el que registraron la extensión para autenticarla, es lo que se encuentra entre corchetes [] cuando definen la extensión en el SIP.conf. Adicionalmente, nat_enable en 0 indica que los teléfonos no trabajaran utilizando NAT (chequeen esto si quieren saber mas), y proxy_register en 1 indica que el teléfono debe registrarse con el proxy utilizando los parámetros antes descritos para poder realizar o recibir llamadas.

Si quieren conocer mas sobre los parametros de configuracion de los telefonos 7940G con SIP, chequeen el siguiente enlace:

Guía de administración SIP Cisco

Parte 3 de la guia

Cisco 7940G y Asterisk - Parte 1

Recientemente me toco reformar el sistema telefónico de la compañía para la que trabajo, en una de las sedes se tiene implementado un "todo-en-uno" de Cisco (UC-520), este aparato incluye central telefónica, router, switch y gateway vpn,

Si bien en esa sede todo funciona correctamente con el UC-520, para la nueva sede se requería de una infraestructura mas expandible y que pudiese albergar mas usuarios de los que el UC-520 permite, adicionalmente aquí había una limitante a nivel monetaria, adquirir alguna solución telefónica de Cisco implicaba un desembolso considerable de dinero, así que me fui por la opción libre, Asterisk,

Asterisk trabaja principalmente con el protocolo SIP, así que a parte del servidor donde se instalaría y las tarjetas de interconexion PSTN (para poder ofrecer conectividad a redes telefónicas  externas), se necesita también de teléfonos IP compatibles con este estándar. Resulta que cuando la empresa adquirió el UC-520, también compro una gran cantidad de teléfonos IP Cisco 7940G, muchos mas de los que eran utilizados para ese entonces.

Para los que no lo sepan, estos teléfonos de fabrica trabajan es con un protocolo propietario de Cisco llamado SCCP, así que no me servían para trabajar con Asterisk, sin embargo investigando un poco encontré que Cisco hace unos cuantos años libero imagenes del software del teléfono compatibles con el estándar SIP, esta entrada es principalmente para indicarles como transformar los 7940G con la imagen SCCP a teléfonos compatibles con SIP, en proximas entradas les mostrare como configurarlos y adicionalmente integrarlos en un directorio telefónico interno centralizado.

Proceso de cambio de firmware

Vamos a necesitar:

1.- Obviamente el teléfono Cisco 7940G
2.- El servicio DHCP y TFTP
3.- El pack de imágenes de software SIP, van a necesitar los archivos (pueden descargarlos desde aqui):

      P003-8-12-00.bin
      P003-8-12-00.sbn
      P0S3-8-12-00.loads
      P0S3-8-12-00.sb2
      OS79XX.TXT
      cmterm-7940-7960-8.2.00-sip.cop

4.- Un archivo que llamaran "XMLDefault.cnf.xml" (notese que tiene 2 extensiones) y donde copian y pegan lo siguiente:

 <Default>  
 <callManagerGroup>  
 <members>  
 <member priority="0">  
 <callManager>  
 <ports>  
 <ethernetPhonePort>2000</ethernetPhonePort>  
 <mgcpPorts>  
 <listen>2427</listen>  
 <keepAlive>2428</keepAlive>  
 </mgcpPorts>  
 </ports>  
 <processNodeName></processNodeName>  
 </callManager>  
 </member>  
 </members>  
 </callManagerGroup>  
 <loadInformation8 model="IP Phone 7940">P0S3-8-12-00</loadInformation8>  
 <loadInformation7 model="IP Phone 7960">P003-07-1-00</loadInformation7>  
 <authenticationURL></authenticationURL>  
 <directoryURL></directoryURL>  
 <idleURL></idleURL>  
 <informationURL></informationURL>  
 <messagesURL></messagesURL>  
 <servicesURL></servicesURL>  
 </Default>  

Configuración servicio TFTP

En mi caso, el servicio TFTP radica en un servidor Linux corriendo CentOS, si tienen esta distribución instalada para poder activar el servicio TFTP básicamente editamos el archivo tftp, ubicado en /etc/xinetd.d/ para que nos quede así:

 service tftp  
 {  
     disable = no  
     socket_type       = dgram  
     protocol        = udp  
     wait          = yes  
     user          = user  
     server         = /usr/sbin/in.tftpd  
     server_args       = -c -s /tftp-directory  
     per_source       = 11  
     cps           = 100 2  
     flags          = IPv4  
 }  

Donde "/tftp-directory" es la ruta del directorio que piensan utilizar para almacenar los archivos que serán descargados por el teléfono mediante tftp (guarden aqui los archivos que les especifique arriba) y "user" el usuario como quieren que se ejecute el servicio. Luego de esto sencillamente escribimos en la consola "service xinetd restart".

Configuración servicio DHCP

El servicio DHCP corre actualmente en un servidor con Windows Server 2012r2, así que también aproveche este para poder realizar este trabajo, deben es asegurarse de crear un scope (ambito) para los teléfonos IP (con un rango de IP validos, gateway, dns, etc) y dentro de este scope se necesita agregar adicionalmente la opción 150, la cual por defecto no se incluye en el servicio DHCP asi que se debe crear, para crear esta opción realizamos lo siguiente:

1.- Nos vamos al administrador del servicio y presionamos sobre "IPv4" con el botón derecho del mouse,
2.- En el menu desplegable presionamos sobre "Configurar Opciones Predeterminadas..."
3.- En el cuadro que nos aparece presionamos "Agregar".
4.- Nos aparece otro cuadro donde debemos llenar los parámetros de la opción, aquí lo importante es que el tipo de dato sea "Dirección IP" y el código "150".

Asegúrense de que cuando configuren la opción en el ambito, apunte directamente al servidor donde funciona el servicio TFTP (en mi caso en el server que corre CentOS). 

Nota:

Estos pasos son como yo termine realizado el trabajo, sin embargo si no quieren hacerlo tal cual,, lo único que necesitan es tener el servicio TFTP y DHCP funcionando, el servicio TFTP debe tener acceso a los archivos que arriba describo y el servicio DHCP debe estar configurado para adicional a los parámetros básicos (ip, mascara, gateway, etc.) incluya la opcion 150 que apunte al servidor donde corre el servicio TFTP, hay una aplicacion para windows que incluye ambos servicios se llama TFTPD32. En mi caso lo realice de esta forma porque asi puedo sencillamente conectar un telefono a la red y ya se que todo esta preparado para que se actualice a SIP y descargue la configuracion de la linea a utilizar (mas adelante hablo sobre esto). 

Lógicamente deben asegurarse que el teléfono descargue su configuración del server DHCP, ya sea colocando el teléfono dentro del mismo segmento L2 que el servidor o utilizando un DHCP Relay. Recuerden que estos telefonos al ser Cisco, se pueden comunicar con equipos Cisco mediante CDP y obviamente son compatibles con la asignación de VLAN de voz mediante el comando "switchport voice vlan XXX".

Si han hecho todo bien, cuando conecten el teléfono a la red y lo enciendan, este comenzara a descargar los archivos del servidor TFTP luego de configurar su IP, si funciono, al final verán que el teléfono en la esquina superior derecha dice "UNPROVISIONED SIP", si no dice esto, algo hicieron mal, verifiquen todo y comiencen de nuevo.

Actualización: si por alguna razón, el teléfono se niega a descargar las imágenes del software para trabajar con SIP y en pantalla les coloca "SEP.xml.cnf file not found", lo que tienen que hacer es crear ese archivo y colocarlo en la raiz del servidor tftp, el contenido de este archivo debe ser el mismo que coloco arriba para el XMLDefault.xml.cnf.

Continua en: Parte - 2

DHCP y NAT

   Todos conocemos de cierta forma el funcionamiento de DHCP y de las traducciones de dirección de red (NAT). NAT es ampliamente utilizado hoy día para tratar de reducir el ritmo en el cual se agotan las direcciones IP enrutables públicamente (en la versión 4 del protocolo IP), es decir, las direcciones IP utilizadas en Internet, aunque NAT no solo se utiliza para lo anterior, también puede ser aplicado en estos casos:

1. Migración de servidores, dado que es mas fácil y rápido realizar un NAT a los paquetes cuando se migra un servidor de un segmento de red a otro que tener que decirle manualmente a cada estación de trabajo la nueva dirección IP de este, y aun si utilizamos DNS, dependemos enteramente del TTL, lo cual evita que la transición sea transparente y rápida si no se sincroniza este parámetro, por ello se suele hacer uso de NAT para estos casos.
2. Seguridad, a veces sencillamente no se desea que se conozca el o los segmento(s) de red detrás del router que realiza NAT. 

   DHCP por otro lado, evita que tengamos que configurar manualmente cada estación de trabajo, automatiza enormemente la asignación de direcciones de red y parámetros asociadas a estas, también habilita la autoconfiguración de servicios (como es el caso de los teléfonos IP). Normalmente nos encontramos con 2 casos de implementacion de servicio DHCP.

Caso nº 1

 El servidor DHCP, que puede ser tanto un servidor como un router, se encuentra dentro del mismo segmento de red que los equipos a los que va a servir, como se muestra a continuación: 

  En el caso anterior, no hay problemas, todo funciona correctamente con una configuración mínima. 

Caso nº 2

   El servidor DHCP no se encuentra dentro del mismo segmento de red que la red a la que sirve: 

   En este caso se soluciona haciendo uso de un DHCP-Relay Agent, el cual es un intermediario, que se comunica de parte del cliente que hace la solicitud con el servidor DHCP por medio de mensajes UNICAST, recordemos que DHCP funciona normalmente es con mensajes Broadcast. Esto tampoco tiene mayor inconveniente mas allá de configurar el relay que puede ser el mismo router que sirve de gateway a la LAN que solicita el servicio. 

Caso nº 3

   Básicamente casi igual al anterior, pero, antes del enlace con el DHCP Server se realiza un NAT. En este caso, notaremos que por mas que configuremos el Relay, los dispositivos que solicitan el servicio DHCP no obtienen respuesta, todo parece estar bien, se tiene conectividad con el DHCP Server, verificado mediante ICMP con algún dispositivo de la LAN que solicita el servicio configurado manualmente. Entonces, ¿cual es el problema?

   Recordemos lo siguiente, NAT traduce direcciones en el caso de un Source-NAT que suele ser lo habitual, se traduce la IP de origen a otra, tenemos entonces el siguiente caso:

1. 192.168.0.1 se quiere comunicar con 10.10.10.1.
2. El host A, quien es el que posee la dirección 192.168.0.1, esta detrás de un NAT, esto implica que cuando quiere comunicarse con 10.10.10.1, lo que el host B (el propietario de 10.10.10.1) "ve" como dirección de origen no es la IP del host A, sino la IP que fue asignada producto de la traducción. 
3. Hasta aquí todo bien, de no ser por como funciona DHCP por medio de un Relay tendríamos conectividad.

   Cuando se hace uso de un DHCP-Relay, este, dentro del mensaje DHCP envía un parámetro llamado GIADDR, este parámetro es la dirección IP de la interfaz que intercepto el paquete DHCP, el proceso es el siguiente:

1. Host A, quiere configurarse con DHCP, el segmento de red es 192.168.0.0/24, para esto, envía un mensaje DHCP-Discover en forma de broadcast, tal cual el protocolo lo estipula. 
2. Dentro de ese segmento, se encuentra el relay, cuya dirección IP es 192.168.0.1, este intercepta el broadcast y envía el mensaje como unicast a la dirección del servidor DHCP, incluyendo adicionalmente en el campo GIADDR la dirección IP 192.168.0.1/24 la cual es la dirección de la interfaz que intercepto el primer broadcast, luego en la cabecera IP incluye como dirección de origen, la dirección 192.168.0.1. 
3. Durante el trayecto hasta el servidor DHCP, ocurre un NAT, ahora la dirección IP de origen del mensaje anterior no es 192.168.0.1, sino la asignada por el NAT (diremos que es 201.202.203.1 en este caso). 
4. Cuando el servidor DHCP recibe el mensaje, se fija en los parámetros internos de este, en especifico el GIADDR dado que este parámetro es el que se toma como referencia para elegir el pool de direcciones IP de donde se asignara la dirección al host, recordemos que en este caso es 192.168.0.1/24.
5. Y aquí es donde viene el problema, el servidor DHCP no se va a fijar en la dirección IP de origen de la cabecera IP para responder el mensaje, sino que directamente utiliza la dirección IP incluida en GIADDR para responder, si, el o los routers que intervienen en el camino desde el server DHCP al relay, no conocen la forma de llegar a la red que se estipula en GIADDR, lo cual suele ser lo habitual si se utiliza NAT, el paquete jamas llegara de vuelta y por lo tanto los equipos jamas se podrán autoconfigurar. 

  Para solucionar esto se pueden hacer unas cuantas cosas:

• Aplicar enrutamiento basado en políticas y túneles IP/IP (GRE), de esta forma cuando detectemos el trafico generado por DHCP-Relay, que se maneja por protocolo UDP puertos 67 y 68, obligamos al router a utilizar como next-hop el tunel IP/IP, este encapsulara el paquete original en otro paquete IP y no realizara NAT, se debe realizar esto por norma general en el router que realiza el NAT.
• Utilizar túneles IPSec
• Utilizar una combinación de lo anterior, ejemplo, GREoIPSec.
• Crear rutas especificas a las redes que solicitan el DHCP, algo inútil en el caso de que la red intermediaria sea Internet y que adicionalmente elimina el propósito de NAT si se utiliza como mecanismo de seguridad.