"Everything you'll ever need to know about OSPF" is a bold statement but is goes back to "Mastering the Foundations" something I've been saying for the past 25 days. If you can master these OSPF foundations the rest is icing on the cake.
PRO-TIP: Don't treat this as a long list of items to memorize but rather a checklist of topics to lab up.
Default Behavior
Won't start unless OSPF can determine a router-id
Router-id determined:
Configured router-id
Highest loopback IP address
Highest interface IP address
Every router within an area must have the same OSPF database
Filtering/Summaries happen at the ABR
Default Priority = 1, highest priority becomes the DR (where applicable)
A Priority of "0" means router will NOT participate in DR/BDR elections.
OSPF Network Types
Broadcast
Default for Ethernet interfaces
Elects DR/BDR
Uses Multicast
Allows more than 2 routers on a link
Timers: Hello - 10, Dead - 40
Non-Broadcast
Elects a DR/BDR
Uses Unicast (neighbor statements)
Allows more the 2 routers on a link
Timers: Hello - 30, Dead - 120
Point-to-Point
Default for Serial and Tunnel interfaces
Does NOT elect DR/BDR
Uses Multicast
Only 2 routers allowed on a link
Timers: Hello - 10, Dead - 40
Point-to-MultiPoint
Does NOT elect DR/BDR
Uses Multicast
Allows more than 2 routers on a link
Installs /32 host routes per neighbor
Timers: Hello - 30, Dead - 120
Point-to-MultiPoint Non-Broadcast
Does NOT elect DR/BDR
Uses Unicast (neighbor statements)
Allows more than 2 routers on a link
Installs /32 host routes per neighbor
Timers: Hello - 30, Dead - 120
Loopback
Default for Loopback interfaces
When included in OSPF, uses a /32
To advertise with mask other-than /32, manually set network type to "point-to-point"
LSA Types
LSA Type-1: Router LSA's
Originated from each router
Flooded within an area
Tells the area about all the links participating in OSPF and are associated with that area
LSA Type-2: Network LSA's
Originated by the DR
Only DR can originate Type-2 LSA's (If there is no DR their aren't any Type-2's)
This LSA tells all the routers in an area about all the routers on a shared medium like Ethernet
LSA Type-3: Summary LSA's
Originated by an ABR
Carry the destination network prefixes from one area into another
From nonbackbone > backbone
Connected Routes
Intra-Area Routes
From backbone > nonbackbone
Connected Routes
Intra-Area Routes
Inter-Area Routes
LSA Type-4: ASBR-Summary LSA's
Originated by an ABR
Tells all the other areas about the ASBR
Tells all the other areas "to get to this Router-ID(ASBR) go through Me(ABR)!"
LSA Type-5: External LSA's
Originated by an ASBR
Flooded through out the OSPF domain, except into stubby areas
Contains the Network prefix and subnet-mask for the external network
LSA Type-7: NSSA External LSA's
Originated by ASBR
Exist only in a Not-So-Stubby Area (NSSA)
Are NOT flooded outside the area they were originated
tl;dr - After failure, success tastes so much sweeter.
Today was all over the map. This morning I came into the labs charging like a bull. I wanted to do IPv6 DMVPN and I did! I was successful. That carried me on a little engineering high knowing I had done something I have never tried before that seemed so foreign and came out of the battle victorious.
But, I'm wise enough to know anyone can get lucky once, but very few get lucky twice.
So I wiped the routers and did it again, minimal errors and mostly from memory... success.
While I was completing my second run through the configs and topology I got an idea for a topology and a challenge: Dual Stack - Multi Hub - DMVPN
I felt comfortable enough with my understanding of the component technologies that I felt could pull it off and I shrugged "what the hell... we'll do it live". (https://www.youtube.com/watch?v=eUFY8Zw0Bag)
As I began the recording I can be quoted as saying something to the effect of "this might take about 30 minutes"... 65 minutes later I ended up at a dead end and I failed.
I got burned by a couple of items:
I had to pull off the tunnel protection on the IPv4 DMVPN and put it back on for it too work. I'm not sure if this is a bug or have I unknowingly fell victim of order of operations and I didn't know it?
Others were oversights and mis-configurations.
Have a Process:
When ever I'm writing configs they rarely look like the running-configs from a routers output or are in the same order, instead I build them in layers, like a cake.
Think ahead about all the elements that you'll need to complete a task.
Which configurable elements can be grouped and entered at the same time?
In-between layers, what can you verify?
Following the process from above I would order the tasks as follows:
Underlay (NBMA) addresses, connectivty
Loopbacks
Crypto
Tunnel Interface for IPv4 topology
Routing protocol for IPv4 topology
Verify
Tunnel interface for IPv6 topology
Routing Protocol for IPv6 topology
Verify
The Resources:
I found this group of documents extremely helpful from all aspects of this configuration. It includes specifics on IPv6 addressing which I still wasn't to keen on, but know I'm much more comfortable. It also broke down the elements we need for the IPv6 DMVPN.
!Hub int tun 0 ip add 10.123.234.1 255.255.255.0 tunnel source Gi0/0 tunnel mode gre multipoint no shut !Spoke int tun 0 ip add 10.123.234.2 255.255.255.0 tunnel source Gi0/0 tunneldestination 10.123.234.1 no shut ! Broke R2#sho int tun 0 Tunnel0 is up, line protocol is down Hardware is Tunnel Internet address is 10.123.234.2/24 MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel linestate evaluation down - no output interface Tunnel source 172.17.100.2 (GigabitEthernet0/0), destination 10.123.234.1 Tunnel Subblocks: src-track: Tunnel0 source tracking subblock associated with GigabitEthernet0/0 Set of tunnels with source GigabitEthernet0/0, 1 member (includes iterators), on interface <OK> Tunnel protocol/transport GRE/IP Key disabled, sequencing disabled Checksumming of packets disabled Tunnel TTL 255, Fast tunneling enabled Tunnel transport MTU 1476 bytes Tunnel transmit bandwidth 8000 (kbps) Tunnel receive bandwidth 8000 (kbps) Last input never, output never, output hang never Lesson Learned: I made the error of incorrectly defining the tunnel destination. I defined it as the remote tunnel interface when actually I needed to use the public NBMA address.
Tunnel0 source tracking subblock associated with GigabitEthernet0/0
Set of tunnels with source GigabitEthernet0/0, 1 member (includes iterators), on interface <OK>
Tunnel protocol/transport GRE/IP
Key disabled, sequencing disabled
Checksumming of packets disabled
Tunnel TTL 255, Fast tunneling enabled
Tunnel transport MTU 1476 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Last input never, output never, output hang never
Explanation: The tunnel interface linestate stays down until it has a valid exit interface and route to the remote tunnel destination.
#2 Lesson Learned - Tunnel Keepalives
In the output below you can see "Keepalive not set". Tunnel keepalives are not set by default. You can configure keepalives under the tunnel interface. You can do this be specifying just the keyword "keepalive" and press enter. This will give you the default value of keepalives sent every 10 seconds and will retry 3 times before considering the tunnel down. Conversely you can specify the keepalive values( example 5 seconds) the retry values can also be set but if they are excluded will default to 3 retries.
R4#sho int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.123.234.4/24
MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
[ ... output omitted ... ]
Keepalive with default values
R3(config-if)#keepalive ?
<0-32767> Keepalive period (default 10 seconds)
<cr>
R3(config-if)#keepalive
R3(config-if)#
R3(config-if)#do sho int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.123.234.3/24
MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive set (10 sec), retries 3
[ ... output omitted ... ]
Keepalive with defined values
R4(config)#int tun 0
R4(config-if)#keepalive 5 R4(config-if)#end R4# R4#sho int tun 0
Tunnel0 is up, line protocol is up Hardware is Tunnel Internet address is 10.123.234.4/24 MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive set (5 sec), retries 3
