Los 3 Principios de enrutamiento

En algunas secciones de este curso haremos referencia a tres principios relacionados con las tablas de enrutamiento que lo ayudarán a comprender, configurar y solucionar problemas de enrutamiento.

Estos principios se extraen del libro de Alex Zinin, Cisco IP Routing.

1. Cada router toma su decisión en forma independiente, según la información de su propia tabla de enrutamiento.

2. El hecho de que un router tenga cierta información en su tabla de enrutamiento no significa que los otros routers tengan la misma información.

3. La información de enrutamiento sobre una ruta desde una red a otra no suministra información de enrutamiento sobre la ruta inversa o de regreso.

¿Cuál es el efecto de estos principios? Observemos el ejemplo en la figura.

 

 
1. Después de tomar su decisión de enrutamiento, el router R1 envía al router R2 el paquete destinado a la PC2. R1 sólo conoce la información de su propia tabla de enrutamiento, que indica que el router R2 es el router del siguiente salto. R1 no sabe si R2 efectivamente tiene o no una ruta hacia la red de destino.

2. Es responsabilidad del administrador de red asegurarse de que todos los routers bajo su control tengan información de enrutamiento completa y precisa de manera tal que los paquetes puedan enviarse entre cualquiera de las dos redes. Esto puede lograrse mediante el uso de rutas estáticas, un protocolo de enrutamiento dinámico o una combinación de ambas opciones.

3. El router R2 logró enviar el paquete hacia la red de destino de la PC2. Sin embargo, R2 descartó el paquete desde la PC2 a la PC1. Aunque R2 tiene información en su tabla de enrutamiento sobre la red de destino de la PC2, no sabemos si tiene la información para la ruta de regreso hacia la red de la PC1.

Enrutamiento asimétrico

Dado que los routers no necesariamente tienen la misma información en sus tablas de enrutamiento, los paquetes pueden recorrer la red en un sentido, utilizando una ruta, y regresar por otra ruta. Esto se denomina enrutamiento asimétrico. El enrutamiento asimétrico es más común en Internet, que usa el protocolo de enrutamiento BGP, que en la mayoría de las redes internas.

Este ejemplo implica que cuando se diseña una red y se resuelven problemas en ella, el administrador de red debe verificar la siguiente información de enrutamiento:

¿Existe una ruta de origen a destino que esté disponible en ambos sentidos?

¿Es la ruta que se tomó en ambos sentidos la misma ruta?  (El enrutamiento asimétrico no es inusual, pero a veces puede causar otros problemas.)

Tomado de: https://cerebrote.wordpress.com/ con algunos aportes del editor del blog.

DHCP Relay en Cisco IOS

Por Oscar Gerometta

Dado que el inicio de la operación del protocolo DHCP se realiza sin contar una dirección de origen y utilizando broadcast como destino, las solicitudes (el discovery generado por el cliente DHCP) no son de suyo ruteables hacias otras subredes. 

De aquí que en principio el protocolo DHCP supone que el servidor y el cliente están conectados a la misma red o subred.

Cuando se desea utilizar servidores DHCP que se encuentran alojados en una red o subred diferente se puede utilizar un agente DHCP relay. 

Un DHCP relay es un dispositivo que recibe las solicitudes de los clientes en formato de broadcast y las reenvía como unicast a la dirección del servidor DHCP.

• DHCP Discovery.
  El cliente DHCP envía una solicitud en formato de broadcast.
• DHCP Relay.
  El agente DHCP relay que recibe el broadcast lo retransmite a uno o más servidores utilizando unicast e incluyendo su dirección como dirección de gateway.
• DHCP Offer.
  El servidor utiliza la dirección de gateway que recibe en la solicitud para determinar a qué subred pertenece el host solicitante y asigna entonces una configuración que corresponda esa subred.
  El servidor DHCP reserva una dirección IP para el cliente y envía la respuesta en un paquete unicast a la dirección del gateway, que luego lo reenvía a la red local.
• DHCP Request.
  El cliente responde en formato broadcast realizando una solicitud explícita de la configuración ofrecida por el servidor.
  El agente DHCP relay interviene nuevamente reenviando la información al servidor DHCP.
• DHCP Acknowledgement.
  Se envía un paquete en formato unicast al DHCP relay que luego lo reenvía al cliente, incluyendo la información de configuración que el cliente ha aceptado.
  Esto completa el proceso.

En estos casos el servidor DHCP responde al DHCP relay y éste se ocupa de reenviarlo al cliente DHCP.

Configuración de un router IOS como DHCP relay

El servicio de DHCP relay se habilita en la interfaz de capa 3 más cercana al cliente DHCP (usualmente, la que opera como default-gateway de la red o subred).

En la configuración es necesario especificar la dirección IP de uno o más servidores DHCP que han de responder las solicitudes. 

Si hay varios servidores DHCP en una misma subred se puede especificar directamente la dirección reservada de subred, de este modo responderá cualquiera de los servidores DHCP de esa subred.

Router#configure terminal
Router(config)#interface GigabitEthernet 0/0
Router(config-if)#ip helper-address [IP servidor DHCP]

Documentación de referencia:

• Configuring the Cisco IOS DHCP Relay Agent

