Cisco Dual-Wan (NAT)

Recientemente me encontré en la necesidad de asesorar a un cliente con un requerimiento que incluía realizar un balanceo de carga entre dos conexiones a Internet. En especifico los requerimientos fueron los siguientes:

1. Balanceo de carga entre dos conexiones a Internet, pero este balanceo de carga debe de ser asimétrico, es decir, debe pasar mas trafico por una conexión que en la otra, en un ratio 1:2. 
2. Se debe aplicar NAT a ambas conexiones. 
3. Se debe realizar un seguimiento de cada conexión para deshabilitarla en caso de una falla indirecta en la misma. 
4. Se requiere realizar port-forwarding en ambas conexiones a servicios y equipos específicos en la LAN. 

El siguiente diagrama, explica mejor la situación:

Lógicamente, el router que se debe configurar en esta ocasión, es el "NAT-ROUTER", En este caso, asumiremos lo siguiente:

1. Los puertos conectados a los ISP son, F0/0 para el ISP01 y F0/1 para el ISP02
2. El puerto conectado a la LAN es F1/0
3. Del lado de la LAN solo existe una subred, 192.168.0.0/24
4. Las IPs que nos asignaron los ISP son, ISP01 172.10.10.10 y ISP02 173.16.0.10
5. Las puertas de enlace son ISP01 172.10.10.1 y ISP02 173.16.0.1

Para poder llevar a buen puerto este proyecto, se debe realizar lo siguiente:

Configurar NAT (PAT en este caso)

El proceso es exactamente el mismo que se realiza habitualmente, esto es, definir que interfaces son inside y que interfaces son outside, definir una lista de acceso con los hosts a los cuales se les realizara el NAT cuando salgan a internet, etc. Pero, adicionalmente, dado que esto es un entorno con dos WAN, es necesario definir reglas de NAT que permitan diferenciar cual se aplicara, según el puerto de salida del paquete.

Según documentación de Cisco, por la forma en que opera IOS con NAT, la simple definición de un ACL que defina los hosts que pueden conectarse a internet, no basta, dado que el sistema realiza una verificación de reglas NAT, luego de consultar la tabla de enrutamiento (y por ende, ya teniendo definida la interfaz de salida del paquete), esto implica que, salvo que definamos una regla NAT que adicionalmente considere la interfaz de salida, podemos terminar con una situación donde un paquete es traducido a una dirección de origen que no concuerda con la dirección de la interfaz de salida.

Ejemplo:

1. Entra un paquete dirigido a 172.16.0.1 con origen 192.168.0.10, el router consulta su FIB (Tabla de Enrutamiento) y decide enviarlo por F0/0 (ISP01), la IP de esta interfaz es 172.17.0.10
2. Luego de lo anterior, se consultan las reglas definidas para NAT, el router comprende que el paquete procede de una interfaz definida como inside y va dirigido a una interfaz outside, adicionalmente concuerda con una lista de acceso definida en la regla, realiza una traducción donde cambia la dirección de origen a 172.18.0.20 (la IP asignada a la interfaz F0/1, que conecta con ISP02).
3. Envía el paquete por la interfaz F0/0

Normalmente un router solo enruta paquetes basado en la IP de destino, pero, que sucedería si el router del ISP02 en el caso anterior utilice algún mecanismo de filtrado o de Policy Based Routing? el paquete recibido por este no concuerda con la subred definida para ese enlace y podría perfectamente descartarlo precisamente por esta razón. 

Para solventar esto, debemos definir no solo listas de acceso de los hosts que queremos puedan tener conexion a internet, sino algo que nos permita definir que regla utilizar, segun la interfaz de salida seleccionada por el router. Para esto utilizaremos algo denominado en Cisco como "route maps". 

Estos mapas de ruta, permiten crear secuencias donde se definen diversos parámetros a evaluar (listas de acceso, interfaces de salida, DSCP, etc.) y solo devuelven como "verdadero" si todos se cumplen. 

Definiendo los route-maps

