Switch Catalyst Password Recovery

Procedure with Password Recovery Enabled

If the password-recovery mechanism is enabled, this message appears: The system has been interrupted prior to initializing the flash file system.

The following commands will initialize the flash file system, and finish loading the operating system software:




Step 1 Initialize the flash file system:

switch: flash_init

Step 2 If you had set the console port speed to anything other than 9600, it has been reset to that particular speed.

Change the emulation software line speed to match that of the switch console port.

Step 3 Load any helper files:

switch: load_helper

Step 4 Display the contents of flash memory:

switch: dir flash:

The switch file system appears:

Directory of flash:

13  drwx         192   Mar 01 1993 22:30:48

11  -rwx        5825   Mar 01 1993 22:31:59  config.text

18  -rwx         720   Mar 01 1993 02:21:30  vlan.dat

16128000 bytes total (10003456 bytes free)

Step 5 Rename the configuration file to config.text.old.

This file contains the password definition.

switch: rename flash:config.text flash:config.text.old

Step 6 Boot the system:

switch: boot

You are prompted to start the setup program. Enter N at the prompt:

Continue with the configuration dialog? [yes/no]: N

Step 7 At the switch prompt, enter privileged EXEC mode:

Switch> enable

Step 8 Rename the configuration file to its original name:

Switch# rename flash:config.text.old flash:config.text

Step 9 Copy the configuration file into memory:

Switch# copy flash:config.text system:running-config

Source filename [config.text]?

Destination filename [running-config]?

Press Return in response to the confirmation prompts.

The configuration file is now reloaded, and you can change the password.

Step 10 Enter global configuration mode:

Switch# configure terminal

Step 11 Change the password:

Switch (config)# enable secret password

The secret password can be from 1 to 25 alphanumeric characters, can start with a number, is case sensitive, and allows spaces but ignores leading spaces.

Step 12 Return to privileged EXEC mode:

Switch (config)# exit


Step 13 Write the running configuration to the startup configuration file:

Switch# copy running-config startup-config

The new password is now in the startup configuration.

Note This procedure is likely to leave your switch virtual interface in a shutdown state. You can see which interface is in this state by entering the show running-config privileged EXEC command. To re-enable the interface, enter the interface vlan vlan-id global configuration command, and specify the VLAN ID of the shutdown interface. With the switch in interface configuration mode, enter the no shutdown command.

Step 14 Reload the switch:

Switch# reload

Source : http://www.cisco.com






OSPF is a link-state interior gateway protocol designed for a large complex network. An IETF standard, OSPF is widely deployed in many large networks. Development began in 1987, and OSPF Version 2 was established in 1991 with RFC 1247. The goal was to have a link-state protocol that is more efficient and scalable than RIP. RFC 2328 (April 1998) is the latest revision to OSPF Version 2.

OSPF runs on top of IP and uses protocol number 89, just as TCP runs on top of IP and uses protocol number 6. OSPF doesn’t use any transport protocol, such as TCP, for reliability. The protocol itself has a reliable mechanism of transportation.

OSPF is a classless routing protocol that supports variable-length subnet masking (VLSM) and discontiguous networks. OSPF employs multicast addresses (all SPF routers) and (designated routers [DR] and backup designated routers [BDR]) to send Hellos and updates. OSPF also provides two types of authentication—plain text and message digest algorithm 5 (MD5).

OSPF uses the Dijkstra algorithm as a part of the routing table calculation process. The Dijkstra algorithm produces the shortest-path tree (SPT). Each router represents itself and its links to the neighbors in an understandable form—link-state advertisements (LSAs). Based on information from the shortest path tree, OSPF can draw the network topology.

Each router in OSPF exchanges information about its cost, type of link, and network information with the other routers. This multistep process is called link-state advertisement (LSA) exchange.

Operation of OSPF

At a very high level, the operation of OSPF is easily explained:

  1. OSPF-speaking routers send Hello packets out all OSPF-enabled interfaces. If two routers sharing a common data link agree on certain parameters specified in their respective Hello packets, they will become neighbors.
  2. OSPF defines several network types and several router types. The establishment of an adjacency is determined by the types of routers exchanging Hellos and the type of network over which the Hellos are exchanged.
  3. Each router sends link-state advertisements (LSAs) over all adjacencies. The LSAs describe all of the router’s links, or interfaces, the router’s neighbors, and the state of the links. Because of the varying types of link-state information, OSPF defines multiple LSA types.
  4. Each router receiving an LSA from a neighbor records the LSA in its link-state database and sends a copy of the LSA to all of its other neighbors.
  5. By flooding LSAs throughout an area, all routers will build identical link-state databases.
  6. When the databases are complete, each router uses the SPF algorithm to calculate a loop-free graph describing the shortest (lowest cost) path to every known destination, with itself as the root. This graph is the SPF tree
  7. Each router builds its route table from its SPF tree.

When all link-state information has been flooded to all routers in an area and neighbors have verified that their databases are identical that is, the link-state databases have been synchronized and the route tables have been built, OSPF is a quiet protocol. Hello packets are exchanged between neighbors as keepalives, and LSAs are retransmitted every 30 minutes. If the network topology is stable, no other activity should occur.

Neighbors and Adjacencies

