Link State Routing Protocols

• Responds instantly to network changes.
• Sends triggered updates when a network change occurs
• Periodic updates are sent at long intervals, such as every 30 minutes.

• Link-state routing protocols generate routing updates only when a change occurs in the network.
  • The router that detects the change will create a link-state advertisement (LSA) and propagates to all neighboring routers using special mulitcast address.
  • Each routing device receives a copy of the LSA, forwards the same copy to all neighboring devices within the area, and updates its link-state database (LSDB).
  • Flooding of the LSAs ensures that the routers can update their database with current information and update their routing tables with the new topology.
  • The routers apply the Dijkstra algorithm (SPF) against the information on the LSDB to build the SPF tree.
  • Each router selects the best paths from their SPF tree and places them in their routing table.
• With link-state routing protocols, incorrect information form any particular router is less likely to cause confusion, because each router maintains its own view of the network – each router independently calculates its best paths to all destinations in the network.
• The following information must be kept by each router in the network in order to make consistent routing decisions:
  • It’s immediate neighbor routers – adjancency information is stored in the OSPF neighbor table, aka adjacency database.
  • All other routers in the network (or in its area of the network) and their attached networks – LSAs stored in topology table or database (LSDB).
  • The best path to each destination – held in the routing table.

OSPF Terminology

• OSPF neighbor table = adjacency database
• OPSF topology table = OSPF tpoplogy database = LSDB
• Routing table = forwarding database

Distance Vector vs Link-State

• One drawback of link-state protocols is the memory resources required to maintain these tables.
  • However, link-state protocols have benefits that outweighs the “routing by rumor” limitations of distance vector.
  • For instance, because the topology table is identical for all OSPF routers in an area and contains full information about all the routers and links in an area, each router can independently select a loop-free and efficient path, based on cost, to reach every network in the area.
• With distance vector routing protocols, routers are not able to see a full picture of the network topology, therefore its routing decisions are based on the information provided by the adjacent neighbors.

OSPF Area Structure

• With link-state routing protocols, routing calculations could require complex and significant time needed to compute route paths if the size of the network become too large.
• Link-state routing protocols, like OSPF, can reduce the size of the calculations by partitioning the network into areas.
• OSPF uses a two-layer area hierarchy:
  • Transit Area
    
    • The primary function of this area is the fast and efficient movement of IP packets.
    • Transit areas interconnect with other OSPF area types.
    • Generally, end users are not found within a transit area.
    • OSPF area 0, also known as the backbone area.
  • Regular Area
    • The primary function of this area is to connect users and resources.
    • Generally, it is not used to link to other areas. In other words, in order to travel from one area to another, the traffic must cross area 0 to get to the next area. It does not allow traffic to pass through it.
    • Also known as non-backbone area.
    • Subtypes are;
      • Standard Area
      • Stub Area
      • Totally Stubby Area
      • Not-so-stubby area (NSSA)
• OSPF forces a rigid two-layer area hierarchy. The network’s physical connectivity must use the two-layer area structure where all non-backbone areas attaching directly to area 0.

OSPF Areas

• The concept of areas, in a way, is a compromise for the problem of including all routing information to all routers involved in an internetwork. In a link-state protocol, all routers keep a copy of the LSDB. If the network grows in size, so does the LSDB that has to include information for each of the additional router in the growing network.
• Using the OSPF area concept, routers within the same area can maintain a detailed database of all the links and database in the same area. OSPF can then be configured to contain only general or summary information about routers and links in other areas.

• A failed link or router, with a proper OSPF configuration, floods that information to other adjacent routers about the failure only in the same area. Routers outside that area do not get this information.
• A properly planned and configured hierarchical structure and limited number of routers in an area allows an OSPF autonomous system to scale to very large sizes.
  • A hierarchical structure means that all areas must connect directly to area 0.
  • Consider OSPF areas 1, 2, and 3 in the same autonomous system. All of these areas have routers inside these areas. Each of the areas 1, 2, and 3 must connect to the backbone area, or area 0. The router that connects each area to the backbone area 0 is called a Area Border Router (ABR).
  • The optimal number of routers that can be inside one area, according to Cisco, is 50 routers per area.

Some OSPF area characteristics are:

• Minimizes routing table entries.
• Localizes the impact of topology change within an area.
• Stops detailed LSA flooding at the area boundary.

Terminologies

• Backbone Router
  • Routers within area 0.
• Area Border Router
  • Connects area 0 to non-backbone areas.
  • Separates LSA flooding zones
  • Becomes the primary point for area address summarization
  • Functions regularly as the source of default routes.
  • Maintains the LSDB for each area with which it is connected
  • The ideal design is to have each ABR connected to two areas only, the backbone and another area. Three areas are the recommended upper limit.

OSPF Adjacencies

The following steps describe how routers form neighbor adjacencies:

• A router sends and receives hello packets to and from its neighboring routers. The packets are usually sent by multicasts.
• The routers exchange hello packet and check whether certain pieces of information match between the two hello packets. Once they have checked that these information match, they can establish a neighbor relationship. The following list outlines the pieces of information that must match between hello packets:
  • Subnet number/subnet mask
  • Hello/Dead interval
  • Area ID
  • Authentication
  • Stub Area Flag
• Once the neighbor adjacency has been established, they can begin exchanging LSAs and confirm receipt of LSAs, and synchronize their LSDB. This puts the neighbor state between the routers in full adjacency.
• If necessary, the routers forward any new LSAs to other neighboring routers, ensuring complete synchronization of link-state information inside the area.

Point-to-Point vs Broadcast Interface Types

• On point-to-point serial link, two routers form a full adjacency with each other
• OSPF routers on LAN links elect one router as the Designated Router (DR) and another as the Backup Designated Router (BDR)
  • All other routers will form full adjacency with the DR and BDR, exchanging each other’s topology information, in the form of LSAs, indirectly through the DR and BDR (?)
  • The DR is responsible for updating each routers by sending updates received from one neighbor on the LAN to all the other routers on the same LAN. One on of the main functions of a DR is to ensure that all the routers on the same LAN have an identical LSDB.
  • If a new router is introduced to the LAN, the DR will pass its LSDB to the new router.
  • Routers on the LAN also maintain a neighbor relationship with other non-DR and non-BDR routers in a two-way adjacency state also known as DROTHERs.

Link State

• LSAs, also called link-state protocol data units (PDUs) facilitate the exchange of link-state information.
• These LSAs let each routers know about the state of each routers and the links between routers – hence, link state.
• LSAs are reliable; they are acknowledge after receipt.
• LSAs are flooded throughout the area (or throughout the domain if there is only one area).
• LSAs have a sequence number and a set lifetime, so each router recognizes that it has the most current version of the LSA.
• LSAs are refreshed periodically to confirm topology information before they age out of the LSDB.

OSPF Metric Calculation

• Link-state routing protocols use Dijkstra’s algorithm to calculate the best paths through a network.
  • It is a mathematical algorithm created by Edsger Dijkstra.
  • The best path to a destination is calculated by assigning a cost to each link in the network, and by placing the specific node at the root of the tree, and adding up the costs toward each given destination. The best path is then added to the routing table.
• The interface cost is calculated based on its configured bandwidth.
• The default cost is calculated using the formula Reference Bandwidth / Interface Bandwidth, where the reference bandwidth is equal to 100Mbps and the the interface bandwidth is expressed in Mbps (Ethernet interface bandwidth defaults to use kbps)
• Alternatively, the OSPF cost for each interface can be manually configured – this overrides the default cost value.

Link-State Data Structures

• LSAs carry a link-state age field value of 30 minutes. This acts as an aging timer for the LSAs.
  • When the timer expires, the router that originally sent the entry sends the LSA, with a higher sequence number, in a link-state update (LSU). This is done to verify that the link is still active.
  • The LSU can contain one or more LSAs
  • Compared to a distance-vector router, which sends the whole routing table at short intervals, the LSA validation saves bandwidth by the infrequent (every 30 minutes) sending of the update.
• When a router receives an LSU, it does the following:
  • If the router does not have the LSA entry it just received in its LSDB, the router adds the entry, sends back an acknowledgement (LSack), floods the information to other routers, runs SPF, and updates its routing table.
  • If the entry already exists and the LSA has same sequence number), it is ignored
  • If the entry already exists but the has a higher sequence number – which means it has new information, it does the same as the first step.
  • If the entry already exists but the LSA includes older information, it sends an LSU to the sender with its newer information

OSPF Packets

• All five OSPF packets are encapsulated directly into an IP packet, bypassing the TCP/IP transport layer completely.
• The OSPF packet does not use TCP or UDP, but still need a reliable transport scheme, therefore it defines its own acknowledgment routine using an acknowledgment packet (LSack).
• In the IP header, an OSPF packet is identified with a Protocol ID number of 89.
• The same header format shown below applies to each OSPF packet type.

The fields on the OSPF header are as follows:

• Version number – Version 2 for IPv4
• Type – refers to one of the 5 types of OSPF packets (Hello, DBD, LSR, LSU, LSack)
• Packet Length – The length of the OSPF packet in bytes.
• Router ID – The RID of the source router
• Area ID – The OSPF area where the packet originated
• Checksum – Used for packet header error detection to ensure that the OSPF packet was not corrupted during transmission.
• Authentication Type – Describes either no authentication, cleartext passwords, or encrypted Message Digest 5 (MD5) for router authentication.
• Authentication – Used with authentication type.
• Data – Contains different information, depending on the OSPF packet type:
  • Hello – A list of known neighbors.
  • DBD – Summary of the LSDB, which includes all known router IDs and their last sequence number, among a number of other fields.
  • LSR - Contains the type of LSU needed and the router ID of the router that has the needed LSU
  • LSU – Contains the full LSA entries. Multiple LSA entries can fit in one OSPF update packet.
  • LSack – Empty.

Establishing OSPF Neighbor Adjacencies: Hello

• The Hello protocol establishes and maintains neighbor relationship by making sure that there is continuous two-way communication between two neighbors.
  • A two-way communication is established when a router receives a hello packet from a neighbor and it sees its own RID listed on the packet.
• Hello packets use the IP multicast address 224.0.0.5 for sending and receiving.
• The following information is contained in a hello packet:
  • Router ID
    • A 32-bit number that uniquely identifies the router.
    • The highest active IP address is chosen as the RID unless a loopback interface exsits. A manually configured RID, however, wins over all.
    • RID is also used as tie breakers during the DR and BDR election process.
  • Hello Interval
    • Specifies how often a router sends hello packets. 10 seconds is the default for multi-access networks.
  • Dead Interval
    • Amount of time that a router waits to hear from a neighbor before considering the link to the neighbor is dead. 40 seconds or four times the hello interval is the default timer.
  • Neighbors
    • Lists the neighbor routers that this router has established adjacency.
  • Area ID
    • The OSPF area ID.
    • To communicate, two routers must share a common segment and their interfaces must belong to the same OSPF area on that segment.
    • They must also share the same subnet and mask
  • Router Priority
    • An 8-bit number that indicates the router’s priority.
    • Priority is used when selecting a DR and BDR.
  • DR and BDR IP Address
    • The IP address for the DR and BDR for the specific multiaccess network.
  • Authentication password
    • The password for authentication, if enabled
  • Stub Area Flag
    • A special area that helps reduce routing updates by replacing them with a default route.

Exchange Process and OSPF Neighbor Adjacency States

1. Down State – An OSPF process starts in down state before any information is exchanged between two neighboring routers. The exchange process begins with a router sending a hello out each interface that is configured for OSPF. The hello packet is sent out multicast address 224.0.0.5.
2. Init State – Directly connected routers configured for OSPF receives the packet from the originating router. These routers will add the originating router to their list of neighbors. This state is the init state.
3. These routers that received the hello packets in turn send unicast reply packet back to the originating router, sending along with it information about themselves. The Neighbor field in the hello packet that they send back lists neighboring routers they know about, including the recently learned router that originally sent the hello packet.
4. Two-way State – When the originating router receives the hello back from the other neighbors, it notices that its own RID is included in the list of neighbors. At this point a two-way state is reached. They now have bi-directional communication.
5. On a broadcast link type, such as an Ethernet LAN, a DR and BDR must be elected. The DR will form a bi-directional adjacency with each routers on the LAN link.
   • If a new router joins the broadcast network in which a DR and BDR already exist, it will get to the two-way state with all the routers, including the DR and BDR, and those that are DROTHER. The new router will form a bidirectional adjacency with only the DR and BDR.
6. Every 10 seconds, the routers exchange hello packets to ensure there is still communication established.

• The routers are considered to be in the exstart state once the DR and BDR are selected. At this point they are ready to exchange link-state information with other routers and start creating their LSDBs.
• The exchange protocol is the process used to discover the network routes and gets the routers to a full state.
• The first step in this process is for the DR and BDR to establish adjacencies with each of the the other routers.
• Once the adjacent routers are in a full state, they do not repeat the exchange protocol unless the full state changes.

The following lists the exchange protocol process:

1. Exstart State
   • Master and slave relationship between each router and DR and BDR.
   • The router with the higher router ID acts as the master during the exchange process.
   • Only the DR exchanges information with the other routers. Non-DR and non-BDR routers don’t exchange information.
2. Exchange State
   • DBD packets (also called DDPs) are exchanged between master and slave routers.
   • A DBD contains a summary of the LSA entry headers in the sending router’s LSDB.
   • The entries can be about a link or a network.
   • An LSA entry header includes
     • Information about the link-state type
     • The address of the advertising router
     • The link’s cost
     • Sequence number
   • The sequence number determines the “newness” of the received link-state information.
3. The following actions are performed upon receipt of the DBDs:
   • An LSack packet is sent to acknowledge receipt of the DBD
   • The received DBD is compared against the contents of the receiving router’s own LSDB.
     • Loading State – if the router finds that the DBD contains a more updated information, it sends an LSR to the other router. The process of sending the LSR is called the loading state.
   • The other router sends an LSU that contains the complete information about the requested entry.
   • The LSU is received and an LSack is sent back to acknowledge receipt of the LSU
4. The router then adds the new link-state entries into its LSDB.

• The routers are considered synchronized and in full state once all LSRs have been received and updated.
• In order to route, all routers must be in full state. When in full state, all routers in the are should have identical LSDB.

Maintaining Routing Information

• If something changes in a link-state environment, the routers notify the other routers in the network about the changes.
  • The notifications are sent through a flooding process.
  • LSUs provide the mechanism for flooding LSAs.
• The steps for the flooding process looks like the following:
  1. A router notices that a link state change on one of its interface. An LSU packet containing and updated LSA packet is sent out to multicast address 224.0.0.6: This address goes to all DRs and BDRs.
  2. The DR sends an LSack back to the original sender. At the same time, the LSU is flooded out to multicast address 224.0.0.5, which goes out to all other OSPF enabled routers.
     • Each router that receives the LSU responds with an LSack to acknowledge receipt.
     • To make the flooding procedure reliable, each LSA must be acknowledged separately.
  3. If a router is connected to another network, it floods the LSU to the DR of the other network. That DR, in turn, multicasts the LSU to other routers in the network.
  4. Once the LSAs have been received, as delivered by the LSU, the LSDB is updated and recomputes new paths.

OSPF Multicast Address

• 224.0.0.5 – goes to all OSPF routers.
• 224.0.0.6 – goes to the DR and BDR.

To simplify OSPF synchronization, only adjacent routers are required to remain synchronized.

• Every 30 minutes, summaries of individual link-state entries are sent to ensure LSDB synchronization. Only summaries and not the complete link-state entries are sent.
• Each link entry has a timer to determine when the next LSA refresh update must be sent.
• The maximum age is 60 minutes, meaning that if an LSA is not refreshed after 60 minutes, it is removed from the LSDB.

NOTE: In a Cisco router, if a route already exists, the routing table is used at the same time the SPF algorithm is calculating. However, if the SPF is calculating a new route, the new route is used only after the SPF calculation is complete.

OSPF Link-State Sequence Numbers

• The link-state sequence numbers helps OSPF maintain an up-to-date database, with most recent link-state records.
• The link-state sequence number field is found in an LSA header. It is 32 bits long.
• The left most bit set starts with 0×80000001 and ends with 0x7FFFFFFF
• It is used to detect old and redundant LSA records. The larger the number, the more recent the LSA is.
• LSRefreshTime is the interval by which OSPF refreshes each LSA – every 30 minutes.
• The sequence number is incremented by 1 each time a record is flooded.
• When a new LSA update is received, the maximum age timer is reset.
• An LSA never remains in the database for longer than the maximum age of 60 minutes without a refresh.
• An LSA can exist in the database for long periods of time as long as it is refreshed every 30 minutes.
• If a sequence number has reached the highest bit set (0x7FFFFFFF), it wraps back around and restarts its sequence to 0×80000001. This processes forces the existing LSA to be flushed out by setting the maxage timer immediately to 60 minutes.

sh ip ospf database Command Output

The following shows how the LS age and LS sequence numbers are kept in the database.

• Link ID – the ID of the router that created the router LSA
• Adv Router (or Advertising Router) – the router ID of teh OSPF router that announced the router LSA.
  • The link ID and Adv router for a router LSA are generally the same.
• Age - how long ago (in seconds) the last update occured
• Seq# – The number of times the LSA for a link has been updated.