Definiremos dos route maps, uno por cada interfaz de salida que evaluen si la IP de origen del paquete y la interfaz de salida del mismo:

(en modo conf)

!Definimos primeramente nuestra ACL

ip access-list standard NAT_PERMITIDOS

   permit 192.168.0.0 0.0.0.255

!

!Este route map, verifica que el paquete salga por el ISP01

route-map 1 permit 10

   match ip address NAT_PERMITIDOS

   match interface fastethernet0/0

!

!Este route map, verifica que el paquete salga por el ISP02

route-map 2 permit 10

   match ip address NAT_PERMITIDOS

   match interface fastethernet0/1

!

Definiendo las reglas NAT

(en modo conf)

ip nat inside source route-map 1 interface fastethernet0/0 overload

ip nat inside source route-map 2 interface fastethernet0/1 overload

Como aprecian, no difiere mucho de la definicion de reglas NAT utilizando unicamente ACL.

Configuración de balanceo de carga y chequeo de conexión

Para rutas estáticas, balanceo de carga asimétrico es una función que no esta explicitamente definida en IOS, para lograr esto, jugaremos con la recursividad de las rutas, dado que normalmente los routers Cisco distribuyen el trafico de forma equitativa entre el numero de rutas que posean la misma métrica y la misma distancia administrativa, resulta evidente que, si creamos 3 rutas estaticas con la misma métrica, misma AD pero apuntando a diferentes salidas (2 al ISP01 y 1 al ISP02), obtendremos un balanceo de carga asimétrico con ratio 1:2 (dado que se reparte el 33% del trafico entre cada salida, pero dos de estas son la misma interfaz).

Adicionalmente, tenemos que considerar los problemas de conexión indirectos de cada ruta, normalmente una ruta es eliminada de la FIB cuando se detecta una falla directa de la interfaz de salida de dicha ruta (esto solo en el caso de rutas estáticas, en rutas aprendidas por protocolos de enrutamiento, el comportamiento es algo mas inteligente). ¿Qué sucede entonces cuando por problemas internos del ISP01 (por ejemplo) no se puede acceder a digamos, www.google.com (dado que el router decidió enviar el trafico hacia dicha pagina por este ISP), pero, la conectividad entre el NAT-ROUTER y el router de dicho ISP funciona correctamente? La ruta no se va a deshabilitar, ocasionando que se siga utilizando, lógicamente el trafico jamas alcanzara la pagina web de google y ahí es cuando tendremos al típico usuario llamando para decir "no hay internet".

Tenemos que utilizar algun mecanismo que permita monitorear el funcionamiento de la conexión, mas allá de la disponibilidad del enlace entre ambos routers. Con Cisco, tenemos una herramienta denominada IP SLA, el único problema de este comando, es que solo esta disponible en routers que posean licencia DATA. En cualquier caso, el procedimiento es como sigue:

Creamos los IP SLA

Estas son reglas de chequeo de servicios, en este caso crearemos dos reglas que chequeen la conectividad con www.google.com por medio de ICMP, una regla utiliza como interfaz de salida la del ISP01 y la otra la del ISP02.

(en modo conf)
ip sla 1 
   icmp-echo www.google.com source-ip 172.10.10.10
   frequency 10
!
ip sla 2
   icmp-echo www.google.com source-ip 173.16.0.10
   frequency 10
!
ip sla schedule 1 life forever start-time now
ip sla schedule 2 life forever start-time now
!

Frequency define cada tanto tiempo en segundos se debe realizar la prueba (en este caso 10 segundos) icmp-echo indica el tipo de prueba a realizar (ping) a que destino y con que origen (notese que los orígenes coinciden con las IP asignadas a nosotros por los ISP). IP SLA SCHEDULE, define cuando comienza a funcionar la prueba, en este caso empieza de inmediato y se debe mantener en funcionamiento de forma permanente. Si quieren verificar el funcionamiento basta utilizar el comando show ip sla.

Creamos los objetos TRACK

