Foundation Topics

Understanding OSPF Fundamentals

Rarely is a name as descriptive as the one given to this protocol—Open Shortest Path First (OSPF). OSPF is an open standard, defined in detail in many RFCs, including RFC 2328. OSPF uses the SPF algorithm to compute the best path to destinations. OSPF builds loop-free paths that converge quickly, but it often requires more processor power and memory than distance vector routing protocols. OSPF can also be more complicated because there are many topology and configuration options to consider.

OSPF is designed to offer flexibility in network design and, as an open standard, support linking routers from various vendors.

This section describes OSPF operation with the assumption that you have some experience with OSPF. Many of the details specific to the underlying OSPF operation are omitted, to focus on the important concepts appropriate to an Exam Certification Guide.

OSPF Snapshot

A link-state routing protocol is a sophisticated routing protocol based on the Dijkstra Shortest Path First (SPF) algorithm. When compared to distance-vector routing, link-state routing processes more information locally to reduce network traffic, trading additional memory and processor time for less bandwidth consumption. Link-state routing protocols record all possible routes, and therefore avoid many of the techniques required by distance-vector protocols to avoid loops.

OSPF, in particular, is a link-state routing protocol used within an autonomous system. It has a number of advantages over distance-vector routing protocols, including the following:

• OSPF is classless and allows summarization.

• It converges very quickly.

• OSPF is a standard, and ubiquitous support can be expected in a heterogeneous environment.

• It conserves network bandwidth.

• It uses multicasts instead of broadcasts.

• It sends incremental change-based updates.

• It uses cost as the metric.

Distance-vector routing protocols advertise routes to neighbors, but a link-state routing protocol advertises a list of its connections. When a link comes up or goes down, a link-state advertisement (LSA) is generated. In the context of link-state routing, a neighbor is simply a directly connected router, or a router on the opposing end of a WAN link, with the same network address (an exception to this is a virtual link, discussed in Chapter 7, "Using OSPF Across Multiple Areas"). LSAs are shared with neighbors and a topological database, also called a link-state database (LDSB) or topology table, is built. LSAs are marked with sequence numbers so that older or newer versions of an advertisement can be recognized; sequence numbers start at 0x8000 0001 and iterate to 0xFFFF FFFF before wrapping back around to 0x0000 00000. Eventually, every router in the same "area" has the same LSDB. Each router then processes this database using SPF and places the best routes into its routing table.

The topology database is the router view of the network within the area. It includes every OSPF router within the area and all the connected networks. This database is essentially a routing table—a routing table for which no path decisions have been made.

To view the current status of the link-state database, use the show ip opsf database command as shown in Example 5-1.

Example 5-1. The show ip ospf database Command Output

SanJose# show ip ospf database

OSPF Router with ID (140.100.32.10) (Process ID 100)



Router Link States (Area 3)

Link ID         ADV Router      Age         Seq#       Checksum Link count
140.100.17.131  140.100.17.131  471         0x80000008 0xA469   1
140.100.17.132  140.100.17.132  215         0x80000007 0xA467   1
140.100.17.194  140.100.17.194  1489        0x8000000B 0xFF16   1
140.100.23.1    140.100.23.1    505         0x80000006 0x56B3   1
140.100.32.10   140.100.32.10   512         0x8000000C 0x46BA   3
140.100.32.11   140.100.32.11   150         0x80000006 0x6A73   1
140.100.32.12   140.100.32.12   1135        0x80000002 0x8E30   1

Net Link States (Area 3)

Link ID         ADV Router      Age         Seq#       Checksum
140.100.17.130  140.100.23.1    220         0x80000007 0x3B42
140.100.17.194  140.100.17.194  1490        0x80000002 0x15C9
140.100.32.11   140.100.32.11   150         0x80000004 0x379E

To reiterate, the topology database is updated by the LSAs and each router within an area has exactly the same topology database. All routers must have the same view of the network; otherwise, routing loops or loss of connectivity will result.

As soon as a router realizes that there has been a change in the network topology, the router is responsible for informing the rest of the routers in the area. Typically, it will identify a change in the state of one of its links for one of the following reasons:

• The router loses the physical or data-link layer connectivity on a connected network.