• In the figure above, the router LSA with link ID 192.168.1.1 has been updated 11 times (seq# 0x8000000B) and the last update occurred 17 seconds ago.

The debug ip ospf packet command is used to troubleshoot and verify that OSPF packets are flowing properly between two routers.

debug ip ospf packet Command Output

The following describes the fields represented in the output:

• v: – indentifies the version of OSPF. For IPv4, it is version 2.
• t: - Specifies the packet type:
  • 1 – hello
  • 2 – DBD
  • 3 – LSR
  • 4 – LSU
  • 5 – LSAck
• l: – Specifies the OSPF packet length in bytes. 48 bytes in the example above.
• rid: – Displays the OSPF router ID
• aid: – Displays the OSPF area ID
• chk: – Displays the OSPF checksum
• aut: – Authentication type:
  • 0 – No authentication
  • 1 – Simple password
  • 2 – MD5
• auk: - Specifies authentication key if used
• keyid: - Displays MD5 key ID
• seq: – Provides the sequence number; only used for MD5 authentication

Resources:

1. RFC 2328: OSPF Version 2
2. OSPF Design Guide
3. OSPF – Hiil2dot0
4. Wikipedia: Link-State Routing Protocol
5. For Fun!!!
   • Dijkstra Applet by Carla Laffra
   • Dijkstra’s Shortest Path Calculator
   • Minimum Route Finder Using Dijkstra Algorithm
6. OSPF Packet Formats
7. OSPF Packet Details

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet, as well as following the links on the resources section of this entry.

I feel like I’m new at this again.

When I made a decision, almost ten months ago, that I will pursue this whole Cisco certification thing, I wanted to make sure that I set the stage right. I was going into the new year strong and motivated. My mindset had to have been made when I started. I will have had the right equipment for labbing up my lessons. And most importantly I wanted a solid study plan.

Getting myself motivated was easy. It didn’t take a lot of convincing that this is the right path for me. I’ve known for a while now that network engineering is what I wanted to do and be good at. I just needed to get myself in gear and actually start the “real” learning process as opposed to learning on the go; learning whatever technology I came across in my daily job without knowing what I will come across to the next day. This time a decision just had to be made and I made it. So that was easy.

I set my timetable to start at the beginning of the new year – seems like the most convenient way to make an excuse for a new year’s resolution. I ordered my books, hit them hard and I was rolling. along the way I accumulated several pieces of hardware for my lab. I was rolling. I spent the first few months “feeling out” a good flow for my study schedule – what works, what doesn’t, what’s under-achieving and what’s over the top. I finally setteled in to a good rhythm with my study plan. Everything was clock work and I think it worked very well for me.

As I went through the ICND1 and ICND2 materials, I slowly developed a good strategy. And by the end of my CCNA journey, I felt comfortable with my methods. I began my BSCI preparation basing most of my strategies on my previous experience wiht the last two tests. Why not? They seemed to have worked well for me and I formed a comfortable and familiar habit.

Now, almost a month into my BSCI studies, I couldn’t be any more wrong about my assumptions. Things aren’t “rolling” as they should and I’m already way behind my reading schedules. I’m slowly realizing that the approach I took on my CCNA studies might not be well-suited for the CCNP.

For example, at the same point in time when I did ICND2, I was already 300 pages deep into my reading and seven chapters into the book. Now, with the BSCI, I have read only about 180 pages and only midway to chapter 4. So I started thinking about why I don’t feel comfortable with my schedule yet and why things aren’t going the way I expected. I have come to several conclusions:

1. Sometime around the end of my CCNA test and the first few days of studying for BSCI, I subconsciously decided that I would get more in-depth with learning the technologies involved in BSCI. This was somewhat a reaction to the general design of the tests themselves; The CCNA tended to focus on broad and general skill sets, therefore, my approach was learning a broad and general understanding of the technologies. The BSCI goes more in depth with routing technologies, and accordingly, my approach is to go deeper into each section of the technologies covered in the routing track.
2. I miss Wendell Odom! Six months reading two books, three times, by Wendell Odom; I got so used to his style of writing and book format that I could never get used to the new ones I’m using. Adjusting to the new books as well as using a lot more supplementary resources is slowing the process down.
3. Supplementary Resources. I’m really going out of my way to find other sources of information for the subjects I read. Mostly, I go to the cisco web site and try to get used to the layout and format of the DocCD (I still don’t have a good clue how that darned maze is organized). You may (or may note) have noticed that I’ve been putting resource links to most of my posts lately. I try to do that to “back-up”) what I’ve read so far and to make sure that what I’ve read is confirmed by another source. So in essence, even though I’ve read only 180 pages of texts from my study guide, I have, in actuality, read a lot more than that when you can’t the pages of texts I read from other sources.
4. I started writing my formal notes earlier. When I was studying for CCNA, I would first read the book all the way through, while taking very light notes (such as jotting down key words, highlighting important concepts on the text, etc). Then I would read it the second time while taking very detailed notes. And on the review phase, I would read the book again while referencing and comparing it with my notes to make sure understood what I wrote from what I read. This is the time I would also throw in outside sources. But this time I sort of changed what I’m doing for the sake of getting more in depth with my approach. I started taking notes on the first read, and also started supplementing my reading on the first pass. My goal is by the time I start my second pass on the book, I would have nearly mastered the concepts and it will feel like a review. Previously, the first reading didn’t allow me to retain much knowledge and the second reading felt like I was reading the book for the first time. This time I’m hoping it won’t feel that way.
5. I recently landed a rare opportunity at work where I can start working on our routers. We are in a state of transition where we are dropping all our internet circuits and ordering new ones. With that comes a lot of opportunity to get involved with the project. And because I’m the only one in our team of 3 that has a CCNA, my boss, who holds an expired CCIE “lightly” suggested that I may want to take the challenge of reconfiguring our site-to-site vpn/gre tunnels that he created but wasn’t particular happy about – because it was too messy, he says. The only problem is I have no idea how to do it. So for the last week, I’ve been studying ISCW materials, reading all about DMVPN, and trying to learn as much as I can so the boss can let me be the guy that primarily maintains the network. I’ve been asking him this opportunity for so long and I’m finally getting my chance. So I don’t want to blow it. And if while immersing myself in this process causes me to delay my BSCI studying, so be it. This opportunity, I believe, will allow me to increase my exposure and knowledge, thus adding experience in dealing with routers and WAN technologies that I can transfer anywhere I wish later on.

I’ve heard about this professor a while back but I didn’t really know the extent of his “Last Lecture’s” popularity until I did some research. If you’re into inspirational talks and all, check out his video on youtube. It is over an hour long but it is well worth your time. I promise it’s not gonna be as dry as one your COD videos It has garnered almost 4million hits in the 8 months it’s been up. To me that’s pretty popular.

I thought the lecture itself was very poignant, in that it really gives one a view into the life of a person who only has 4-6 months to live, who knows it, and is willing to tackle it head on. It’s not one of those rah-rah motivational speeches (of which I have a few collections of) but it’s more of a auto-biography of how he achieved his childhood dreams in ways that we don’t always expect to achieve them. I even thought that the general theme that he touches upon can apply to all of our own goals and dreams – whether it be attaining the CCIE or making your first million in the next 3 years

Yesterday, he passed away. May he rest in peace.

‘Last Lecture’ computer-science professor Randy Pausch dies
By Elizabeth Montalbano , IDG News Service , 07/25/2008

Randy Pausch, a computer-science professor who became internationally known for his inspiring “Last Lecture,” passed away in Chesapeake, Virginia, Friday after losing a battle with pancreatic cancer. He was 47.

In an obituary issued by Carnegie Mellon in Pittsburgh, where Pausch was a professor of computer science, human-computer interaction and design, University President Jared L. Cohon said Pausch has had “an enormous and lasting impact” on the university community.

“He was a brilliant researcher and gifted teacher,” Cohon said. “Carnegie Mellon – and the world – are better places for having had Randy Pausch in them.”

Gabriel Robins, a computer-science professor at the University of Virginia and Pausch’s former colleague, called Pausch “a force of nature” in the obituary, and said it was no accident that people of all ages, cultures and religions flocked to him.

You can check out his web site here. including a few more videos. I assume the news of his death has brought lots of visitors to this site because it suddenly got so slow.

ABC also did an hour long interview with Diane Sawyer about his life. Follow the youtube series here.

Never ever do this…

… on a production environment. Specially when you’re in California on a late Friday afternoon and the router in play is in New York and there is nobody there to reboot the router for you.

How did I get myself in such a predicament? Well, I was on our NY router doing some “investigatory” work and doing various show commands to print out and later peruse for self-study. Well turns out that oh-so convenient shortcut “sh” was not a shortcut for “show“, but a shortcut for “shutdown“. It actually took me a little while before I realized that I indeed bone-headedly shut down the interface when after a few minutes the prompt wasn’t showing up. All the while I thought I mistakenly typed a show command without any parameters so it’s trying to gather up all the parameters for me to try out. Then it occured to me, “I’m in the freaking interface mode. My heart starts palpitating and my mouth suddenly got so dry after the realization that I just killed a production router. But… never to be defeated by wanton careless mistake, I quickly realized that even though I killed a virtual tunnel, the serial connection to the router should still be up. So I quickly emailed our admin and casually asked what the public serial IP address was.

“Why?”, he asks.

“Just ’cause”, I reply.

And he gave it to me. I log on, got back to the interface, and “no shut” that puppy! And all is good in the IT world.

• This table lists some common EIGRP debug commands:

The majority of the notes will focus on discussing each show and debug commands. The sample outputs will be based on the figure and configuration below below:

R1#show running-config
<output omitted>
interface FastEthernet0/0
ip address 172.16.1.1 255.255.255.0

!
<output omitted>
interface Serial1/0
bandwidth 64
ip address 192.168.1.101 255.255.255.224