Estos objetos permiten en conjunto con los IP SLA devolver un estado verdadero o falso, según análisis de los resultados devueltos por IP SLA. En este caso, queremos que se tome cada IP SLA definido y se analice si existe o no conectividad, utilizamos lo siguiente:

(en modo conf)
track 1 ip sla 1 reachability
track 2 ip sla 2 reachability

Nota: En versiones anteriores de IOS los comandos antes expuestos no funcionan, si este es el caso, se debe hacer uso de los siguientes:

(en modo conf)

track 1 rtr 1 reachability

track 2 rtr 2 reachability

Configuramos las rutas estáticas

Finalmente creamos las rutas estáticas correspondientes, sin embargo, estas rutas tienen un añadido como se observa a continuación:

(en modo conf)

ip route add 0.0.0.0 0.0.0.0 172.10.10.1 track 1

ip route add 0.0.0.0 0.0.0.0 173.16.0.1 track 2

ip route add 0.0.0.0 0.0.0.0 fastethernet0/0 track 1

En este caso, observen el añadido de la palabra clave track, seguido de un numero que concuerda con los objetos track que creamos previamente. Esto le indica al router que solo debe instalar la ruta en la FiB cuando el objeto track devuelve como resultado de la prueba "verdadero" esto es, cuando se tiene conectividad con www.google.com, en caso contrario la ruta se elimina, evitando enviar trafico por esta si no se tiene un correcto funcionamiento. Ademas, también deben apreciar que existe una ruta adicional que apunta a la interfaz f0/0 (ISP01) ademas de la ruta que apunta directamente a la IP gateway de este ISP, esto es lo que comentaba de la recursividad y el balanceo de carga, las 3 rutas funcionan correctamente, tienen la misma AD y la misma métrica, dos de estas salen por la misma interfaz, recordemos que los routers Cisco envían de forma equitativa el trafico entre cada ruta, por ende aquí estamos obteniendo un balanceo de carga asimétrico 1:2 (por cada paquete que sale por F0/1, dos salen por F0/0).

Configuración Port-Forwarding

En este caso solo dejare la plantilla para realizar esto, se debe llenar por cada puerto que se requiera abrir. 

ip nat inside source static tcp/udp host_destino p_destino 172.10.10.10 p_origen extendable

ip nat inside source static tcp/udp host_destino p_destino 173.16.0.1 p_origen extendable

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

Hoja de Ayuda configuracion DHCP Routers

Configurar Router como servidor DHCP
  Nota: los paquetes DHCP son paquetes UDP que utilizan los mensajes "discovery (broadcast), offer (unicast), request (broadcast), acknowledge (unicast)".

1.- Entramos al modo configuración del router.

2.- Escribimos "ip dhcp pool pool_nombre" donde pool_nombre es el nombre del parque de direcciones que vamos a ofrecer a los clientes.

3.- Al hacer lo anterior entramos en el modo (dhcp-config), dentro de este modo tecleamos los siguientes comandos para realizar las configuraciones pertinentes:

          a.- "network direccion_red mascara" para especificar  la red y por ende parque de direcciones a utilizar.

          b.- "default-router IP_Router" especificamos el gateway a enviar a los clientes.

          c.- "dns-server IP_DNS" especificamos la dirección del DNS a enviar a los clientes. 

4.- Si deseamos evitar que determinadas IP sean asignadas (como la del gateway por ejemplo) fuera del modo (dhcp-config) tecleamos "ip dhcp excluded IP_bajo IP_alto" donde ip_bajo ip_alto forman un rango, si solo se introduce una dirección entonces solo esa dirección sera excluida, si se introduce un rango, todas las IPs dentro de ese rango seran excluidas. 

5.- Si deseamos configurar nuevamente el mismo pool DHCP volvemos a utilizar el comando del paso 2 colocando el nombre que utilizamos originalmente, caso contrario se creara otro pool dhcp, podemos tener tantos como sean necesarios para controlar las múltiples redes conectadas al router. 

