DMVPN Part 1

So I briefly covered some points about DMVPN here from a night when I did a lab and wanted to remember some of it. I thought for my own sake I'd step back and really examine DMVPN. So back to the textbook.

DMVPN stands for "Dynamic Multipoint VPN". It is a way of creating dynamic VPNs for an organisation. This should remove the overhead of configuring individual VPNs. DMVPNs are ALWAYS setup in a hub & spoke configuration.

I've gone through the steps in the book using my home lab:

1. Basic Configuration of IP Addresses

Pretty easy... my routers are all connected to my switch and have 192.168.123.0/24 range IP addresses on their fast ethernet interfaces.

2. GRE Multipoint Tunnel configuration on all routers (for spoke-to-spoke connectivity).

This can be broken down further into two steps. Setup NHRP and setup mGRE - both of these are done under the tunnel interface.

An example of this is:

This is done on each router, however you don't have to do the nhrp map command to the hub router on the spoke routers. These are the commands underlined in red. They are not required on the hub router.

The authentication command is optional.

This can be verified using the following command:

The coolest thing about this is that we have two tunnels from the hub router to the spoke routers, but if the spoke routers decide to communicate, they will dynamically build a tunnel between them. Imagine in a DMVPN network, this is pretty useful.

Could do this all day!! It's so cool. However, the default operation of DMVPN is to send traffic as clear text. :O

3. Configure IPsec to Encrypt mGRE Tunnels

Apply IPsec to the configuration involves:

1. Setting up the crypto isakmp policy
2. Setting a key with the ip address 0.0.0.0 (because of the dynamic IP setting)
3. Setting up a transform set
4. Setting up an IPsec profile
5. Applying the profile to the tunnel interface

OSPF Basics

Taking advantage of my serial ports, doing some OSPF.

There are two ways to setup OSPF:

1. Under the interface using "ip ospf <process-id> area <area-id>"
2. Under the routing process using the network command

If both are configured, the interface command supersedes the setting under the routing process. So for example if an interface is configured both ways with different areas, the area given under the interface will be the one used.

OSPF Cost = Reference/Bandwidth

New rack!

This post has nothing to do with my CCIE journey... but a bit about my home lab. I'm changing jobs this week after 6 years and the guys at work (knowing my CCIE lab and study) decided to buy me a rack as a farewell gift. *sob*

At first I thought assembling it was some sort of punishment for leaving:

Tossed up mounting it on the wall (it has a wall mount), putting it on wheels (it has wheels too!) but opted to keep it on my buffet just so I have fast easy access to re-cable and power the routers and switches as often as I want to.

Here is the back. I still haven't put on the side panels, the back or the front.

And here is the front:

I think technically the rack costs more than the equipment in it. I'm not sure I'll include its price in my CCIE lab setup since I didn't pay for it. :)

Serial, serial... :(

Having problems with my serial ports at the moment, I think one of the network modules I received last week has a hardware fault. I've tried unbelievable number of combinations, but whether its the DCE, DTE and in multiple different routers, whenever I bring up the port it takes a few seconds and then it throws a "Level 2 Watch Dog Timeout" error and reboots the router.

See exhibit A below :(

I guess you win some and lose some. $55 wasted.

DMVPN Phase 1

DMVPN Phase 1 uses mGRE and NHRP.

To setup DMVPN Phase 1 do the following steps on each router:
1. setup mGRE config, use "tunnel mode gre multipoint" on the hub router
2. configure NHRP - network ID & mapping

Smartport Macros

I vaguely remember using these as a younger network engineer and possibly not understanding them well. It was just our SOP (Standard Operating Procedure) to apply the macro to the interface as the switch was set up or modified.

These are pretty simple to understand and save heaps of time. :)

The old way is below. Here you define the macro first and apply them to the ports that require it.

The new way (which I think seems a lot less intuitive), firstly you define the ports you want and then apply to macro to them.

Spanning-Tree BPDUs

Firstly introducing the newest member to the "Kylie's CCIE Lab" family. I found it really hard to find an affordable Layer 3 switch for my at home lab. Layer 3 switches seem to be a lot more expensive than routers. This 3560 cost me $90 plus $10 postage. I also got a second serial card for $55. This brings the total cost of my lab up to $430 so far. Things are getting serious.

Here's a photo of my new switch sitting on my routers. :)

I spent a bit of time today reviewing spanning tree protections.

BPDU Guard

Can be enabled globally or per interface (for portfast ports)

Puts a port into err-disable status if a BPDU is received on it

BPDU Filter

Drops BPDUs both inbound and outbound on an interface.

If enabled per interface, it can cause a switching loop because it will just silently and continually drop BPDUs both inbound and outbound. This is a way of terminating a STP domain.

Enabling it globally is safer. It is only enabled on portfast ports and will terminate when a BPDU is received. The port will go into STP negotiation.

Root Guard

Similar to BPDU Guard, except it only errdisables the port if the BPDU is declaring that it is coming from a superior root bridge.

LoopGuard & UDLD 

'nuff said :P

Something new... (for me)

How cool is the errdisable recovery feature. In production this could cause a lot of flapping on a port, but when testing BPDUguard it is great. Using "errdisable recovery interval 120", the interface comes back up every 2 minutes and errors again.