Fuente: Mis libros de Networking

Cisco ASA - Como configurar enrutamiento entre 2 VLAN internas

Problema inicial

Un cliente solicitó la siguiente configuración. Se tenia un DMZ configurado en un Cisco ASA 5505 y ya se habían configurado otras VLANs para diferentes propósitos, por ejemplo el acceso a Internet para visitantes. Pero el cliente necesitaba una VLAN secundaria configurada para teléfonos IP. Adicionalmente se tenia que enrutar tráfico entre las dos VLAN internas. Aquí está el escenario que se usará en este caso:

Solución

Primero es importante comprender que el ASA es un Firewall, no un Router!. Una mejor solución para este caso sería tener un Router detrás del Firewall o un Switch de capa 3.

En este caso el ASA debe tener una licencia Security Plus para poder hacer esto. También es importante mencionar que los comandos van a ser diferentes si es que el Firewall está corriendo una versión de sistema operativo anterior al 8.3. Si este fuera el caso consulta aquí.

Como configurar enrutamiento VLAN en un ASA 5505

1. Conéctese al Firewall, ingrese al modo enable y luego al modo de configuración global

User Access Verification
Password:

Type help or '?' for a list of available commands. 

Petes-ASA> enable
Password: ********
Petes-ASA# configure terminal
Petes-ASA(config)#

2. Como se muestra en el diagrama se tienen 3 VLANs. La VLAN 0 es Outside y va a estar conectada en Ethernet 0/0. La VLAN 1 es Inside y va a estar conectada a Ethernet 0/1. La VLAN 112 es para los teléfonos y va a estar conectada a Ethernet 0/2. A continuación se configuran las direcciones IP, se añaden las VLANs a las interfaces físicas.

Nota: No es necesario asociar la VLAN 1 a  Ethernet 0/1 porque por defecto todos los puertos están asociados a la VLAN 1.

Petes-ASA(config)# interface Ethernet0/0
Petes-ASA(config-if)# switchport access vlan 2
Petes-ASA(config-if)# interface Ethernet0/2
Petes-ASA(config-if)# switchport access vlan 112
Petes-ASA(config-if)# interface Vlan1
Petes-ASA(config-if)# nameif inside
Petes-ASA(config-if)# security-level 100
Petes-ASA(config-if)# ip address 192.168.12.254 255.255.255.0
Petes-ASA(config-if)# interface Vlan2
Petes-ASA(config-if)# nameif outside
Petes-ASA(config-if)# security-level 0
Petes-ASA(config-if)# ip address 123.123.123.123 255.255.255.248
Petes-ASA(config-if)# interface Vlan112
Petes-ASA(config-if)# nameif PHONE_VLAN_112
Petes-ASA(config-if)# security-level 100
Petes-ASA(config-if)# ip address 192.168.112.254 255.255.255.0

3.Para hacer que el tráfico pueda dirigirse a Internet necesitamos especificar una ruta hacia el Router externo

Petes-ASA(config)# route outside 0.0.0.0 0.0.0.0 123.123.123.124

4. Active el 'Hair Pinning' (la opción para que se pueda enrutar un paquete hacia la misma interface por la que llegó) y permita el paso de trafico entre interfaces.

Petes-ASA(config)# same-security-traffic permit inter-interface
Petes-ASA(config)# same-security-traffic permit intra-interface

5. En este siguiente paso, si no configuraste ningún access-lists entonces puedes saltarlo debido a que el trafico va a ser permitido desde una interface con mayor seguridad (la Inside y la de telefonos) hacia una de menor seguridad (la interface Outside). Para este ejemplo se creará un ACL de todas maneras.

Petes-ASA(config)# access-list VLAN112_outbound extended permit ip 192.168.112.0 255.255.255.0 any
Petes-ASA(config)# access-list outbound extended permit ip 192.168.12.0 255.255.255.0 any
Petes-ASA(config)# access-group outbound in interface inside
Petes-ASA(config)# access-group VLAN112_outbound in interface PHONE_VLAN_112

 
6. Ahora configuramos el NAT dinámico de manera que todo el tráfico que viene de las VLAN Inside y de la VLAN de telefonía pueda ser nateado hacia la dirección IP pública.

Petes-ASA(config)# object network obj_any
Petes-ASA(config-network-object)# subnet 0.0.0.0 0.0.0.0
Petes-ASA(config-network-object)# nat (inside,outside) dynamic interface
Petes-ASA(config-network-object)# object network obj_any-01
Petes-ASA(config-network-object)# subnet 0.0.0.0 0.0.0.0
Petes-ASA(config-network-object)# nat (PHONE_VLAN_112,outside) dynamic interface

7.  Ahora configuramos una NAT estática para que el trafico que viaja entre la VLAN Inside y la VLAN de telefonía no sea nateado.

Petes-ASA(config)# object network obj-192.168.12.0
Petes-ASA(config-network-object)# subnet 192.168.12.0 255.255.255.0
Petes-ASA(config-network-object)# nat (inside,PHONE_VLAN_112) static 192.168.112.0
Petes-ASA(config-network-object)# object network obj-192.168.112.0
Petes-ASA(config-network-object)# subnet 192.168.112.0 255.255.255.0
Petes-ASA(config-network-object)# nat (PHONE_VLAN_112,inside) static 192.168.112.0