Configuración Router como relay DHCP

   En el caso de poseer un servidor DHCP dedicado en una red distinta a la que se quiere administrar por este servicio, debemos hacer un forwarding de los mensajes DHCP enviados por los equipos, para ello debemos configurar la interfaz del router que da directamente con la red que queremos administrar de la siguiente forma:

1.- nos introducimos en la interfaz del router que esta conectada con la red donde estan los clientes a asignarles direcciones DHCP por medio del comando "interface nombre_interface".

2.- una vez en el modo (conf-if) tecleamos el comando "ip helper address Direccion_IP_Servidor_DHCP" donde direccion_ip_servidor_dhcp como su nombre lo indica, es la dirección IP del servidor que gestiona el servicio DHCP. 

Nota: hay que recordar obviamente, tener las listas DHCP configuradas en el server o en el router destino del relay.

Hoja de ayuda NAT

Continuando con las Hojas de Ayuda para configuracion de switches y routers, esta vez los comandos basicos para NAT/PAT de un router.

NAT significa Network Address Translation, básicamente se encarga de "traducir" una IP privada en una IP publica. Esto es necesario para poder establecer comunicacion entre una red privada e internet. 

Guias de configuración 

NAT ESTATICO (solo una IP pública para una única IP privada)

• Router(config)# ip nat inside source static IP_PRIVADA IP_PUBLICA
• Router(config)# interface INTERFACE_IP_PRIVADA
• Router(config-if)# ip nat inside
• Router(config)# interface INTERFACE_IP_PUBLICA
• Router(config-if)# ip nat outside

NAT DINAMICO (múltiples IPs públicas para un determinado grupo de IPs privadas)

• Router(config)# ip nat pool NOMBRE_RANGO IP_INICIO IP_FIN  netmask MASCARA
• Router(config)# access-list ID_LISTA permit DIRECCIONES_IP_A_PERMITIR
• Router(config)# ip nat inside source list ID_LISTA  pool NOMBRE_RANGO
• Router(config)# interface INTERFACE_IP_PRIVADA
• Router(config-if)# ip nat inside
• Router(config)# interface INTERFACE_IP_PUBLICA
• Router(config-if)# ip nat outside

PAT UNIDIRECCION (una sola direccion IP publica)       

• Router(config)# access-list ID_LISTA permit IP_O_RANGO_IP
• Router(config)# ip nat inside source list ID_LISTA interface INT_SALIDA overload
• Router(config)# interface INTERFACE_IP_PRIVADA
• Router(config-if)# ip nat inside
• Router(config)# interface INTERFACE_IP_PUBLICA
• Router(config-if)# ip nat outside

PAT MULTIDIRECCION (múltiples direcciones IP publicas)

• Router(config)# ip nat pool NOMBRE_RANGO RANGO_PAT_PUBLICO netmask MASCARA
• Router(config)# access-list ID_LISTA permit IP_O_RANGO_IP
• Router(config)# ip nat inside source list ID_LISTA pool NOMBRE_RANGO overload
• Router(config)# interface INTERFACE_IP_PRIVADA
• Router(config-if)# ip nat inside
• Router(config)# interface INTERFACE_IP_PUBLICA
• Router(config-if)# ip nat outside

Comandos verificacion NAT funcionan fuera de conf

• show ip nat translation
• show ip nat statistic
• 
  

Notas: PAT trabaja multiplexando los puertos, NAT, no. Por ende PAT es mas eficiente para dar servicio a mas de una IP privada con una sola IP publica. 

Si quieren hacer esto utilizando no un router sino una PC, podrian hacer uso de IPTABLES/NETFILTER de Linux.

VLAN y VTP Hoja de ayuda

CREACIÓN  Y RENOMBRADO DE VLANS

  Para crear una VLANs basta con entrar en el modo configuración del switch y teclear:

vlan NUMERO_VLAN

Tras lo cual se entra en el modo configuración de esa VLAN donde podemos cambiarle su nombre con el comando:

name NOMBRE_VLAN

Nota: las vlan también son creadas automáticamente (de no existir) al configurar un puerto como acceso y asignarle una VLAN.

