CCIE Route/Switch v5 GNS3 Lab: DMVPN QoS Profile (Micro-Lab)

Hey all!

Just a tiny lab today to cover one line of the CCIEv5 study guide: DMVPN QoS Profiling per-group from the head-end.

It's a very flexible technology that allows you to assign groups from the DMVPN 'spokes' and QoS policy from the DMVPN head-end (hub).

In this lab I've build a very small DMVPN which works perfectly, but lacks per-group QoS policy. You've been asked by your senior network engineer to add this, what she thinks will be a quick task.

Here's your topology: Go!

You can download the solved and unsolved lab here: http://1drv.ms/Zgmfpf. Try it yourself!

Please note that the 'solved' version shows a DMVPN policy which is different between each client DMVPN router. You could just as easily assign all client DMVPN tunnels to the same group, and control them all with the same policy. This lab shows how granular you can be.

Good luck!
kyler

CCIE Route/Switch v5 GNS3 Lab: GRE P2P Tunneling and DMVPN over GRE

Hey all!

GRE tunneling is a fascinating topic. To a host traversing a GRE tunnel, the hops are transparent. A router that doesn't support a protocol can be made to route it with no changes to the older router - just encapsulate it in something the older router understands and you're good to go. And the commands for a DMVPN and P2P GRE tunnel can be written in such a way that they can be simply copy and pasted to a new router to have it dial in, peer with your IGP, and start injecting routes. It's an incredibly simple and powerful tool which allows for good security.

With the way corporate hacks are becoming bigger news items every day, I'd think any network engineer worth their salt is going to want to know how to encrypt traffic between controlled routers for just about everything. Even on private networks we now know the government is listening and copying data for analysis, and I'm just not cool with that. Call me a liberal, but I think our right to freedom from illegal search and seizure means something. And here's a way you can enforce it.

In the following topology I had a few different technologies to setup, so I created a clover-leaf type topology, where each leaf is a different tech, and you bridge them in the middle for seamless routing. I wrote out hopefully good instructions and requirements, as well as validation steps that should help those of you working the 'Unsolved' version, which you can download below.

Here's the topology:

Download the solved and unsolved versions here: http://1drv.ms/1rViikp

Good luck!
kyler

CCIE Route/Switch v5 GNS3 Lab: BGP Pathing, Scalability, Summarization (+ BONUS MPLS VPN, VRF)

Hey all,

This GNS3 lab covers a breadth of BGP and MPLS topics:
BGP pathing and route preference
BGP scalability using route-reflectors and peer-groups
BGP summarization and redistribution
MPLS VPN config using a redundant route-reflector config and private VRFs (similar to what ISPs use to create private networks for their customers)
MPLS basic interface config

The 'unsolved' version (which you can download below) has the IGPs and IPs configured for both the ISP network and both the HQ and remote network for CompanyA, which has asked you to come in and configure the BGP portions. Because you also work for the ISP, you'll need to configure their MPLS and BGP, configure an MPLS VPN, and configure private VRFs to keep the company's traffic separate. It's a big job - get started!

The topology looks like this:

You can download both the solved and unsolved GNS3 lab here: https://1drv.ms/f/s!AliOPzHSO-GngbgZiNH9YSAZv6hbhw

Good luck!
kyler