Archivo del sitio

Que MAC tiene un Switch ? – BACKPLANE

Este post es de cara a la eterna duda del principiante. La mayoría de los alumnos de Cisco, al principio piensan que los Switch tienen una MAC en cada uno de sus puertos, pues bien, esto no es así, un Switch de capa 2, solo tiene una MAC propia y esa MAC pertenece al BACKPLANE OTra cosa muy distinta son las MAC que asocia a cada puerto por sercibidas por él, al tener algún equipo final (host) conectado a dicho puerto. Ya sabéis que los Switch gestionan las tablas MAC.

El blackplane también es conocido como `Bus´, conecta todos los puertos del switch internamente (en el switch).

El switch internamente es una red en pequeño, cada puerto se comunica con los demás, manejan una gran cantidad de tráfico entre ellos.
En el switch el ancho de banda interno determina el rendimiento individual de todos sus puertos. Existen 2 arquitecturas utilizadas para su implementación.

1) Bus, es un bus interno de muy alta velocidad (por encima de los 3 Gbps.), pero compartido.

2) Múltiples Buses (Crossbar), la matriz de conmutación es un conmutador o switch.

Anuncios

VTP en routers CISCO

VTP proporciona un medio sencillo de mantener una configuración de VLAN coherente en toda la red conmutada y nos reduce la necesidad de configurar manualmente la red. No olvidando que es un protocolo de capa 2.

VTP es propietario de cisco, si no son dispositivos cisco hay que usar otros estándares de protocolos abiertos como GVRP( GARP VLAN REGISTRATION PROTOCOL).

VTP forma un dominio único y dentro de este dominio VTP intercambia:
Nombre del dominio.
Versión de VTP.
Lista de Vlan.
Parámetros específicos de cada Vlan.

Dentro de los tres modos de VTP los switches están por defecto en modo servidor.
Cuando están en modo transparente ya todos sabemos lo que hace el swicht, pero puede tener dos versiones, en la versión dos permite que aunque ese swicht no esté configurado dentro del dominio VTP, reenvíe igualmente los paquetes VTP aún siendo esos VTP de versión1.

En una red muy grande hay varios servidores de VTP no solo uno. VTP anuncia solo VLAN comprendida entre 1 y 1005. Hay una nueva versión, la tres, y va el rango desde la 1 a la 4096 pero solo funciona con swiches cisco con CatOS, la parte positiva es que Versión 3 es compatible con IEEE 802.1Q

Hay un número de versión en los Switch con VTP, este número se incrementa cada vez que hay un cambio en las Vlan. Todos los demás switch se actualizan a este, hay que tener cuidado no pongamos algún switch que tengamos en el almacén de repuesto y este tenga un número antiguo de revisión y sea más alto, este nos tiraría la red abajo con su base de datos de la vieja VLAN.
Para evitar este desastre lo mejor es cambiar el nombre de dominio de VTP en el Switch que vamos a instalar y volver a poner el nombre de dominio que le corresponde, después comprobar que esta a cero el número de la versión.
VTP no es un protocolo seguro ya que los mensajes se transmiten en texto plano, debemos ponerle como mínimo contraseña al VTP.

Hay tres tipos de anuncios VTP.
Summary Advertisements: Se generan cada 300 segundos y son enviados por el servidor de VTP, también se pueden generar cuando hay un cambio en la base de datos de la VLAN. Este tipo de anuncio informa a los otros Switch del nombre del dominio cuando todavía no tienen ninguno, el switch que lo recibe completa el campo del nombre del dominio con el recibido y manda un ACK Advertisements.
Despues el servidor envía otro summary advertisements que no tengo muy clara su finalidad, tengo que comprobarlo antes de postearlo para no cometer un error en la documentación y a continuación sin haber recibido esta vez ninguna respuesta por el switch receptor, el servidor lanza un Subsets Advertisement, que hace al switch receptor añadir las ID de las Vlanes y el número de revisión, quedando completa toda la información de la que hablabamos más arriba.

Subsets Advertisement: Estos anuncios se generan cada vez que se produce un cambio en alguna VLAN.

Advertisements Request from Client: Se generan cada vez que un cliente necesita que le envíe la configuración, por ejemplo después de un reset del switch. Recordaros que no tienen nada almacenado en la flash, como es el fichero vlan.dat en el caso de los que cumplen el rol de servidor de VTP.
Para configurar la versión 2, solo tenemos que hacer los siguiente:
Switch#configure terminal
Switch(config)#vtp version 2

Para poner a switch en alguno de los modos (ejemplo: servidor) y de paso contraseña, haríamos lo siguiente:
Switch(config)#vtp mode server
Switch(config)#vtp password cmdsistemas

Tenemos los siguentes comandos de verificación que podéis usar:
show vtp status
show vtp counters
show vlan brief
show interfaces switchport module (y el número de módulo sin estos paréntesis, por ejemplo poner un 1 directamente)

Visitar este enlace, sobre todo la parte de resolución de problemas, es el último de los tres botones que os salen para seleccionar, se ve muy claro con los dibujos: http://www.cisco.com/warp/public/473/vtp_flash/

Segmento TCP, acuse de recibo y tamaño de la ventana TCP

TCP Segment Acknowledgement and windows Size

A los que estudiamos o estamos preparando un CCNA se nos explica que el tamaño de la ventana de TCP, varía ajustandose a la congestión del circuito. Se envían varios paquetes segmentados por el tamaño de la MTU y se recibe un acuse de recibo cuando se completa el tamaño de la ventana, el caso sería el siguiente:
Windows Size = 3000
Sequence number 3001 ———–(1500 bytes)———> Receive 3001-4500
Sequence number 4501————(1500 bytes)———> Receive 4501-6000

Receive Acknowledge <——————— Acknowledgement number 6001

El número de confirmación es el número del próximo byte esperado y así se van enviando todos los paquetes que conforman los datos a enviar.

Congestión y control de flujo en TCP:
A)Windows Size = 3000
Sequence number 3001 ———–(1500 bytes)–xxxxxx Receive 3001-4500 Receive 4501-6000

B)Receive Acknowledge Receive 3001-4500
Sequence number 4501————(1500 bytes)-xxxxxx Receive 4501-6000 <–debido a la congestión perdemos este paquete
Sequence number 6001————(1500 bytes)-xxxxxx Receive 6001-7500 Receive 7501-9000

¿Se vuelve a enviar este paquete perdido al ser el primero de dos dentro de la ventana?

Los hosts pueden emplear también una característica optativa llamada “acuses de recibo selectivos” (SACK). Si ambos hosts admiten los SACK, es posible que el destino acuse recibo de los bytes de segmentos discontinuos, y el host solo necesitará volver a transmitir los datos perdidos.

C)Receive Acknowledge Receive 3001-4500
Sequence number 4501————(1500 bytes)-xxxxxx Receive 4501-6000 Receive 6001-7500
Sequence number 7501————(1500 bytes)-xxxxxx Receive 7501-9000 <–Segment is lost because of congestion at the receive
Receive Acknowledge <——————— Acknowledgement number 4501 and Windows size = 1500
Receive Acknowledge <——————— Acknowledgement number 7501 and Windows size = 1500

Al perder datos varía la ventana.

SLOW-STAR un protocolo dentro de tcp.
Es un protocolo o mejor dicho algoritmo usado como control de congestión en TCP y no lo enseñan en el CCNA.

Slow-start es un algoritmo de control de congestión del protocolo TCP, pero mejor leemos en Wikipedia lo que hace:
http://es.wikipedia.org/wiki/Slow-start
Si ya lo hemos leido nos daremos cuenta que el caso B no se puede hacer sin el uso de SACK, ya que reinicia al mms debido al algoritmo de evitación de congestión SLOW-start, es decir TCP tiene memoria ya que cuando se nota la congestión se reduce el tamaño de la ventana a la mitad nunca siendo inferior a dos sementos, dando a TCP el punto o proporcionando a TCP de una memoria de el punto donde comienza la congestión de la red,pudiendo anticiparse al futuro. Es decir el ultimo caso después de recibir la ventana a 1.500, no se enviaran de 1500 en 1500 si no que se tomara otra medida de tamaño del paquete, por ejemplo de 750 en 750 bytes, volviendo a enviar dos como hasta ahora.

He editado este post a fecha de 2015 siendo un post del 2012, ya que entiendo no se veía clarificatorio para personas que hacen sus pinitos en redes, por las preguntas que me llegaban por privado.

EIGRP – Sucesor – Sucesor factible

Hoy ha sido un día duro, hemos estado peleando con el sucesor factible de EIGRP y resulto dificil su comprensión.
Vamos a verlo en el blog con una analogía que probablemente a muchos nos resultará familiar y nos va ayudar bastante, siempre hay que buscar un punto pedagógico 🙂

Digamos que usted es un fumador. Y que quiere salir a fumar un cigarrillo. La mayoría de las veces, tienes 2 paquetes contigo. Te vas fuera y fumas con el paquete de cigarrillos que ya tienes abierto (su paquete abierto es el router sucesor). Pero de vez en cuando bajas a fumar y se te olvida el paquete abierto (la ruta del sucesor se cae). Puesto que usted tiene un segundo paquete de cigarrillos , lo abres y comienzas a fumar (haces uso del sucesor factible).

Agradecimientos a Raúl por la imagen.

Si no tienes el segundo paquete de cigarrillos, tendrías que preguntar a la gente de tu alrededor para poder fumar (en las rutas de red activas tienes que enviar consultas a tus vecinos para buscar una ruta).

El sucesor es la mejor ruta a una red determinada. Es lo que se ve en la tabla de enrutamiento de salida de show ip route. Cuenta con la mejor métrica a la red.
Un sucesor factible es una ruta de respaldo. Este es un concepto importante de EIGRP – una ruta de respaldo se puede utilizar inmediatamente si la ruta principal (el sucesor) se cae. Como decíamos es inmediatamente por lo tanto no hay corte en el flujo de datos y esa es la gran ventaja. Si una ruta no tiene un sucesor factible, las transiciones de ruta a estado activo, empieza pregutando a otros routers si tienen una ruta a la red que ahora mismo no llega, no comienza enviando el tráfico como haría en el caso anterior.

En resumen, “el sucesor” es el REY y el Sucesor Factible es el principe que espera por el trono o la corona.

Ahora lo que determina un sucesor factible es un poco más complicado.
Digamos que su router sucesor tiene anunciada una distancia de 90, y su distancia desde el router es de 10.
Total 90 + 10 = 100, por lo que la distancia factible es de 100. Para que un router se pueda calificar como sucesor factible, la distancia anunciada al router tiene que ser menor que la distancia factible del sucesor. (Es necesario para asegurar un camino libre de bucles). Así que si otro router notifica la misma ruta con una distancia notificada de 95, siendo esta menor que la distancia factible del actual sucesor,por lo tanto se nombrara como sucesor factible.

Si una tercera ruta esta siendo notificada al router con una distancia notificada de 100 o superior, este NO será calificado como un sucesor factible, ya que la distancia publicada no es menor que la distancia factible.

Vamos a ver un ejemplo:
R3# show ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(3.3.3.3)

Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,
r – reply Status, s – sia Status

P 192.168.5.0/24, 1 successors, FD is 3072
via 10.0.35.5 (3072/512), Serial1/3
via 10.0.34.4 (4352/1792), Serial1/2

La parte superior de las rutas dadas (donde vemos la “P”) indica la Distancia Factible de la ruta, FD es 3072.

En las dos rutas que se indican a continuación, hay dos números. Estos son la distancia factible y la distancia notificada.
La distancia notificada es la distancia a la que dice el router remoto que está de la ruta a alcanzar. Por ejemplo si un router es el sucesor y resulta que lo que queremos alcanzar desde otro router es una red lan de este sucesor, la distancia notificada será el coste de su red lan.
La distancia factible es la distancia total, es decir es la distancia remota + el costo del enlace para alcanzar al router que anuncia la distancia notificada.

Entonces por el camino a través de 10.0.35.5, la distancia notificada (AD) es de 512, y cuando el router calcula su propio costo para el enlace conectado, la Distancia factible se convierte en 3072.
De la segunda vía(ruta) a través 10.0.34.4, el router remoto nos esta enviando una distancia notificada de 1792
y cuando el router actual añade su propio costo de la conexión hasta lo que sería llegar al futuro router sucesor, la distancia factible se convierte en 4352.

3072 está “más cerca” (es decir, inferior) a 4352,por eso 3072 es nombrara como ruta sucesor.
Pero ya que la distancia notificada el segundo enlace es 1792, y 1792 es menor que 3072, al router se convierte en un sucesor factible (recuerde, la comparación se anuncia la distancia frente a la distancia es posible)

De la segunda vía a través 10.0.34.4, el router remoto es la publicidad de una distancia de 1792, y cuando el router actual añade su propio costo de la conexión a esto, la distancia factible se convierte en 4352. 3072 está “más cerca” (es decir, inferiores) a 4352,por lo que se nombrara como sucesor factible se convierte en la ruta del sucesor.

Pero ya que la distancia notificada del segundo enlace es 1792, y 1792 es menor que 3072, la ruta se convierte en sucesor factible (recuerde, la comparación es distancia notificada frente a la distancia factible.

Pudiera suceder otro caso en el que la distancia notificada de la segunda vía fuese, digamos, 4092(es un ejemplo no el caso expuesto) en lugar de 1792, luego una notificación de 4092 es mayor que la distancia factible (FD) de 3072,por lo que no se nombrara como sucesor factible, no va a calificar como una ruta de sucesor factible.

En resumen con referencia al ejemplo:
Digamos que tenemos dos rutas. Dos rutas diferentes, ambas a 100 de distancia del router en el que estas.

Primera ruta tiene AD de 200. 200 + 100 = 300 FD.

Segunda ruta tiene AD de 250. 250 + 100 = 350 FD.

La primera ruta se convierte en el sucesor (menor FD – 300).
La segunda vía puede convertirse en un sucesor factible, ya que su AD (250) es menor que el DF (300) del sucesor.

La segunda vía no se convierta en el sucesor, ya que todavía tiene un alto FD.

RIP y TRIGGERED update

Hola a todos los que habéis preguntado por RIP y sus triggered y a los que no también, al parecer quedan muchas dudas en el CCNA sobre este tema.
Me estáis preguntando por correo que al configurar RIP versión 1, cuando se produce un cambio en la topología que vosotros forzais con un Shutdown, no os lanza los trigger y queréis saber como podéis hacer para activarlos, ya que en la documentación hace mención a que pueden surgir si se produce un evento antes de que lanzar las actualizaciones de RIP que por defecto están a 30segundos.

Pues bien, en RIP versión 1 no se puede.

En el RFC 1058: no dice que RIPv1 no soporta los triggered update.

En Rip versión 2 debéis de usar el comando estando dentro de router RIP: IP RIP TRIGGERED

VLAN NATIVA – SWITCH CISCO – ENLACE DE DATOS

VLAN Nativa.- una VLAN nativa está asiganada a un puerto troncal 802.1Q, un puerto de enlace troncal 802.1Q admite el tráfico que llega de una VLAN y también el que no llega de las VLAN’s, la VLAN nativa sirve como un identificador común en extremos opuestos de un elace troncal, es aconsejable no utilizar la VLAN1 como la VLAN Nativa.

VLAN de administración.- Es cualquier vlan que el administrador configura para acceder a la administración de un switch, la VLAN1 sirve por defecto como la VLAN de administración si es que no se define otra VLAN para que funcione como la VLAN de Administración, siendo recomendable cambiarla, por seguridad.

Supongamos que estamos en Ethernet, con varios Switches en un mismo dominio, Vlans y 802.1Q operando.
Sabemos y tenemos claro el concepto de vlan nativa, sabiendo que esta diseñada para permitir a los switches la capacidad de reenviar al menos tráfico de una vlan, como el ARP,el STP, …, en definitiva tráfico de control.

Pero no sabemos del todo bien el funcionamiento del VLAN Tagging.

Los switch añaden un tag con su VLAN ID (VID) para todos los paquetes entrantes al SW. Por ejemplo un Switch1 añade un “tag” con su VID (VLAN ID) para todas las tramas entrantes!!!

Si esas tramas deben pasar por “otros switches” intermedios (Sw2-Sw3…) para llegar al destino, NO se modifica el VID, como por ejemplo se hace en el switching de ATM, ahí sí que se modifican los VC que sería el equivalente a los VID de las VLAN.

El Switch Final (llamadoSWX) en su salida hacia un PC, elimina TODOS los tags en TODOS sus paquetes salientes y hace la entrega de la trama correspondiente al pc de turno, por poner un ejemplo de entrega.

No parece haber problema, puesto que todos los datagramas llevarán un tag, pero que pasa si un switch recibe un datagrama sin etiquetar?
Y si un switch no 802.1q recibe una trama etiquetada o un paquete 802.1q?

Para conocer la respuesta debemos saber que para poder configurar un enlace troncal debemos tener una relación de la vlan NATIVA en cada extremo del enlace.
Si tenemos en ambos extremos vlan distintas como nativas 10 y 11 respectivamente, no va haber conectividad entre ambas, estamos en un enlace en modo TRUNK o troncal, por lo tanto siempre tiene que haber relación entre ambos extremos cada vez que se use una unión entre un SW(x) y otro SW(y).

¿Si Switch1 envía una trama SIN TAG?
El propósito de la VLAN nativa es permitir que pasen tramas SIN ETIQUETA, pero que no estén etiquetadas no quiere decir que no tengan VID, además pretendemos que pasen las tramas por el enlace troncal, no por cualquier otro sitio.Estas tramas sin etiquetar si que pasarían, técnicamente hablando.

Cada uno de los puertos del switch tiene una “cosa” que se llama PVID, es el Port VID.
Hay que saber que cuando se usa 802.1q, a cada puerto físico que hay en el Switch se le asigna un PVID IGUAL al de la VID NATIVA. (saber esto es importantísimo y sobre todo no olvidarnos de que estamos hablando de cuando usamos 802.1q)
Y actua de la siguiente manera:
1)Cuando un puerto recibe una trama etiquetada, la respeta, lleva el PVID de la VLAN nativa y el VID de la Vlan correspondiente.
2)Cuando un puerto recibe una trama sin etiqueta, se considera el PVID como etiqueta y este adquiere el valor a efectos de etiqueta o VLAN ID (VID) y al ser este marcado como nativo (como deciamos anteriormente) se considera trafico nativo por decirlo de alguna manera y pasa como si fuera esta vlan nativa atraves del troncal.

Otro caso o duda que nos pueda surgir:
Cuando un puerto físico del switch que no es 802.1q o un switch al que le llega una trama 802.1q recibe un datagrama 802.1q (con tag implícito o sin el) la etiqueta es ignorada y el paquete es conmutado como una trama estándar.

Por lo tanto por un enlace troncal el tráfico STP, ARP, etc va marcado con el VID de la vlan nativa, pero el tráfico que va a pasar por el enlace troncal proveniente de equipos que no pertenecen a ninguna VLAN, pasan tambien por el enlace troncal sin etiquetar realmente, pero a efector internos van con el PVID al valor de la Vlan Nativa y por lo tanto como si fueran esta. Si no hay 802.1q iran como estandar pero entendiendo siempre que es porque ignoran por completo la etiqueta, lo que no quiere decir que la eliminen.

Escribir en este post y os intentaremos solucionar las dudas.
Agradecimientos a Vic_Thor que me ha sacado de alguna duda que la propia documentación de CCNA no lo hacía, incluso la de CCNP deja algun agujero abierto a dudas.

Switchport port-security (en puertos troncales)

Algunos preguntáis si se pueden configurar puertos toncales,la respuesta es si.
Si podemos configurar puertos troncales.

Switch(config)# int fa0/24
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport port-security
Switch(config-if)# switchport port-security maximum 5
Switch(config-if)# switchport port-security mac-address sticky

•Port security puede ser solo configurado en modo de puerto de acceso estatico o puerto troncal. Un secure port no puede ser de acceso dinámico.

•Un secure port o puerto seguro, no puede ser un puerto destinado a switched Port Analyzer (SPAN).

•Un secure port no puede pertenecer a Fast EtherChannel o a un grupo de puerto Gigabit EtherChannel.

Las VLAN de voz solo soportan puertos de acceso no puertos en modo troncal, OJO a pesar de que la configuración se permite.

•Cuando activas la seguridad en el puerto en una interfaz que también está configurado con una VLAN de voz, hay que configurar dos como el máximo permitido de direcciones seguras en el puerto.
Cuando el puerto esta conectado a un telefono Ip de Cisco, el teléfono IP requiere una dirección MAC.

La dirección del telefono Ip de cisco es aprendida en la Vlan de voz, pero no es aprendida en la VLAN de acceso.
Si conectas un PC al teléfono IP de Cisco, no se necesita ninguna MAC más. Pero si conectamos más de un PC al telefono IP, debemos configurar suficientes direcciones seguras que permitan una para cada PC y otra más para teléfono, que no se nos olvide este.

•Cuando introduces el máximo número de direcciones seguras para un interface y el nuevo valor es mas grande que el anterior este se sobrescribe y se elimina el valor anterior. Si por el contrario el nuevo valor es menor pero el número configurado de direcciones seguras es mayor el comando será rechazado.

Tutorial como crear una actividad con Packet Tracer

Os dejo un tutorial de como crear actividades con el Packet Tracer de Cisco.
Esta realizado por Guerrero .


Muy valido para diseñar nuestros ejercicios.

Creación de sesión multiusuario con Packet Tracer de Cisco 5.1

Con packet tracer podemos conectar varios usuarios en diferentes equipos, es decir podemos trabajar unos con otros, conectando diferentes redes, para aprender en clase es bastante ideal ya que tenemos que colaborar unos con otros.
Os dejo un enlace de como se hace la parte de la conexión, la topología ya es cosa vuestra.
Como está en ingles igual os cuesta un poco pero se entiende bien visualmente sin falta de audio.
Esta realizado por un instructor de Cisco (gstMrO–> John Owens) y agradecemos que comparta el video.

Y en Español y más completo, creado por Guerrero formador de CISCO:

Si tenéis cualquier duda podéis escribirnos preguntando a donde siempre:
consultas@cmdsistemas.es

Pedimos disculpas a la futura EX MINISTRA ESPAÑOLA de CULTURA y a su Ley Sinde, por poner enlaces didácticos y de aprendizaje a otros sitios WEB.
Saludos.

Protocolo SLARP , se me configuran solos los serial ?

Es un protocolo que funciona parecido a un DHCP en lo que se refiere a resultados, por lo que hemos podido comprobar, en las últimas IOS de CISCO y sin configurar ambos interfaces SERIAL, si tenemos el del extremo contrario con una IP asignada, el que esta sin configuración aprende la IP siguiente, eso siempre se produce en conexiones SERIAL y con Encapsulación HDLC que como sabeis es propietaria de CISCO y es con la que vienen por defecto configurados, así que no es de extrañar que en una conexión reciente en laboratorio con unos de los router nuevecito o después de un erase y reload nos aparezca sola la ip del serial. Eso de sola …
No hay documentación en un CCNA de como desactivarla.
Podemos usar para desactivar SLARP el comando no service config. , OJO en ambos lados es decir en el seria de Router1 y en el Serial de Router2
Si esto no funciona podemos desactivar el interface level escribiendo: no ip address slarp retry
OJO, esta última opción creo que con Packet Tracer no funciona siempre refiriendonos a la versión actual.

Desactivamos SLARP en R1, una vez desactivado aún lo seguimos viendo como UP, hasta que lo desactivan en R2
R1#show ip interface brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES unset administratively down down
FastEthernet0/1 unassigned YES manual up up
Serial0/1/0 192.168.5.2 YES SLARP up up
ATM0/2/0 unassigned YES unset administratively down down

Después de desactivarlo en R2:
R1#show ip interface brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES unset administratively down down
FastEthernet0/1 unassigned YES manual up up
Serial0/1/0 unassigned NO SLARP up up
ATM0/2/0 unassigned YES unset administratively down down

R2#show ip interface brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 192.168.2.1 YES NVRAM up down
FastEthernet0/1 unassigned YES NVRAM administratively down down
ATM0/1/0 unassigned YES NVRAM administratively down down
Serial0/3/0 192.168.5.1 YES NVRAM up up
Loopback0 192.168.0.10 YES NVRAM up up
Loopback1 172.16.10.1 YES NVRAM administratively down down
Loopback2 172.16.11.1 YES NVRAM administratively down down

Capturas proporcionadas por Cesar, Faustino y Raúl.

Podéis buscar la definición del protocolo por ejemplo aquí: http://www.worldlingo.com/ma/enwiki/es/Cisco_HDLC#SLARP
¡Ah! y no olviden vitaminarse y supermineralizarse