Configuración modo troncal o acceso de un puerto del switch

Nos metemos en el puerto o puertos a configurar y segun se necesite tecleamos:

• Modo troncal: switchport mode trunk
• Modo acceso: switchport mode access

Segun se haya configurado podemos realizar ciertas configuraciones adicionales, por ejemplo para modificar la VLAN nativa (la VLAN utilizada para el modo troncal) podemos teclear:

    switchport native vlan NUMERO_VLAN  (Por defecto es la 1 y se recomienda cambiarla por seguridad)

Si el puerto esta configurado como acceso debemos entonces asignarle la VLAN a la cual tiene acceso con el siguiente comando:

   switchport access vlan NUMERO_VLAN (si la VLAN no se ha creado aun, tras teclear esto se crea automaticamente)

VLAN TRUNKING PROTOCOL (VTP)

   Si deseamos configurar este protocolo de cisco, basta con primero identificar que switch va a ser servidores, que switch o switches funcionaran como transparentes y cuales switches seran clientes, una vez hecho esto y segun sea el caso de debe teclear lo siguiente:

1. vtp version 2 (asignamos la version con la cual se trabajara)
2. vtp mode server/transparent/client (segun sea el caso, como se explico previamente)
3. vtp domain NOMBRE_DOMINIO_VTP (identificador del dominio VTP)
4. vtp password CONTRASEÑA_DOMINIO_VTP (contraseña de acceso al dominio VTP)

Obligatoriamente tanto el domain como el password deben coincidir en todos los switches que se desee comuniquen por medio de VTP. 

Recordar: 

• Solo puede existir un servidor, este transfiere la información de las VLAN (numero y nombre).
• Los switches en modo transparent, solo reenvian las tramas de configuración VTP pero no las utilizan.
• Los switches en modo client, reenvian las tramas de configuración VTP y las utilizan para configurarse ellos mismos.

PROTOCOLO DOT1Q (ENRUTAMIENTO INTERVLAN)

  Normalmente VLANs distintas no pueden comunicarse entre si, y si existe mas de una segmentación en un dominio fisico, salvo que utilicemos el protocolo dot1q no es posible hacer que todas puedan comunicarse con otras redes o entre si. 

  El protocolo dot1q básicamente lo que hace es agregar una etiqueta a la trama que sale del router hacia una VLAN, esta etiqueta no es mas que el numero de dicha VLAN y se utiliza como identificador para que esta sea capaz de tomarla como suya. 

  En el caso de no hacer uso de switches multicapa, se debe entonces segmentar la interfaz del router que da hacia la red física donde estan configuradas las VLAN para esto basta con:

1. Crear una subinterfaz dentro de la interfaz que da hacia el segmento físico, supongamos que la interfaz es la F0/0, para crear una subinterfaz basta con agregar un punto seguido de un numero después del ultimo 0, ejemplo: F0/0.X donde "X" es el numero de la subinterfaz, por conveniencia, este numero se asigna como el mismo al de la VLAN a la que dara servicio. 
2. Una vez dentro de la configuración de la subinterfaz teclear: encapsulation dot1q NUMERO_VLAN
3. Asignar una IP a la subinterfaz tal cual se haria si se configurara la interfaz completa puesto que esta servira como gateway de la red a la que surtira. 
4. Se sale de la subinterfaz y se ingresa en la interfaz completa y se levanta con no shutdown. 

nota: NO se debe agregar una IP a la interfaz completa cuando se hacen subinterfaces. 

Ejemplo:

   Nuestro router A esta conectado por medio de la interfaz F0/1 a un segmento físico con un switch que tiene configurado dos VLAN, las cuales son 20 y 30 con las siguientes características:

VLAN 20

IP RED: 192.168.20.0/24

VLAN 30

IP RED: 192.168.30.0/24

Configuración subinterfaz para la VLAN 20