Before any LSAs can be sent, OSPF routers must discover their neighbors and establish adjacencies. The neighbors will be recorded in a neighbor table, along with the link (interface) on which each neighbor is located and which contains other information necessary for the maintenance of the neighbor.

The tracking of other OSPF routers requires that each router have a Router ID, an IP address by which the router is uniquely identified within the OSPF domain. Cisco routers derive their Router IDs by the following means:

1. If the Router ID has been manually configured using the router-id command, that Router ID is used.

2. If no Router ID has been manually configured, the router chooses the numerically highest IP address on any of its loopback interfaces.

3. If no loopback interfaces are configured with IP addresses, the router chooses the numerically highest IP address on any of its physical interfaces. The interface from which the Router ID is taken does not have to be running OSPF.

Using addresses associated with loopback interfaces has two advantages:

  • • The loopback interface is more stable than any physical interface. It is active when the router boots up, and it only fails if the entire router fails.
  • • The network administrator has more leeway in assigning predictable or recognizable addresses as the Router IDs.

The Cisco OSPF will continue to use a Router ID learned from a physical interface even if the interface subsequently fails or is deleted. Therefore, the stability of a loopback interface is only a minor advantage. The primary benefit is the ability to control the Router ID.

The OSPF router begins a neighbor relationship by advertising its Router ID in Hello packets.

Hello Protocol

The Hello protocol serves several purposes:

  • • It is the means by which neighbors are discovered.
  • • It advertises several parameters on which two routers must agree before they can become neighbors.
  • • Hello packets act as keepalives between neighbors.
  • • It ensures bidirectional communication between neighbors.
  • • It elects Designated Routers (DRs) and Backup Designated Routers (BDRs) on Broadcast and Nonbroadcast Multiaccess (NBMA) networks.

OSPF-speaking routers periodically send a Hello packet out each OSPF-enabled interface. This period is known as the HelloInterval and is configured on a per interface basis. Cisco uses a default HelloInterval of 10 seconds for broadcast networks and 30 seconds for non-broadcast; the value can be changed with the command ip ospf hello-interval. If a router has not heard a Hello from a neighbor within a period of time known as the RouterDeadInterval, it will declare the neighbor down. The Cisco default RouterDeadInterval is four times the HelloInterval and can be changed with the command ip ospf dead-interval.

Each Hello packet contains the following information:

  • • Router ID of the originating router.
  • • Area ID of the originating router interface.
  • • Address mask of the originating interface.
  • • Authentication type and authentication information for the originating interface.
  • • HelloInterval of the originating interface.
  • • RouterDeadInterval of the originating interface.
  • • Router Priority.
  • • DR and BDR.
  • • Five flag bits signifying optional capabilities.
  • • Router IDs of the originating router’s neighbors. This list contains only routers from which Hellos were heard on the originating interface within the last RouterDeadInterval.
  • • When a router receives a Hello from a neighbor, it will verify that the Area ID, Authentication, Network Mask, HelloInterval, RouterDeadInterval, and Options values match the values configured on the receiving interface. If they do not, the packet is dropped and no adjacency is established.
  • • Whenever a router sends a Hello, it includes in the packet the Router IDs of all neighbors listed for the link on which the packet is to be transmitted. If a router receives a valid Hello in which it finds its own Router ID listed, the router knows that two-way communication has been established.
  • • After two-way communication has been established, adjacencies may be established. However, as mentioned earlier, not all neighbors will become adjacent. Whether an adjacency is formed or not depends on the type of network to which the two neighbors are attached. Network types also influence the way in which OSPF packets are transmitted; therefore, before discussing adjacencies, it is necessary to discuss network types.

Route Table

  • • The Dijkstra algorithm is used to calculate the Shortest Path Tree from the LSAs in the link state database.
  • • OSPF determines the shortest path based on an arbitrary metric called cost, which is assigned to each interface. The cost of a route is the sum of the costs of all the outgoing interfaces to a destination. RFC 2328 does not specify any values for cost. Cisco routers calculate a default OSPF cost as 108/BW, where BW is the configured bandwidth of the interface and 108 is the reference bandwidth. As discussed previously, the default reference bandwidth can be changed with the command auto-cost reference-bandwidth. Fractional costs are rounded down to the nearest whole number.
  • • The command ip ospf cost can be used to override the default automatic cost calculations and assign a fixed cost to an interface. LSAs record cost in a 16-bit field, so the total cost of an interface can range from 1 to 65535.

Network Types

OSPF defines five network types:

Point-to-point networks

Point-to-point networks, such as a T1, DS-3, or SONET link, connect a single pair of routers. Valid neighbors on point-to-point networks will always become adjacent. The destination address of OSPF packets on these networks will always be the reserved class D address, known as AllSPFRouters.

Broadcast networks

Broadcast networks are multi-access in that they are capable of connecting more than two devices, and they are broadcast in that all attached devices can receive a single transmitted packet. OSPF routers on broadcast networks will elect a DR and a BDR.

Nonbroadcast Multiaccess (NBMA) networks

