Road to CCIE

Hello networking nerds!

After to think accurately concerning my road map I have decided to prepare the CCIE R&S. I think that will be good way to acquire more knowledge and extend my current netoworking concepts.

From now on, I will plublish my key methods that I am doing to achieve the theorical CCIE exam as easy as be possible.

  • Mnemonics for Memorizing

In order to pass the theorical par of CCIE you will need to memorize a lot of concepts and processes. In this section I will share the mnemonics made by me:

BGP

Screen Shot 2017-09-24 at 17.15.03.png

The first mnemonic will be OKUN.

The next table let you memorize the process to determine the best route in BGP.

Screen Shot 2017-09-24 at 17.47.32

Mnemonic:           N
                                WLLA
                               OMNI

 

OSPF

Screen Shot 2017-09-24 at 17.24.54

Mnemonic: HD-3L

EIGRP

Screen Shot 2017-09-24 at 17.33.17

Anuncios
Publicado en CCIE, Uncategorized | Etiquetado , , , , | Deja un comentario

VXLAN – VTEP

Hoy os queremos presentar uno de los roles más importantes en el estándar VXLAN y son los VTEPs.

Screen Shot 2017-08-23 at 23.49.10.png

Los gateways que actúan como VTEP son conocidos en una Fabric como Leaf y además son los encargados de realizar una encapsulación/desencapsulación MAC-in-UDP para mandar tramas en forma de paquetes a través de una red IP con protocolo BGP generalmente.

  • Descubrimiento VTEP

Ahora bien, si nos centramos en como se envían los datos entre end hosts debemos saber que los datos serán enviados por el túnel VXLAN creado entre ambos o varios VTEPs. Para poder enviar una trama (layer 2) por el túnel deberemos de saber a qué VTEP destino mandar. La primera vez el VTEP origen deberá de descubrir cuál es el VTEP destino y aquí es dónde queremos profundizar puesto que es un punto clave a la hora de decidir la configuración de VXLAN.

Para realizar el descubrimiento de VTEPs tenemos 3 opciones:

  1. Flood and Learn

Consiste en formar grupos multicast y enviar las tramas por el túnel VXLAN al grupo multicast con lo cual llegaría a todos los VTEP del grupo multicast. Una vez el VTEP reciba el paquete y lo desfragmente cuando vea el VNI (Identifier de segmento VXLAN) sabrá si le corresponde a él o no.

Screen Shot 2017-08-23 at 23.52.05.png

    2. BGP EVPN (más usada)

Consiste en enviar toda la información relacionada con los VTEPs mediante la extensión EVPN a través de BGP. Se elige BGP porque es un protocolo estándar que soporta alta escalabilidad. Recuerden que se usa BGP en Internet.

3. Controller SDN

A diferencia de BGP EVPN se aisla el plano de control en un device. Uno de los inconvenientes sería que si sólo existe un controller, tendríamos único punto de fallo.

Por último os presentamos una comparación entre los principales procesos de detección:

Screen Shot 2017-08-23 at 23.53.46.png

Publicado en VXLAN | Etiquetado | Deja un comentario

AWS Certified Advanced Networking – Specialty

As you can inspect the AWS platform is growing so fast and the best way to dominate most of services on AWS is to prepare some official certification. Nevertheless, you need also to practising a lot of with the AWS console.

Screen Shot 2017-07-16 at 20.47.47

The next week I will begin the AWS Certified Advanced Networking Certification and I would like to know if somebody would be interested in share de videos of the course. I love the cloud guru website and there is available the course.

https://acloud.guru/learn/aws-certified-advanced-networking-specialty

Send me an email if you are interested:

networkingcontrol@gmail.com

Publicado en Uncategorized | Deja un comentario

VPC-AWS

A continuación introduciremos una de las secciones más importantes del examen AWS-CSAA que es VPC. Es de suma importacia controlar esta sección porque si no no podrás avanzar en el curso de la certificación de AWS Architect Associate.

Screen Shot 2017-05-19 at 20.56.26

Figura2. VPC

VPC (Virtual Private Cloud) nos permite interconectar a través de Internet el datacenter de nuestro cliente con os recursos alojados en el cloud de AWS.

Como podeis ver en la figura2 para crear un VPC deberemos de crear también los otros recursos de AWS. Siguiendo los pasos que os detallamos en cuestión de minutos podemos tener una VPC funcionando perfectamente:

  1. Create IGW

Primero se debe de crear el Internet Gateway que el que permite la conexión de AWS con Internet.

Screen Shot 2017-05-20 at 00.41.002. Create VPC

Screen Shot 2017-05-20 at 00.42.443. Create Subnet

Como podeis comprobar en la imagen debemos de asociar la subnet al VPC.

Screen Shot 2017-05-20 at 00.45.01.png4. Create Routing Table

Deberemos de añadir la ruta por defecto como veis en la imagen para tener salida a Internet. Fijaros que el status debe de ser “Active”

Screen Shot 2017-05-20 at 00.47.39

5. (Optional) Create NAT device

Ya por último si no asignamos ninguna EIP (Elastic IP) a los recursos que deban de tener salida a INET deberemos de usar el NAT device para permitir a los recursos de una subnet privada salir a Inet.