1. En el router tecleamos interface f0/1.20
2. Entramos entonces a la configuración de la subinterfaz, configuramos el protocolo dot1q:                encapsulation dot1q 20
3. Configuramos una IP para la interfaz recordemos, esta sera el gateway de la red de la VLAN 20                          ip address 192.168.20.1 255.255.255.0
4. De querer recibir servicio DHCP externo, se configura el ip helper-address
5. Salimos de la subinterfaz con exit

Configuración subinterfaz para la VLAN 30

1. En el router tecleamos interface f0/1.30
2. Entramos entonces a la configuración de la subinterfaz, configuramos el protocolo dot1q:                encapsulation dot1q 30
3. Configuramos una IP para la interfaz recordemos, esta sera el gateway de la red de la VLAN 30                          ip address 192.168.30.1 255.255.255.0
4. De querer recibir servicio DHCP externo, se configura el ip helper-address
5. Salimos de la subinterfaz con exit

Por ultimo solo debemos meternos en la interfaz completa y "levantarla":

1. interface f0/1
2. no shutdown
3. exit

MULTILAYER SWITCH (SWITCH CAPA 3)

   Estos switches tienen la particularidad que pueden funcionar tanto en modo capa 2 como en modo capa 3 o una combinación de ambos. La creación y configuración de VLANS y su enrutamiento al utilizar un switch de esta clase evita la necesidad de hacer una división en subinterfaces en un router. 

  La creación de VLANS se hace como normalmente se haria en un switch (VLAN NUMERO_VLAN). Para configurar el protocolo dot1q basta con acceder a cada VLAN creada y configurar de la siguiente manera:

1. interface vlan NUMERO_VLAN
2. ip address IP_RED MASCARA (esta es la IP de la interfaz, igual que cuando se configura un router en subinterfaces, esta es la que sirve de gateway)
3. Nos salimos de la interface con exit y entramos en la interfaz fisica que da hacia los switches de distribucion, esta interfaz es la que se utilizara como troncal.
4. Dentro de esta interfaz tecleamos: switchport mode trunk y luego switchport trunk encapsulation dot1q
5. Hecho esto, el enrutamiento intervlan esta completo y el protocolo dot1q activo. Salimos de la interfaz con exit.

  Si deseamos activar el modo capa 3 del switch (enrutamiento) dentro de la configuración global tecleamos: ip routing

   Luego en cada interfaz que de hacia otros routers, debemos teclear: no switchport, hecho esto podremos configurarle una IP a dichas interfaces y luego podremos configurar los protocolos de enrutamiento tal cual se haria en un router convencional. 

Ficha para configurar una red por rutas estaticas

  Normalmente, cuando configuramos una red debemos siempre seguir una serie de pasos que si bien dentro de cada uno de estos pueden variar en complejidad, la sumarización de todos tiende a ser algo bastante mecánico. En este caso les traigo una pequeña lista paso a paso de que se debe hacer para configurar una red por medio de rutas estáticas, no es algo muy elaborado pero en mi caso, viene a ser útil para cuando quiero llevar un orden de lo que hago.

Pasos generales para configurar una red con rutas estáticas 