NBMA networks, such as X.25, Frame Relay, and ATM, are capable of connecting more than two routers but have no broadcast capability. A packet sent by one of the attached routers would not be received by all other attached routers. As a result, extra configuration might be necessary for routers on these networks to acquire their neighbors. OSPF routers on NBMA networks elect a DR and BDR, and all OSPF packets are unicast.

Point-to-multipoint networks are a special configuration of NBMA networks in which the networks are treated as a collection of point-to-point links. Routers on these networks do not elect a DR and BDR, and the OSPF packets are unicast to each known neighbor.

Virtual links, described later, are special configurations that are interpreted by the router as unnumbered point-to-point networks. OSPF packets are unicast over virtual links.

OSPF Packet Details

OSPF Protocol Header Format

Database Description Packet Format

  • Interface MTU— This field contains the largest data size, in bytes, that can be send through the associated interface. This option has been added starting from RFC 2178. This field must be set to 0 when sending the packet over a virtual link.
  • Options— Options for this field were discussed in the previous section on the Hello packet format.
  • I Bit— When set to 1, this means that this is the first packet in DBD exchange.
  • M Bit— When set to 1, this means that more packets will follow.
  • MS Bit— Use this for master and slave. When this bit is set, it means that the router is a master in the DBD exchange process. If this bit is set to 0, it means that the router is the slave.
  • DBD Sequence Number— This field contains a unique value set by the master. This sequence number is used during database exchange. Only a master can increment the sequence number.
  • LSA Header— This field consists of a list of the link-state database headers.

Link-State Request Packet Format

  • LS Type— Identifies what type of LSA is being requested.
  • Link-State ID— Represents the link-state ID of that specific LSA.
  • Advertising Router— Contains the router ID of the router that is originating this LSA.

Link-State Update Packet Format

Link-State Acknowledgment Packet

The last type of OSPF packet, the link-state acknowledgment packet, is used to acknowledge each LSA. This packet is sent in response to link-state update packets. Multiple LSAs can be acknowledged in a single link-state acknowledgment packet. This packet is responsible for the reliable delivery of link-state update packets.

OSPF Areas

OSPF provides two levels of hierarchy throughout an area. An area is a 32-bit number that can be defined such as “Area 0.” Area 0 is a backbone area, which is required if more than one area is configured. All areas must be connected to Area 0.

OSPF has several types of areas, which can be defined according to the needs of a network:

Normal Areas

  • • When the area is defined by default, it is considered a normal or regular area. Normal areas have the following characteristics:
  • • Summary LSAs from other areas are injected.
  • • External LSAs are injected.
  • • External default LSAs can be injected.

Stub Areas

In stub areas, no external LSAs are allowed.

Stub areas have the following characteristics:

  • • Summary LSAs from other areas are injected.
  • • The default route is injected as a summary route.
  • • External LSAs are not injected.

Configuring Area 1 as a Stub Area

RouterF# router ospf 1

area 1 stub

Totally Stubby Areas

Totally stubby areas are the most restricted form of area. Routers in this type of area rely on only the injection of a default summary route from the ABR. No other external or summary information is included in the routing table. This is an extension to the stub area, so all the characteristics are still true for this area. This area has the following characteristics:

  • • No summary LSAs are allowed.
  • • No external LSAs are allowed.
  • • The default route is injected as a summary route.

Configuring the ABR to Make Area 1 Totally Stubby

  • • RouterF# router ospf 1

area 1 stub no-summary

Not-So-Stubby Areas

This is also an extension of the stub area. NSSAs were created to inject external routes from stub areas into the OSPF domain. In the NSSA, when the ASBR injects a route into the AS, it generates a Type 7 LSA. The ABR translates this LSA to a Type 5 LSA, which is propagated to the rest of the autonomous system. The Type 7 LSA flooding scope is within the NSSA area.

NSSAs have the following characteristics:

  • • Type 7 LSAs carry external information within an NSSA.
  • • Type 7 LSAs are converted into Type 5 LSAs at the NSSA ABR.
  • • No external LSA are allowed.
  • • Summary LSAs are injected.

Configuring an NSSA on All the Routers in the NSSA Area

RouterF# router ospf 1

area 1 nssa

Totally Not-So-Stubby Areas

This type of area is an extension to the NSSA. If only one exit point exists, this is the most recommended form of NSSA area type.

  • • No summary LSAs are allowed.
  • • No external LSAs are allowed.
  • • The default route is injected as a summary route.
  • • Type 7 LSAs are converted into Type 5 LSAs at the NSSA ABR.
  • Configuration on the NSSA ABR, for Totally NSSA Area
  • • RouterF# router ospf 1

area 1 nssa no-summary

OSPF LSA Details

LSA Type 1, Router LSAs are produced by every router. This most fundamental LSA lists all of a router’s links, or interfaces, the state and outgoing cost of each link, and any known OSPF neighbors on the link. These LSAs are flooded only within the area in which they are originated.

LSA Type 2, Network LSAs are produced by the DR on every multi-access network. The DR represents the multi-access network and all attached routers as a pseudonode, or a single virtual router. In this sense, a Network LSA represents a pseudonode just as a Router LSA represents a single physical router. The Network LSA lists all attached routers, including the DR itself. Like Router LSAs, Network LSAs are flooded only within the originating area.