8. Habilitamos enrutamiento y configuramos el MTU para las tres VLANs

Petes-ASA(config)# router eigrp 500
Petes-ASA(config-router)# network 192.168.12.0 255.255.255.0
Petes-ASA(config-router)# network 192.168.112.0 255.255.255.0
Petes-ASA(config-router)# passive-interface outside
Petes-ASA(config-router)# exit
Petes-ASA(config)# mtu inside 1500
Petes-ASA(config)# mtu outside 1500
Petes-ASA(config)# mtu PHONE_VLAN_112 1500

9. Guardamos los cambios y procedemos a hacer las pruebas

Petes-ASA(config)# write memory
 
Building configuration...
Cryptochecksum: aab5e5a2 c707770d f7350728 d9ac34de
[OK]
 
Petes-ASA(config)#

Aqui está la configuración completa para "Copiar y Pegar":

interface Ethernet0/0
switchport access vlan 2
!
interface Ethernet0/1
!
interface Ethernet0/2
switchport access vlan 112
!
interface Vlan1
nameif inside
security-level 100
ip address 192.168.12.254 255.255.255.0
!
interface Vlan2
nameif outside
security-level 0
ip address 123.123.123.123 255.255.255.248
!
interface Vlan112
nameif PHONE_VLAN_112
security-level 100
ip address 192.168.112.254 255.255.255.0
!
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface
!
access-list VLAN112_outbound extended permit ip 192.168.112.0 255.255.255.0 any
access-list outbound extended permit ip 192.168.12.0 255.255.255.0 any
!
object network obj-192.168.12.0
subnet 192.168.12.0 255.255.255.0
nat (inside,PHONE_VLAN_112) static 192.168.112.0
object network obj-192.168.112.0
subnet 192.168.112.0 255.255.255.0
nat (PHONE_VLAN_112,inside) static 192.168.112.0
object network obj_any
subnet 0.0.0.0 0.0.0.0
nat (inside,outside) dynamic interface
object network obj_any-01
subnet 0.0.0.0 0.0.0.0
nat (PHONE_VLAN_112,outside) dynamic interface
!
mtu inside 1500
mtu outside 1500
mtu PHONE_VLAN_112 1500
!
access-group outbound in interface inside
access-group VLAN112_outbound in interface PHONE_VLAN_112
!
router eigrp 500
network 192.168.12.0 255.255.255.0
network 192.168.112.0 255.255.255.0
passive-interface outside
!
route outside 0.0.0.0 0.0.0.0 123.123.123.124

Fuente: http://www.petenetlive.com/ con algunas traducciones y adecuaciones del editor del BLOG

Un sueño hecho realidad: sea socio de Cisco collaboration

Pablo Marrone |

¿Alguna vez soñó con tener una línea directa con los grupos de Cisco que diseñan productos y soluciones? 

¿O tal vez poder compartir sus ideas e inquietudes con colegas y usuarios de Colaboración de Cisco? 

¿O tener acceso exclusivo y anticipado a los nuevos productos, o conversaciones con los expertos, o incluso influenciar la dirección de desarrollo?

Este es el momento en que los sueños se hacen realidad. 

El programa CCP (Customer Connection Program) provee todo lo anterior y mucho más. La membresía es gratuita y abierta a organizaciones que usan las soluciones de Colaboración de Cisco, incluyendo Telepresencia, Comunicaciones Unificadas, Webex, Jabber y Customer Collaboration.

Influencie la dirección de los desarrollos

• Únase a los grupos de asesores, quienes trabajan con los desarrolladores, analizando los conceptos de una solución, priorizando el diseño y la estrategia
• Tenga una línea directa donde podrá sugerir mejoras en los productos y soluciones
• Participe en exclusivos programas de prueba y adopción temprana

Manténganse informado con adelantos exclusivos

• Manténgase al día en cuanto a las novedades de productos, a través de sesiones de roadmap exclusivas
• Complemente sus conocimientos con sesiones exclusivas de gran profundidad técnica
• Conozca las novedades de los productos ANTES de que sean anunciadas

Comparta con sus colegas y acceda a valiosos recursos profesionales

• Aprenda de sus colegas, compartiendo las mejores prácticas. Discuta estrategias de proyectos con otros miembros del CCP
• Obtenga respuestas casi inmediatasde parte de los gerentes de producto de Cisco y sus ingenieros; así como tambien de los usuarios y partners expertos
• Intercambie información con otros miembros del CCP y con los ejecutivos de Cisco durante Cisco Live, donde se desarrollan eventos exclusivos , sesiones NDA y talleres de trabajo

Únase al CCP ahora. Es sencillo, inmediato y gratuito. Comience a aprovechar los beneficios cuanto antes.

¿Quiere discutir más ideas y conocer más detalles? Baje la aplicación “Call Cisco” para IOS o Android, y comuníquese con nosotros.

Fuente: Blog Cisco Latinoamérica

Por qué América Latina debe aprovechar Internet de Todo

Internet de Todo (IoT) -un ‘sistema nervioso’ global de redes que conectan personas, procesos, datos y cosas- ofrece posibilidades de transformación para la región, con consecuencias importantes en desarrollo, empleo y competitividad.
 
