EIGRP Authentication

To illustrate the similarities (and differences) between OSPF and EIGRP, I will be using the same topology and IP addressing from my OSPF lab.

The assumed starting point with this lab is that all devices have been cabled, and IP addressing has been set on all serial, ethernet, and loopback adapters.  Since I already covered PPP authentication in my previous lab, you can either opt to enable it, or just enter encapsulation ppp on the interfaces and forgo the authentication.  EIGRP authentication will be enabled on the 10.0.0.0/8 network.

If you are continuing this lab directly after the OSPF lab, you can easily clear your OSPF settings, and keep everything else, by entering

R1(config)# no router ospf 1
R2(config)# no router ospf 1
R3(config)# no router ospf 1

Remember that with EIGRP, there aren't special neighbor relationship states like in OSPF.  Routers will either become neighbors with one another, or they will not, depending on if they pass the requirements to be neighbors-if you can't recall these, they are:

operating in the same subnet
both configured with the same AS number
matching K values
successful authentication

Interestingly, the hello timers do not need to match, however if you do modify the hello/dead timers, you need to ensure that the configuration will work, and a neighboring router's dead timer does not expire.

To begin, we will start at router R1.  Keeping in mind that we must use matching AS numbers, we will use the value 7 for our AS number on this network.  Like OSPF, EIGRP uses wildcard masks with its network statements.

R1(config)# router eigrp 7
R1(config-router)#network 10.0.0.0 255.0.0.0
R1(config-router)#network 172.30.1.0 0.0.0.255
R1(config-router)#network 192.100.254.0 0.0.0.3

R2(config)#router eigrp 7
R2(config-router)#network 10.0.0.0 255.0.0.0
R2(config-router)#network 172.30.2.0 0.0.0.255
R2(config-router)#network 192.100.254.0 0.0.0.3
R2(config-router)#network 192.100.254.4 0.0.0.3

R3(config)#router eigrp 7
R3(config-router)#network 10.0.0.0 255.0.0.0
R3(config-router)#network 172.30.3.0 0.0.0.255
R3(config-router)#network 192.100.254.4 0.0.0.3

Next, we will configure EIGRP authentication over the 10.0.0.0/8 network.  EIGRP authentication is slightly more complex then the configuration set on OSPF and has a few more features available.

EIGRP uses the concept of key chains.  These key chains can be given a lifespan, so that you can automatically rotate different passwords amongst the routers based on two parameters- accept-lifetime and send-lifetime.  The router dates and clocks must be synchronized in order for key lifetime to work correctly.

Starting on R1, our first step will be to create a key chain.

R1(config)#key chain red

Next, we define an individual key by giving it a number and a name

R1(config-keychain)#key 1
R1(config-keychain-key)#key-string LAN

In this lab, I won't be configuring lifetimes for the keys, but the command syntax is:
accept-lifetime [H:M:S] [month] [day number] [yyyy] [H:M:S] [month] [day number]

The send-lifetime command uses the same parameters.

Now we will instruct the router to use this key on its fa0/0 port

R1(config)#int fa0/0
R1(config-if)#ip authentication mode eigrp 7 md5
R1(config-if)#ip authentication key-chain eigrp 7 red

Now, for authentication to be successful (and for the neighbor relationships to form again) the key-strings and key numbers for R1, R2 and R3 must match.  The key chain name does not need to match.

R2(config)#key chain blue
R2(config-keychain)#key 1
R2(config-keychain-key)#key-string LAN
R2(config-keychain-key)#int fa0/0
R2(config-if)#ip authentication mode eigrp 7 md5
R2(config-if)#ip authentication key-chain eigrp 7 blue

R2 and R1 should now be neighbors on the 10.0.0.0/8 network.  You can confirm this with the command
show ip eigrp neighbors.  You will see 10.0.0.1 listed, but not 10.0.0.3 as authentication has not yet been configured on R3.

Authentication will now be configured on R3

R3(config)#key chain yellow
R3(config-keychain)#key 1
R3(config-keychain-key)#key-string LAN
R3(config-keychain-key)#int fa0/0
R3(config-if)#ip authentication mode eigrp 7 md5
R3(config-if)#ip authentication key-chain eigrp 7 yellow

Now, when you run show neighbors on R2, you will also see R3 as authentication matches between the three routers on the 10.0.0.0/8 network.