LSA Type 3, Network Summary LSAs are originated by ABRs. They are sent into a single area to advertise destinations outside that area. In effect, these LSAs are the means by which an ABR tells the internal routers of an attached area what destinations the ABR can reach. An ABR also advertises the destinations within its attached areas into the backbone with Network Summary LSAs. Default routes external to the area, but internal to the OSPF autonomous system, are also advertised by this LSA type.

LSA Type 4, ASBR Summary LSAs are also originated by ABRs. ASBR Summary LSAs are identical to Network Summary LSAs except that the destination they advertise is an ASBR not a network. The command show ip ospf database asbr-summary is used to display ASBR Summary LSAs .

LSA Type 5, Autonomous System External LSAs, or External LSAs, are originated by ASBRs. They advertise either a destination external to the OSPF autonomous system, or a default route external to the OSPF autonomous system. External LSAs are flooded throughout the autonomous system.

LSA Type 6, Group Membership LSAs are used in an enhancement of OSPF known as Multicast OSPF (MOSPF). MOSPF routes packets from a single source to multiple destinations, or group members, which share a class D multicast address. Although Cisco supports other multicast routing protocols, MOSPF is not supported as of this writing.

LSA Type 7, NSSA External LSAs are originated by ASBRs within not-so-stubby areas (NSSAs). An NSSA External LSA is almost identical to an AS External LSA, as the section on OSPF packet formats shows. Unlike AS External LSAs, which are flooded throughout an OSPF autonomous system, NSSA External LSAs are flooded only within the not-so-stubby area in which it was originated.

LSA Type 8, External Attributes LSAs were proposed as an alternative to running Internal BGP (iBGP), to transport BGP information across an OSPF domain. This LSA has never been deployed on a wide scale, and is not supported in IOS.

LSA Type 9 – 11, Opaque LSAs are a class of LSAs that consist of a standard LSA header followed by application-specific information. The Information field can be used directly by OSPF or indirectly by other applications to distribute information throughout the OSPF domain. Opaque LSAs have been used to add various extensions to OSPF, such as traffic engineering parameters for Multiprotocol Label Switching (MPLS) networks.

OSPF Media Types

For OSPF, media can be divided into four categories:

Multiaccess Media

Multiaccess media includes Ethernet, Fast Ethernet, Gigabit Ethernet, FDDI, Token Ring, and similar multiaccess media. OSPF runs as a broadcast network type over these media. The OSPF network type of broadcast is on by default over these media.

In this network type, the DR and the BDR are elected to reduce the flooding on the segment. The multicast capabilities of OSPF are used to form adjacencies and to efficiently distribute the information to other routers on the segment.

In broadcast network types, the interface subnet mask is checked in the Hello packet. If the masks of the two routers are different, an adjacency will not be formed.

Because this network type is on by default, no specific configuration is required for this media.

Multiaccess Media Example,

Point-to-Point Media

Point-to-point media includes HDLC and PPP encapsulation links, Frame Relay/ATM point-to-point subinterfaces, and similar point-to-point interfaces.

The OSPF network type of point-to-point is on by default on these media. No DR or BDR election takes place on this medium type. All the OSPF packets are multicast-based. The reason for sending all OSPF packets as multicast is that, in some cases of unnumbered links, the destination address is not known.

Nonbroadcast Multiaccess Media

Many media fall under this category of nonbroadcast multiaccess (NBMA), including Frame Relay, X.25, SMDS, and ATM. Additional configuration is required for this type of medium. The OSPF network type on these media is nonbroadcast, by default. Several network type options can be defined in this scenario. This medium can be run in several modes under OSPF:

  • • Broadcast model
  • • Point-to-point model
  • • Point-to-multipoint model

Broadcast Model

In the broadcast model, the broadcast network is simulated. DRs and BDRs are elected. The broadcast model can be simulated in two ways:

  • • Configure the network-type broadcast.
  • • Configure the neighbor statement.

Configure the Network Type as Broadcast

RouterA# interface serial 0

encapsulation frame-relay

ip ospf network-type broadcast

The command ip ospf network-type broadcast must be configured on all the routers’ Frame Relay interfaces

OSPF State message’s,

OSPF Adjacencies

OSPF creates adjacencies between neighboring routers for the purpose of exchanging routing information. Not every neighbor becomes adjacent in a broadcast environment. The Hello protocol is responsible for establishing and maintaining an adjacency.

A router can be in several neighbor states:

OSPF Down State

The neighbor state shows DOWN. This state means that no information has been received from the neighbor yet.

OSPF Attempt State

The Attempt state is valid for neighbors on NBMA networks. If a neighbor is in this state, it means that no information is received from this neighbor, but serious effort is being made to contact the neighbor. Serious effort means that this router will constantly send a Hello packet upon every Hello interval to contact the neighbor.

OSPF Init State

Init state is a one-way Hello. Upon receiving this Hello, R2 declares a one-way state because R2 doesn’t see itself (its router ID) in that Hello packet.

OSPF 2-Way State

An OSPF neighbor reaches the 2-way state when bidirectional communication is established. This is the beginning of an OSPF adjacency. The DR and BDR are elected in this state.

OSPF Exstart State

This state is used for initialization of the database synchronization process. Master and slave are elected in this state. The first sequence number for DBD exchange is also decided in this state.