• The router does not receive a predetermined number of consecutive OSPF hello messages.

• The router receives an LSA update from an adjacent neighbor, informing it of the change in the network topology.

In any of these instances, the router will generate an LSA and flood it to all its neighbors with the following stipulations:

• If the LSA is new, the route is added to the database, the route is flooded out other links so other routers are updated, and SPF is rerun.

• If the sequence number is the same as the current entry in the topology table, the router ignores the advertisement.

• If the sequence number is older, the router sends the newer copy (from memory) back to the advertiser to make sure that all neighbors have the latest LSA.

All OSPF operations center on populating and maintaining the following tables:

• Neighbor table

• Topology database

• Routing table

It is useful now to take a step back and focus on the relationships between pairs of OSPF speakers.

Neighbors and Adjacencies

OSPF develops neighbor relationships with routers on the same link by exchanging hello messages (sometimes shortened to hellos). Upon initial exchange of hello messages, the routers add each other to their respective neighbor tables. A neighbor table is a list of connected OSPF speakers (devices running OSPF). OSPF speakers send multicast hellos with destination address 224.0.0.5 on all OSPF-enabled interfaces. OSPF sends out hello packets every 10 seconds on a broadcast link and every 30 seconds on a nonbroadcast link. The contents of a hello message are shown in Table 5-2.

After two routers complete an initial exchange based on hellos, they go through a process of exchanging information about the network. After the routers have synchronized their information, they are adjacent. Figure 5-1 outlines the formal states that a neighbor relationship transitions through in the process of forming a "full" adjacency. Once full state is reached, tables must be kept up-to-date. LSAs are re-sent whenever there is a change, or every 30 minutes to keep them "fresh."

Figure 5-1. The States of Updating the Routers About the Network

[View full size image]

The following list describes each possible state of a neighbor relationship:

• Down— This is the first OSPF neighbor state. It means that no information (hellos) has been received from this neighbor.

• Attempt— This state is only valid for manually configured neighbors in an NBMA environment. In Attempt state, the router sends unicast hello packets every poll interval to the neighbor from which hellos have not been received within the dead interval.

• Init— This state indicates that the router has received a hello packet from its neighbor, but the receiving router's ID was not included in the hello packet.

• 2-Way— This state indicates that bi-directional communication has been established between two routers.

• Exstart— Once the DR and BDR are elected, the actual process of exchanging link-state information can start between the routers and their DR and BDR.

• Exchange— In the exchange state, OSPF routers exchange database descriptor (DBD) packets.

• Loading— In this state, the actual exchange of link-state information occurs.

• Full— In this state, routers are fully adjacent with each other. All the router and network LSAs are exchanged and the router databases are fully synchronized.

Hellos continue to be sent periodically and the adjacency is maintained as long as hellos are exchanged. Missing hello messages result in a router declaring the adjacency dead.

As soon as OSPF identifies a problem, it modifies its LSAs accordingly and sends the updated LSAs to the remaining neighbors (with full adjacencies). Being event-driven, this LSA process intrinsically improves convergence time and reduces the amount of information that needs to be sent across the network.

One key piece of information exchanged in LSAs is OSPF metric information.

Many OSPF vendor implementations assign each link a cost of 10. The Cisco implementation makes cost inversely proportional to 100 Mbps, as follows:

An administrator can override this default cost. Typically, this is done for compatibility with other OSPF speakers or because some links are faster than 100 Mbps.

Sometimes the metric is equivalent for multiple paths to a destination. In this case, OSPF will load balance over each of the equivalent interfaces. Cisco routers will automatically perform equal-cost load balancing for up to four paths, but this parameter can be increased by configuration to as many as sixteen paths.

The cost is applied to the outgoing interface. The routing process will select the lowest cumulative cost to a remote network.

Designated Router and Backup Designated Router

If routers are connected to a broadcast segment (for example, when several routers in one VLAN are on the same switch) then one router on the segment is assigned the duty of maintaining adjacencies with all other segment routers. This job is known as the designated router (DR) and the responsible router is selected using information in hello messages. For redundancy, a backup designated router (BDR) is also elected.

DRs are created on multiaccess links because the number of adjacencies grows at a quadratic rate. For a network of n routers, the number of adjacencies required would be