In a subsequent post, this lab will be expanded on and I will go into further detail about tweaking successor routes and feasible successor routes by changing the bandwidth and delay value on the links.

OSPF Lab

In this lab, we will be configuring OSPF using the following topology:

Routers R1, R2, and R3 will be connected both via ethernet links to SW1 and serial links between each other.  In my topology, I am using a NM-4A/S module on R2, so my link from R2 to R1 will be designated as S1/0 and from R2 to R3 will be S1/1.  All clocking will be configured on R2's serial links for simplicity.  PPP PAP authentication will be configured between R1 and R2, and PPP CHAP authentication between R2 and R3.

R1-3 will be configured to utilize OSPF  authentication with MD5 on the 10.0.0.0/8 network.

In this lab, we will manually configure R2 to be the DR for the ethernet network, and R1 to be the BDR.  The neighbors connected via serial link will become full neighbors as they are on a point to point type link.

The start of this lab will assume that all physical cabling has been completed, hostnames will be correctly configured on the routers and IP addresses on the serial, Ethernet, and loopback adapters have been set.  Verify connectivity by pinging all remote interfaces.

First, we will establish PPP connectivity on the serial links.  Starting at R1:

R1(config)#username R2 password pass!
R1(config)#int s0/0
R1(config-if)#encapsulation ppp
R1(config-if)#ppp authentication chap

You should see the line protocol on s0/0 drop at this point.  Lets resolve this problem by configuring PPP on R2's S1/0 link.

R2(config)#username R1 password pass!
R2(config)#int s1/0
R2(config-if)#encapsulation ppp
R2(config-if)#ppp authentication chap

Verify with a ping to IP address 192.100.254.1 from R2 that you have successfully configured CHAP.

Next, lets setup PPP with PAP on the serial link from R2 to R3.

R2(config)#username R3 password password!
R2(config-if)#int s1/1
R2(config-if)#encapsulation ppp
R2(config-if)#ppp authentication pap
R2(config-if)#ppp pap sent-username R2 password password!

R3(config)#username R2 password password!
R3(config)#int s0/0
R3(config-if)#encapsulation ppp
R3(config-if)#ppp authentication pap
R3(config-if)#ppp pap sent-username R3 password password!

At this point, you should be able to ping between R2 and R3.

Now that our PPP links have been configured, its time to configure OSPF on our routers.

Starting at R1 (and remember, the process id does not have to match with OSPF as it is purely a local concept, unlike EIGRP, but the area must match.)  Also, OSPF uses wildcard masks for the interfaces.  Pay close attention to the configuration.  A shortcut I use in determining the wildcard mask is to take the incremental value, and subtract is by one.  So for example, a /30 network has a incremental value of 4.  So the wildcard mask must be 0.0.0.3

R1(config)# router ospf 1
R1(config-router)#router-id 11.11.11.11
R1(config-router)#network 10.0.0.0 0.255.255.255 area 1
R1(config-router)#network 172.30.1.0 0.0.0.255 area 1
R1(config-router)#network 192.100.254.0 0.0.0.3 area 1


R2(config)# router ospf 1
R2(config-router)# router-id 12.12.12.12
R2(config-router)# network 10.0.0.0 0.255.255.255 area 1
R2(config-router)# network 172.30.2.0 0.0.0.255 area 1
R2(config-router)# network 192.100.254.0 0.0.0.3 area 1
R2(config-router)# network 192.100.254.4 0.0.0.3 area 1


R3(config)#router ospf 1
R3(config-router)#router-id 2.2.2.2
R3(config-router)#network 10.0.0.0 0.255.255.255 area 1
R3(config-router)#network 172.30.3.0 0.0.0.255 area 1
R3(config-router)#network 192.100.254.4 0.0.0.3 area 1

It is important to configure the RID first, if you want manual control over the election process.  Otherwise, the OSPF enabled router will use its loopback adapater as its RID.  If this were to happen, R3 would be the LAN's DR, and R2 would be the BDR.

At this point, our OSPF configuration should be complete.  Let's use some verification commands to ensure that things are operating the correctly.

Assuming a ping is successful between all devices,  lets see what running  show ip ospf neighbor reveals on each device.

As you can see, R2 is in fact the DR, and R1 is the BDR for the 10.0.0.0 network.  R3 is listed as a FULL/DROTHER.