!

<output omitted>
router eigrp 100
network 172.16.1.0 0.0.0.255
network 192.168.1.0

• The R1 configuration has EIGRP enabled in autonomous system 100.
• The network 172.16.1.0 0.0.0.255 command configures EIGRP on interface Fa0/0 and advertise this network. The wildcard mask specifies that only interfaces on the 172.16.1.0/24 subnet will be advertised by EIGRP.
  • NOTE: However, the full Class B network 172.16.0.0 will be advertised because by default, EIGRP has autosummarization enabled.
• The network 192.168.1.0 enables EIGRP on the serial 0/0/1 interface and allows R1 to advertise this network.

R2#show running-config
<output omitted>
interface FastEthernet0/0
ip address 172.17.2.2 255.255.255.0

!

<output omitted>
interface Serial1/0
bandwidth 64
ip address 192.168.1.102 255.255.255.224

!

<output omitted>
router eigrp 100
network 172.17.2.0 0.0.0.255
network 192.168.1.0

• R2 is configured with AS 100.
• The network 172.17.2.0 0.0.0.255 configures EIGRP on interface Fa0/0 and advertises this network. The wildcard mask specifies that only interfaces on the 172.17.2.0/24 subnet will be advertised.
• NOTE: Because EIGRP automatically autosummarizes, the full Class B network 172.17.0.0 will be advertised.
• The network 192.168.1.0 command starts EIGRP on the serial 0/0/1 interface and allows R2 to advertise this network.

show ip route

figure 1: R1 sh ip route

• The leftmost column identified with a “D” indicates that the route is an internal EIGRP.
• Following that is the network number (172.16.0.0)
• The field in brackets [90/450514560] shows the administrative distance and the EIGRP metric, respectively.
  • The first number 90 is the administrative distance. It is used to choose the best route between two or more routes to the exact same destination from different routing protocols.
    • For example EIGRP with administrative distance of 90 beats RIP that has an administrative distance of 120.
  • The EIGRP metric is used as the FD in the EIGRP topology table.
  • NOTE: Administrative distance will only be used when comparing routes to the same destination (address and mask). For example, a router will use a RIP route over an EIGRP route if the RIP route is a more specific route than the EIGRP route.
• The next value on the first line of the routing table 192.168.1.102 is the address of the next-hop router.
• The next value 00:00:01 is the length of time since EIGRP last advertised this network to the router. EIGRP does not refresh routes periodically; it resends the routing table only when neighbor adjacencies change.
• The last value on the first line, Serial1/0 refers to the interface on which packets sent to 172.17.0.0 goes out.

• Notice in figure 1 that the routing table includes summary routes the forwards to null0.
  • null0 is a directly connected, software only interface.
  • null0 prevents the routing of a packet to other routers in search of a more precise, longer match.
  • For example, router R1 receives a packet to destination 172.16.3.5. This network does not match any known subnet. It then matches the summary route and subsequently gets forwarded to a null interface and dropped. This prevents the packet from being forwarded to a default route and possibly creating a loop.
  • The interfaces with the null0 routes are the connected interfaces of this router that are summarized. The only other summarized route is the route to network 172.17.0.0 on R2′s network. This was not summarized by R1. Rather, it was advertised by R2 as a summary.
  • Figure 2 shows the routing table with the no auto-summary configured on R1.

Figure 2: sh ip route on R1 with no auto-summary

show ip protocol

• The show ip protocol command provides information about any and all dynamic routing protocols running on the router
• It will display any route filtering occurring on EIGRP outbound or inbound updates.
• Identifies whether EIGRP is generating a default network or receiving a default network in EIGRP updates.
• Provides information about other settings (e.g. K values, hop count, variance).
  • NOTE: Because the routers must have identical K values for EIGRP to establish an adjacency, the show ip protocols command helps determine the current K-value setting before an adjacency is attempted

Figure 3: EIGRP show ip protocols

• Notice in the output that auto-summarization is enabled. This is the default setting
• Maximum Path: 4 – This line refers to the the maximum number of paths it can load-balance with.
  • By using the maximum-paths command, you can specify up to 16 paths.
• Routing for Networks: - This line shows the networks for which the router is routing.
  • Recall that in the network configuration, the 172.16.1.0 network specified a wildcard 0.0.0.255. Therefore in the routing information, the network address and prefix length is displayed.
  • Accordingly, the 192.168.1.0 network shows the major Class C network (without the prefix) because it was configured without a wildcard. Recall that if a wildcard is not used, the major network Class A, B, or C is displayed.
• Routing Information Sources: – Identifies all other routers that have an EIGRP neighbor relationship with this router.
  • show ip eigrp neighbors command provides a detailed display of EIGRP neigbors.
• Distance: – shows the administrative distances for EIGRP
  • Internal Networks – has an administrative distance of 90, which applies to networks from other routers inside the same ASN.
  • External Networks – has administrative distance of 170, which applies to networks introduced to EIGRP for this autonomous system through redistribution.

show ip eigrp interfaces

Figure 4: show ip eigrp interfaces Command Output

The following list describes the various elements of the output:

• Interface – the interface configured for EIGRP.
• Peers – how many EIGRP neighbors are connected to this router
• Xmit Queue Un/Reliable – number of packets remaining in the Unreliable and Reliable transmit queues.
• Mean SRRT – Mean SRTT interval, in milliseconds
• Pacing Time Un/Reliable – Pacing time used to determine when EIGRP packets should be sent out the interface.
• Multicast Flow Timer - Maximum number of seconds that the router will wait for an ACK packet after sending a multicast EIGRP packet, before switching from multicast to unicast.
• Pending Routes – Number of routes in the packets in the transmit queue waiting to be sent.

show ip eigrp topology

Figure 5: show ip eigrp topology Command Output

• This command displays the content of the EIGRP topology table.
• The command shows that the router has an ID of 192.168.1.101 and is in autonomous system 100.
  • The EIGRP ID is the highest IP address on an active interface for this router, unless loopback interfaces are configured, in which case it is the highest IP address assigned to a loopback interface.
• The command output also lists the networks known by this router through the EIGRP routing process. The codes associated with the networks are as follows:
  • Passive (P) – Means that the network is in a stable working condition. The network is available and installation can occur in the routing table.
  • Active (A) – This means that an outstanding query is in the process. The networks, therefore, is unavailable and the routing table cannot be updated at this time.
  • Update (U) – This network is being updated (placed in an update packet). This code also applies if the router is waiting for an ack for this update packet.
  • Query (Q) – There is an outstanding query packet for this network other than being in the active state. This code also applies if the router is waiting for an ack for a query packet.
  • Reply (R) – The router is generating a reply for this network or is waiting for an acknowledgment for the reply packet.
  • Stuck-in-Active (S) - There is an EIGRP convergence problem for this network.
• In each line:
  • Displays the number of successors available for a route. In the example above, each networks have 1 successor each.
  • After the mention of the successors, the FD is listed also telling us how the router was learned (eg. through the next-hop router, directly connected, or via summary).
  • The first number in brackets is the FD for that network through the next hop router. The second number is the AD form the next-hop-router to the destination network.

show ip eigrp traffic

• This command displays the number of various EIGRP packets sent and received.
• The figure below goes through the output of the command:

Figure 6: show ip eigrp traffic Command Output

• This example shows that Router 1 has sent 26296 hello messages and received 13151 hello messages.

debug eigrp packets

• This command can be used to verify EIGRP connectivity.
• Also displays the types of EIGRP packets sent and received by the other router that this command is executed on.

Figure 7: debug eigrp packets Command Output When a Neighbor’s Interface Comes Up.

• In the example Hello packets are sent reliably, therefore the sequence (Seq) number does not increment.
• In this example, when R2 receives an update from R1, values appear in the sequence number field.
  • Seq 18/18 indicates that 192.168.1.101 is sending this packet as sequence number 18 (the first number indicated) to R2 and the sequence number 18 (the second number) has been received from R2 by neighbor 192.168.1.101. 192.168.1.101 is expecting to receive sequence number 19 in the next reliable packet from R2.
• R2 returns an ACK packet with Seq 0/18. Ack packets are sent as unreliable, but notice that the unreliable/reliable flag (un/rel 1/0) is set. This means that the acknowledgment was sent in response to a reliable packet.
• serno 17-17 (at the end of the last highlighted line) refers to the Serial number. This indicates the number of changes that the two neighbors register in their EIGRP topology tables.

Sequence Number vs Serial Number

• Whenever a query, update, or reply is sent, the sequence number increments.
• The serial number increments each time the topology table changes.
  • The topology table can have more than 100 changes, and yet the sequence number can only increase by 1.

Figure 7: debug eigrp packets Command Output When a Neighbor’s Interface is Shut Down.

• An interface on R1 is shutdown.
• R1 sends a query packet to R2 to find out if R2 has a path to the lost network
• Because a query is a reliable packet, R2 responds with an ACK packet to acknowledge the receipt of the query packet from R1.
• At the same time, R2 sends a reply packet to R1.
• The serial number 18-20 represents the number of changes to the topology table since the start of the neighbor relationship between R1 and R2.