En este caso tenéis dos opciones usar Nat Gateway o Nat Instance, nosotros os aconsejamos NAT Gateway por seguridad.

Screen Shot 2017-05-20 at 00.51.29

Recordad que el uso de EIP tiene coste y se empieza a facturar nada más se asocia a alguna instancia. El resto de recursos no tiene coste.

Por último os resumimos las limitaciones que presenta una VPC con AWS.

Screen Shot 2017-05-20 at 00.23.14

 

Publicado en AWS | Etiquetado , , , , | Deja un comentario

AWS-Brief

Hoy después de un mes ausente preparando la certificación de AWS-Certified Solution Architect ya puedo decir que estoy certificado en AWS.

Screen Shot 2017-05-15 at 23.53.47

Figura1. AWS Scheme

Debido a la importancia que está tomando el cloud computing y sobretodo el cloud público de Amazon he pensado en preparar un sección exclusiva de AWS para que vayais familiarizándose con AWS. Una de las tareas que os recomiendo es cada mañana visitas el blog de AWS https://aws.amazon.com/blogs/aws/ dónde os sorprenderéis de como avanza… Cada día sale un servicio nuevo.

A continuación podeis comprobar como en 2016 ya empezaba a ser la certificación más valorada del mercado.

Screen Shot 2017-05-15 at 22.30.40

Para empezar la sección empezaremos por “Bastion Host” y NAT device.

Bastion Host: Dispositivo que permite centralizar los accesos a los recursos internos (generalmente instancias c2) haciendo una red más segura. Toma el rol de un Gateway RDP sin tener que guardar las credenciales de acceso en el bastion host. Éste dispositivo es esencial en cualquier plataforma para que las instancias no estén en la red pública.

NAT Device: Dispositivo que permite a las instancias de las redes privadas poder acceder a Internet. Hay que tener en cuenta que por defecto está habilitado Source Destination check; Deshabilitar para poder enviar y recibir tráfico cuando no sea el origen o destino el NAT device.

No dudéis en mandar vuestras dudas a networkingcontrol@gmail.com

Publicado en Uncategorized | Deja un comentario

CCIE Route Reflector

A continuación les detallamos el funcionamiento de la features de BGP conocida como Route Reflector.

Si recordais en el CCNP R&S ya se indicó que existe la regla de Split Horizon:

“When a BGP speaker receives an UPDATE message from an internal  peer, the receiving BGP speaker shall not re-distribute the routing  information contained in that UPDATE message to other internal peers. This is split horizon rule use within AS to prevent loops”

Pues para evitar no propagar las rutas a los vecinos iBGP aparece el route reflecto.

A continuación nos basaremos en el siguiente esquema de red:

En un inicio comprobaremos como R2 no recibe el prefijo 172.26-24-0/24 propagado por R5.

Ahora configuraremos el R3 como Route Reflecto:

Ahora ya aparece el prefijo 172.26.24.0/24

Nutshell:

  • Ignore the Split Horizon Rule.
  • Reduce the number of relationships between neighbors; instead of N *(N-1)/2 will be (N-1) adjacency.

 

Publicado en CCIE | Deja un comentario

CCIE-BGP advertise conditional

Hoy empezamos la semana con la “cool” feature que nos permite elegir a qué ISP anunciar nuestros prefijos. Puesto que en la mayoría de casos nos encontraremos con un deployement multi homed ésto nos permitirá que si un ISP tiene problemas (loop, problemas en backend…) dejaremos de anunciarle nuestros prefijos para anunciarlos por el otro ISP que es estable.

Topología:

En este caso siempre estamos anunciando los prefijos por el ISP-TELIANET porque el enlace es de 10Gbps; pero en caso de caída nos interesará propagar los prefijos por el ISP-INET_SOL.

Configuración:

Track del prefijo: 10.2.4.0/24
R1(config)#access-list 1 permit 10.2.4.0 0.0.0.255
R1(config)#route-map EXIST permit 10
R1(config-route-map)#match ip address 1
R1(config)#route-map EXIST permit 20
R1(config-route-map)#end

Router-map para decidir que prefijos anunciar

R1(config)#access-list 2 permit 10.10.10.0 0.0.0.255
R1(config)#access-list 3 permit 20.20.20.0 0.0.0.255
R1(config)#route-map ADVERTISE permit 10
R1(config-route-map)#match ip address 2-3
R1(config-route-map)#end

Creamos advertise-conditioned para ISP-TELIANET

R1#show running-config | s bgp
router bgp 65001
 synchronization
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 redistribute connected
 redistribute static
 neighbor 10.1.2.2 remote-as 1299
 neighbor 10.1.2.2 advertise-map ADVERTISE exist-map EXIST
 neighbor 10.1.3.3 remote-as 10250
 no auto-summary

Verificación:

Comprobamos como R1 todavía ve el prefijo monitorizado 10.2.4.0/24 y por ello anuncia todos sus prefijos hacia el ISP con enlace 10Gbps.

Si ponemos en “shutdown” la interfaz

En la tabla de rutas BGP ya no aparecerá el prefijo con “track”

Por ello ahora hemos dejado de anunciar hacia el ISP- TELIANET.

No dudeis en enviarnos vuetsras dudas via mail: networkingcontrol@gmail.com

Publicado en CCIE | Deja un comentario