Diario TI 09/05/15 8:50:45
América Latina enfrenta importantes retos en desarrollo y competitividad, pero a la vez tiene una gran oportunidad de repensar su futuro y avanzar varios pasos hacia adelante. La siguiente fase de Internet, Internet de Todo (IoT) -un ‘sistema nervioso’ global de redes que conectan personas, procesos, datos y cosas- ofrece posibilidades de transformación para la región, con consecuencias importantes en desarrollo, empleo y competitividad.

Internet de Todo hace las conexiones más relevantes y valiosas que antes, convirtiendo la información en acciones que crean nuevas capacidades, experiencias más enriquecedoras y oportunidades económicas sin precedentes para los negocios, las personas y los países.

Cerca del 99% de los objetos físicos que algún día pueden ser parte del Internet de Todo, están aún desconectados. Con sólo aproximadamente 10 mil millones del 1.5 billones de cosas actualmente conectadas, hay un gran potencial para conectar lo desconectado. Cisco predice que 19 millones de millones de dólares de valor potencial se generará en la próxima década, impulsado por la conexión de personas con personas, personas con máquinas, máquinas con máquinas, etc, todo esto a través del Internet de Todo.

El valor potencial puede ser creado o será migrado a través de compañías del sector público y privado y de las industrias que aprovechen el Internet de Todo en la próxima década. De estos, 860 mil millones corresponden a América Latina. Si el Internet de Todo no es implementado, esta suma se dejará sobre la mesa. El reto es claro: la digitalización de países, ciudades, empresas y organizaciones es una oportunidad que América Latina no puede desaprovechar, una oportunidad sin precedentes para avanzar en productividad y competitividad.

Esta región, un mercado de más de 600 millones de personas, cuenta con sólidos fundamentos macroeconómicos. Sin embargo, los indicadores económicos y sociales destacan la necesidad de aumentar la productividad de la región para mantener su impulso económico y social. La disminución de la velocidad de crecimiento de la economía mundial y el cambio de los patrones de inversión combinados con retos en educación, salud, infraestructura y tecnología son temas que hay que resolver.

El principal reto a futuro en la región no es pues la inestabilidad económica sino el bajo crecimiento, que podría estar en tasas de 1-2% anuales, el cual no es suficiente para las grandes expectativas de la población, en especial la naciente clase media. La única manera de crecer a una tasa mayor es aumentando la productividad: mejorando la educación, aumentando la innovación, mejorando la infraestructura y logrando una mayor competitividad. Dentro de este contexto, la digitalización de la región y en especial Internet de Todo, jugarán un papel determinante.

Líderes de gobierno y de ciudades tienen visiones muy claras y ambiciosas en materia de agendas digitales. Sin embargo, estas contrastan con la realidad. Según el reciente Global Information Technology Report, América Latina y el Caribe, aunque han avanzado en el entorno de las TICs, todavía están muy abajo en el ranking. En el Networked Readiness Index, una medida de 143 países que se basa en el entorno, preparación, uso e impacto de las TICs, el primer país de la región en el ranking es Chile, ocupando la posición 38 y los demás le siguen con grandes diferencias. Lo que evidencia que la región esta aún muy por debajo en conectividad en comparación con otros países y regiones del mundo.

La penetración de banda ancha de América Latina está por debajo del promedio del mundo. Lo cual es muy bajo y puede ser un limitante para la adopción de Internet de Todo. Los países de la región deben implementar políticas para impulsar el crecimiento de las conexiones de banda ancha. Creemos que este es uno de los factores prioritarios para aumentar la productividad y competitividad de nuestras economías a todos los niveles y así mejorar la calidad de vida de nuestros ciudadanos.

Invito a los líderes de la región a considerar las posibilidades que ofrece Internet de Todo, no solamente para los gobiernos sino también para el sector privado. El primer paso es aumentar la disponibilidad y adopción de la banda ancha, en particular mediante políticas que permitan alcanzar el acceso universal, aumentar la asequibilidad, incrementar las competencias digitales y cerrar las brechas de género. Adicionalmente, la región debe duplicar sus inversiones en infraestructura en general y en tecnología en particular para aumentar la productividad. Internet de Todo exige también un cambio de mentalidad y un afán por innovar.

Estas son medidas que deben tomarse para asegurar que la región puede disfrutar las ventajas de la próxima fase de Internet. Los beneficios de Internet de Todo pueden ser varias veces mayores en magnitud en comparación con las etapas anteriores de Internet. La digitalización de la región es una oportunidad que no da espera.

Por Jordi Botifoll, Presidente Cisco América Latina, WEF América Latina, Cancún

Fuente: DiarioTI

Cisco propone simplificación de la nube híbrida y anuncia incorporación de 35 ISVs a Intercloud

Cisco ha anunciado la incorporación de 35 proveedores de software independientes (ISVs, Independent Software Vendors) a su iniciativa Intercloud, la mayor red mundial de Clouds interconectadas que Cisco está construyendo junto con sus partners.
 
Diario TI 11/06/15 8:21:18

