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
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
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.
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 18.104.22.168, 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 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: 22.214.171.124/32, R2 has loopback2:
I wasn't very familiar with dot1q tunneling aka Q-in-Q. But since I started working for a service provider, I was more and more involved with this technology almost on a daily basis. So I started researching and reading more about. While studying and reviewing switching topics, I came across dot1q and while implementing the INE lab, I noticed a few things that I thought this is worth a post here and it is officially my first study post! So enough talking and let's start tagging!! QinQ is simply a techniuq used (mainly by ISPs) to keep traffic from customers segregated within the ISP's cloud. Suppose Customer A has 2 sites and it needs to have both sites privately connected within the ISP
As I mentioned in a previous post, I thought its a good idea to have a separate post for my lab. I heard many stories about CCIEs who prepared for the lab exam using GNS3. GNS3 is a real solid tool and can help a lot. I know this for sure as I have completed my CCNP studies using GNS3 running on my old Dell Inspiron with 2GB of RAM only. And you know what? it worked really well. I especially enjoyed Routing labs except when GNS3 crashes on me at the most critical times! I spent plenty of time debating building my own lab, renting one or just use GNS3. I dropped the idea of rack rentals, it just didn't
I guess one of the most simple tasks to kick off your CCIE study is to know the required materials. If you do a quick Google search, you will notice how almost all CCIE's or the candidates agree on 85%-95% of the study materials and will have a very similar reading list. I haven't had a serious hard time searching and eventually obtaining the materials that I think would be enough (hopefully!) to pass the CCIE written exam. I can't really guarantee the lab exam, since so many people only pass after failing multiple times. So, for now, I will not comment or speculate about the lab exam until my first attempt and then will see how good or bad