1.- Ubicar/seleccionar la IP base que se va a utilizar
2.- Subnetear de ser necesario esta IP base según los requerimientos de hosts. Incluyendo las subredes necesarias para los enlaces WAN.
3.- Conexión de los dispositivos (Routers, Switches, equipos, etc) presentes en la red.
4.- Configuración de los routers:
    a.- Entrar al modo privilegiado (enable)
    b.- Entrar al terminal de configuración (config terminal)
    c.- añadir un nombre al router (hostname "nombre")
    d.- añadir una contraseña al modo enable (enable secret "contraseña")
    e.- añadir un ID de acceso al terminal de configuración (line con 0; password "contraseña"; login)
    f.- añadir un mensaje del día (banner motd #mensaje#)
    g.- entrar a cada interface, asignarle una IP, MSK, Identificación, velocidad de reloj en caso de ser serial DCE y activar (interface "interfaz a configurar"; ip address IP MSK; description "nombre"; clock rate "velocidad"; no shutdown)
    h.- asignar las rutas estáticas, sumarizadas de ser posible  (ip route IP_RED MSK Interfaz o IP_SALIDA)

    i.- asignar una ruta estática predeterminada de ser necesario

    j.- asignar una ruta estática flotante de ser necesario
    k.- guardar la configuración (copy running-config startup-config o copy run start)
    l.- verificar la configuración (show interfaces, show ip interface brief, show running-config)
5.- configurar los equipos presentes en la red
6.- verificar el correcto funcionamiento de todo por medio de los equipos (ping, arp, netstat, show ip route, traceroute)
   

Sumarización de rutas estáticas

    Permite englobar múltiples subredes dentro de una única dirección de red, disminuyendo el tamaño de la tabla de enrutamiento y por consecuencia aumentando el rendimiento del dispositivo. Solo puede realizarse si:

          a.- Las subredes pueden englobarse dentro de una única dirección de red.

          b.- Todas las subredes utilizan la misma IP de siguiente salto o interfaz de salida.

Pasos para realizar la sumarización

1.- Se escriben todas las IPs de las subredes que cumplen con lo estipulado anteriormente, una debajo de la otra en binario.

2.- Bit a Bit comenzando desde el bit de la izquierda se hace una comparación de columnas, si se encuentra una que no coincide, se detiene el proceso, ese es el máximo de bits posibles para la sumarización.

3.- La dirección IP sumarizada sera la formada por todos los bits previos coincidentes seguidos de suficientes 0s para completar los 32 bits. La mascara, corresponde al numero de bits coincidentes

   Ejemplo

                      Dirección A:  10100000.11010000.01011010.11110000  por la interfaz s0/0/0

                      Dirección B:  10100000.11100000.11110000.00001111  por la interfaz s0/0/0

                      Dirección C;  10100000.10111110.00000111.11011001  por la interfaz s0/0/0

     Las 3 direcciones solo coinciden en los 9 primeros bits, tomamos estos y los demás los volvemos 0 (10100000.10000000.00000000.00000000), nuestra dirección sumarizada en decimal es entonces 160.128.0.0/9. basta con hacer un ip route 160.128.0.0 255.128.0.0 s0/0/0 para abarcar las redes en una sola entrada de ruta estática. Esto funciona porque la mascara de subred es la que determina cuantos bits deben coincidir entre la IP origen y destino, estamos reduciendo esta cantidad a lo mínimo posible,

  Ruta estática predeterminada (gateway of last resort)

   La ruta estática predeterminada es una ruta que se utiliza en caso de que el paquete a enviar contenga una dirección que no aparece listada en ninguna ruta especifica de la tabla de enrutamiento. Se configura de la misma manera que una ruta normal solo que su dirección IP y mascara serán ambas 0.0.0.0, ejemplo ip route 0.0.0.0 0.0.0.0 interfaz o IP próximo salto. Normalmente son utilizadas cuando el router configurado esta a su vez conectado a otro router que se utiliza para una sola ruta especifica o cuando se establecen conexiones a ISP (internet service provider).

   Ruta estática flotante (o de respaldo)

   Una ruta estática flotante es una ruta de respaldo que se utiliza solo cuando la ruta principal cae, los routers ajustan la prioridad de una ruta en función de su distancia administrativa, tomando en cuenta solo la ruta que posea el menor valor, este valor varia entre 0 - 255 y se coloca al final de todos los parámetros del comando ip route. Ejemplo, tenemos dos posibles via para llegar a la red 192.168.1.0 255.255.255.0 por la interfaz s0/0/0 o por la ruta de respaldo en s0/0/1.

Ajustamos la interfaz s0/0/0 como principal: ip route 192.168.1.0 255.255.255.0 s0/0/0 1

Ajustamos la interfaz s0/0/1 como secundaria: ip route 192.168.1.0 255.255.255.0 s0/0/1 2
 

  En el caso de que la ruta principal falle (por ejemplo, se desconecte el cable de conexión) se borra automáticamente esta entrada de la tabla de enrutamiento y se asigna la de respaldo.