Next, lets configure authentication between the three routers on the 10.0.0.0 network.

R1(config)#int fa0/0
R1(config-if)#ip ospf authentication message-digest
R1(config-if)#ip ospf message-digest-key 1 md5 Pass!


R2(config)#int fa0/0
R2(config-if)#ip ospf authentication message-digest
R2(config-if)#ip ospf message-digest-key 1 md5 Pass!


R3(config)#int fa0/0
R3(config-if)#ip ospf authentication message-digest
R3(config-if)#ip ospf message-digest-key 1 md5 Pass!

While entering these commands, you may lose a neighbor, but after succesfully entering all three sets of commands, you should re-establish your neighbor relationships.  If you haven't, ensure that you've spelt the key correctly amongst the devices, and enabled authentication on the correct interfaces.

At this point, the lab is complete according to the specifications set in the beginning. You can verify your configuration with the remaining commands:


show ip ospf interface -this is useful for verifying timers, neighbors, DR and BDR's and the OSPF area

show ip protocols - this command is useful for verifying the current timers 

show ip route ospf- lists out all routes learned by the OSPF routing protocol

Data-Link Protocol Overview

I'm going to provide an overview here of the different data-link protocols, and then as promised earlier, post an EIGRP lab and an OSPF lab, illustrating the differences in the configurations.  However I want to set these up in something of a more advanced lab, utilizing PPP with authentication.  Due to the complexity of Frame-Relay, it will get its own seperate lab and overview.

I'd rather not go too deep into the overall theory, as this information can be found elsewhere, instead I will provide a brief overview of the major features of each, along with how to configure these protocols.

WAN Data-Link Protocols

Three of the major configurable data-link protocols covered on the CCNA exam are:

HDLC
PPP
Frame-Relay

You can check to see what type of encapsulation an interface is using with the show int [interface] command.  The default for a ethernet port is "ARPA" which is ethernet type II.











HDLC

High-Level Data Link Control (HDLC) is fairly basic in terms of configuration compared to the other WAN data-link protocols.  It is set using the interface command encapsulation hdlc.  There is not much other configuration to be done with this protocol other then ensuring that both routers are using the same encapsulation protocol.  As far as the features offered by HDLC, they include identifying the protocol type with the 2 byte HDLC Protocol Type field, and error detection in the Frame Sequence Check (FCS) field in the data-link trailer.  The industry standard version of HDLC does not include the 2 byte type field, therefore, HDLC implemented on a Cisco router is only compatible with another Cisco router.
HDLC is the default encapsulation type used on a Cisco serial interface:

PPP

Compared to HDLC, the industry standard version of PPP (RFC 1661-by the IETF) contains the 2 byte Protocol Type field.  This means that a Cisco router using PPP on a serial link, is compatible with a non Cisco router utilizing the same layer 2 protocol on the opposing end of the link.

Besides the protocol type field, the other main features of PPP include:

Multi-link support
PAP/CHAP Authentication
Error Detection
Looped Link Detection

PPP relies on two protocols to operate-Link Control Protocol (LCP) and Network Control Protocol (NCP).  The LCP is responsible for initial link establishment, and then continues to exchange messages with the neighboring router to maintain the quality of the link.  NCP negotiates the network layer protocol which is sent over PPP.  You can find more detailed information about the initial link establishment in the RFC that I linked above.

For basic troubleshooting and configuration purposes, it is enough to know that to establish a PPP link, LCP must successfully complete an exchange with its neighboring router.  If this exchange is successful, the LCP Open state will be reached.  After the LCP Open state is reached, authentication, if it is enabled, will be performed, and if successfully passed, the NCP phase will begin.  There can be multiple NCPs per link.  Remember that NCP is used for layer 3 protocols, such as IP, AppleTalk, IPX, etc.  You can visually inspect the status of LCP and NCP with the command show interface [int]

As you can see in this example, LCP is closed.  This can be helpful in troubleshooting instances-if LCP is closed when you expect it to be open, you can start your troubleshooting process at layers 1 and 2.  If it is open and a ping fails, for example, you could probably start at layer 3.