debug ip eigrp

• This command can be used to verify EIGRP operation.
• It displays EIGRP packets sent and received by the router.

Figure 8: debug ip eigrp Command Output of R2 When a Neighbor’s Interface Comes Up

• In the above example, and internal route (indicated by Int) for 172.16.0.0/16 is advertised to R2.
• To calculate the FD to reach network 172.16.0.0/16, the bandwidth and delay from “M” information seen on the highlighted output above.
  • M 40514560 – 40000000 514560
    • which means, the FD is 40514560. It is derived by adding the 40000000 (the bandwidth) + 514560 (the delay)
• To calculate the AD from R1 for network 172.16.0.0, the bandwidth and delay from the Source Metric information (SM) is added. In the highlighted text:
  • SM 28160 – 25600 2560 means: the AD is 28160. It is derived by adding 25600 (the bandwidth) + 2560 (the delay)

Figure 9: debug ip eigrp Command Output of R2 when an interface in R1 that leads to network 172.16.0.0/16 is shut down.

• R2 discovers that its neighbor no longer knows how to get to network 172.16.0.0/16.
  • The metric value (4,294,967,295) is the highest possible value using 32-bit numbers (or 2³²); it indicates that the route is unreachable.
  • R2 removes this entry form the EIGRP table and looks for alternative EIGRP routes.
• The debug output indicates that the routing table is not updated; this means that EIGRP did not find an alternative route to the network.
• The next statment verifies that the EIGRP process has removed the old route and that the route is not in the IP routing table
• R2 then informs the neighbor that it does not have a path to this network either.

Figure 10: Experimental IOS 12.5 command:

Oops! I guess not!

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet, as well as following the links on the resources section of this entry.

• unprivileged mode = user mode = user exec mode
• privileged mode = enable mode = priviledged exec mode

You’d think that after 7 months of dedicated Cisco study that I’d know these terms like the back of my hand. Oh, are you wrong! More like the back of neck

So last night I was reading about EIGRP and trying to setup a little lab setup from my extra CCNA books I never got to use. I came across some statements asking me to do things in privileged mode and things I can and can’t do in unprivileged mode. I had to go back to my “early days” and re-affirm that what I understood the book saying is what it’s really trying to say. I was right, of course but the fact that I had to second guess myself with something as elementary meant that I didn’t have everything down cold yet.

EIGRP Queries and Stuck-In-Active

• With EIGRP, if a router loses a route and it does not have an FS in the topology table, it sends out queries to neighboring routers to recompute a new route. This process puts the route in what is termed active state.
  • A route is considered passive when a router is not recomputing a new route.
• To recompute a new route, the router sends out queries to all neighbors on interfaces other than the one used to reach the previous successor (a function of split horizon). The query inquires the other routers whether they have a route to a given destination.
  • If the receiving router has an alternative route, it replies back to the sending router letting it know about the alternative route and the query ends there.
  • If the receiving neighbor does not have a route, it queries all of its own neighbors asking for an alternative route.
  • The queries propagate through the network creating an expanding tree of queries.
  • When a router responds to the query, it stops propagating on that portion of the network. However, the query can still propagate in other portions of the network as the other routers attempt to find alternative paths.
• When a route goes active, a reply must be received for every generated queries, otherwise it stay active the whole time.
• Stuck-in-Active
  • If the router does not receive a reply to all outstanding queries within 3 minutes (default setting), the route goes on stuck-in-active (SIA) state.
  • To change the limit limit before an outstanding query is stuck in active state use the router configuration command:
    • timers active-time [time-limit | disabled], where time-limit is in minutes.
  • When a route goes on SIA state, the neighbor relationship between the router and the neighbors that failed to reply resets. This action causes a recomputation of all routes known from that neighbor and to re-advertise all the routes it knows about to that neighbor.
  • Common causes of SIAs
    • Router has high CPU usage or memory problems that results in the router being too busy to respond or unable to allocate enough memory to process the query or build the reply packet.
    • Bad link between the router routers, which allows the two routers just enough to keep the route connected and receiving packets, but not enough that some packets or lost therefore some queries and replies are lost.
    • Unidirectional link, which results with traffic only flowing in one direction.
  • Many networks have implemented an erroneous approach of using multiple EIGRP autonomous systems in hopes of decreasing the chances of stuck-in-active route. This approach is somewhat simulating the effect of using OSPF areas.
    • There is an unintended result for doing this: If a query reaches the edge of the autonomous system, the original query is answered. However, the edge router then initiates a new query in the other autonomous system where the route can potentially go in stuck-in-active state.
    • Another misconception about autonomous system boundaries is that implementing multiple autonomous systems protects one AS from route flaps in another AS. However, if routes are redistributed between AS, route transitions form one AS are detected in another.

Preventing SIA Connections

• Cisco IOS Software Release 12.1(5) introduced a new feature called Active Process Enhancement.
  • This feature enables an EIGRP router to monitor the progression of the search for a successor route and ensure that the neighbor is still reachable by using two new addition to the EIGRP packet header:
    • SIA – Query
    • SIA – Reply
  • The result is improved network reliability by reducing unintended termination of neighbor adjacency.

The following diagram illustrates how the process works before and after the addition of the Active Process Enhancement:

Before

• Router A sends a query for network 10.1.1.0/24 to Router B
• Router B has no entry for this network, so it queries Router C
• If problem exists beween router B and C, the reply packet from Router C to Router B might be delayed or lost.
• Router A has no visibility of downstream progress and assumes that no response indicates problems with Router B
• After Router A’s 3-minute active timer expires, the neighbor relationship with Router B is reset, along with all known routes from Router B.

After

• With the Active Process Enhancement feature, Router A queries downstream Router B (with an SIA-Query) at the midway point of the active timer (one and a half minutes by default) about the status of the route.
• Router B responds (with an SIA-Reply) that it is searching for a replacement route.
• Upon receiving this SIA-Reply response packet, Router A validates the status of Router B and does not terminate the neighbor relationship.
• Meanwhile, Router B will send up to three SIA-Queries to Router C. If they go unanswered, Router B will terminate the neighbor relationship with Router C.
• Router B will then update Router A with an SIA-Reply indicating that the network 10.1.1.0/24 is unreachable.
• Routers A and B will remove the active route from their topology tables.
• The neighbor relationship between Routers A and B remains intact.

EIGRP Query Range

• Query Scoping - limiting the scope of query propagation through the network (the query range) – helps reduce incidences of SIA.
• Keeping the query packets close to the source reduces the chance that an isolated failure in another part of the network will restrict the convergence (query/reply) process.
• Note that remote routers seldom needs to know advertised routes across and entire network. Consider using default routes.

Consider the following example:

• In the figure above Router B notices the loss of network 10.1.8.0 and sends a query to Routers A, C, D, E.
• These routers, in turn, send queries to their neighbors, requesting an FS for 10.1.8.0.
• The redundant topology causes each path to receive duplicate queries as the process starts.
• As a result, not only do the remote routers have to respond to queries form the regional offices, but they also continue the search by reflecting the queries back toward the other regional office router, which makes the convergence process even more complicated.

Examining the Query Process

• Refer to the above figure. Assume that the EIGRP metric for the Ethernet link is 1000 and the serial link is 100,000
• Router B advertises 10.1.8.1/24 to all other routers
• Router A’s best route to get to the 10.1.8.0/24 network is through the Ethernet link to Router B.
• Remote routers C, D, and E prefer the serial link through B as the best path to 10.1.8.0/24.
• Here’s how the Toplogy table for 10.1.8.1/24 for Routers C, D, E would look like.

• Router A’s topology table for 10.1.8.0/24:

• With the information above, Routers C, D, and E determine that router B is the successor and Router A is the FS to reach network 10.1.8.0/24 – because it meets the feasibility conditon that the AD through router A (which is 2000) be less than the FD through Router B (101,000).
• Note also that router A does not have an FS because none of other routes meet that feasiblity condition (i.e. all the other routes have ADs higher (101,000) than the FD of the current successor (B = 2000).

Assume that Router B loses the path to network 10.1.8.0/24:

• Router B, then sends queries out to all its four neighbors.
• When the remote sites receive this query, they automatically install the path through their FS, which is Router A, in their routing table and sends a response to Router B with their supposedly good path through Router A. They also remove the path through Router B from their topology tables.
• Router B receives the responses from the remote routers and waits for a response from Router A.
• Because Router A only has one successor and no FS, it takes a little bit longer because it knows from its topology table that Routers C, D, and E each has a path to the lost network so it builds and sends it’s own query to Routers C, D, and E.
• At this point Router B is still waiting for a response from Router A.
• When the remote routers receive the query from Router A, they now learn that their path through A is not good. So they check their topology tables for alternative routes. This time there is none. Router B has already informed them that its path to 10.1.8.0/24 is gone.
• Because the remote routers don’t have anything to give to Router A as a response, they build a query and send it to all their neighbors; it is not sent to Router A because the message came from A (split horizon) which leaves B as the only choice to send the query to.
• Remember Router B is still waiting for a response from Router A.
  • Router B receives the query from the remote routers but it cannot respond to them because it still has not received a response from A.
  • Router A on the other hand is waiting for a response from either C, D, or E.
  • Routers C, D, and E are waiting for Router B to respond to their queries.
• Router B then goes to SIA state first because it is the router that sent the first query and whose SIA timer expired first.
• Router B then resets its neighbor relationship with A.
• As soon as the neighbor relationship goes down, Router B can immediately respond to Router C, D, and E, saying that router B does not have a path to 10.1.8.0/24.
• Routers C, D, and E can then respond to Router A that they do not have a path.

• After Router B and Router A resets their neighbor relationship, adjacency is restored. Router B does not pass the 10.1.8.0/24 network to Router A because it no longer exist.
• Router A learns that the remote side do not have a path to 10.1.8.0/24 so it removes the 10.1.8.0 network form its topology table.

Limiting the EIGRP Query Range

• Trying to determine the amount of information necessary to properly route traffic to the correct destination requires some business decision to weigh what is appropriate. Oftentimes the network manager must analyze the amount of information passed through the remote routers and the capacity and bandwidth that it can handle.
• A properly designed network would have each remote site with redundant WAN links to separate distribution sites. If both distribution sites pass a default route to the remote sites, the remote sites load balance to all networks behind the distribution site routers. This means maximum bandwidth utilization and less CPU and memory usage, which also means smaller and less expensive router required.
• It is optimal for all remote site to see all available routes so it can select the best path. However it must be taken into consideration the amount of bandwidth a larger internetwork would require in order to achieve this.

Two options for making EIGRP more scalable are:

1. Use of Route Summarization
2. Configuring Stub Routers

Limiting Query Range with Summarization

• Summarization minimizes the size of routing tables which means less CPU and memory usage and less bandwidth to transmit.
• Summarization reduces the chance of networks becoming stuck-in-active, because it reduces the number of routers the see each query. Therefore the chances of a query encountering issues is reduced.
• NOTE: A router extends the query about a network only if it has an exact match in the routing table.

Consider the following figure for example:

• Router B sends a summary route of 172.30.0.0/16 to Router A.
• When network 172.30.1.0/24 goes down, Router B sends a query to Router A asking for an alternative path to 172.30.1.0/24.
• Becuase Router A only received a summarized route 172.30.0.0/16, the network 172.30.1.0/24 is nowhere to be found on Router A’s routing table. Router A replies with a “network 172.30.1.0/24 unreachabel” message.
• The message does not extend the query any further.

Another Example, recall back to the earlier figure:

• Going back to a familiar scenario, the figure above has the ip summary-address eigrp command configured on the outbound interfaces of Routers A and B so that Routers A and B advertises the 10.0.0.0/8 summary to remote Routers C, D, and E.
• The 10.1.8.0/24 network is not advertised to the remote routers.
• When the network 10.1.8.0/24 goes down and Routers A and B sends queries to Routers C, D, and E, the routers immediately reply to Routers A and B that the destination is unreachable because that specific route is not in any of the Remote sites’ routing tables. The remote routers therefore don’t extend the queries back to Routers A and B which prevents Routers A and B from becoming SIA waiting for the query process to receive all the replies.

Limiting Query Range Using a Stub

• Hub-and-spoke network topologies commonly use stub routing.
• In a hub-and-spoke topology the remote router forwards all traffic that is not local to a hub router; the remote router does not need to keep a complete routing table. Generally, hub routers need to send only a default route to the remote routers.
• There is no advantage for a hub-and-spoke topology to have full routing table on the remote routers because everything goes through the hub router anyway. Besides, a full routing table on the spoke routers only increases the amount of memory required.
• Route summarization and route filtering can also be used to conserve bandwidth and memory requirements on the spoke routers.
• Traffic from a hub router should not use a remote router as a transit path.
• In order to prevent this, EIGRP stub routing can restrict the remote router from advertising the hub router’s routes back to other hub routers.
  • For example, going back to the figure above, if a remote router receives routes from hub Router A, the remote routers don’t advertise it back to Router B.
  • And because the remote router does not advertise the hub routes back to other hub routers, the hub routers do not use the remote routers as a transit path.
• EIGRP Stub
  • Only remote routers are configured as stubs. The stub feature does not prevent routes from being advertised to the remote router.
  • Stub routers are not queried. Instead, hub routers connect to the stub router answer the query on behalf of the stub router.
  • A hello packet carries the information about a router being a stub router.
    • Any neighbor that receives a packet informing it of the stub status does not query the stub router for any routes. Therefore, a router that has a stub peer does not query the peer.
  • When stub routing is enabled in dual-homed remote configurations, you do not have to configure filtering on remote routers to prevent them from appearing as transit paths to the hub routers.
  • EIGRP stub routing should be used on stub routers only. A stub router is defined as a router connected to the network core or hub layer, and through which core transit traffic should not flow.
  • A stud router should have only hub routers for EIGRP neighbors.
• Configuring an EIGRP stub
  • use the router configuration command:

eigrp stub [receive-only | connected | static | summary]

eigrp stub Command Parameters:

• Any combinations can be used with the exception of receive-only keyword.
• If any of the keywords (except receive-only) is used individually, the connected and summary routes are not sent automatically.

The following example configuration configures a stub that advertises connected and summary routes:

Router(config)#router eigrp 1
Router(config-router)#network 10.0.0.0
Router(config-router)#eigrp stub

The following configuration does not send connected, summary, or static routes:

Router(config)#router eigrp 1
Router(config-router)#network 10.0.0.0 eigrp
Router(config-router)#eigrp stub receive-only

• The EIGRP stub feature does not automatically enable route summarization on the hub router. If desired, the network administrator can configure route summarization.
• If a true stub network is required, the hub router can be configured to send a default route to the spoke routers. This approach is the most simple and conserves the most bandwidth and memory on the spoke routers.
• NOTE: Although EIGRP is a classless routing protocol, it behaves like a classful protocol, such as having automatic summarization on by default. When configuring the hub router to send a default route to the remote router, configure the ip classless command. By default, the ip classless command is enabled in all Cisco IOS images that support EIGRP stub routing.

• Without the stub feature, if a route is lost EIGRP sends a query to the spoke routers. The EIGRP stub route feature allows a network professional to prevent sending queries to the spoke router under any conditions.

The following is an example of how a stub feature would work on a network:

• In the above figure, Routers C, D, and E are configured as stub routers, therefor queries for 10.1.8.0/24 network are not sent to these routers.
• In addition, hub sites are able to immediately answer queries without propagating queries to the remote sites, saving CPU and bandwidth. Convergence time is also improved even when the remote sites are dual-homes to the two hub sites.

The figure below shows another example with the configurations following that:

RouterB#show running-config
<output omitted>
ip route 10.1.4.0 255.255.255.0 10.1.3.10
!
interface ethernet 0
ip address 10.1.2.1 255.255.255.0
!
interface serial 0
ip address 10.2.2.3 255.255.255.254
ip summary-address eigrp 100 10.1.2.0 255.255.254.0
!
interface serial 1
ip address 10.1.3.1 255.255.255.0
!
router eigrp 100
redistribute static 1000 1 255 1 1500
network 10.2.2.2 0.0.0.1
network 10.1.2.0 0.0.0.255
<output omitted>

Using the above figure and configuration, the network behaves differently with various eigrp stub configurations as follows:

• eigrp stub connected
  • Router B will advertise only 10.1.2.0/24 to Router A. Even though 10.1.3.0/24 is a connected network as well, it is not advertised to Router A because it is not configured in a network command, and connected routes are not redistributed
• eigrp stub summary
  • Router B will advertise only 10.1.2.0/23 (the summary route configured on the router) to Router A.
• eigrp sub static
  • Router B advertises only 10.1.4.0/24 (the configured static route on the router) to Router A.
• eigrp stub receive-only
  • Router B does not advertise anything to Router A.

Graceful Shutdown

• A graceful shutdown is a feature that would allow an EIGRP routing process that is about to shut down to broadcast a goodbye message to inform adjacent peers about the topology change that is about to occur.
  • This feature allows other EIGRP peers to synchornize and recalculate neighbor relationships more efficiently than would occur if the peers had to rely on the hold timer expiring.
  • Without it, a neigbor wouldn’t normally warn a peer that it was about to go down. The other router would have to wait for the hold timer to expire and packets could be lost in the process.
• Goodbye Messages
  • The goodbye message is supported in Cisco IOS Software Release 12.3(2), 12.3(3)B, and 12.3(2)T and later.
  • They are sent in Hello packets
  • EIGRP sends and interface goodbye messages with all K values set to 255 when taking down all peers on an interface.
• If a router IOS does not support goodbye messages, it will misinterpret the message as K-value mismatch and display the following:

*Apr 26 13:48:41.811: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down: K-value mismatch

• For supported software releases, the following message is displayed by routers when goodbye messages are received:

*Apr 26 13:48:42.523: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down: Interface Goodbye received

Note: Goodbye messages recieved by a nonsupporting router does not disrupt the network operation. It will use the hold timer to determine a down peer.

• An EIGRP router will send a goodbye message on an interface if:
  • The EIGRP network command is removed.
  • The EIGRP process is shut down (using no router eigrp).
• But it wont send goodbye messages if:
  • An interface is shut down
  • Or the router is reloaded

Resources:

1. Troubleshooting EGIRP [pdf]- Networkers 2001
   

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet, as well as following the links on the resources section of this entry.

EIGRP Load Balancing

• With load balancing a router is able to route traffic over its multiple ports that have the same metric from the destination address.
• The default setting allows a maximum of 4 equal paths for balancing. Up to 16 is supported. To set the maximum path, use the router configuration command:
  • maximum-paths maximum-path, where maximum-oath is the number of paths from 1-16.
  • A maximum-path of 1 means load balancing is disabled
• When a packet is process-switched, load balancing over equal-cost paths occurs on a per-packet basis.
• When packets are fast-switched, load balancing over equal-cost paths is on a per-destination basis.
• Load balancing is performed only on traffic that passes through the router, and not traffic generated by the router.

Unequal-cost load balancing

• EIGRP can also balance traffic across multiple paths that have different metrics.
• IOS uses the concept of EIGRP variance to allow unequal-cost metrics to load balance.
  • Use the variance multiplier router configuration command to configure.
  • The multiplier value is used for load balancing. It can be any value between 1 and 128. The default value is 1, meaning equal-cost load balancing. The multiplier will define the range of metric values that are accepted for load balancing.
• Feasible Route with Variance
  • A route is feasible if the next router in the path is closer to the destination than the current router and if the metric for the entire alternate path is within the variance.
    • This is not always intuitive as one might think. For example, in the figure below, look at Router D. The metric (AD) to get to router A is 25. The current FD of RouterE via Router C is 20. Although Router D is only one hop away from Router A, while E->C->A are two hops, the route to Router A via Router C is still closer (20<25). Therefore, RouterD can’t be a feasible route.
  • If a path is not a feasible successor, the path is not used in load balancing.
  • Two feasibility conditions must be met:
    1. The current FD must be greater than the AD learned from the next router. In other words, the next router in the path must be closer to the destination than the current router; this prevents routing loops.
    2. The variance multiplied by the current FD must be greater than the metric through the next router (the alternative FD).
  • To illustrate the point, consider the figure below:
    

• In the figure above, router E has 3 paths to Net X:
  • E->B->A: metric of 30
  • E->C->A: metric of 20
  • E->D->A: metric of 45
• Because the path through Router C has the best metric (FD of 20), it is chosen as the successor.
• By applying variance 2 command on RouterE, the path through router B meets the feasibility conditions.
• To revisit the criteria:
  1. The current FD must be greater than the AD learned from the next router. In other words, the other route must be a feasible successor to be considered for load balancing.
     • In this case, RouterB is a feasible successor because the current FD of 20 is greater than the AD of router B, which is 10.
     • Router D is not even considered possible option for load balancing because it doesn’t qualify as a feasible successor.
  2. The variance multiplied by the local best metric (the current FD) must be greater than the metric through the next router (the alternative FD).
     • The FD through RouterB (30) is less than twice the FD of the successor (Router C), which is 40 (2 X 20), which meets the second criteria to be considered for load balancing.
     • The FD through RouterD is 45 which is greater than twice the FD of the successor C. It doesn’t pass the the second criteria to be considered for load balancing. In fact, even if the variance is 3, which meets the second criteria for Router D (45 < 3 times the successor of 60), Router D still cannot be considered for load balancing because it still doesn’t meet the first criteria – that is, RouterD still is not a feasible successor.

EIGRP WAN Links

• By Default, EIGRP uses up to 50 percent of the bandwidth declared on an interface or subinterface.
• The different scenarios on which EIGRP can be implemented on NBMA links are:
  • Pure Multipoint Configuration (no subinterfaces)
  • Pure Point-to-Point Configuration (each VC on a separate subinterface)
  • Hybrid Configuration (point-to-point and multipoint subinterfaces)

Configuring EIGRP Authentication

Router Authentication

• By default, there is no authentication required for routing protocol packets.
• Authentication can be applied for neighbor routers to limit what routers can participate in routing based on predefined passwords.
• When you configure a neighbor router authentication on a router, the router authenticates the source of each routing update packets that it receives.
• This is accomplished by the exchange of an authentication key (password) known to both the routers involved.
• EIGRP supports two forms of authentication:
  • Simple Password (or Plain-text authentication) – these are not secure and totally vulnerable to attacks. The passwords are sent in plain text over the wire and anyone that know how to use a simple protocol analyzer can easily capture the data.
    • Correction: There is no option for configuring simple password/plain-text authentication with EIGRP. // updated 08.19.10

  

• MD5 Authentication – this form of authentication is more secure because it doesn’t actually send the key or password over the wire. Instead, it sends hashed keys, or message digest instead of the authenticating key itself.
  • MD5 authentication is a cryptographic authentication. To set it up, a router needs a key (password) and a key ID configured. An algorithm is run on the routing protocol using the key and the key ID to generate a message digest (called a hash). The message digest is sent on the wire instead of the key. When the hash is received on the other side, a similar algorithm is run and compares the result to the received message digest. If it’s a match, then it is authenticated.

EIGRP MD5 Authentication

• To configure EIGRP MD5 authentication, you must configure an authenticating key and a key ID on both the sending and receiving routers.
• Each key has its own key ID stored locally on the router.
• Key chains allow you to manage several keys. But only one key is used at a time (whichever is activated at the time).
  • If the keys are not activated they cannot be use.
  • If there’s a point in time when no key is activated, neighbor authentication cannot occur and routing updates will fail.
  • The software examines the key numbers from lowest to highest and uses the first valid key it sees.

Configuring MD5 Authentication

• The autonomous-system is the EIGRP autonomous system number in which authentication is to be used.
• The key-chain is the name of the authentication key chain from which a key is to be obtained for that interface.
• The key key-id configures the key ID number of an authentication key on a key chain. You can use any number from 0 to 2147483647 and it does not have to be configured in order.
• The key-string command configures the alphanumeric password used to authenticate sent and received EIGRP packets. The key string can contain from 1 to 80 uppercase to lowercase alphanumeric characters, except that the first character cannot be a number.

Configuration Example

Refer to the figure above where the configuration is applied:

R1#show running-config
<output omitted>
key chain R1chain
key 1
key-string Key1Pass
accept-lifetime 04:00:00 Jan 1 2006 infinite
send-lifetime 04:00:00 Jan 1 2006 04:01:00 Jan 1 2006
key 2
key-string Key2Pass
accept-lifetime 04:00:00 Jan 1 2006 infinite
send-lifetime 04:00:00 Jan 1 2006 infinite
<output omitted>
interface FastEthernet0/0
ip address 172.16.1.1 255.255.255.0
!
interface Serial0/0/1
bandwidth 64
ip address 192.168.1.101 255.255.255.224
ip authentication mode eigrp 100 md5
ip authentication key-chain eigrp 100 R1chain
!
router eigrp 100
network 172.16.1.0 0.0.0.255
network 192.168.1.0
auto-summary

• The ip authentication mode eigrp 100 md5 enables md5 authentication on S0/0/1 interface
• The ip authentication key-chain eigrp 100 R1chain command tells the router to use the R1chain key chain
• To configure the key chains themselves:
  • Enter the configuration mode for the R1 key chain by using the command key chin R1 chain.
  • Identify the key number by entering the Key 1 command.
  • Give the Key 1 its password using the command key-string Key1Pass, with Key1Pass as the password.
• accept-lifetime 04:00:00 Jan 1 2006 infinite
  • tells the router to accept the key for use on packets received by R1 from Jan 1, 2006 starting at 4am.
• send-lifetime 04:00:00 Jan 1 2006 04:01:00 Jan 1 2006
  • tells the router that sending packets is only valid for 1 minute from 4am on Jan 1, 2006 to 4:01am on the same day.

• You can specify more than one key on a key chain. In the example configuration above, Key 2 is defined with a password key2Pass using the command: key-string Key2Pass.
• accept-lifetime 04:00:00 Jan 1 2006 infinite
  • tells the router that the key is acceptable for use on packets received by R1 from January 1, 2006 onward.
• send-lifetime 04:00:00 Jan 1 2006 infinite
  • tells the router that it can start sending packets from 4am on Jan 1, 2006 onward.

• With the configuration above, the router will accept and attempt to verify the MD5 digest of any EIGRP packets with a key ID equal to 1 or 2. All other packets will be dropped.
• R1 will send all EIGRP packets using key 2, because key 1 is no longer valid for use when sending (remember it was configured to be valid for only 1 minute.)

MD5 Verification

Helpful commands for verifying MD5 authentication:

• show eigrp neighbors
  • make sure that the neighbor table show that two router have successfully formed an EIGRP adjacency
• show ip route
  • verify that network on the neighboring router has been learned via EIGRP over the right serial connection.

Troubleshooting MD5 Authentication

• Here’s an example of a successful authentication using the debug eigrp packets command:
  • The sample below shows that R1 is receiving EIGRP packets with MD5 authentication (with key ID equal to 1) from R2.

R1#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
*Apr 21 16:38:51.745: EIGRP: received packet with MD5 authentication, key id = 1
*Apr 21 16:38:51.745: EIGRP: Received HELLO on Serial0/0/1 nbr 192.168.1.102
*Apr 21 16:38:51.745: AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

• The next example shows a failed MD5 authentication:
  • to start off the example, Router1′s key is modified to simulate a failure. The key string (password) will be changed as follows:
  • R1(config-if)#key chain R1chain
    R1(config-keychain)#key 2
    R1(config-keychain-key)#key-string wrongkey
  • Notice the results from R2 when the command debug eigrp packets is issued. Key 2 on R2 is expecting a different password from R1 that it received.
  • show ip eigrp neighbors command also shows that R2 does not have any EIGRP neighbors because the adjacency with R1 is down due to mismatched authentication.

R2#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
R2#
*Apr 21 16:50:18.749: EIGRP: pkt key id = 2, authentication mismatch
*Apr 21 16:50:18.749: EIGRP: Serial0/0/1: ignored packet from 192.168.1.101, opcode = 5
(invalid authentication)
*Apr 21 16:50:18.749: EIGRP: Dropping peer, invalid authentication
*Apr 21 16:50:18.749: EIGRP: Sending HELLO on Serial0/0/1
*Apr 21 16:50:18.749: AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Apr 21 16:50:18.753: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.101
(Serial0/0/1) is down: Auth failure

R2#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
R2#

Resources:

1. How Does Unequal Cost Path Load Balancing (Variance) Work in IGRP and EIGRP?
2. How Does Load Balancing Work?
3. Configuration Notes for the Implementation of EIGRP over Frame Relay and Low Speed Links
4. Configuring EIGRP Route Authentication- Cisco IOS IP Routing Protocols Configuration Guide, Release 12.4
5. IP Enhanced IGRP Route Authentication
6. EIGRP Message Authentication Configuration Example

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet, as well as following the links on the resources section of this entry.

In the BSCI Authorized Self Study Guide book, I came across some statements on the EIGRP load-balancing section that says:

When a packet is process-switched, load balancing over equal-cost paths occurs on a per-packet basis.
When packets are fast-switched, load balancing over equal-cost paths is on a per-destination basis. (Teare & Paquet, p.101)

It was a bit challenging for me to comprehend what that meant, firstly, because I wasn’t sure what process-switched and fast-switched meant. And secondly, I wasn’t sure how per-packet and per-destination load balancing worked.

So I posted a question on the techexams.net message board and some of the replies lead me to a satisfactory link that helped shed some light to these concepts.

Find the link for the quoted passages below at the bottom of the page:

Process Switching. With this switching method, incoming packets are copied to the router’s buffers, associated with a destination network according to a routing table entry, encapsulated, and then forwarded out the appropriate interface. The router’s CPU processes every packet in process switching.

Fast Switching. Fast switching handles the first packet in a stream just like process switching, but then creates a fast switching cache against which following packets are compared. Subsequent packets in the same stream have their incoming frame header stripped off and compared to the first packet. When a match is found, the header appended to the first frame is appended to subsequent frames prior to forwarding. This method helps to eliminate the need for routing table lookups for each packet in the same stream, increasing router throughput. Fast switching is the default method on lower-end Cisco routers.

Per-Destination and Per-Packet Load Balancing

You can set load-balancing to work per-destination or per-packet. Per-destination load balancing means the router distributes the packets based on the destination address. Given two paths to the same network, all packets for destination1 on that network go over the first path, all packets for destination2 on that network go over the second path, and so on. This preserves packet order, with potential unequal usage of the links. If one host receives the majority of the traffic all packets use one link, which leaves bandwidth on other links unused. A larger number of destination addresses leads to more equally used links. To achieve more equally used links use IOS software to build a route-cache entry for every destination address, instead of every destination network, as is the case when only a single path exists. Therefore traffic for different hosts on the same destination network can use different paths. The downside of this approach is that for core backbone routers carrying traffic for thousands of destination hosts, memory and processing requirements for maintaining the cache become very demanding.

Per-packet load-balancing means that the router sends one packet for destination1 over the first path, the second packet for (the same) destination1 over the second path, and so on. Per-packet load balancing guarantees equal load across all links. However, there is potential that the packets may arrive out of order at the destination because differential delay may exist within the network. In Cisco IOS software, except the release 11.1CC, per packet load balancing does disable the forwarding acceleration by a route cache, because the route cache information includes the outgoing interface. For per-packet load balancing, the forwarding process determines the outgoing interface for each packet by looking up the route table and picking the least used interface. This ensures equal utilization of the links, but is a processor intensive task and impacts the overall forwarding performance. This form of per-packet load balancing is not well suited for higher speed interfaces.

Per-destination or per-packet load-balancing depends on the type of switching scheme used for IP packets. By default, on most Cisco routers, fast switching is enabled under interfaces. This is a demand caching scheme that does per-destination load-balancing. To set per-packet load-balancing, enable process switching (or disable fast switching), use these commands:

Router# config t
Router(config)# interface Ethernet 0
Router(config-if)# no ip route-cache
Router(config-if)# ^Z

Now the router CPU looks at every single packet and load balances on the number of routes in the routing table for the destination. This can crash a low-end router because the CPU must do all the processing. To re-enable fast switching, use these commands:

Router# config t
Router(config)# interface Ethernet 0
Router(config-if)# ip route-cache
Router(config-if)# ^Z

Sources:

1. Router Switching Methods
2. Per-Destination and Per-Packet Load Balancing

A few days ago I posted some of my thoughts about the lack of entry/mid-level bloggers out there. Although not overwhelming, the response was rather positive and results were unexpected. What’s unexpected? I didn’t expect anyone to actually reply much less, introduce their own blog. Well I’m glad they did. We certainly need to see more of this.

Here are some of the new CCNA/CCNP blogs to note:

• Cisco Fun – This from a guy who calls himsef Suffah. He’s currently studying for his CCNP. A regular poster on the techexams.net forums. Interestingly, we both passed our CCNA exam on the exact same day. Will we repeat the same feat (hey that rhymes!) for BSCI? We shall see…
• Network Bit – An engineer by the name Joey Boyer. He just recently started a new CCNP blog and will be joining us in the same journey. He is actually still working on Security+, but soon plans to move on to CCIP on his way to CCIE
• CCNP2B – Another budding engineer by the name of Michael Hocutt currently working on BSCI. His goal is to endure the fun and exciting journey through CCNP and beyond.
• CCNP Adventure – “I have started this blog as a direct response to a call from popular CCNP Blogger, Aragoen Celtdra” is the first sentence on his first post. I didn’t realize I was popular . Nevertheless, let’s encourage him to continue posting and help each other out on our quest.

These are just some of the few new ones. Let’s also not forget some of the CCNA/CCNP bloggers that have been out there for a while.

• Network Ninja – Here, Deon Botha, our brotha’ from another motha’… and fatha’ , who hails from South Africa blogging about his journey towards attaining his CCNP. He passed CCNA in March 2008 and has already made a mark in the blogging world with his excellent write ups and lab tutorials. He works for a Cisco Partner in South Africa as a Solutions Manager. He hopes to ultimately attain his R&S CCIE.
• CCNP Pursuit – A network engineer from Columbus. Ohio. He blogs about his pursuit for the CCNP and hopes to achieve a CCIE. Not much is known from him but he writes a pretty good blog.
• Cisco Black Belt – Currently a cisco white belt, this dude will someday achieve the top level from the Cisco dojo. Just a few weeks away from attaining his CCNA so let’s give him some love and drop some notes of encouragement on his blog.
• Common Abnormality – Currently studying for the ISCW, Jeremy L. Gaddis is no stranger to technology. A self-proclaim technological swiss-army knife, his experience extends from working on high-speed fiber optic networks to occasionally hacking some perl and php scripts to teaching as an adjunct faculty at a post-secondary institution. He also owns his own consulting firm and his favorite color is sushi. huh!
• IT Daddy – A cool guy, blogging about his CCNA experience. I’ve never met this guy but if there ever was a person I’d want watching my back (in case I trip on an ethernet cable in the data center or something ) , it’s this fellow right here. I’ve known him since I started my studies and a frequent poster at techexams forums. A real class act who always checked up on me regularly by sending me flowers (oops), I meant email messages reassuring me that I “gots that baby down!” Check him out in all his craziness.

Lastly I have to mention this blog, that even though it’s owner is no longer with us, is still one of us. He has served to inspire us and show us commitment in what he does through his own accounts:

• Jonathan Kintner

Well there you have it folks. Our list of CCNA/CCNP candidates is growing. And hopefully as this list crosses over to the CCIE list more bloggers and Cisco hopefuls out there join the fray.

By the way if you happened to have contacted me before and I left off your blog, I humbly apologize. I’d like to promote as many of you out there so please let me know if I didn’t catch yours (or if you have a new blog or existing blog focused on Cisco certification) and I’ll surely add yours next. You may go to the about page and fill out the “Contact Me” form. If not I can always steal your links from someone else who has it