How detect Network Failure

Firtly, we need to know that we can detect a Network failure in Layer 1, 2 or 3.

Layer 2 Failure

ü  Only between a pair of Cisco’s switches.

ü  Detecting a failure can take more than 20 seconds.

ü  If you cannot use BFD, you can run UDLD on routed interfaces to detect link problems faster than the routing protocol hello mechanisms would


Layer 3 Failure

  • Protocols
    • BFD


Publicado en Uncategorized | Deja un comentario

Dot1Q Vs Q-in-Q

Today we review the main differences between both Layer2 protocols Dot1Q and Q-in-Q.

  1. Dot1Q (802.1Q) Trunking Protocol
  • 802.1Q inserts a 4-byte header, also called a tag into the original Ethernet frame (right after Source Address field) instead of encapsulating the Ethernet header.
  • A frame with 802.1Q tag , the first 2 byte after the source address (SA) holds a registered Ethernet type value of 0X8100 , which represents that the frame includes an 802.1Q header.
  • 802.1Q is often called frame tagging as it not encapsulates the frame; it tags/adds a header into the frame.

Screen Shot 2017-12-13 at 13.26.12.png

2. Q-in-Q Tunneling 

802.1Q-in-Q tunneling is the mechanism to tag 802.1Q frames with additional 4 byte tag, an 802.1Q tagged frame is again tagged with another 802.1Q tag. This is very useful is service provider implementation, the ingress SP switches forwards frames by looking into the first 802.1Q tag up-to the egress switch, egress switch removed the tag when delivering the frame to egress port, upon receiving the frame the customer switch gets the frame with second tag which is the actual VLAN information based on which frames needs to be forwarded to the actual destination.


Screen Shot 2017-12-13 at 13.26.21.png

  • Standard Protocol
  • Switchport mode dot1q-tunnel interface level command is used to configure interface carrying Q-in-Q frames.
  • While configuring the Q-in-Q the MTU needs to be carefully addressed, as the frame coming from customer may already contain 1500 bytes and by implementing Q-in-Q adds additional 4 byte in the frame. So the total frame size can grow up to 1504 bytes.
  • Specific layer2 management protocols (like CDP, LLDP, STP, VTP) needs to be explicitly configured to allow via the Q-in-Q interfaces to cross the SP boundary. Use the following commands:

(config-if)#l2protocol-tunnel stp

(config-if)#l2protocol-tunnel cdp

(config-if)#l2protocol-tunnel vtp

(config-if)#l2protocol-tunnel cos

  • With 802.1Q tunneling, tagged customer traffic comes from an 802.1Q trunk port on a customer device and enters the service-provider edge switch through a tunnel port. The link between the 802.1Q trunk port on a customer device and the tunnel port is called an asymmetrical link because one end is configured as an 802.1Q trunk port and the other end is configured as a tunnel port.
  • SP switch tunnel port is assigned an access VLAN ID unique to customer.
  • Tunnel ports learn customer MAC addresses.
  • Asymmetrical links do not support the Dynamic Trunking Protocol (DTP) because only one port on the link is a trunk. I.e. Customer side is trunk and SP side is the access port.
Publicado en CCIE, Uncategorized | 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:


Screen Shot 2017-11-26 at 18.47.50.png

The first mnemonic will be ILL + ASS 🙂 


Screen Shot 2017-09-24 at 17.15.03.png

Mnemonic: 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


Screen Shot 2017-12-03 at 21.06.36

Mnemonic: HD-3L

Screen Shot 2017-12-03 at 21.04.20.png

Mnemonic: WIFE-DEA

Screen Shot 2017-12-12 at 00.11.43.png

Mnemonic: IIEENN

Screen Shot 2017-12-12 at 01.20.40.png

Mnemonic: TAMASA


Screen Shot 2018-02-17 at 18.57.30.png

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


Mnemonic: PIC MOD


Screen Shot 2017-11-29 at 22.03.17.png

Mnemonic: GAVEE O

(L-point-to-point;LAN multipoint; V-multiple VLANs;)

IPv6 Tunneling

Screen Shot 2017-12-14 at 13.44.46.png

Mnemonic: MAGIC 🙂 6

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


Hello folks!

Today I want to share with you a pretty cool LAB that I have just done to practise the PIM protocol and DMVPN.


Pay attention! Remember break down all issues in your CCIE LAB
  • Firstly we need to verify connectiity IP



  • Troubleshooting DMVPN



  • Configure & Verify Multicast dense-mode protocol


Finally we wanted to attach the configuration of all devices.



Publicado en Uncategorized | Deja un comentario


Basically, Unicast Reverse Path Forwarding (uRPF) let us to avoid accepting spoofing sources and prevent DDoS attacks on Edge Routers.


  • Very Low impact on CPU
  • Tipically done in Hardware
  • Less wasted bandwidth
  • Will keep the “NET” cleaner

uRPF has 2 methods:

  1. Strict Mode: Firstly check the source IP addr against the FIB table and if appear there will try to reach the source IP addr through the same interface where arrived. Way back to the source out on the same interface as it receives a packet. If can’t achieve this source IP addr from the interface where arrived to border router then will be dropped.
    • Where?
      • On single Homed Edge Router


  1. Loose Mode: The Edge router only will verify that exists the source IP addr in the FIB table.
    • Where?
      • On Multihomed Edge Routers, on Edge router when VRF’s
  2. VRF Mode: Like Loose mode, however applied to VRF. Verifies that the traffic from the source of the VRF has to route back in the VRF routing table.

If you want to dive more, watch this video.



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


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.


  • Let you avoid redistribution
  • You need IOS-XE OS
  • Control plane will be EIGRP
  • Establish an EIGRP multihop adjacency using LISP as the encapsulation method for transport through the WAN network.

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 “”


The routers are CSR1000V with “csr1000v-universalk9.16.06.02” because older versions cannot let us to create EIGRP OTP.

As you can see all of these routers are running on ESXi Server.



  1. Configure OSPF into CORE network
CSR_1#show running-config | section ospf
router ospf 10
network area 0
network area 0
CSR_2#show running-config | section ospf
router ospf 10
network area 0
network area 0
network area 0
CSR_3#show running-config | section ospf
router ospf 10
network area 0
network area 0
network area 0
CSR_4#show running-config | section ospf
router ospf 10
network area 0
CSR_5#show running-config | section ospf
router ospf 10
network area 0

2. Configure EIGRP OTP

router eigrp CCIE
address-family ipv4 unicast autonomous-system 100
topology base
neighbor GigabitEthernet2 remote 10 lisp-encap 1
exit-address-family2. Configure EIGRP Named
router eigrp CCIE
address-family ipv4 unicast autonomous-system 100
topology base
neighbor GigabitEthernet2 remote 10 lisp-encap 1


Pay attention to “neighbor GigabitEthernet2 remote 10 lisp-encap 1” here you are configuring EIGRP over LISP protocol.



CSR_4#show ip eigrp interfaces
EIGRP-IPv4 VR(CCIE) Address-Family Interfaces for AS(100)
Xmit Queue PeerQ Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes
Lo0 0 0/0 0/0 0 0/0 0 0
Gi2 1 0/0 0/0 37 0/0 100 0
CSR_5#show ip eigrp interfaces
EIGRP-IPv4 VR(CCIE) Address-Family Interfaces for AS(100)
Xmit Queue PeerQ Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes
Lo0 0 0/0 0/0 0 0/0 0 0
Gi2 1 0/0 0/0 10 0/0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms


Publicado en Uncategorized | Deja un comentario


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


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 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