OSPF Exchange State

In the Exchange state, the router describes its entire link-state database through DBD packets. Each DBD sequence is explicitly acknowledged. Only one outstanding DBD packet is allowed at a time. Link-state request packets are also sent in this state to request a new instance of the LSA.

OSPF Loading State

In the Loading state, LS request packets are sent to request the more recent instance of an LSA that has not been received during the exchange process.

OSPF Full State

This state means that the complete information has been exchanged between OSPF neighbors.

Address Summarization

The Cisco OSPF can perform two types of address summarization: inter-area summarization and external route summarization. Inter-area summarization is, as the name implies, the summarization of addresses between areas; this type of summarization is always configured on ABRs. External route summarization allows a set of external addresses to be redistributed into an OSPF domain as a summary address and is configured on ASBRs.

OSPF summarization example.

router ospf 1

network area 15

network area 0

area 15 range

Filtering Between Areas

LSA filtering example

router ospf 1

area 25 filter-list prefix area25outbound out

ip prefix-list area25outbound seq 10 deny

ip prefix-list area25outbound seq 20 permit le 32

The OSPF command area PID filter-list prefix specifies the name of a filter list to apply to outbound or inbound LSAs. Outbound lists filter LSAs sent into areas other then the one specified by the command. In our example, the list filters LSAs with addresses originating in area 25 and being sent into non-area 25 areas, such as area 0. Inbound lists filter LSAs as they are sent into area 25.

The first line of the prefix list is clear. The statement denies address from being advertised in a type 3 LSA. The second line permits everything else: every address with a mask from length 0 to length 32 bits. This second line is required because there is a implicit “deny all” statement at the end of the prefix list. is prevented from being sent in type 3 LSAs outside of area 25. Every other address is permitted.


OSPF has the capability of authenticating all packets exchanged between neighbors. Authentication may be by simple passwords or by MD5 cryptographic checksums.

Authentication using simple clear-text passwords (type 1) or MD5 cryptographic checksums (type 2) can be configured. When authentication is configured, it must be configured for an entire area.

To configure type 1 authentication for an area, the command ip ospf authentication-key is used to assign a password of up to eight octets to each interface attached to the area. The passwords do not have to be the same throughout the area, but must be the same between neighbors. Type 1 authentication is then enabled by entering the area authentication command to the OSPF configuration.

interface Serial 0/0

ip ospf authentication-key password

router ospf 1

area 0 authentication

To configure type 2 authentication for an area, the command ip ospf message-digest-key md5 assigns a password of up to 16 bytes and key ID between 1 and 255 to each interface attached to the area. Like type 1, the passwords do not have to be the same throughout the area, but both the key ID and the password must be the same between neighbors. Type 2 authentication is then enabled by entering the area authentication message-digest command to the OSPF configuration.

interface Serial 0/0

ip address

ip ospf message-digest-key 15 md5 password

router ospf 1

network area 0

area 0 authentication message-digest

area 25 authentication message-digest



Source : http://www.cisco.com, BSCI Cisco Student Guide


EIGRP is occasionally described as a distance vector protocol that acts like a link-state protocol.

Compared to distance vector protocols, link-state protocols are far less susceptible to routing loops and bad routing information. The forwarding of link-state packets is not dependent on performing the route calculations first, so large networks might converge faster. And only links or prefixes and their states are advertised, not routes, which means the change of a link will not cause the advertisement of all routes using that link.

Although EIGRP updates are still vectors of distances transmitted to directly connected neighbors, they are nonperiodic, partial, and bounded. Nonperiodic means that updates are not sent at regular intervals; rather, updates are sent only when a metric or topology change occurs. Partial means that the updates will include only routes that have changed, not every entry in the route table.

Bounded means that the updates are sent only to affected routers. These characteristics mean that EIGRP uses much less bandwidth than typical distance vector protocols use. This feature can be especially important on low-bandwidth, high-cost Wide Area Network (WAN) links.

Another concern when routing over low-bandwidth WAN links is the maximum amount of bandwidth used during periods of convergence, when routing traffic is high. By default, EIGRP uses no more than 50 percent of the bandwidth of a link. Later IOS releases allow this percentage to be changed with the command ip bandwidth-percent eigrp.

EIGRP is a classless protocol (that is, each route entry in an update includes a subnet mask).

EIGRP uses the same formula that IGRP uses to calculate its composite metric. However, EIGRP scales the metric components by 256 to achieve a finer metric granularity. So if the minimum configured bandwidth on the path to a destination is 512K and the total configured delay is 46000 microseconds, IGRP would calculate a composite metric of 24131. EIGRP, however, will multiply the bandwidth and delay components by 256 for a metric of 256 x 24131 = 6177536.

EIGRP has four components :

  • • Protocol-Dependent Modules
  • • Reliable Transport Protocol (RTP)
  • • Neighbor Discovery/Recovery
  • • Diffusing Update Algorithm (DUAL)

Protocol-Dependent Modules

EIGRP implements modules for IP, IPX, and AppleTalk, which are responsible for the protocol-specific routing tasks. For example, the IPX EIGRP module is responsible for exchanging route information about IPX networks with other IPX EIGRP processes and for passing the information to the DUAL.