In this example, I have set an IP address on both routers, used the interface command encapsulation ppp on both ends of the link, and then issued a show int s0/0 command.  You can see that LCP is open, and that "IPCP" and "CDPCP" NCP's are both open.  It might be confusing that these aren't displayed as "NCP".  Just remember to substitute where the "N" should be with whatever layer 3 protocol you are using when you are searching for the NCP state.

PPP Configuration


PPP isn't too complicated to configure.  First, the encapsulation must be changed from the HDLC default to PPP with the command encapsulation ppp on the desired interface(s).  Next, authentication can be configured-either PAP or CHAP.  Remember that CHAP is more secure than PAP, as it utilizes a 3 way handshake protocol, with CHAP replying to the challenge with a one way hash algorithm.

PAP is configured by issuing the command ppp authentication pap on the interfaces of both routers.  For this example, it will be between routers Seattle and Tacoma.

On router Seattle, the command ppp pap sent-username Seattle password pass!  is entered, also on the interface.  On router Tacoma, the command ppp pap sent-username Tacoma password pass! is entered.  At this point, the PAP authentication is complete.

Configuration CHAP authentication has two key differences from PAP authentication.  The first, is that the username/password is entered in global config mode.  The second, is that the username you are entering with this command, is the hostname of the neighboring router.  Continuing with the example using router's Tacoma and Seattle, the configuration would be:

In global config mode on Tacoma, username Seattle password pass! You would then switch to the interface and enter in ppp authentication chap

Next, in global config mode on Seattle, username Tacoma password pass!.  Followed with the interface command, ppp authentication chap.

Also available is the command ppp authentication chap pap which will instruct the router to attempt CHAP authentication first, and if that fails, PAP.

The last item of note is the keep-alive timer.  By default, the timer will be 10 seconds.  If a LCP keep alive message is not recieved within a number of keep alive cycles, the link will be terminated.  The keepalive is set on the serial link itself.  It is generally best to leave this setting alone.  The timer can be verified with the show interfaces command.

Troubleshooting/Debug

PPP verification can be seen with the commands

show interfaces -LCP status, NCP status, encapsulation type, keepalive time, clockrate
debug ppp authentication - here you can view the authentication messages sent and received by the router.  This could be useful for determining an authentication type mismatch.

EIGRP-Successors and Distance

The terminology describing the distance or metric as seen by a router and its neighbors in EIGRP can be confusing.  Lets start first with the Feasible Distance (FD) and Reported Distance (RD).

Feasible Distance: This is the calculated metric at the local router to a destination subnet
Reported Distance: This is the metric advertised, or reported, by an EIGRP neighbor to reach the advertised route.
It is easier to understand this concept with a diagram:

(These are hypothetical values)

R1's feasible distance to reach its directly attached fa0/0 subnet is 28,610.  When it advertises this route to R2 through either a topology exchange or a bounded update, it will advertise the metric as 28,610.  At R2, this is the reported distance.  R2 then takes into account the bandwidth and delay of its serial link to R1 in order to reach the 10.0.1.0/24 network.  This calculated metric is R2's feasible distance, or in this example 1,258,478.


The Feasibility Condition: Successor Routes and Feasible Successor Routes
Next, we have the terms Successor Route and Feasible Successor route.  A successor route is a route with the lowest metric to a destination subnet.  A Feasible Successor route is essentially a backup route, but it has to meet a certain condition in order to be eligible in EIGRP.  This "eligibility" is determined by what is called the "Feasibility Condition".  In order for a route to be considered a feasible route, it must have a RD that is lower than the successor route's FD.

Again, this is something that is easier to understand by seeing it in a network diagram.  I have again used hypothetical values RD/FD values to make it easier to understand the concept.

As you can see in the diagram, R2 is advertising a RD of 2,020,000.  R3 is advertising a RD of 220,000.  The FD from R4 to R1 is 280,000.  In order to meet the Feasibility Condition, a route's RD must be less then the successor route's FD.  R2's route clearly exceeds this with a RD of 2,020,000.  R3's RD on the other hand, is 220,000, which is less than the FD of the successor route on R4-280,000.  The route through R3 to R1's subnet is then considered a feasible successor route.

Terminology aside, in plain English: R3's route can be considered a valid backup route, since the metric R3 is reporting is lower then R4's best route metric.

In this instance, the successor route (R4-R1) would be installed in the routing table, and the feasible successor would be visible under a show ip eigrp topology