Two routers require the following adjacencies:

Four routers require the following adjacencies:

Ten routers require the following adjacencies:

As you can see, maintaining the segment consumes increasingly more bandwidth and processing as the number of routing devices increases.

The purpose of a DR is to be the one router to which all other routers are adjacent. Using a DR reduces the number of adjacencies that consume bandwidth and processing to n – 1. Yes, larger networks still involve more processing, but with a DR, the adjacencies scale with the network. This growth rate is shown in Table 5-3 and illustrated in Figure 5-2.

Figure 5-2. Adjacencies from Table 5-3

[View full size image]

The role of the DR is to receive updates and distribute them to each segment router, making sure that each router acknowledges receipt and has a synchronized copy of the LSDB. Routers advertise changes to the "AllDRs" multicast address, 224.0.0.6. The DRs then advertise the LSA using the "AllSPF" multicast address, 224.0.0.5. Each router then acknowledges receipt.

The BDR listens passively to this exchange and maintains a relationship with all the routers. If the DR stops producing hellos, the BDR promotes itself and assumes that role.

Note that DRs and BDRs are only useful on multiaccess links because they reduce adjacencies. The concept of a DR is not used on point-to-point links because there can be only one adjacency.

If a DR fails, the BDR is promoted. The BDR is elected on the basis of highest OSPF priority and ties are broken in favor of the highest IP address. The default priority is 1 and a priority of 0 prevents a router from being elected. Priority can be set from 0–255; to change the priority from its default for a particular interface, use the following command:

Router(config-if)# ip ospf priority number

DRs are stable—even if a better candidate joins the network the DR will not change.

To put this description in context, consider the network shown in Figure 5-3. There are five routers, A through E, with priorities ranging from zero to three. Intuitively, you might expect that A would be the DR, that B would be the BDR, and that E would never let itself be elected. Generally, this is true, but it neglects some important details.

Imagine that Router C starts first. Router C sends out hellos and waits the dead time for a response. Receiving no response, Router C conducts an election and becomes the BDR. Because there is no DR, Router C promotes itself to DR. Next, suppose that Router E starts. Router E has a priority of zero, so it will not become the BDR. Router B starts third and is elected BDR. Router A and Router D start last.

In this scenario, Router C is the DR and Router B is the BDR—not what we expected. This is because designated routers do not preempt—once elected they serve until they are rebooted. If Router C restarts, Router B promotes itself to DR and Router A is elected BDR while Router C is down. If Router B goes down, Router A promotes itself and elects Router C or Router D (whichever has the highest IP address). Finally, when the BDR is rebooted, Router B wins the election for BDR.

Multiple Areas

An OSPF area is a logical grouping of routers that are running OSPF with identical topological databases. An area is a subdivision of the OSPF routing domain. Each area runs SPF separately and summaries are passed between each area.

This section begins with a description of the problems associated with single-area networks, and then discusses how multiple-area structures overcome problems specific to a large single area.

Problems with OSPF in a Single Area

Consider a growing OSPF network with a single area. Several problems emerge in relation to capacity:

• The SPF algorithm runs more frequently. The larger the network, the greater the probability of a network change and a recalculation of the entire area. Each recalculation in a large network takes longer and involves more work than recalculations in a small area.

• The larger the area, the greater the size of the routing table. The routing table is not sent out wholesale, as in a distance vector routing protocol. However, the greater the size of the table, the longer each lookup becomes. The memory requirements on the router also increase as the size of the table increases.

• In a large network, the topological database increases in size and eventually becomes unmanageable. The topology table is exchanged between adjacent routers at least every 30 minutes.

As the various databases increase in size and the calculations increase in frequency, the CPU utilization increases while the available memory decreases. This can affect network latency or cause link congestion, resulting in various additional problems, such as convergence time, loss of connectivity, loss of packets, and system hangs.

Area Structure

OSPF creates a two-level hierarchy of areas. Area zero (also called the backbone area or transit area) is always the central area; all other areas attach to area zero. Area zero forms the top level in the hierarchy and the remaining areas form the bottom level of the hierarchy. This hierarchical design supports summarization and minimizes routing table entries.

