Deployment Management Tools


Screen Shot 2018-01-28 at 21.44.17.png

Ansible is an open source tool based on Python, used to deploy applications to remote nodes and provision servers in a repeatable way. It gives you a common framework for pushing multi-tier applications and application artifacts using a push model setup, although you can set it up as master-client if you’d like. Ansible is built on playbooks (YAML language) that you can apply to an extensive variety of systems for deploying your app.



Screen Shot 2018-01-28 at 21.44.10.png

Chef is an open source tool for configuration management, focused on the developer side for its user base. Chef operates as a master-client model, with a separate workstation needed to control the master. It’s based on Ruby. The Chef design is transparent and based on following the instructions it’s given, which means that you’ll have to make sure your instructions are clear.



Screen Shot 2018-01-28 at 21.46.27.png

Puppet is one of the long standing tools in the full-fledged configuration management space. It’s an open source tool, but given how long it’s been around, it has been well vetted and deployed in some of the biggest and most demanding environments. Puppet is based on Ruby, but uses a customized Domain Scripting Language (DSL) closer to JSON for working within it. It runs as a master-client setup and uses a model-driven approach. The Puppet code design works as a list of dependencies, which can make things easier or more confusing, depending on your setup.




Screen Shot 2018-01-28 at 21.46.20.png

Fabric is a Python-based tool for streamlining SSH in application deployments. Its primary usage is for running tasks across multiple remote systems, but it can also be extended with plugins to provide more advanced functionality. Fabric will configure your system, do system/server administration, and automate the deployment of your app.



Screen Shot 2018-01-28 at 21.49.03.png

SaltStack (or Salt) is a CLI-based tool that can be set up as a master-client model or a non-centralized model. Based on Python, Salt offers a push method and an SSH method of communication with clients. Salt allows for grouping of clients and configuration templates to simplify the control of the environment.

Publicado en CCIE, Uncategorized | Deja un comentario

Leaking VRF

Hi colleagues!

Today, after having few issues with leaking vrf  I have decided to share with you clearly how configure this feature in Cisco devices.

Goal: The network device in VRF can be reached from other router using global routing table.

As you can see bellow,  we’ll use this simple topology:


Firstly we’ll configure loopback interfaces and OSPF routing in the routers from London, Newcastle and Manchester.

Afterward we’ll go into PE1 router and we definte all VRF’s


For now, we won’t use route-target attribute in VRF.

Next, we need to apply the VRF’s to the proper interfaces:


Because the goal of this deployement is to allow to talk each other using OSPF; we’ll enable OSPF on PE router.


router ospf 1 vrf london
network area 0
router ospf 2 vrf Newcastle
network area 0
router ospf 3 vrf Manchester
network area 0

We need to enable also BGP protocol like the most of PE router. Remember to enable redistribution between both routing protocols.

router ospf 1 vrf london
redistribute bgp 1 subnets
network area 0
router ospf 2 vrf Newcastle
redistribute bgp 1 subnets
network area 0
router ospf 3 vrf Manchester
redistribute bgp 1 subnets
network area 0
router bgp 1
bgp log-neighbor-changes
address-family ipv4 vrf Manchester
redistribute connected
redistribute ospf 3
address-family ipv4 vrf Newcastle
redistribute connected
redistribute ospf 2
address-family ipv4 vrf london
redistribute connected
redistribute ospf 1

Now, if we try to see the Manchester networks from London-CE:

London#show ip route
Codes: L – local, C – connected, S – static, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2
i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
ia – IS-IS inter area, * – candidate default, U – per-user static route
o – ODR, P – periodic downloaded static route, H – NHRP, l – LISP
+ – replicated route, % – next hop override

Gateway of last resort is not set is variably subnetted, 2 subnets, 2 masks
C is directly connected, FastEthernet0/0
L is directly connected, FastEthernet0/0 is variably subnetted, 2 subnets, 2 masks
C is directly connected, Loopback0
L is directly connected, Loopback0

As you can see London can’t see the Manchester’s routes. In order to see the routes in London we’ll use VRF leak method.

ip vrf Manchester
rd 65001:3
route-target export 65001:3
ip vrf Newcastle
rd 65001:2
route-target export 65001:2
ip vrf london
rd 65001:1
route-target export 65001:1
route-target import 65001:3


  • Is mandatory to configure route-target export in all VRFs
  • Only use route-target import if you need VRF-LEA


We take advantage of using EVE-NG and we can use wireshark to verify the update packets



Publicado en Uncategorized | Deja un comentario

Be BGP Expert Engineer

Today I’ll take advantage of the topology created by Stuart Fordham in order to dive so deeply how works BGP.