Reliable Transport Protocol

The Reliable Transport Protocol (RTP) manages the delivery and reception of EIGRP packets. Reliable delivery means that delivery is guaranteed and that packets will be delivered in order.

Guaranteed delivery is accomplished by means of a Cisco-proprietary algorithm known as reliable multicast, using the reserved class D address Each neighbor receiving a reliably multicast packet unicasts an acknowledgment.

Ordered delivery is ensured by including two sequence numbers in the packet. Each packet includes a sequence number assigned by the sending router. This sequence number is incremented by one each time the router sends a new packet. In addition, the sending router places in the packet the sequence number of the last packet received from the destination router.

In some cases, RTP may use unreliable delivery. No acknowledgment is required, and no sequence number will be included for unreliably delivered EIGRP packets.

EIGRP uses multiple packet types, all of which are identified by protocol number 88 in the IP header:

  • • Hellos are used by the neighbor discovery and recovery process. Hello packets are multicast and use unreliable delivery.
  • • Acknowledgments (ACKs) are Hello packets with no data in them. ACKs are always unicast and use unreliable delivery.
  • • Updates convey route information. Unlike RIP and IGRP updates, these packets are transmitted only when necessary, contain only necessary information, and are sent only to routers that require the information. When updates are required by a specific router, they are unicast. When updates are required by multiple routers, such as upon a metric or topology change, they are multicast. Updates always use reliable delivery.
  • • Queries and Replies are used by the DUAL finite state machine to manage its diffusing computations. Queries can be multicast or unicast, and replies are always unicast. Both queries and replies use reliable delivery.
  • • Requests were a type of packet originally intended for use in route servers. This application was never implemented, and request packets are noted here only because they are mentioned in some older EIGRP documentation.

If any packet is reliably multicast and an ACK is not received from a neighbor, the packet will be retransmitted as a unicast to that unresponding neighbor. If an ACK is not received after 16 of these unicast retransmissions, the neighbor will be declared dead.

The time to wait for an ACK before switching from multicast to unicast is specified by the multicast flow timer. The time between the subsequent unicasts is specified by the retransmission timeout (RTO). Both the multicast flow timer and the RTO are calculated for each neighbor from the smooth round-trip time (SRTT).

The SRTT is the average elapsed time, measured in milliseconds, between the transmission of a packet to the neighbor and the receipt of an acknowledgment. The formulas for calculating the exact values of the SRTT, the RTO, and the multicast flow timer are proprietary.

Neighbor Discovery/Recovery

Because EIGRP updates are nonperiodic, it is especially important to have a process whereby neighborsEIGRP-speaking routers on directly connected networksare discovered and tracked. On most networks, Hellos are multicast every five seconds, minus a small random time to prevent synchronization. On multipoint X.25, Frame Relay, and ATM interfaces, with access link speeds of T1 or slower, Hellos are unicast every 60 seconds.[5] This longer Hello interval is also the default for ATM SVCs and for ISDN PRI interfaces.

In all cases, the Hellos are unacknowledged. The default Hello interval can be changed on a per interface basis with the command ip hello-interval eigrp.

Point-to-point subinterfaces send Hellos every 5 seconds. When a router receives a Hello packet from a neighbor, the packet will include a hold time. The hold time tells the router the maximum time it should wait to receive subsequent Hellos. If the hold timer expires before a Hello is received, the neighbor is declared unreachable and DUAL is informed of the loss of a neighbor. By default, the hold time is three times the Hello interval180 seconds for low-speed nonbroadcast multiaccess (NBMA) networks and 15 seconds for all other networks. The default can be changed on a per interface basis with the command ip hold-time eigrp. The capability to detect a lost neighbor within 15 seconds, as opposed to 180 seconds for RIP and 270 seconds for IGRP, is one factor contributing to EIGRP’s fast reconvergence. Information about each neighbor is recorded in a neighbor table.

Diffusing Update Algorithm

DUAL is a convergence algorithm that replaces the Bellman-Ford or Ford-Fulkerson algorithms used by other distance vector protocols. The design philosophy behind DUAL is that even temporary routing loops are detrimental to the performance of a network. DUAL uses diffusing computations, first proposed by E. W. Dijkstra and C. S. Scholten, to perform distributed shortest-path routing while maintaining freedom from loops at every instant. Although many researchers have contributed to the development of DUAL, the most prominent work is that of J. J. Garcia-Luna-Aceves.

Before the operation of DUAL can be examined, a few terms and concepts must be described.

Upon startup, a router uses Hellos to discover neighbors and to identify itself to neighbors. When a neighbor is discovered, EIGRP will attempt to form an adjacency with that neighbor. An adjacency is a logical association between two neighbors over which route information is exchanged. When adjacencies have been established, the router will receive updates from its neighbors. The updates will contain all routes known by the sending routers and the metrics of those routes. For each route, the router will calculate a distance based on the distance advertised by the neighbor and the cost of the link to that neighbor.

The lowest calculated metric to each destination will become the feasible distance (FD) of that destination. For example, a router may be informed of three different routes to subnet and may calculate metrics of 380672, 12381440, and 660868 for the three routes. 380672 will become the FD because it is the lowest calculated distance.