Routers in area zero are called backbone routers. Routers that link area zero and another area are called Area Border Routers (ABR). OSPF routers that redistribute routing information from another routing protocol are called Autonomous System Boundary Routers (ASBR).

OSPF Packet Types

As OSPF link-state information is shared between areas, an intricate set of mechanisms is followed, relying on a number of different OSPF packet types. All OSPF traffic is transmitted inside IP packets. Receivers recognize OSPF traffic because it is marked as IP protocol 89.

OSPF includes five packet types:

• Hello packets— Establish communication with directly attached neighbors.

• Database Descriptor (DBD)— Sends a list of router IDs from whom the router has an LSA and the current sequence number. This information is used to compare information about the network.

• Link State Requests (LSR)— Follow DBDs to ask for any missing LSAs.

• Link State update (LSU)— Replies to a link-state request with the requested data.

• Link-state acknowledgements (LSAck)— Confirm receipt of link-state information.

All OSPF packets have a common format that contains the following nine fields:

• Version— All packets are assumed to be version 2 in this chapter. OSPF version 3 is discussed in the context of IPv6 in Part VIII of this book.

• Type— There are five packet types, numbered 1 to 5.

• Packet Length— The length in bytes.

• Router ID— 32-bit identifier for the router.

• Area ID— 32-bit identifier for the area.

• Checksum— Standard 16-bit checksum.

• Authentication Type— OSPFv2 supports three authentication methods:

  - no authentication

  - plaintext passwords

  - MD5 hashes

• Authentication Data— 64-bit data, either empty, with a plain-text word, or with a "message digest" of a shared secret.

• Data— Values being communicated.

Configuring OSPF in a Single Area

This section examines the configuration of a Cisco router for OSPF within a single area. The commands are few in number and relatively simple; the implications of the commands on the network are somewhat more complicated.

Required Commands for Configuring OSPF Within a Single Area

In this section, you learn to configure an internal OSPF router. An internal router is one in which all interfaces lie within a single area. The sole OSPF function of an internal router is to route within the area.

The router needs to understand how to participate in the OSPF network, as defined by the following parameters:

• OSPF process— Declare an OSPF process.

• Participating interfaces— Identify the interfaces to be used by OSPF.

• Area— Define area per interface. This discussion assumes that all active interfaces are in the same area.

• Router ID— A unique 32-bit ID, usually drawn from an interface IP address.

The following subsections describe the commands required for configuring OSPF on a single internal router.

Enabling the OSPF Routing Protocol

To configure OSPF as the routing protocol, use the following command:

Router(config)# router ospf process-number

Here, process-number is not globally significant. It is possible to have more than one process running on a router (although that would be an unusual configuration) and two OSPF processes could route for different parts of the network. The process number does not have to be the same on every router in the area.

The OSPF network Command

Once OSPF is turned on, you must define the interfaces that are to participate in OSPF and the area that they reside in by using the following command:

Router(config-router)# network network-number wildcard-mask area area-number

					  

Like RIP, the network command identifies the interfaces on which OSPF is to be active. Unlike RIP, this command has a wildcard mask that allows it to be very specific. All interfaces that match the network wildcard pattern will be active in OSPF in the given area.

The area parameter places the interface in an area. A router can have different interfaces in different areas (and thus be an ABR). The area-number is a 32-bit field and the format can either be a simple decimal or in dotted-decimal format. Some implementations of OSPF might only understand one of the formats, but the Cisco IOS accepts either form.

After identifying the interfaces on the router that are participating in the OSPF domain, hellos are exchanged, LSAs are sent, and the router inserts itself into the network.

You can apply the network command in different ways, yet each way achieves similar results.

Imagine that a router has the following interfaces:

• FastEthernet 0/0: 192.168.100.1/24

• FastEthernet 0/1: 192.168.101.1/24

• FastEthernet 0/2: 192.168.102.1/24

• FastEthernet 0/3: 192.168.103.1/24

• Serial 1/0: 10.100.100.1/30

• Serial 1/1: 10.100.100.5/30

It is possible to enable OSPF area 0 on all interfaces with the following command:

Router(router-config)# network 0.0.0.0 255.255.255.255 area 0