Remember though-there can in fact be more then one successor route.  Depending on the load balancing options configured on the router (the default is 4 equal metric routes), if four routes are found to have the best metric, and have equal metrics, all four of those routes will be successor routes and will be installed in the routing table.

There can also be multiple feasible successor routes, provided they meet the feasibility condition.  Feasible successor routes are not installed in the routing table, but can be seen in the EIGRP topology table.

 I'll explain the configuration details of equal and unequal load balancing in a later post.

EIGRP Theory

EIGRP- Enhanced Interior Gateway Routing Protocol
This is only meant to be a brief overview.  I will be posting about the DUAL algorithm, the "feasibility condition" and terminology (anyone who has worked with EIGRP knows how confusing the chosen terms can be), and configuration/verification in their own separate sets of posts.

EIGRP-The "hybrid" routing protocol.
EIGRP is known as a hybrid routing protocol.  Its metric can make use of bandwidth, delay, reliability, and load.  By default, only bandwidth and delay are used.  EIGRP does not send periodic updates, and routing information does not expire.  Instead, EIGRP is aware of its neighbor's connection status through the use of hello messages.  If these messages are not received within a specific interval time, and the hold timer expires, EIGRP declares the route to be down and can immediately change to a backup route (known as a feasible successor route) if it exists, or it will use the Diffusing Update Algorithm (DUAL) to send a series of queries to neighboring routers in search of a valid path to the destination subnet.

EIGRP can operate in both a classful and a classless addressing scheme.  It does enable auto-summarization by default, so this is something to watch out for if working in a discontinguous network, or one that utilizes VLSM.  Unlike OSPF, any router can make use of summary routes in order to reduce the size of the routing table.

EIGRP Neighbors
The concept of neighbors is similar to OSPF, but simpler as there are not different states of the neighbor relationship-routers either form a neighbor relationship, or do not form a relationship.

Routers may form a neighbor relationship if:
-They are operating in the same subnet
-The routers are both configured with the same Autonomous System (AS) number
-The K values on both routers match
-Both routers pass authentication, if configured

If these four parameters are successfully met, the two routers become neighbors and begin by initiating a full topology transfer using the Reliable Transport Protocol (RTP).  After this topology exchange, the routers continue to send periodic hellos to the multi-cast address of 224.0.0.10.  In the event of a topology change, the router will notify its neighbor with an EIGRP update message using either the multicast address of 224.0.0.10 on multi-access networks, or the router's unicast IP address in a point to point type of relationship.  Two terms are used to describe EIGRP's update messages-bounded and partial.  A partial update will contain new information such as when a route changes, or a link goes down.  These are only sent in the event of a topology change.  The term bounded means that the updates are only sent to routers that are affected by this new change in the network topology.

Timers
The default hello interval depends on the link type being used.  Usually, a router configured to operate on a multi-point nonbroadcast multiaccess (NMBA) network such as Frame Relay, will have a default hello interval of 60 seconds.  The default hold time is 3x the hello interval.  On most other networks, the hello interval defaults to 5 seconds.  Unlike OSPF, these timers do not have to match in order to form a valid neighbor relationship, however if the timers are configured incorrectly, and the hold timer expires before receiving another hello message from its neighbor, EIGRP will drop the adjacency.

DUAL FSM
DUAL FSM (finite state machine) is the algorithm used by EIGRP to calculate the best path to a destination subnet.  It works to provide loop-free paths, and backup loop-free paths, which can be put to immediate use.  If a link goes down, DUAL makes a logical decision depending on whether it has any valid backup routes in its topology table-directly install a backup route (feasible successor route-this will be explained in further detail later), or if a feasible successor route does not exist, it will place the destination subnet in a "active" state and send queries to its neighbors.  If the neighbors have a valid route to the destination subnet, one of the types of messages they will send back is a reply message with information about the route.

OSPF Metric Calculation

This post will go abit more into detail about the OSPF metric calculation and the different bandwidth commands that can be applied.

The basic idea behind OSPF metric calculation is adding outgoing interface costs from the source network to the destination network.  The SPF algorithm calculates this metric using the formula:

Reference Bandwidth  / Interface Bandwidth

This sounds easy enough, but a potential problem that can play into calculating the metric has to do with the  units used by the formula, and what units the router config command auto-cost reference <value> and the interface command bandwidth <value> use.  When the formula is applied by the SPF algorithm, IOS converts the units to use the same type- Mbps.