BGP Topology.JPG

CCIE – BGP Topology

Note the topology was created on EVE-NG (

  1. Firstly we’ll focus on create our first BGP-Confederation:

R1(config)#router bgp 100
R1(config-router)#bgp confederation identifier 105
R1(config-router)#bgp confederation peers 101 102
R1(config-router)#neighbor remote-as 101


R13(config)#router bgp 101
R13(config-router)#bgp confederation identifier 105
R13(config-router)#bgp confederation peers 100
R13(config-router)#neighbor remote-as 100


R14(config)#router bgp 102
R14(config-router)#bgp confederation identifier 105
R14(config-router)#bgp confederation peers 100
R14(config-router)#neighbor remote-as 100

Afterward we’ll create the eBGP session between R1 and R2.

Note that you need to use the AS 105 on R1 instead of the BGP AS confederation 100. (

2. We are going to use soft reconfiguration feature that let us to update our loc-RIB without tear-down the BGP session.

Firstly, we want to expose the nutshell about this powerful feature:




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

OpenStack for CCIE

Two weeks ago I had my first try of CCIE R&S and I failed because of a few questions regarding Openstack and IoT.

In this section we’ll focus on in the main parts of OpenStack.

  1. OpenStack Components
  • Nova: Manage and provisioning computer resources.
  • Neutron: Manage Network and IP addresses
  • Cinder: Creation, attach, detach of block storage devices to servers.
  • Keystone: Directory services that contains users mapped to services they can access.
  • Glance: Provides discovery, registration and retrieval of VM.
  • Swift: Object storage
  • Horizon: Dashborad for tenants based on Python.
  • Heat: Orchestrates cloud applications via templates using a few APIs
  • Mistral: Workflow
  • Celiometer: Single point for contact for billing system
  • Trove: Database
  • Sahara: Automated way like Wizard to provision Hadoop clusters.
  • Ironic: provisions bare-metal servers.

Note that the mandatory components would be only: Nova, Neutron, Keystone, Glance and Horizon.

To reduce your time memorizing I have thought this mnemonic:

Screen Shot 2018-01-08 at 23.43.57

Mnemonic: HONK NEG

Publicado en Uncategorized | Deja un comentario


Nowadays, one of the mandatory requirements is Datacenter resilience. In order to get resilience in our datacenter we use often the VSS protocol in CORE devices.


  •  Supervisor Engine 720 (WS-SUP720-3BXL): The VSL link between both members of VSS only works with line card WS-SUP720-3BXL.
  • Befor to create the VSS (switch convert mode virtual) we need to verify that Port-channel is connected and UP.
  • Verify both members has the same config and same IOS fimrware.

Here we have attached a figure with all required steps:


Feel free to order as you need about VSS:   networkingcontrol.JPG
Publicado en CCIE, Uncategorized | Etiquetado , , , , | Deja un comentario

IPv6 knowledge required for CCIE

In this section we’ll summarize all you need to know about IPv6 for CCIE.

Screen Shot 2018-01-06 at 19.19.29

  1. Checksum
  • The IPv6 header has fewer fields than IPv4 header, and header checksum was removed. IPv6 header is more efficient.
  • In IPv4, a 16-bit field is used to verify the header’s integrity.
  • In IPv6 the checksum is handled by Layers 2 and 4 instead of Layer 3. With IPv6, checksums are required fot both transport protocols (TCP/UDP).
  • In IPv4 the checksum with UDP is OPTIONAL.
  1. Fragmentation
  • When the packet is larger than MTU of the outgoing link; unlike that IPv4 (use DF don’t fragment field) IPv6 uses ICMPv6 message “Packet Too Big” to sent to the originating node. However IPv4 also support Packet Too Big ICMP message.
  • Unlike in IPv4, IPv6 always fragment IPv6 packets in hosts;never on routers.
  • IPv6 Fragment Header: header used when IP fragmentation occurs. 64 bits.
  • MSS unlike MTU, packet exceeding MSS are not fragmented, they’re simply discarded.
  • MSS is decided during TCP three-way handshake and not packet by packet.
  • Minimum MTU: 1280 Bytes; in IPv4: 576 Bytes
  • PMTUD – Path MTU Discovery How works? sender assumes that PMTU “largest size of datagram without fragmentation” is the MTU of first hop and send all datagrams with DF bit set. If some router on the way has lower MTU and needs to fragment; will discard datagrams and return a Too Big message.

Screen Shot 2018-03-31 at 11.54.02.png

Next, take into account:

  • Fragment Header: 64 bits
  • IPv6 Identification Header: 32 bits
Publicado en Uncategorized | Deja un comentario

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