Según la empresa, este primer grupo de ISVs acelerará la creación de innovadores servicios Cloud a través de tres áreas clave -plataformas de desarrollo de próxima generación, Big Data y analytics y servicios Cloud para Internet of Everything (IoE)-, con el fin último de ayudar a las organizaciones a capturar las oportunidades que resultan del IoE.

Desde San Diego, donde hoy concluye el evento Cisco Live, la compañía informa además haber optimizado su solución Cisco Intercloud Fabric con nuevas funcionalidades de seguridad, gestión entre nubes y soporte de hipervisores adicionales. Estas innovaciones eliminan aún más la complejidad del Cloud híbrido facilitando el movimiento flexible de cargas de trabajo y manteniendo las políticas de red y seguridad a través de entornos Cloud públicos y privados.

Cisco Intercloud Fabric cuenta ya con más de 100 clientes y 65 partners a escala global. Diez partners Intercloud -Cirrity, Datalink, iland, Long View, Peak 10, Presidio, QTS, Quest, Sungard Availability Services y Virtustream- anunciaron ayer en Cisco Live nuevos servicios Cloud híbridos construidos sobre Cisco Intercloud Fabric, mientras KPIT Technologies, Holtzbrinck Publishing y The Salvation Army están utilizando la solución para implementar un modelo operativo único en entornos de desarrollo/test, producción y calidad.

Servicios Cloud para el IoE

Cisco y sus partners ofrecerán a las organizaciones servicios y aplicaciones Cloud de próxima generación a través de Cisco Intercloud Marketplace, un mercado global centrado en los partners que Cisco prevé abrir este otoño. Los nuevos servicios de los ISVs anunciados en Cisco Live se centrarán en:

- Plataformas de desarrollo.
Los desarrolladores están pasando de apoyarse en el Cloud para entornos de desarrollo/test a crear y distribuir aplicaciones en producción. Cisco ha anunciado su colaboración con distintas compañías de desarrollo y distribución de aplicaciones comerciales como Apprenda, Active State y Docker para que sus innovadores entornos de desarrollo Cloud formen parte de Intercloud. Cisco también está ampliando su participación en las principales comunidades de desarrollo open source como Cloud Foundry, OpenShift y Kubernetes, además de estar construyendo una suite de herramientas integradas para facilitar a los desarrolladores el diseño de micro-servicios basados en contenedor. Igualmente, la comunidad de desarrollo de Cisco puede acceder mediante la iniciativa DevNet a las últimas APIs y micro-servicios de las tecnologías Cloud, IoE y Big Data de Cisco que se ofrecen a través de Intercloud.

- Big Data y Analytics.
Las organizaciones demandan nuevas fórmulas para gestionar el crecimiento exponencial de datos y obtener capacidad de análisis en tiempo real. Para responder a esta necesidad, Cisco colabora con proveedores líderes de soluciones de Big Data como MapR, Hortonworks, Cloudera y la comunidad Apache Hadoop. Al trabajar con estos partners, Cisco extenderá sus soluciones Hadoop on-premise al Cloud y proporcionará una implementación híbrida de soluciones Big Data empresariales, facilitando a los clientes finales el mantenimiento de las mismas políticas, control y seguridad en sus implementaciones de Big Data, así como una gran flexibilidad y una escalabilidad virtualmente ‘ilimitada’.

- Servicios Cloud para el IoE.
Como complemento a las plataformas de desarrollo y a las funcionalidades de Big Data y analítica necesarias para el IoE, Cisco proporcionará APIs a la comunidad de desarrollo para garantizar las funcionalidades de control, rendimiento y seguridad desde el data center hasta el dispositivo, algo crítico cuando se gestionan miles de millones de conexiones. Cisco también ofrecerá a través de Intercloud servicios IoE clave como Virtualización de Datos, Energywise (gestión energética a través de la red) y Cisco Services Exchange Platform. Con este modelo abierto en torno a las APIs y los micro-servicios, desarrolladores y organizaciones tienen la posibilidad de integrar estas funcionalidades críticas en sus propios servicios y aplicaciones.

En este primer grupo de nuevos desarrolladores de aplicaciones y partners de servicios de Cisco Intercloud Marketplace se encuentran ActiveState, Apprendra, Basho, Chef, Citrix, CliQr, Cloud Enabled, CloudBerry Lab, Cloudera, Cloudify, CloudLink, Couchbase, CTERA, Datadog, Davra Networks, Desktopsites, Druva, Egnyte, ElasticBox, F5 Networks, Hortonworks, Informatica, MapR, MongoDB, Moonwalk, Nirmata, Panzura, Pegasystems, Platfora, Sanovi, ScaleArc, Skytree, StoAmigo Talisen Technologies y Zenoss.

Simplificación de la nube híbrida

A medida que las organizaciones conectan sus nubes privadas con las nubes públicas, se encuentran con una gran complejidad generada por los distintos entornos heterogéneos formados por diferentes infraestructuras, hipervisores, interfaces de usuario y requisitos de seguridad.