Another way of achieving the same result is to break up the command into the 10 networks and the 192 networks, as follows:

Router(router-config)# network 10.0.0.0 0.255.255.255 area 0
Router(router-config)# network 192.168.100.0 0.0.3.255 area 0

A third way is to enable it independently on each interface, as follows:

Router(router-config)# network 192.168.100.1 0.0.0.0 area 0
Router(router-config)# network 192.168.101.1 0.0.0.0 area 0
Router(router-config)# network 192.168.102.1 0.0.0.0 area 0
Router(router-config)# network 192.168.103.1 0.0.0.0 area 0
Router(router-config)# network 10.100.100.1 0.0.0.0 area 0
Router(router-config)# network 10.100.100.5 0.0.0.0 area 0

These three examples achieve exactly the same result. All six interfaces are enabled, placed in area 0, and begin to process OSPF traffic.

By using the first approach (one all-encompassing statement), you may inadvertently include interfaces that you might not want included. The third option involves a lot of typing, but gives the administrator more control. The technique you choose to use is a function of your particular network topology, and generally you should choose the technique that is the most straightforward to document and explain. You need to be intimately familiar with the use of the wildcard mask with the network command to enable OSPF on router interfaces.

Configuration Options for an Internal Router

The following options allow you to tune the OSPF configuration of an internal router:

• Router ID

• Loopback interface

• cost command

• priority command

Defining the Router ID and Loopback Interfaces

The router needs an ID to participate in the OSPF domain. The router ID is used to identify LSAs in the OSPF database. The router ID can be defined by an administrator or left to the discretion of the router. Most people define the ID so that it is easier to track events in the network, for internal documentation, and for other system-administration purposes.

The OSPF router ID can be defined by the router-id command. If the router-id command is not present, then the router ID will be the highest IP address of a loopback interface. If no loopbacks are present, then the router ID will be the highest IP address of the first active interface.

Generally, using the router-id command is not recommended because BGP and OSPF normally pick a router ID the same way. Manually specifying a router ID can result in these IDs differing, which can be a source of problems with BGP operation.

Router(config)# router ospf
Router(config-router)# router-id ip-address

The preferred way to control the router ID is to use a loopback interface address. A loopback interface is a virtual interface and is always active. The following shows how to configure a loopback interface:

Router(config)# interface loopback interface-number
Router(config-if)# ip address ip-address subnet-mask

Loopbacks are typically assigned a /32 mask to minimize their use of address space.

Once the router ID of the router has been chosen, the router ID is stable and is not subject to the flippancy of physical interfaces on a router. Changing the router ID can break some OSPF configurations, such as virtual links. Loopback interfaces, which do not physically exist, can never go down and are therefore more stable than physical interfaces.

Changing the Default Cost

The cost metric is calculated as 100,000,000 bps divided by the bandwidth of the interface in bits per second. Sometimes—especially when dealing with faster lines or other vendor routers that use a different cost—it is useful to change this default value. The cost command manually overrides the default:

Router(config-if)# ip ospf cost cost

Cost is a 16-bit value (0 to 65,535) and lower values are preferred. Table 5-4 shows examples of default costs

As shown in Table 5-4, the calculation of bandwidth gives Fast Ethernet and Gigabit Ethernet a metric of 1. In this situation, you might want to manipulate the default cost to prefer the faster path.

A second way to deal with high-bandwidth paths is to change the numerator in the automatic calculation. The ospf auto-cost reference-bandwidth router-configuration command changes the numerator in the metric formula to account for higher speeds:

Router(config-router)# ospf auto-cost reference-bandwidth reference-bandwidth

					  

Here, reference-bandwidth is in megabytes per second. The range is 1 to 4,294,967; the default is 100. Set it to 1000 to give Gigabit links a cost of 1 and FastEthernet paths a cost of 10.

Determining the Designated Router Using the priority Command

Remember that hello messages include a priority field and thus provide a mechanism by which the DR and BDR are elected. To be "up for election," the priority must be a positive integer between 1 and 255. If its priority is 0, the router cannot participate in the election. Otherwise, highest priority wins. All Cisco routers have a default priority of 1, and the highest router ID is used as a tiebreaker. As previously discussed in the "Electing DRs and BDRs" section, the command to adjust priority on an interface-by-interface basis is

