OSPF

So between work and packing for a move and trying to study, I finally finished the OSPF section of the INE workbook.  This covered quite a bit of the OSPF configuration and so I got a few lessons learned that bit me in the butt or things that I feel I need to remember.

When enabling OSPF on an interface with secondary addresses, the secondary is auto-magically added to OSPF unless the command ip ospf <proc-id> area <area> secondaries none is given.

I also learned that I have to get it through my thick head that the default OSPF network type for DMVPN is point-to-point.  That works for when you only have one peer but let's be real.  If have only one endpoint, then why would you use DMVPN?  The network type needs to be changed on each site, hub and spoke, to another type.

So, we all know about DR elections and how they basically work but what about the time that it takes for the election to complete.  That time is not configurable with an OSPF specific command but is equal to the dead time.  So if the test says make the election process to complete in 3 seconds, make the dead time 3 seconds and WHAMMO.  Just remember to do this on all the neighbors on that segment so that relationships form.

When using the P2P network type, there are not Type 2 LSAs that are sent.  The Type-1 LSAs include both the network segment and the information about the neighboring OSPF router.

When using P2MP non-broadcast, there is nothing in the output of show ip ospf interface or show ip ospf interface brief that shows that it is non-broadcast.  Difference can be seen in the debug output when unicast packets are send to the configured neighbors.

If you are trying to use bandwidth to manipulate routes, change the bandwidth on the interface that is in the opposite area on the ABR.  This will change the metric since it will be used for calculations when the LSA is sent into the desired area.

With capability transit on by default, a router with a virtual-link does not have to use the virtual-link if the router has another path that is shorter (smaller metric).  Turning this off, forces the router to use the virtual-link path.  In the case of the land that I just did, there were three routers on the segment.  Two of them had virtual-links to each other.  The object was to force the router that had to have the virtual-link to not use the shorter path through the third router.  By default, since capability transit was on, the router always picked it since it advertised a smaller metric.  After turning off capability transit, the router would route to the other side of the virtual-link first and that router would then router to the third router.  Basically, it created inefficient routing but was able to show the capability.

To suppress hellos, you can use the P2P network type and combine that with deman circuit functionality to suppress pacing and aging.  Makes for a quiet OSPF process.  It must be huntin' wabbits.

 I had a lab where I had to configure multiple keys on an interface for MD5 authentication on the hub router.  The routers using key 1 would not come up.  Debugging showed that the router was not sending key 1.  I had to remove the key and re-add it to all the needed routers and then I cleared the process.  After that, all the routers came up.  Only thing that I can think of is that my code hiccuped.

I tried to do SHA authentication on IOS 15.2(4)S, IOU/L 15.3(1)3T, and IOU/L 15.4(1)T.  I could only use it on the 15.4 code.  Great fun there.  Also with SHA, HMAC-SHA-256 is the only version specified in the RFC.  Wouldn't surprise me if they say on the test use the version of SHA that is in RFC 5709.  Another interesting fact about SHA.  It cannot be used on virtual-links.  Have to stick with good ole MD5 there.

When using the area range command, the area ID that the command asks for is the area where the routes are being summarized from.  This is not the area ID that is being summarized to.

NSSA Type-7 translation is done by default by the router with the highest router-id that connects to area 0 from the NSSA area.

The area filter-list command has in and out options.  With the in optio, it applies the prefix-list to the area with routes coming from other areas.  With the out option, it applies the filter to routes coming from the specified area to all other areas on the router.

Distribute-lists for OSPF only affect the local routing table and not the OSPF database.  The same can be seen with the distance comamnd.

When using route-maps with distribute-lists, the filtering is only on traffic coming in and only for the local routing table.  If does not affect the OSPF database in any way. 

I need to pay more attention to the command line line listing for distribute-list when looking at it on Cisco's web page.  It has again bit me in the buttocks when I looked at it for route-maps.  The syntax is

distribute-list {{access-list-name | access-list-number | gateway prefix-list-name | prefix prefix-list-name [gateway prefix-list-name]} in [interface-type interface-number] | route-map route-map-name in}


When using the summary-address command with not-advertise, it will not only filter the route from the routing table as it goes out but it will also remove it from the local database.  This means that it won't get advertised to the router neighbors.  This functionality is done on external routes being translated at an ABR from the NSSA area.  The route will still show up as a Type-7 (NSSA External) in the database of the NSSA routers.

The database filter option filters all LSAs going to a specific neighbor or out of a specific interface.  It still allows relationships to form and LSAs to come in from neighbors but none are sent to the neighbor or out the interface.