The curious case of OSPF LSA Type 4

by Baher - 0

I've always been fascinated by OSPF. I remember back in the day when I felt that I really know OSPF inside out until I went for a job interview where several interviewers grilled me on OSPF and I was like you know what? I really have to go back and dig as deep as possible into OSPF (and no, I did not get that job...).OSPF has many features and quirks, its flexible but also has many limitations, it's scalable but also can cause major headaches in large scale networks. In this post, I will be focusing on LSA Type 4 just because this a really interesting LSA. It is often misunderstood, misrepresented and as I will show towards the end, in

Route Selection Criteria

by Baher - 0

I've been conducting interviews over the past 6 years and I've done probably hundreds of technical phone screening, on-site whiteboard sessions. I always make sure I ask questions on topics that are typically considered as core network fundamentals and I do that for two reasons. If the role is for a senior network engineer/architect, I want to confirm that the basics are not overlooked when I give the candidate a design or troubleshooting scenario. If the role is for a more of a junior level network engineer, I want to make sure that the candidate has a solid understanding of the fundamental network concepts. I'm a firm believer that solid understanding of the network fundamentals is key for any network

Busting 5 Myths of EIGRP

by Baher - 0

In this post, I'm going to explain some core EIGRP topics that are poorly or even incorrectly documented in many resources including Cisco's documents, forums and books. This post will be loosely based on the topology in this Article. The focus will be on R4 and how it's seeing 192.168.10.0/24. For all routers, I configured EIGRP with (metric weights 0 0 0 1 0 0) to remove Bandwidth from the metric calculation to simplify this post. R4#sh ip eigrp top P 192.168.10.0/24, 1 successors, FD is 7680 via 10.1.42.2 (7680/5120), Ethernet0/2 via 10.1.41.1 (10240/5120), Ethernet0/1 R4#sh ip eigrp top all P 192.168.10.0/24, 1 successors, FD is 7680,

DMVPN Phase-3

by Baher - 0

This is the third and final post regarding DMVPN which will cover Phase-3. Phase-2 and Phase-3 are very similar. In both phases, spokes can access each other directly by bringing an on demand tunnel. That said, there is some minor configuration difference and specific commands that we need to add to the tunnel interfaces of the hub and spokes. I feel like I have covered a good amount of static mapping in the previous two posts, I will just use dynamic mapping here. R1: interface Tunnel0 ip address 10.1.1.1 255.255.255.0 no ip redirects ip nhrp map multicast dynamic ip nhrp network-id 111 ip nhrp redirect tunnel source FastEthernet0/0 tunnel mode gre multipoint R2: interface Tunnel0 ip address 10.1.1.2 255.255.255.0 no ip split-horizon eigrp 100

DMVPN Phase-2

by Baher - 0

To continue with DMVPN topic, this post will be explaining DMVPN Phase-2. The main difference between Phase-1 and 2 is the spoke to spoke reachability. As shown in the previous post, a spoke can only reach another spoke through the Hub. There is no direct spoke to spoke communication. Phase-2, however, changes this behavior where spokes can talk to each other directly. I'm going to use the same topology and IP addressing. So let's go directly to the actual configuration. DMVPN Phase-2: Static Mapping R1: interface Tunnel0 ip address 10.1.1.1 255.255.255.0 ip nhrp map 10.1.1.2 192.168.1.2 ip nhrp map 10.1.1.3 192.168.1.3 ip nhrp map 10.1.1.4 192.168.1.4 ip nhrp network-id 111 tunnel source FastEthernet0/0 tunnel mode gre multipoint R2: interface Tunnel0 ip address 10.1.1.2 255.255.255.0 no ip

DMVPN Phase-1

by Baher - 0

In this series, I'm going to explain all three phases of DMVPN. DMVPN should be thought of as a routing technology and not necessarily a security one. Yes, you can encrypt these VPN tunnels but DMVPN is more like dynamically created GRE tunnels with the use of NHRP. The encryption, while not mandatory, is typically used to secure the encapsulated traffic across the public internet. An important note, I find the naming Phase 1, 2 and 3 is very confusing as it clearly can get confused with IPsec Phases. A better way to think of is DMVPN Type 1, 2 and 3 were each type represents a different configuration and behavior. Throughout this post, I'm going to use the same topology below.

RIPv2 Timers, Explained And Simplified! Part 2/2

by Baher - 0

For the second part of this post, I will be covering a couple of scenarios by changing the default values of RIPv2 timers. First scenario is when the Flush After time is configured to last longer than Holddown timer in which case, the route will get flushed when the Holddown timer expires even though the Flush After timer is still on. This is the RIPv2 config for R1: Another look at the graphical representation of how timers look like now. The red line demonstrates when the route should be flushed from the routing table Again, focusing on how R1 receives network 5.5.5.5, I will make R4's gig1/0 passive. Network 5.5.5 should remain in the routing table for about 6min before it gets

RIPv2 Timers, explained and simplified! Part 1/2

by Baher - 0

RIPv2 is probably one of the simplest routing protocols. Even its timers are often described as 'basic' - but how basic are they? I mean sure, we know 'Update timer' is 30 seconds, 'Invalid After' timer is 180 seconds, 'Holddown' timer is 180 seconds and finally 'Flush After' timer is 240 seconds. However, I found that those timers and their function are somewhat poorly, or even wrongly, documented in some online posts. As always, no better way to understand any technology than run it in a lab. I'm going to explain, in details, RIPv2 timers. First, starting with this simple network:   Each one of those routers has a loopback interface matches the router number. For example, R1 has loopback1: 1.1.1.1/32, R2 has loopback2:

Top