CCIE R&S EIGRP LAB

This is my CCIE R&S EIGRP study and wanted to share with you because is the best way to keep on learning.

The topology was created on EVE-NG.

Captura

 

I’ll cover these topics from CCIER&Sv5.1 blueprint.

  • EIGRP Summarization (auto-summary / manual)
  • EIGRP Summarization with default Routing
  • EIGRP Summarization with Leak Map
  • EIGRP summary metric
  • EIGRP Named
  • EIGRP Variance
  • EIGRP convergence timers
  • EIGRP IP FRR
  • EIGRP Query Scoping with summarization
  • EIGRP Stub routing with Leak Map
  • EIGRP Graceful & NSF
  • DMVPN
  • PfR to Route Control

Take into account that CCIE11 router is located between 2 EIGRP modes. So we need to do redistribution with the AS numbers of EIGRP.

router eigrp LFA
!
address-family ipv4 unicast autonomous-system 10
!
topology base
redistribute eigrp 100
exit-af-topology
network 10.10.11.0 0.0.0.255
network 10.10.13.0 0.0.0.255
exit-address-family
!
!
router eigrp 100
network 172.26.20.0 0.0.0.255
network 172.26.21.0 0.0.0.255
redistribute eigrp 10

After finishing the basic configuration in all devices like IP addresses and routing section we need to verify full connectivity.

  1. Summarization

In this section we need to be careful because inEIGRP auto-summary is enabled by default. To avoid issues like BLACK HOLE I advice you:

  • Don’t Summarize
  • Use LEAK-MAP (if you want summarize)
Anuncios
Publicado en Uncategorized | Deja un comentario

Deployment Management Tools

1.ANSIBLE

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.

 

2.CHEF

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.

 

3.PUPPET

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.

 

 

4.FABRIC

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.

 

5.SALTSTACK

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:

Leaking_VRF.JPG

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

VRF_Creation.JPG

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

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

VRF aSSOCIATION.JPG

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

PE

router ospf 1 vrf london
network 10.0.0.0 0.0.0.3 area 0
!
router ospf 2 vrf Newcastle
network 10.0.0.4 0.0.0.3 area 0
!
router ospf 3 vrf Manchester
network 10.0.0.8 0.0.0.3 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 10.0.0.0 0.0.0.3 area 0
!
router ospf 2 vrf Newcastle
redistribute bgp 1 subnets
network 10.0.0.4 0.0.0.3 area 0
!
router ospf 3 vrf Manchester
redistribute bgp 1 subnets
network 10.0.0.8 0.0.0.3 area 0
!
router bgp 1
bgp log-neighbor-changes
!
address-family ipv4 vrf Manchester
redistribute connected
redistribute ospf 3
exit-address-family
!
address-family ipv4 vrf Newcastle
redistribute connected
redistribute ospf 2
exit-address-family
!
address-family ipv4 vrf london
redistribute connected
redistribute ospf 1
exit-address-family

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

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/30 is directly connected, FastEthernet0/0
L 10.0.0.2/32 is directly connected, FastEthernet0/0
192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.0.0/24 is directly connected, Loopback0
L 192.168.0.1/32 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

NOTES:

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

VRF_leaking.JPG

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

SNiffer.JPG

LSU.JPG

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 (http://eve-ng.net/)

  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 1.1.1.13 remote-as 101
R1(config-router)#end

 

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

 

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

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. (https://learningnetwork.cisco.com/message/662744#662744)

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

VSS

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.

Requirements:

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

VSS_basic_Configpng.png

Feel free to order as you need about VSS: networkingcontrol@gmail.com   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

Next, take into account:

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