“Con Cisco Intercloud Fabric, las organizaciones pueden eliminar esa complejidad manteniendo un mismo modelo operativo -así como las políticas de red y seguridad- y obteniendo un movimiento flexible de las cargas de trabajo a través de entornos híbridos, con independencia del hypervisor elegido y todo desde una única consola de gestión”, comenta Cisco, agregando que las nuevas funcionalidades de Cisco Intercloud Fabric simplifican aún más la adopción del Cloud híbrido soportando la gran mayoría de nubes públicas e hipervisores en tres áreas clave como seguridad, control y flexibilidad.

Fuente: DiarioTI

Como configurar un Port Channel

Es importante conocer que el origen del port-channel está orientado hacia la optimización de los Anchos de Bandas de dos equipos que conectan a través de dos o más puertos de datos, en pro de utilizar toda la capacidad de estos puertos en una sola conexión virtual. Esta configuración puede estar enfocada a interconexiones de equipos en una LAN ó enlaces de proveedores de servicios (Principal - Backup).

Configuración de un Port-Channel con Puertos en Modo Access 

Los Port-Channel tienen que ser creados en la misma VLAN o en su defecto establecer un puerto Troncal (Se explicará más adelante).

Se crea el port-channel o interfaz virtual y se asocian los puertos que conformarán la interfaz PO.

Configurando SW 1:

sw1#conf term

sw1(config)#int port-channel 1

sw1(config-if)#switchport

sw1(config-if)#switchport mode access

sw1(config-if)#switchport access Vlan 110

sw1(config-if)#exit

sw1(config)#

 

sw1(config)#int f0/1

sw1(config-if)#switchport

sw1(config-if)#switchport mode access

sw1(config-if)#switchport access Vlan 110

sw1(config-if)#channel-group 1 mode desirable

sw1(config-if)#exit

sw1(config)#

 

sw1(config)#int f0/2

sw1(config-if)#switchport

sw1(config-if)#switchport mode access

sw1(config-if)#switchport access Vlan 110

sw1(config-if)#channel-group 1 mode desirable

sw1(config-if)#exit

sw1(config)#do wr

Configurando SW2:

sw2#conf term

sw2(config)#int port-channel 1

sw2(config-if)#switchport

sw2(config-if)#switchport mode access

sw2(config-if)#switchport access Vlan 110

sw2(config-if)#exit

sw2(config)#

sw2(config)#int f0/1

sw2(config-if)#switchport

sw2(config-if)#switchport mode access

sw2(config-if)#switchport access Vlan 110

sw2(config-if)#channel-group 1 mode auto

sw2(config-if)#exit

sw2(config)#

 

sw2(config)#int f0/2

sw2(config-if)#switchport

sw2(config-if)#switchport mode access

sw2(config-if)#switchport access Vlan 110

sw2(config-if)#channel-group 1 mode auto

sw2(config-if)#exit

sw2(config)#do wr

Con el fin de lograr estabilidad en el port-channel es importante establecer la comunicación del protocolo PAgP basado en los siguientes datos:

• ON: Un ethernet channel útil existe si dos grupos de puertos en MODO ON están conectados entre sí. En vista que en este modo no existe tráfico de negociación de paquetes PAgP.
• AUTO: Este modo PAgP coloca un puerto en estado de negociación pasiva, sólo responde a los paquetes PAgP.
• DESIRABLE:  Este modo PAgP coloca un puerto es colocado en estado de negociación activa, es decir, el puerto inicia el envío de paquetes PAgP a otros puertos LAN.
• PASIVE / ACTIVE:  Este protocolo OPEN coloca los puertos en modo pasivo o en activo para la negociación.

Configuración de un Port-Channel con Puertos en Modo Trunk

Configurando SW 1:

sw1#conf term

sw1(config)#int port-channel 1

sw1(config-if)#switchport

sw1(config-if)#switchport trunk encap dot1q

sw1(config-if)#switchport mode trunk

sw1(config-if)#switchport nonegotiate

sw1(config-if)#switchport trunk allowed vlan vlan-list

sw1(config-if)#exit

sw1(config)#

sw1(config)#int f0/1

sw1(config-if)#switchport

sw1(config-if)#switchport trunk encap dot1q

sw1(config-if)#switchport mode trunk

sw1(config-if)#switchport nonegotiate

sw1(config-if)#channel-group 1 mode desirable

sw1(config-if)#exit

sw1(config)#

sw1(config)#int f0/2

sw1(config-if)#switchport

sw1(config-if)#switchport trunk encap dot1q

sw1(config-if)#switchport mode trunk

sw1(config-if)#switchport nonegotiate

sw1(config-if)#channel-group 1 mode desirable

sw1(config-if)#exit

sw1(config)#do wr

Configurando SW2:

sw2#conf term

sw2(config)#int port-channel 1

sw2(config-if)#switchport

sw2(config-if)#switchport trunk encap dot1q

sw2(config-if)#switchport mode trunk

sw2(config-if)#switchport nonegotiate

sw2(config-if)#switchport trunk allowed vlan vlan-list

sw2(config-if)#exit

sw2(config)#

sw2(config)#int f0/1

sw2(config-if)#switchport

sw2(config-if)#switchport trunk encap dot1q

sw2(config-if)#switchport mode trunk

sw2(config-if)#switchport nonegotiate

sw2(config-if)#channel-group 1 mode auto

sw2(config-if)#exit

sw2(config)#

sw2(config)#int f0/2

sw2(config-if)#switchport

