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.

STP Timers, Uplinkfast, Backbone fast

Tonight was a revision of standard STP, 802.1D
(PS - I hope over the year my studying will become more insightful :P)

Timers

The default timers for Spanning Tree are:

Hello = 2s

Max-age = 20s

Forward-delay 15s

To speed up spanning-tree convergence, these timers can by modified. 

Interesting points:

• Timers are always learnt from the root bridge.
• The forward-delay is how long the port stays in each the listening and learning states. So if the forward-delay is set to 15s it will take 30s for the port to move to the forwarding state

Portfast

Portfast makes a port go straight to forwarding. It can be enabled on an interface or set as the default in global configuration, only affecting access ports.

Interesting points:

• You can force portfast on a trunk port by using the command "spanning-tree portfast trunk". This is useful for servers such as ESX which may have a trunk to it. 
• Portfast should never be used on a port connecting to another switch, but if a port configured for portfast receives a BPDU it will process it and can move into blocking if needed.

An example below of bringing up a port that is configured as a trunk for portfast. Each VLAN goes directly to forwarding.

UplinkFast

This is a Cisco propriety feature only available for use with 802.1D because all of the rapid spanning tree protocols have their own means for speeding up convergence of STP

This is set with a global configuration command and speeds up convergence for a direct failure of the root port happens.

The example below shows how when the root port is shut down a new root port is immediately moved into forwarding.

BackboneFast

BackboneFast is similar to UplinkFast in that it is Cisco Proprietry, also only useful with 802.1D and is a global configuration command. It speeds up convergence when an indirect failure occurs by sending our Root Link Queries (RLQ)

Something else I learnt today while reading about RPVST+ is that portfast is a necessity, not just something that is nice to have.

Serial, serial, oh my!!

So I ordered a serial network module for my routers which arrived today.

This isn't the greatest value purchase. At $55 including delivery, it actually cost the same amount as the routers. :( But it does give me 5 times as many ports to play with.

Anyway... I only bought one so I actually can't connect to anything. :( But it works and I've ordered another one to compliment it.

This takes the total cost of my home lab to $280 + $110 = $390. So far! Things are getting serious.

BGP

I took the time tonight to review setting up neighbour relationships in BGP. I have to admit, the 2811 routers with the latest IOS in my home lab work brilliantly for this.

I went over IBGP neighbours, eBGP neighbours (above). Re-acquainted myself with the output of "sh ip bgp" and had a quick go at version 4 peer-group config.

Tonight I reviewed the basics of BGP which I really needed. :(

Incidentally, I did the Cisco BGP course about 4 years ago with a scary little CCIE who reminded me a lot of Ben Chang from Community. If someone in the class forgot something like the AD of a routing protocol he would yell at them, 'This is an advanced course!!'. He scared me into being pretty good at BGP and I sat the exam 2 days after the course. I can just imagine how mad he'd be at me now. :P

OSPF Broadcast & Route Redistribution Basics

Intro

I have tomorrow off work so I've kind of spent a bit of time tonight working out what I can do with my baby lab (it definitely needs to grow more... but there's still a bit you can do with 4 routers and a layer 2 switch). I'm pretty tired now and ready to collapse into bed, but I thought I'd do a quick update.

Here's what my lab looks like at the moment (no rack yet... its definitely a work in progress and the goal is to add to it each payday. I think the rack will be my final purchase)

So what can I play around with this setup. Well, I did some OSPF broadcast (makes sense) and then did a little bit of route redistribution.

OSPF Broadcast

So when OSPF is run on an ethernet interface it is automatically assumed to be in a broadcast network. Here is the output of my R1 in a OSPF broadcast network situation:

Some points I learnt about OSPF broadcast networks tonight are:

• as mentioned ethernet defaults to broadcast
• the timers set to 10s for Hellos, 40s for Dead Timer
• the broadcast address is 224.0.0.5
• and although the DR router sends the updates, the next hop stays the originating router

Route Redistribution

I was getting pretty tired by this stage, but here is my R1 with RIP, Inter-Area OSPF, External EIGRP and External OSPF routes.

I guess the main takeaway I got from this is that every routing protocol uses its own metric:

• RIP: hop count
• EIGRP: a formula based on bandwidth, delay, reliability, load & mtu
• OSPF: cost based on bandwidth

When redistributing routes into RIP you have to set a metric for the hop count. 3 is good, anything higher than 16 is ignored.

When redistributing routes into EIGRP you have to set values for all 5 values used in the formula. Apparently mtu isn't used but you still have to set it. It seems pretty standard to just use 1, 1, 1, 1, 1

When redistributing routes into OSPF you don't have to set a value for the metric, OSPF defaults to a metric of 20 with a metric-type of 2.

EIGRP Route Filtering

Narbik's EIGRP Lab 4 - Route Filtering

There are THREE ways of filtering routes from the EIGRP process

Hop Count

By default EIGRP will discard routes that have a hop count higher than 101, but you can configure a different maximum hop count in the EIGRP process by using:

metric maximum-hops %d

Using this will reject any routes that have a hop count greater than %d

Distribute List

Firstly you define an access list that specifies the route you want to filter, and then under the EIGRP process you use the following command:

distribute-list xxx in f0/0

xxx is the number of the access list. This will filter the route from the table. The access-list is written with the source-address being the advertising neighbor and the destination-address being the route.

Distance

Distance can be used to filter routes or improve routes. Again using an access list to specify the route you want to change, under the eigrp routing process use the following command:

distance %metric a.b.c.d 0.0.0.0 xx

where a.b.c.d is the neighbor, %metric is the Administrative Distance (AD) and xx is the access-list number. By default EIGRP has a AD of 90. This can be changed lower to make the route preferred, or if you change it to 255 it will remove the route from the table!