Router(config-if)# ip ospf priority number

A Working Configuration of OSPF on a Single Router

Example 5-2 is a working configuration of OSPF on a single router. The Charlotte router will be the DR on F1/0 unless another device on the segment has a priority greater than 100. The link attached to F1/0 has a cost of 1. The cost on F3/0 has been changed to 10.

Example 5-2. Configuring OSPF

Charlotte(config)# router ospf 100
Charlotte(config-router)# network 140.100.0.0 0.0.255.255 area 3
Charlotte(config-router)# interface FastEthernet1/0
Charlotte(config-if)# ip address 140.100.17.129 255.255.255.240
Charlotte(config-if)# ip ospf priority 100
Charlotte(config-if)# interface FastEthernet3/0
Charlotte(config-if)# ip address 140.100.17.193 255.255.255.240
Charlotte(config-if)# ip ospf cost 10

Checking the Configuration of Single-Area OSPF

The set of commands shown in Table 5-5 configuration and maintenance of a live OSPF network.

The OSPF show commands are very detailed and give a comprehensive understanding of the state of the network. You need to understand the concepts in this chapter to interpret the output of the show commands provided in subsequent sections.

The show ip ospf Command

The show ip ospf command shows how OSPF is running on a particular router. It includes the number of times that the SPF routing algorithm has run, which is indicative of the stability of the network. To issue the command, use the following syntax:

Router# show ip ospf [process-id]

Example 5-3 shows the output of this command. Table 5-6 explains how to interpret this information.

Example 5-3. The show ip ospf process-id Command Output

SanJose# show ip ospf 100
 Routing Process "ospf 100" with ID 140.100.32.10
 Supports only single TOS(TOS0) routes
It is an internal router
 SPF schedule delay 5 secs, Hold time between two SPFs 10 secs
 Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs
 Number of external LSA 0. Checksum Sum 0x0
 Number of DCbitless external LSA 0
 Number of DoNotAge external LSA 0
 Number of areas in this router is 1. 1 normal 0 stub 0 nssa
    Area 3
    Number of interfaces in this area is 3
    Area has no authentication
    SPF algorithm executed 10 times
    Area ranges are
    Link State Update Interval is 00:30:00 and due in 00:18:54
    Link State Age Interval is 00:20:00 and due in 00:08:53
    Number of DCbitless LSA 2
    Number of indication LSA 0
    Number of DoNotAge LSA 0

The show ip ospf database Command

The show ip ospf database command displays the contents of the router's topological database and the different LSAs that have populated the database:

Internal routers, the primary subject of this chapter, will only display router and network LSAs. This command has many parameters that enable you to examine very specific information.

Example 5-4 shows the output of the show ip ospf database command. Table 5-7 explains the important fields.

Example 5-4. The show ip ospf database Command Output

SanJose# show ip ospf database

       OSPF Router with ID (140.100.32.10) (Process ID 100)


        Router Link States (Area 3)

Link ID         ADV Router      Age         Seq#       Checksum Link count
140.100.17.131  140.100.17.131  471         0x80000008 0xA469   1
140.100.17.132  140.100.17.132  215         0x80000007 0xA467   1
140.100.17.194  140.100.17.194  1489        0x8000000B 0xFF16   1
140.100.23.1    140.100.23.1    505         0x80000006 0x56B3   1
140.100.32.10   140.100.32.10   512         0x8000000C 0x46BA   3
140.100.32.11   140.100.32.11   150         0x80000006 0x6A73   1
140.100.32.12   140.100.32.12   1135        0x80000002 0x8E30   1

        Net Link States (Area 3)
Link ID         ADV Router      Age         Seq#       Checksum
140.100.17.130  140.100.23.1    220         0x80000007 0x3B42
140.100.17.194  140.100.17.194  1490        0x80000002 0x15C9
140.100.32.11    140.100.32.11    150         0x80000004  0x379E

Table 5-7. Explanation of the show ip ospf database Command Output