sw2(config-if)#switchport trunk encap dot1q

sw2(config-if)#switchport mode trunk

sw2(config-if)#switchport nonegotiate

sw2(config-if)#channel-group 1 mode auto

sw2(config-if)#exit

sw2(config)#do wr

 

Cuando se establezca el port-channel a través del comando switchport trunk allowed vlan permitirán el trafico de todas la vlan por defecto o especificarán el tráfico de las vlans autorizadas.

Así como tambien; si tienen una NATIVE VLAN contraria a la default es importante que la incluyan en la configuración del port-channel en ambos switches.

OJO:

Los comando nonegotiate y las configuraciones de los channel group en modo desirable y auto son claves para una conexión port virtual estable y que garantizará una comunicación troncal. 

 

Fuente: El cuadernito de Networking

Enrutamiento IP en entornos con VRFs

Por Oscar Gerometta

Cuando implementamos VRFs podemos diferenciar, en principio, 2 redes que están operando e interactuando entre sí:

• La red de servicios que es la que opera brindando conectividad entre extremos distantes. Este es el rol esencial de la red del Proveedor de Servicios clásico.
• La red cliente que es la red dispersa que necesita interconectar puntos remotos a través de la red de servicios. Si bien en la gráfica de más abajo representé una única red cliente para mayor claridad, sobre una red de servicio pueden conectarse múltiples redes cliente diferentes sin que ocurran superposiciones de ningún tipo.

Cada una de estas redes tienen su propio dominio de enrutamiento, completamente independiente. Para que todo esto funcione hay que considerar 3 dominios de enrutamiento diferentes:

• El dominio de enrutamiento de la red cliente que utiliza un protocolo de enrutamiento para gestionar las rutas de la red cliente. Típicamente es un IGP (RIPv2, EIGRP, OSPF), pero también es posible que utilice BGP.
• El dominio de enrutamiento de la red de servicios que utiliza un protocolo de enrutamiento interior para gestionar las rutas de la red de servicios. Típicamente encontramos en este caso OSPF, EIGRP o IS-IS.
• El dominio de enrutamiento BGP de la red de servicios que utiliza un address-family vpnv4  para transportar las rutas de la red cliente a través de la red de servicios.

Para que BGP pueda transportar las rutas de la red cliente es necesario que se redistribuyan las rutas de la red cliente dentro de un address-family asociado a la VRF de la red cliente, del mismo modo que las rutas del address-family luego deben ser redistribuidas dentro de la VRF.

De esta forma, el transporte de rutas de la red cliente sobre la red de servicios puede ser representado de la siguiente manera:

Consecuencias de esto:

• Las rutas de la red cliente solamente se encuentran en la tabla de enrutamiento de las VRFs y los CEs. Nunca se incorporan a la tabla de enrutamiento de la red de servicios (PEs y Ps).
• Las rutas de la red de servicios nunca se mezclan con las rutas de las VRFs.
• Cuando hay múltiples VRFs en un mismo PE, las rutas de cada VRF se mantienen independientemente unas de otras.
• En el router P nunca se encuentran rutas de las redes cliente.

Fuente: http://librosnetworking.blogspot.com/

Password seguro en Interner de las Cosas

Por: 

Beto Garcia

Internet es la conexión pública más grande del mundo. Año trás año ha crecido en capacidades de transmisión y, actualmente, es el medio más utilizado por todo tipo de usuarios para la transmisión de datos públicos y privados.


Hoy, estamos ante una nueva tendencia denominada Internet de las Cosas, cuyo concepto esencial es conectar objetos o sensores capaces de recibir instrucciones y ejecutar acciones dependiendo de su estado. Pero estas nuevas “cosas” aún no cuentan con la inteligencia de un Firewall −para protegerse de intromisiones no deseadas− por ahora solo pueden permitir o denegar su conexión mediante un password.

Por esta razón, debemos tomar conciencia de la importancia de un password no predecible, tomando las precauciones necesarias para que el usuario la resguarde de manera eficaz (una vez generada), y así evite el mal uso de un acceso restringido a equipos sensible en su operación.

¿Y por qué es tan importante?

El Hacking tradicional evolucionó al Social Hacking, donde al entablar una simple conversación o revisar el perfil de una persona X en las redes sociales (una posible víctima) se pueden obtener sus datos privados. De esta manera, con esos datos podrán predecir sus passwords de acceso a perfiles públicos, cuentas bancarias y, por consiguiente, a las “cosas” que tenga controladas a través de Internet.

Por eso, en Cisco nos esforzamos por desarrollar equipos robustos que puedan asegurar conexiones seguras a redes corporativas como VPN’s, y también que puedan detectar la intromisión de virus −tipo malware− cuyo objetivo es extraer información sensible al ámbito público.

Sin embargo, si el atacante se registra con las credenciales de la víctima, estos equipos se vuelven accesibles porque validan esa conexión.

Crear passwords no predecibles

Entonces, mi consejo para que no puedan revelar tus Passwords:

1. No utilices fechas importantes (cumpleaños, aniversario de boda, etc.).
2. No utilices nombres propios (de familiares o amigos directos).
3. No intercales números con nombres propios (0sc4r, M4nu3l, s4m4n7h4).
4. No utilices el nombre de tu mascota.
5. No utilices el nombre de la empresa donde trabajas.