The feasibility condition (FC) is a condition that is met if a neighbor’s advertised distance to a destination is lower than the router’s FD to that same destination.

If a neighbor’s advertised distance to a destination meets the FC, the neighbor becomes a feasible successor for that destination.

Every destination for which one or more feasible successors exist will be recorded in a topological table, along with the following items:

  • • The destination’s FD
  • • All feasible successors
  • • Each feasible successor’s advertised distance to the destination
  • • The locally calculated distance to the destination via each feasible successor, based on the feasible successor’s advertised distance and the cost of the link to that successor
  • • The interface connected to the network on which each feasible successor is found.

For every destination listed in the topological table, the route with the lowest metric is chosen and placed into the route table. The neighbor advertising that route becomes the successor, or the next-hop router to which packets for that destination are sent.

EIGRP Packet Formats

The IP header of an EIGRP packet specifies protocol number 88, and the maximum length of the packet will be the IP maximum transmission unit (MTU) of the interface on which it is transmittedusually 1500 octets. Following the IP header is an EIGRP header followed by various Type/Length/Value (TLV) triplets. These TLVs will not only carry the route entries but also may provide fields for the management of the DUAL process, multicast sequencing, and IOS software versions.

EIGRP Packet Header

  • Version— Specifies different versions of EIGRP. Version 2 of EIGRP was implemented beginning with Cisco IOS Software Releases 10.3(11).
  • Opcode— Specifies the types of EIGRP packet contained. Opcode 1 is the update packet, opcode 3 is the Query, opcode 4 is the reply, and opcode 5 is the EIGRP hello packet.
  • Checksum— Used as the regular IP checksum, calculated based on the entire EIGRP packet, excluding the IP header.
  • Flags— Involves only two flags now. The flag indicates either an init for new neighbor relationship or the conditional receive for EIGRP RTP.
  • Sequence— Specifies the sequence number used by the EIGRP RTP.
  • Acknowledgment— Used to acknowledge the receipt of an EIGRP reliable packet.
  • Autonomous System Number— Specifies the number for the identification of EIGRP network range.

General TLV Fields

These TLVs carry EIGRP management information and are not specific to any one routed protocol. The Parameters TLV, which is used to convey metric weights and the hold time.

EIGRP IP Internal Route TLV

EIGRP IP External Route TLV

EIGRP Behavior

Unlike IGRP, EIGRP is an advanced distance vector protocol that carries the subnet mask information when an update is sent out. Therefore, EIGRP supports discontiguous network and variable-length subnet masking (VLSM).

EIGRP Summarization

Two types of summarization take place in EIGRP—autosummarization and manual summarization. Autosummarization is the default behavior for EIGRP, just as it is for RIP and IGRP. Basically, when the router sends out a routing update, it automatically summarizes the route to its natural major network when the route is advertised across a major network boundary.

Figure shows an example of autosummarization. In Figure Router R1 needs to send an update about the network to R2 across a major network of R1 then autosummarizes the update to its classful network of and sends it to R2. The problem of autosummarization is that the design of the network cannot be discontiguous.

For example, Router R1 needs to send an update about the network to R2 across a major network of R1 then autosummarizes the update to its classful network of and sends it to R2. The problem of autosummarization is that the design of the network cannot be discontiguous.

Manual summarization in EIGRP is configurable on a per-interface basis in any router within the network. The command for EIGRP manual summarization is ip summary-address eigrp autonomous-system-number address mask. With EIGRP, summarization can be done on any interface and any router in the network, compared to OSPF, which can summarize only on an area border router (ABR) and an autonomous system border router (ASBR). When manual summarization is configured on the interface, the router will immediately create a route to null 0 with an administrative distance of 5. This is to prevent routing loops of summary address. Finally, when the last specific route of the summary goes away, the summary route is deleted.

EIGRP Manual Summarization Example

Configuring EIGRP Manual Summarization

interface s0

ip address

ip summary-address eigrp 1

Example demonstrates how R1 is summarizing addresses of,, and into one update of Summarization in EIGRP reduces the size of the routing table and the number of updates. It also limits the query range, which is crucial in terms of making a large EIGRP network more stable and more scalable.

EIGRP Query Process

Although EIGRP is an advanced distance vector routing protocol and convergence time is low, an EIGRP router still relies on its neighbor to advertise routing information. To achieve fast convergence, EIGRP can’t rely on a flush timer like IGRP. EIGRP needs to actively search for the lost routes for fast convergence. This process is called the query process.

At this stage, the route is said to be in the Active state.

Queries are sent out to all the neighbors and on all interfaces except for the interface to the successor. If the neighboring routers do not have the lost route information, more queries are sent to the neighboring routers’ neighbors until the query boundary is reached. Query boundary consists of either the end of the network, the distribute list boundary, or the summarization boundary.

If any neighbor fails to reply in three minutes, the route is said to be stuck in active (SIA), and the neighbor relationship of the router that didn’t reply to the query is reset.

Default Routes and EIGRP

EIGRP recognizes the route as the default route and allows it to be redistributed into EIGRP domain as the default route. EIGRP also uses its own method of propagating the default route with the ip default-network command.

The ip default-network command specifies a major network address and flags it as a default network. This major network could be directly connected, defined by a static route, or discovered by a dynamic routing protocol.

