EIGRP OTP

Today, studying the written CCIE R&S exam I have just found out the EIGRP Over The Top feature and I would like to share with you briefly.

Overview:

  • Let you avoid redistribution
  • You need IOS-XE OS
  • Control plane will be EIGRP

Basically is a L2TP protocol that let us to avoid the redistribution. In this way the troubleshooting will be more clear.

In order to explain we’ll use the next topology created on “draw.io”

Screen Shot 2017-11-21 at 23.08.49

The customer NetworkingControl dowsn’t want to use rdistribution over EIGRP on your CE routers. So after speak with the ISP they will do changes in a maintainance window.

After the maintainance the configuration on the PE’s and CE’s devices would be the next:

 

Anuncios
Publicado en Uncategorized | Deja un comentario

LDP vs RSVP

I want to share some brief notes about two protocols used for setting up the LSP in MPLS: LDP and RSVP protocols.

LDP

LDP is the youngest one. Was created explicitly to distribute labels and it’s not an extension or added functionality to a relatively old protocol like in the RSVP.

LDP is designed to be highly extensible, using TLV triplets to be able to transport multiple additional fields in the future and warrantee the compatibility with previous versions via ignoring the unknown new fields.

LDP is highly flexible, as supports local and remote neighbors (using targeted LDP sessions). This flexibility allows an LSR to exchange label information with local and remote peers which enables it to support the engineering of multiple services and functionalities like LDP session protection.

LDP is a reliable protocol, because it uses TCP as transport. Only the neighbor discovery and maintenance is performed using UDP. The incremental updates functionality is a point in favor of its scalability.

Now you are being thinking: If LDP is so reliable, extensible, functional and scalable, why do we even think about using an alternative to it in the MPLS core to do the job of setting up the labeled switched paths? Well, it follows the explanation:

LDP follows the IGP in the decisions the later takes. The price to pay for that decision is loss of stability of the LSPs that LDP set up.

  • Instability: if the IGP changes, the LDP will change with it, but late. LDP could set up instable LSPs in the network.
  • Convergence: the convergence events that happens on every network are inherited by LDP and that could lead to data loss or looping conditions. The convergence time of the IGP will set a lower convergence time limit to LDP and to the LSPs (not considering LDP FRR capabilities yet).
  • Race conditions: race conditions may always appear when two protocols interact in an unsynchronized way, and that may leads to data loss.

RSVP

RSVP protocol was developed to support the IntServ QoS model resource reservations for each flow that demands specific QoS requirements as it traverses the network. Original RSVP does not scale very well because the number of end to end sessions that the intermediate devices must support may grow very fast in the SP core as more flows require QoS reservations, and that affects the control plane state that devices must support.

The extension performs scalability by aggregation, but… of what? It aggregates multiple flows of data into one LSP in a way that 1 RSVP session set up 1 LSP that can transport multiple flows of data. As the amount of state on each node of the network is proportional to the number of LSPs traversing the node, aggregation alleviates (that does not solve) the problem of scalability.

The path reservation is initiated by the ingress LSR using Path and Resv messages. The Path message travels from ingress LSR (head-end) to egress LSR (tail-end) and the Resv in the opposite direction.

  • RSVP Path
    • Label request
    • ERO (Explicit Route Object, explicit route)
    • RRO (Recorded Route Object, loop avoidance)
    • Tspec (Bandwidth Reservation, QoS requirements)
  • RSVP Resv
    • Label object (Assigned Label)
    • RRO (Loop avoidance)

One of the most advantage, RSVP does not follow the IGP, and that allows the head-end to take independent decisions about the traffic flows it reserves.

When to use wich one?

We need to use natively the LDP because as we explained before is a dedicated protocol exclusively for getting LSP paths in MPLS.

However if our networks needs enforce traffic engineering capabilitiies we’ll use RSVP.

LSP Designa Attributes

Screen Shot 2017-11-11 at 13.08.58

LSP Topology

Screen Shot 2017-11-11 at 13.10.19

I you want to exapand your knowledge about MPLS I recommend you this great book:

Screen Shot 2017-11-11 at 14.10.12

MPLS Enabled Applications

Publicado en CCIE | Deja un comentario

BGP Advanced

BGP-PIC

Protocol Independent Convergence (PIC) let us just like EIGRP install a Feassible Successor route into RIB and FIB tables. In this way, the network converge will be speed up.

This feature is availble after 15 IOS version.

 

BGP-BACKDOOR

Cuando usamos eBGP y existe algún otro protocolo IGP como EIGRP u OSPF debido a que eBGP posee una menor AD la ruta siempre irá a través de eBGP cuando no siempre el best path.

Screen Shot 2017-10-12 at 17.53.43.png

Tras realizar la configuración habitual de EIGRP y BGP ocurre lo siguiente:

Screen Shot 2017-10-12 at 17.54.26.png

Como se puede comprobar desde R1 para alcanzar las networks 10.210.1.0/24 y 10.211.1.0/24 va a través de R3 cuando las debería de alcanzar a través de R2 que es el best path. Para solucionar este problema usamos Backdoor.

Screen Shot 2017-10-12 at 17.58.47.png

Screen Shot 2017-10-12 at 17.58.41.png

BGP DISTANCE

Publicado en CCIE | Etiquetado , , | Deja un comentario

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 summarize all possible BGP status:

Screen Shot 2017-09-25 at 00.17.53.png

Mnemonic: ICA O2E

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

Screen Shot 2017-09-25 at 00.06.20.png

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

The mnemonic will be SQUASH-R.

QoS Service Models

Screen Shot 2017-10-21 at 13.00.01

Mnemonic: DIE CDC.

Queuing Tools

Screen Shot 2017-11-18 at 14.17.53

Mnemonic: CLIP  +   W

Congestion Avoidance Methods

Screen Shot 2017-10-21 at 13.24.09

Multicast Routing Protocols

MulticastRoutingProtocols.JPG

Mnemonic: PIC MOD

 

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