Sin embargo, si ya utilizaste estos datos, te hago las siguientes recomendaciones:

6. Utiliza palabras con más de 8 caracteres.
7. Usa caracteres de forma aleatoria, la repetición continua hará que memorices tu clave.
8. Intercala más de un símbolo ( ¡@#$%^&* )
9. Intercala más de un número.
10. Activa el Generador de Códigos de Seguridad en redes sociales para intentos de sesión en dispositivos desconocidos.
11. Mantén privados tus datos de contacto en redes sociales.

El ejemplo de un password seguro: [Tdr5-oiD#-8HtG-@jsU]

Transmisiones seguras

Internet de las Cosas se expande rápidamente por el mundo. Eso significa que cada  día hay más objetos conectados que están en condiciones de recibir instrucciones. Por eso, es necesario que tengas en cuenta esta transformación cuando generes tu password. Así, evitarás que algún extraño encienda las luces de toda tu casa y el televisor a todo volumen, a las tres de la mañana.

Y tú ¿sigues utilizando el nombre y año de tu pareja como password?

Si te gustó este artículo, creemos que también podría interesarte esta infografía sobre el panorama de seguridad del 2015: 

Fuente: Blog Cisco Latinoamérica

Virtual Routing and Forwarding: Elementos básicos de VRF

Por Oscar Gerometta

Una tecnología sobre la que no se habla habitualmente es la implementación de VRFs (Virtual Routing and Forwarding). 

Se la suele vincular a la implementación de VPNs MPLS, donde es un recurso necesario, pero también es un recurso útil cuando debemos intercambiar rutas de múltiples redes diferentes sobre una misma infraestructura de enrutamiento, manteniendo las rutas de cada red totalmente independientes.

Por ese motivo me pareció adecuado dedicar un post al menos a los rudimentos de las VRFs.

Como se desprende de lo que dije antes, podemos utilizar VRFs para mantener múltiples instancias de enrutamiento de modo simultáneo en un único router. 

En este caso, cada instancia de enrutamiento es totalmente independiente, con su propia tabla de enrutamiento, sin interacción con el enrutamiento de otra instancias, lo que permite incluso que haya superposición de redes IP en una misma infraestructura sin que haya conflictos de direccionamiento.

Una VRF está definida por un conjunto de elementos específicos:

• Un Nombre que la identifica localmente en el dispositivo y permite ingresar al modo de configuración de esa VRF específica.
• Un Route Distinguisher que identifica dentro de una red las VRFs que componen la misma red virtual y que intercambian información de enrutamiento entre sí.
• Un Exported Route Target que identifica a qué otra VRF dentro de la misma red se envía información de enrutamiento de esa VRF.
• Un Imported Route Target que idendifica de qué otra VRF dentro de la misma red se aprende información de enrutamiento para esa VRF.
• Un conjunto de interfaces asociadas a la VRF.

Elementos de configuración básica

Router(config)#ip vrf Prueba1
Router(config-vrf)#rd 1:10
Router(config-vrf)#route-target export 1:10
Router(config-vrf)#route-target import 1:10
Router(config-vrf)#exit
Router(config)#interface GigabitEthernet2
Router(config-if)#ip vrf forwarding Prueba1

Hay que tener presente que al incorporar o retirar una interfaz de una VRF se remueve automáticamente la configuración IP existente en la interfaz y se deberá configurar nuevamente según corresponda.

La tabla de enrutamiento

Al crear VRFs se habilitan diferentes instancias de enrutamiento en un mismo dispositivo, separadas lógicamente. Cada instancia de enrutamiento es completamente independiente y se mantiene una tabla de enrutamiento para cada instancia.

De esta manera, en un router que implementa VRFs se encuentran varias tablas de enrutamiento:

• La tabla de enrutamiento global o de la infraestructura, en la que se mantienen las rutas propias de la infraestructura física.
  Se consulta utilizando el comando:
  Router#show ip route
• Una tabla de enrutamiento independiente por cada VRF, en la que se encuentran exclusivamente las rutas de la red virtual a la que pertenece esa VRF.
  Su estructura es resultado del intercambio de información de enrutamiento con otras VRFs de la misma red virtual definido utilizando los comandos route-target.
  Se consulta utilizando el comando:
  Router#show ip route vrf Prueba1

El enrutamiento de cada VRF es completamente independiente, del mismo modo que el direccionamiento IP asociado a las interfaces y al enrutamiento. 

Por lo tanto cada VRF puede tener sus propias rutas estáticas o instancia de un protocolo de enrutamiento. La metodología de configuración del protocolo de enrutamiento en cada VRF cambia ligeramente según el protocolo del que se trate.

Adicionalmente, a nivel de la infraestructura se utiliza una instancia de MP-BGP para transportar la información de enrutamiento entre VRFs de diferentes routers que deben intercambiar información de enrutamiento.

Vea la forma de configurar en este video: https://www.youtube.com/watch?t=318&v=iw4BneMFG4U



Recursos:

• Cisco Active Network Abstraction Reference Guide, 3.7, Part 2 

Fuente: http://librosnetworking.blogspot.com/