Unequal-Cost Load Balancing in EIGRP

EIGRP and IGRP use the same equation to calculate their metrics, and they share the same behavior when it comes to unequal-cost load balancing. EIGRP also can install up to six parallel equal-cost paths for load balancing, like IGRP can, and EIGRP also uses the same variance command as IGRP to do unequal-cost path load balancing.

Unequal-Cost Load Balancing Example

Remember the rules for multipath operation:

  • • The neighboring router utilized as an alternate pathway must be closer to the destination (that is, it must be advertising a smaller metric than that of the local router for a given destination). It’s not possible to go back to go forward.
  • • The metric advertised by the neighbor must be less than the variance of the local router’s metric. Variance = Variance Factor 3 Local Metric.

To use the unequal-cost load-balancing feature of EIGRP, you use the variance command. Variance is a multiplier in which a metric may be different from the lowest metric to a route. The variance value must be of integer value; the default variance value is 1, meaning that the metrics of multiple routes must be equal to load-balance.

In last example the metric through the 256 kbps link is 4.8 times larger than the metric through the 1544 kbps link. Therefore, for the 256 kbps link to be considered in the routing table, a variance of 5 must be configured in Router 1. The configuration in Router 1 is simply variance 5 under the router eigrp command.

Setting Maximum Paths

The maximum number of routes over which EIGRP can load balance is set with the maximum-paths paths command. paths may be any number from 1 to 16 in IOS 12.3(2)T and later 12.3(T) releases and any number from 1 to 6 in earlier versions. The default for all versions is 4.

EIGRP Redistribution

Stub Routing

When an entry in a router’s EIGRP topology table changes for the worse (either the metric increases, or the successor is no longer accessible), if there is no feasible successor for the address, the entry goes into Active state, and the router sends query packets to all its neighbors.

A router that has EIGRP Stub neighbors will not send queries to the stubs, thereby eliminating the chance that a stub-configured remote site will cause stuck in active conditions, and routing instabilities in other parts of the network.

EIGRP stub router configuration.

router eigrp 15

eigrp stub

EIGRP Error Messages

Some EIGRP error messages that occur in the log have mystified many network administrators.

  • DUAL-3-SIA— This message means that the primary route is gone and no feasible successor is available. The router has sent out the queries to its neighbor and has not heard the reply from a particular neighbor for more than three minutes.
  • Neighbor not on common subnet— This message means that the router has heard a hello packet from a neighbor that is not on the same subnet as the router.
  • DUAL-3-BADCOUNT— Badcount means that EIGRP believes that it knows of more routes for a given network than actually exist. It’s typically (not always) seen in conjunction with DUAL-3-SIAs, but it is not believed to cause any problems by itself.
  • Unequal, <route>, dndb=<metric>, query=<metric>— This message is informa-tional only. It says that the metric the router had at the time of the query does not match the metric that it had when it received the reply.
  • DUAL-3-INTERNAL: IP-EIGRP Internal Error— This message indicates that there is an EIGRP internal error. However, the router is coded to fully recover from this internal error. The EIGRP internal error is caused by software problem and should not affect the operation of the router.
  • IP-EIGRP: Callback: callbackup_routes— At some point, EIGRP attempted to install routes to the destinations and failed, most commonly because of the existence of a route with a better administrative distance. When this occurs, EIGRP registers its route as a backup route. When the better route disappears from the routing table, EIGRP is called back through callbackup_routes so that it can attempt to reinstall the routes that it is holding in the topology table.
  • Error EIGRP: DDB not configured on interface— This means that when the router’s interface receives an EIGRP hello packet and the router goes to associate the packet with a DDB (DUAL descriptor block) for that interface, it does not find one that matches. This means that the router is receiving a hello packet on the interface in which doesn’t have EIGRP configured.
  • Poison squashed— The router threads a topology table entry as a poison in reply to an update (the router set up for poison reverse). While the router is building the packet that contains the poison reverse, the router realizes that it doesn’t need to send it.


MD5 cryptographic checksums are the only authentication supported in EIGRP, which on first consideration might seem less flexible than RIPv2 and OSPF, which support both MD5 and clear-text passwords. However, clear-text password authentication should be used only when a neighboring device does not support the more secure MD5. Because EIGRP will be spoken only between two Cisco devices, this situation will never arise.

The steps for configuring EIGRP authentication are:

Step 1. Define a key chain with a name.
Step 2. Define the key or keys on the key chain.
Step 3. Enable authentication on an interface and specify the key chain to be used.
Step 4. Optionally configure key management.

key chain Edwards

key 1

key-string PanchoBarnes

interface Serial0/0.1

ip address

ip authentication key-chain eigrp 15 Edwards

ip authentication mode eigrp 15 md5

Optional : Send-time & accept-time

Stuck-in-Active Neighbors

When a route goes active and queries are sent to neighbors, the route will remain active until a reply is received for every query. But what happens if a neighbor is dead or otherwise incapacitated and cannot reply? The route would stay permanently active. The active timer and SIA-retransmit timer are designed to prevent this situation. Both the active timer and the SIA-retransmit timer are set when a query is sent.



Source : http://www.cisco.com, cisco BSCI student guide