By default, an Ethernet interface will use the value 10,000 for its bandwidth.  This unit type is set in Kbps, in Mbps that would be converted to a value of 10.  The default reference bandwidth value is 100.  This value is set in Mbps.  So by default, an Ethernet cost will be calculated as 100/10 = 10

It is recommended to change the reference-bandwidth value when working with bandwidth speeds at or great then 100 Mbps, otherwise the cost for both a 1 Gbps interface, and a 100 Mbps interface would be the same : 1.

Alternatively, this formula can be overriden by manually setting the interface cost value within a range of 1-6535 by using the interface command ip ospf cost.  Do not confuse this command with ip ospf priority, this command is used to modify an interface's priority value to be used with a designated/backup designated router election.

To verify your configuration, you can use the command show ip ospf interface.  The output will list detailed information about the interface, along with the calculated cost.  This example shows the default bandwidth cost on a fast ethernet interface.

By default, the formula used was 100Mbps/100Mbps
Now we will modify the reference bandwidth value to use 1000 Mbps.

As you can see now, the formula was modified to 1000Mbps/100Mbps.

Key OSPF Concepts

OSPF is a link-state routing protocol, which uses the Dijkstra Shortest Path First (SPF) algorithm to determine the best routes to destination subnets.

There are three tables maintained by OSPF: neighbors, the link-state database, and the IP routing table.
These tables can be seen with the following commands:

show ip ospf neighbor
show ip ospf database
show ip route

Importance of the RID
OSPF routers are uniquely identified by a router ID, or RID.  There are three main ways a router derives its RID.

The first is that the RID is manually set while in router config mode with the command router-id [value]
The RID is a 32 bit dotted decimal ID.

The second, is that the router picks the highest IP address out of any loopback adapters configured, and in the up state.

The last method is that the highest IP address is chosen out of an interface where at least the first interface status is "up".  So an IP address assigned to an interface with a status of up, down could be selected if it was the highest address.

Requirements for OSPF routers to become neighbors:

-Be on the same subnet with matching masks and ID's
-Having matching Hello and Dead intervals
-Be operating in the same OSPF Area
-Exchange and pass any authentication configured

Hello messages include the sending RID, Area ID, Hello and Dead timer intervals, router priority, RID of the DR and BDR, and a list of "seen" or neighbors the router already has paired with.


OSPF routers have four different neighbor states:
-Down: the neighbor is not reachable
-Init: A Hello has been received, but it does not contain the local router's RID in the seen list.
-2-Way: The local router has recieved a Hello message with its own RID listed in the seen list from the neighboring router.  These two routers must then match the required parameters for becoming neighbors.
-Full: The neighbors having matching LSDB's and are considered to be fully adjacent.


Depending on the network topology, and the types of OSPF interfaces in use, some routers will not become fully adjacent.  In a multi-access network, there will be an elected DR and BDR router.  Other routers will become fully adjacent with the DR and BDR routers and be considered to have full adjaceny and have exchanged their topology information with the DR.  Non DR/BDR routers will be displayed as DROther in the neighbor table and their state will be 2-way.

DR/BDR Election
The router sending the highest OSPF priority will become the DR.  OSPF priority is configured by interface with the command ip ospf priority <value 0-255>.  If the value is set to 0, the router will exclude itself entirely from the election.  If there is a tie, it will be broken by whichever router has the highest RID.  If a new OSPF router enters the network after the election with a higher priority/RID, it will not cause another election cycle.

In a point to point situation, there will not be a DR/BDR election, and valid neighbors will become fully adjacent with each other.

The type of OSPF interface is configured with the interface command ip ospf network <broadcast, point-to-point>  There are other types, but they are outside the scope of the CCNA.  point-to-point is assumed on serial links, such as how broadcast is assumed on Ethernet interfaces.

LSDB Exchange
When two routers have matching LSDB databases, they are considered to be in full adjacency with one another.  This happens by the two routers exchanging lists of their LSA's with one another.  Any gaps in consistency of the received LSA lists and their own LSDB tables is solved by sending a request for the LSA in question.  Maintenance of the relationship between the two routers is performed by continuing to exchange hello's every hello interval (default, 10 seconds).  If a hello is not heard within the dead interval, the connection will be considered lost to the neighbor.  LSA's are flooded every 30 minutes by default, or if there is a change to the topology.