Field	Explanation
OSPF Router with ID (140.100.32.10) (Process ID 100)	Router ID and process ID of this router.
Router Link States (Area 3)	The router LSAs, showing the links connecting the router to neighbors discovered via the Hello protocol.
Link ID	The link ID, which is the same as the OSPF router ID.
ADV Router	Router ID of the advertising router.
Age	Time (in seconds) since the last update.
Seq #	The sequence number.
Checksum	The checksum on the entire LSA update. Ensures integrity.
CCNP BSCI Official Exam Certification Guide, Fourth Edition - Graphically Rich Book About the Author About the Contributors About the Technical Reviewers Acknowledgments Icons Used in This Book Command Syntax Conventions Foreword Introduction Part I: Introduction to Scalable Networks Chapter 1. Network Design "Do I Know This Already?" Quiz Foundation Topics Foundation Summary Q&A Chapter 2. IP Address Planning and Summarization "Do I Know This Already?" Quiz Foundation Topics Foundation Summary Q&A Part II: EIGRP Chapter 3. EIGRP Principles "Do I Know This Already?" Quiz Foundation Topics Foundation Summary Q&A Chapter 4. Scalable EIGRP "Do I Know This Already?" Quiz Foundation Topics Foundation Summary Q&A Scenarios Scenario Answers Part III: OSPF Chapter 5. Understanding Simple Single-Area OSPF "Do I Know This Already?" Quiz Foundation Topics Foundation Summary Q&A Scenarios Scenario Answers Chapter 6. OSPF Network Topologies "Do I Know This Already?" Quiz Foundation Topics Foundation Summary Q&A Chapter 7. Using OSPF Across Multiple Areas "Do I Know This Already?" Quiz Foundation Topics Foundation Summary Q&A Scenarios Scenario Answers Chapter 8. OSPF Advanced Topics "Do I Know This Already?" Quiz Foundation Topics Foundation Summary Q&A Part IV: IS-IS Chapter 9. Fundamentals of the Integrated IS-IS Protocol "Do I Know This Already?" Quiz Foundation Topics Foundation Summary Q&A Chapter 10. Configuring Integrated IS-IS "Do I Know This Already?" Quiz Foundation Topics Foundation Summary Q&A Scenarios Scenario Answers Part V: Cisco IOS Routing Features Chapter 11. Implementing Redistribution and Controlling Routing Updates "Do I Know This Already?" Quiz Foundation Topics Foundation Summary Q&A Scenario Scenario Answers Chapter 12. Controlling Redistribution with Route Maps "Do I Know This Already?" Quiz Foundation Topics Foundation Summary Q&A Chapter 13. Dynamic Host Control Protocol "Do I Know This Already?" Quiz Foundation Topics Foundation Summary Q&A Part VI: BGP Chapter 14. BGP Concepts "Do I Know This Already?" Quiz Foundation Topics Foundation Summary Q&A Chapter 15. BGP Neighbors "Do I Know This Already?" Quiz Foundation Topics Foundation Summary Q&A Scenarios Scenario Answers Chapter 16. Controlling BGP Route Selection "Do I Know This Already?" Quiz Foundation Topics Foundation Summary Q&A Scenarios Scenario Answers Part VII: Multicasting Chapter 17. What Is Multicasting? "Do I Know This Already?" Quiz Foundation Topics Foundation Summary Q&A Chapter 18. IGMP "Do I Know This Already?" Quiz Foundation Topics Foundation Summary Q&A Chapter 19. Configuring Multicast "Do I Know This Already?" Quiz Foundation Topics Foundation Summary Q&A Part VIII: IPv6 Chapter 20. Introduction to IPv6 and IPv6 Addressing "Do I Know This Already?" Quiz Foundation Topics Foundation Summary Q&A Scenarios Chapter 21. IPv6 Routing Protocols, Configuration, and Transitioning from IPv4 "Do I Know This Already?" Quiz Foundation Topics Foundation Summary Q&A Scenarios Appendix A. Answers to Chapter "Do I Know This Already?" Quizzes and Q&A Sections Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9 Chapter 10 Chapter 11 Chapter 12 Chapter 13 Chapter 14 Chapter 15 Chapter 16 Chapter 17 Chapter 18 Chapter 19 Chapter 20 Chapter 21 Remember the name: eTutorials.org Copyright eTutorials.org 2008-2023. All rights reserved.