Selecting best paths
Path selection is performed by running the SPF algorithm.  The LSDB table does not itself identify the best route to the destination subnet.  The SPF algorithm operates by adding the OSPF cost for each outgoing interface between itself as the starting point, and the destination.  The route with the lowest cost is installed in the routing table.

Load Balancing
By default, OSPF load balances over four equal cost routes.  This can be adjusted, up to a maximum of 16, with the router config command maximum-paths <value>

Metric Calculation
The cost of each interface can be set manually using the ip ospf cost command, with a value between 1 and 65,535.
The router can calculate the cost itself by taking the reference bandwidth and dividing it by the interface bandwidth.

Authentication
There are three types that can be used by OSPF.  The commands are used per interface.

Null/none (default)
 ip ospf authentication null

Plaintext                
ip ospf authentication
ip ospf authentication-key <value>

MD5        
ip ospf authentication message-digest
ip ospf message-digest-key <key number> md5 <password>

Dynamic Routing Protocol Info

Some general information regarding the different routing protocols.

Administrative Distance Summary

Type
Connected	0
Static	1
BGP (external)	20
EIGRP (internal)	90
IGRP	100
OSPF	110
IS-IS	115
RIP	120
EIGRP (external)	170
BGP (internal)	200
Untrustable	255

Multi-cast addresses used 

RIP-2: 224.0.0.9
OSPF: 224.0.0.5, 224.0.0.6
EIGRP: 224.0.0.10

All except RIP-1 support manual summarization.
RIP and EIGRP support auto-summarization, OSPF does not.
Out of RIP, OSPF, EIGRP, and IS-IS, only EIGRP is Cisco proprietary.

Configuring RIP (v1)

RIP version 1 overview

-RIP v1 is a classful routing protocol, as a result, auto-summarization is used and subnet masks are not sent in routing updates.  RIP cannot be used in discontinguous networks.

-RIP determines the subnet mask for subnet ID's by looking at the address masks configured on its own interfaces for the classful network in question.  This is why a VLSM IP address scheme cannot be used.  If the router does not have any interfaces assigned to the address received in the routing update, RIP will assume the classful mask.

-Routing updates are sent as a broadcast by default every 30 seconds on UDP port 520

-RIP Timers

This can be a confusing topic, and in general, there is conflicting information on the operation of these timers. By default, RIP uses a 30 second update timer, a 180 second invalid timer, a 240 second flush timer, and a 180 second holddown timer.

Each time a routing advertisement is received for a particular route (30 seconds by default), the invalid and flush timers reset to zero and begin counting upwards.  If the invalid timer reaches 180 seconds, the route is marked as invalid, and the hold-down timer begins.  The flush timer counts alongside the invalid timer, and upon reaching 240 seconds, the route in question will be flushed from the routing table.

There is controversy concerning the operation of the hold-down timer.  The first, and most reoccurring theory  is that during the hold-down timer, the router can accept routes from any source as long as the metric is equal to, or lower then the original metric used for the route. This is what I saw happen in my physical lab.

The second theory is that the router cannot install any routes until the hold-down timer expires, regardless of the metric.

I tested this using physical lab equipment, and it seems that using the default settings and timers, the routers will accept a route from the original source, even if the hold-down timer has not yet expired, perhaps the router behavior is different based upon the IOS version in use.

My topology consisted of :

R1 LAN --->R1 ------ > R2 ------- > R3

When I set R1's serial link to not send RIP traffic (passive-interface s0/0 in router config mode), R2 continued to send updates to R3 every 30 seconds for R1's attached fa0/0 LAN.  After the invalid timer expired, R2 sent a poisoned route for R1's LAN out all interfaces-it increased the metric from 1 to 16, declaring it an invalid route.  When I re-enabled RIP traffic on R1's serial, R2 received the advertisement for R1's LAN, and before the hold-down timer had expired, installed the route and resumed forwarding advertisements with the correct metric to R3.

First Post!

After having my notes scattered across multiple notebooks, .doc files, and various note taking programs, I have decided to settle on using this blog to compile all of my notes and random Cisco related thoughts and questions.  I'll be keeping this fairly updated, and I plan on extending this past CCNA related material after I certify and move onwards to the CCNP.