OSPF is an internal routing protocol. (While primarily used inside a single company, it can span multiple sites.) Based on RFC 2328, it's an open standard. Because of this, OSPF is available on Microsoft's Windows Server 2003 OS, Linux, and many other network devices - unlike Cisco's EIGRP routing protocol. Like other dynamic routing protocols, OSPF enables routers to disclose their available routes to other routers.

OSPF is a link-state routing protocol that runs Dijkstra's algorithm to calculate the shortest path to other networks. Taking the bandwidth of the network links into account, it uses cost as its metric. OSPF works by developing adjacencies with its neighbors, periodically sending hello packets to neighbors, flooding changes to neighbors when a link's status changes, and sending "paranoia updates" to neighbors of all recent link state changes every 30 minutes.

While OSPF is an excellent routing protocol for networks of all sizes, one of its weaknesses is that it can be quite complex to configure. On the other hand, it offers more features than simpler protocols such as RIP.

Here are some of OSPF's strengths:

* It converges quickly, compared to a distance-vector protocol.
* Routing update packets are small, as it doesn't send the entire routing table.
* It's not prone to routing loops.
* It scales very well for large networks.
* It recognizes the bandwidth of a link and takes this into account in link selection.
* It supports variable-length subnet masks (VLSM) or Classless Inter-Domain Routing (CIDR).
* It supports a long list of optional features that many others don't.

Configure OSPF

Some may find OSPF configuration intimidating, so let's look at how to make it easy. Let's start with a basic network: Our network example has two routers - one in San Diego (192.168.1.0 /24) and one in Dallas (192.168.2.0 /24). Between these two routers, there's a point-to-point T1 circuit with IP network address 1.1.1.0/30. The San Diego router's WAN interface is 1.1.1.1, and the Dallas router's WAN interface is 1.1.1.2.

We'll begin by configuring the router in San Diego. The first step to configuring OSPF is to use the router ospf command when in Global Configuration Mode. Here's an example:

Router(config)# router ospf {process number}
Router(config-router)#

While it doesn't matter which process number you use, I recommend keeping it the same on all OSPF routers on your network. I usually use 100 to keep everything simple. However, if you use different process numbers, OSPF will still work and exchange all routes - unlike EIGRP.

After entering OSPF Configuration Mode, the most common next step is to specify which networks OSPF will advertise, which you can do using the network command. Here's an example:

Router(config-router)# network 192.168.1.0 0.0.0.255 area 0
Router(config-router)# network 1.1.1.0 0.0.0.3 area 0

The first parameter is the network ID, and the second parameter is the inverse mask. The inverse mask - or wildcard mask - is the inverse of the subnet mask. It tells OSPF what range of interfaces the IP addresses given will apply to. Therefore, you can have one network statement that covers multiple interfaces.

You also need to specify the area, which is how OSPF organizes networks. All traffic must flow through area 0. In a small network, it's logical to put all networks in area 0, as we did in the example.

After you've configured each side of the network, the routers will exchange routes and form adjacencies. You should see a statement in the log file or console that looks something like the following:

*Mar  1 02:53:33.370: %OSPF-5-ADJCHG: Process 100, Nbr 1.1.1.1 
  on Ethernet0/0 from LOADING to FULL, Loading Done

To make sure you see these types of messages, use the log-adjacency-changes command in your OSPF router configuration. This command causes OSPF to enter information into the router's log file whenever it loses or regains connectivity with its neighbors. Here's an example:

Router(config-router)# log-adjacency-changes

Check the status of OSPF

After you've configured OSPF, you need to know how to check its status. Here are some common OSPF commands, along with links to their Cisco documentation and sample output from our example:

* show ip ospf
* show ip ospf neighbor
* show ip ospf interface
* show ip route ospf

For more information on OSPF, see Cisco's OSPF Design Guide and Cisco's OSPF Documentation.

Classless Inter-Domain Routing (CIDR, pronounced "cider" or "cedar") is a method of categorizing Internet Protocol (IP) addresses for the purpose of allocating IP addresses to users and for efficiently routing IP packets on the Internet.

During the first decade of the modern Internet after the invention of the Domain Name System (DNS) it became apparent that the devised system based on classful networkscalable (cf. RFC 1517). To alleviate the shortcomings, the Internet Engineering Task Force published in 1993 a new set of standards, RFC 1518 and RFC 1519, to define a new concept of allocation of IP address blocks and new methods of routing IPv4 packets. design of distributing the address space and routing IP packets was not

An IP address is interpreted in two parts: a network-identifying prefix followed by a host address within that network. In the prior classful network architecture IP address allocations were based on octet (8-bit) boundary segments of the 32-bit IP address, forcing either 8, 16, or 24-bit network prefixes. Thus, the smallest allocation and routing block contained only 256 addresses—too small for most enterprises, and the next larger block contained 65,536 addresses—too large to be used efficiently by even large organizations. This led to inefficiencies in address use as well as routing because the large number of allocated small (class-C) networks with individual route announcements, being geographically dispersed with little opportunity for route aggregation, created heavy demand on routing equipment.

Classless Inter-Domain Routing is based on variable-length subnet masking (VLSM) to allow allocation on arbitrary-length prefixes. Variable-length subnet masks are mentioned in RFC 950 (1985). CIDR encompasses:

• the VLSM technique of specifying arbitrary-length prefixes. A CIDR-compliant address is written with a suffix indicating the number of bits in the prefix, such as 192.168.0.0/16. This permits more efficient use of increasingly scarce IPv4 addresses.
• the aggregation of multiple contiguous prefixes into supernets, and, wherever possible in the Internet, advertising aggregates, thus reducing the number of entries in the global routing table. Aggregation hides multiple levels of subnetting from the Internet routing table, and reverses the process of "subnetting a subnet" with VLSM.
• the administrative process of allocating address blocks to organizations based on their actual and short-term projected need, rather than the very large or very small blocks required by classful addressing schemes.

While IPv6 maintains the IPv4 CIDR convention of indicating prefix length with a suffix, the IPv4 concept of class was abandoned in IPv6.

Prefix aggregation

Another benefit of CIDR is the possibility of routing prefix aggregation (also known as "supernetting" or "route summarization"). For example, sixteen contiguous Class C (/24) networks could now be aggregated together, and advertised to the outside world as a single /20 route (if the first 20 bits of their network addresses match). Two aligned contiguous /20s could then be aggregated to a /19, and so forth. This allows a significant reduction in the number of routes that have to be advertised over the Internet, preventing 'routing table explosions' from overwhelming routers, and stopping the Internet from expanding further.

See IPv4 subnetting reference.

CIDR

IP/CIDR	Δ to last IP addr	Mask	Hosts (*)	Class	Notes
a.b.c.d/32	+0.0.0.0	255.255.255.255	1	1/256 C
a.b.c.d/31	+0.0.0.1	255.255.255.254	2	1/128 C	d = 0 ... (2n) ... 254
a.b.c.d/30	+0.0.0.3	255.255.255.252	4	1/64 C	d = 0 ... (4n) ... 252
a.b.c.d/29	+0.0.0.7	255.255.255.248	8	1/32 C	d = 0 ... (8n) ... 248
a.b.c.d/28	+0.0.0.15	255.255.255.240	16	1/16 C	d = 0 ... (16n) ... 240
a.b.c.d/27	+0.0.0.31	255.255.255.224	32	1/8 C	d = 0 ... (32n) ... 224
a.b.c.d/26	+0.0.0.63	255.255.255.192	64	1/4 C	d = 0, 64, 128, 192
a.b.c.d/25	+0.0.0.127	255.255.255.128	128	1/2 C	d = 0, 128
a.b.c.0/24	+0.0.0.255	255.255.255.000	256	1 C
a.b.c.0/23	+0.0.1.255	255.255.254.000	512	2 C	c = 0 ... (2n) ... 254
a.b.c.0/22	+0.0.3.255	255.255.252.000	1,024	4 C	c = 0 ... (4n) ... 252
a.b.c.0/21	+0.0.7.255	255.255.248.000	2,048	8 C	c = 0 ... (8n) ... 248
a.b.c.0/20	+0.0.15.255	255.255.240.000	4,096	16 C	c = 0 ... (16n) ... 240
a.b.c.0/19	+0.0.31.255	255.255.224.000	8,192	32 C	c = 0 ... (32n) ... 224
a.b.c.0/18	+0.0.63.255	255.255.192.000	16,384	64 C	c = 0, 64, 128, 192
a.b.c.0/17	+0.0.127.255	255.255.128.000	32,768	128 C	c = 0, 128
a.b.0.0/16	+0.0.255.255	255.255.000.000	65,536	256 C = 1 B
a.b.0.0/15	+0.1.255.255	255.254.000.000	131,072	2 B	b = 0 ... (2n) ... 254
a.b.0.0/14	+0.3.255.255	255.252.000.000	262,144	4 B	b = 0 ... (4n) ... 252
a.b.0.0/13	+0.7.255.255	255.248.000.000	524,288	8 B	b = 0 ... (8n) ... 248
a.b.0.0/12	+0.15.255.255	255.240.000.000	1,048,576	16 B	b = 0 ... (16n) ... 240
a.b.0.0/11	+0.31.255.255	255.224.000.000	2,097,152	32 B	b = 0 ... (32n) ... 224
a.b.0.0/10	+0.63.255.255	255.192.000.000	4,194,304	64 B	b = 0, 64, 128, 192
a.b.0.0/9	+0.127.255.255	255.128.000.000	8,388,608	128 B	b = 0, 128
a.0.0.0/8	+0.255.255.255	255.000.000.000	16,777,216	256 B = 1 A
a.0.0.0/7	+1.255.255.255	254.000.000.000	33,554,432	2 A	a = 0 ... (2n) ... 254
a.0.0.0/6	+3.255.255.255	252.000.000.000	67,108,864	4 A	a = 0 ... (4n) ... 252
a.0.0.0/5	+7.255.255.255	248.000.000.000	134,217,728	8 A	a = 0 ... (8n) ... 248
a.0.0.0/4	+15.255.255.255	240.000.000.000	268,435,456	16 A	a = 0 ... (16n) ... 240
a.0.0.0/3	+31.255.255.255	224.000.000.000	536,870,912	32 A	a = 0 ... (32n) ... 224
a.0.0.0/2	+63.255.255.255	192.000.000.000	1,073,741,824	64 A	a = 0, 64, 128, 192
a.0.0.0/1	+127.255.255.255	128.000.000.000	2,147,483,648	128 A	a = 0, 128
0.0.0.0/0	+255.255.255.255	000.000.000.000	4,294,967,296	256 A

(*) Note that for routed subnets bigger than /31 or /32, 2 needs to be subtracted from the number of available addresses - the largest address is used as the broadcast address, and typically the smallest address is used to identify the network itself. See RFC 1812 for more detail. It is also common for the gateway IP for that subnet to use an address, meaning that you would subtract 3 from the number of usable hosts that can be used on the subnet.

Classful network is a term that is used to describe the network architecture of the Internet until around 1993. It divided the address space for Internet Protocol Version 4 (IPv4) into five address classes. Each class, coded by the first three bits of the address, defined a different size or type (unicast or multicast) of the network.

Today, remnants of classful network concepts remain in practice only in a limited scope in the default configuration parameters of some network software and hardware components (e.g. netmask), but the terms are often still heard in general discussions about network structure among network administrators.

Classes

To remain compatible with the existing IP address space and the IP packet structure, the definition of IP addresses was changed in 1981 in RFC 791 to allow unicast addresses with three different sizes of the network number field (and the associated rest field), as specified in the table below:

Class	Leading Bit String	Size of Network Number Bit field*	Size of Rest Bit field
Class A	0	8	24
Class B	10	16	16
Class C	110	24	8
Class D (multicast)	1110	not defined	not defined
Class E (reserved)	1111	not defined	not defined

• Includes the number of bits used for the leading bit string. Hence, number of bits actually used to specify the network number are 7, 14 and 21 respectively.

This allowed the following population of network numbers (excluding addresses consisting of all zeros or all ones, which are not allowed):

Class	Leading Bit String	Number of Networks	Hosts Per Network
Class A	0	128	16,777,214
Class B	10	16,384	65,534
Class C	110	2,097,152	254

The number of valid host addresses available is always 2^N - 2 (where N is the number of bits used, and the subtraction of 2 adjusts for the invalidity of the first and last addresses). Thus, for a class C address with 8 bits available for hosts, the number of hosts is 254.

The larger network number field allowed a larger number of networks, thereby accommodating the continued growth of the Internet.

The IP address netmask, which is commonly associated with an IP address today, was not required because the mask was implicitly derived from the IP address itself. Any network device would inspect the first few bits of the IP address to determine the class of the address.

The method of comparing two IP addresses' physical networks did not change, however (see subnet). For each address, the network number field size and its subsequent value were determined (the rest field was ignored). The network numbers were then compared. If they matched, then the two addresses were on the same network.

The replacement of classes

This first round of changes was enough to work in the short run, but an IP address shortage still developed. The principal problem was that most sites were too big for a "class C" network number, and received a "class B" number instead. With the rapid growth of the Internet, the available pool of class B addresses (basically 2¹⁴, or about 16,000 total) was rapidly being depleted. Classful networking was replaced by Classless Inter-Domain Routing (CIDR), starting in about 1993, to solve this problem (and others).

Early allocations of IP addresses by IANA were in some cases not made very efficiently, which contributed to the problem. (However, the commonly held notion that some American organizations unfairly or unnecessarily received class A networks is a canard; most such allocations date to the period before the introduction of address classes, when the only thing available was what later became known as "class A" network number.)

Class ranges

The address ranges used for each class are given in the following table, in the standard dotted decimal notation.

Class	Leading bits	Start	End	CIDR equivalent	Default subnet mask
Class A	0	0.0.0.0	127.255.255.255	/8	255.0.0.0
Class B	10	128.0.0.0	191.255.255.255	/16	255.255.0.0
Class C	110	192.0.0.0	223.255.255.255	/24	255.255.255.0
Class Dmulticast) (	1110	224.0.0.0	239.255.255.255	/4	not defined
Class E (reserved)	1111	240.0.0.0	255.255.255.255	/4	not defined

Special ranges

Some addresses are reserved for special uses (RFC 3330).^[1]

Addresses	CIDR Equivalent	Purpose	RFC	Class	Total # of addresses
0.0.0.0 - 0.255.255.255	0.0.0.0/8	Zero Addresses	RFC 1700	A	16,777,216
10.0.0.0 - 10.255.255.255	10.0.0.0/8	Private IP addresses	RFC 1918	A	16,777,216
127.0.0.0 - 127.255.255.255	127.0.0.0/8	Localhost Loopback Address	RFC 1700	A	16,777,216
169.254.0.0 - 169.254.255.255	169.254.0.0/16	Zeroconf / APIPA	RFC 3330	B	65,536
172.16.0.0 - 172.31.255.255	172.16.0.0/12 *	Private IP addresses	RFC 1918	B	1,048,576
192.0.2.0 - 192.0.2.255	192.0.2.0/24	Documentation and Examples	RFC 3330	C	256
192.88.99.0 - 192.88.99.255	192.88.99.0/24	IPv6 to IPv4 relay Anycast	RFC 3068	C	256
192.168.0.0 - 192.168.255.255	192.168.0.0/16 *	Private IP addresses	RFC 1918	C	65,536
198.18.0.0 - 198.19.255.255	198.18.0.0/15 *	Network Device Benchmark	RFC 2544	C	131,072
224.0.0.0 - 239.255.255.255	224.0.0.0/4	Multicast	RFC 3171	D	268,435,456
240.0.0.0 - 255.255.255.255	240.0.0.0/4	Reserved[2],[3],[4]	RFC 1166	E	268,435,456

^* Note that these ranges listed were originally defined as consecutive network blocks and their "CIDR Equivalent" notation makes them appear to be in the wrong "Class". While nowadays CIDR allows to use this range as a Class B subnet, some network hard- and software still has hard-coded limitations which still prevent use of subnets other than Class C size.

Bit-wise representation

In the following table:

• n indicates a binary slot used for network ID.
• H indicates a binary slot used for host ID.
• X indicates a binary slot (without specified purpose)))

Class A
  0.  0.  0.  0 = 00000000.00000000.00000000.00000000
127.255.255.255 = 01111111.11111111.11111111.11111111
                  0nnnnnnn.HHHHHHHH.HHHHHHHH.HHHHHHHH
Class B
128.  0.  0.  0 = 10000000.00000000.00000000.00000000
191.255.255.255 = 10111111.11111111.11111111.11111111
                  10nnnnnn.nnnnnnnn.HHHHHHHH.HHHHHHHH

Class C
192.  0.  0.  0 = 11000000.00000000.00000000.00000000
223.255.255.255 = 11011111.11111111.11111111.11111111
                  110nnnnn.nnnnnnnn.nnnnnnnn.HHHHHHHH

Class D
224.  0.  0.  0 = 11100000.00000000.00000000.00000000
239.255.255.255 = 11101111.11111111.11111111.11111111
                  1110XXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX

Class E
240.  0.  0.  0 = 11110000.00000000.00000000.00000000
255.255.255.255 = 11111111.11111111.11111111.11111111
                  1111XXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX

Enhanced Interior Gateway Routing Protocol - (EIGRP) is a Cisco proprietary routing protocol loosely based on their original IGRP. EIGRP is an advanced distance-vector routing protocol, with optimizations to minimize both the routing instability incurred after topology changes, as well as the use of bandwidth and processing power in the router. Routers that support EIGRP will automatically redistribute route information to IGRP neighbors by converting the 32 bit EIGRP metric to the 24 bit IGRP metric. Most of the routing optimizations are based on the Diffusing Update Algorithm (DUAL) work from SRI, which guarantees loop-free operation and provides a mechanism for fast convergence.

Basic operation

The data EIGRP collects is stored in three tables:

• Neighbor Table: Stores data about the neighboring routers, i.e. those directly accessible through directly connected interfaces.

• Topology Table: Confusingly named, this table does not store an overview of the complete network topology; rather, it effectively contains only the aggregation of the routing tables gathered from all directly connected neighbors. This table contains a list of destination networks in the EIGRP-routed network together with their respective metrics. Also for every destination, a successor and a feasible successor are identified and stored in the table if they exist. Every destination in the topology table can be marked either as "Passive", which is the state when the routing has stabilized and the router knows the route to the destination, or "Active" when the topology has changed and the router is in the process of (actively) updating its route to that destination.

• Routing table: Stores the actual routes to all destinations; the routing table is populated from the topology table with every destination network that has its successor and optionally feasible successor identified (if unequal-cost load-balancing is enabled using the variance command). The successors and feasible successors serve as the next hop routers for these destinations.

Unlike most other distance vector protocols, EIGRP does not rely on periodic route dumps in order to maintain its topology table. Routing information is exchanged only upon the establishment of new neighbor adjacencies, after which only changes are sent.

Multiple metrics

EIGRP associates five different metrics with each route:

• Total Delay (in 10s of microseconds)
• Minimum Bandwidth (in kilobits per second)
• Reliability (number in range 1 to 255; 255 being most reliable)
• Load (number in range 1 to 255; 255 being saturated)
• Minimum path Maximum Transmission Unit (MTU) (though not actually used in the calculation)

For the purposes of comparing routes, these are combined together in a weighted formula to produce a single overall metric:

where the various constants (K₁ through K₅) can be set by the user to produce varying behaviors. An important and totally non-obvious fact is that if K₅ is set to zero, the term is not used (i.e. taken as 1).

The default is for K₁ and K₃ to be set to 1, and the rest to zero, effectively reducing the above formula to (Bandwidth + Delay) * 256.

Obviously, these constants must be set to the same value on all routers in an EIGRP system, or permanent routing loops will probably result. Cisco routers running EIGRP will not form an EIGRP adjacency and will complain about K-values mismatch until these values are identical on these routers.

EIGRP scales Bandwidth and Delay metrics with following calculations:

Bandwidth for EIGRP = 10⁷ / Interface Bandwidth

Delay for EIGRP = Interface Delay / 10

On Cisco routers, the interface bandwidth is a configurable static parameter expressed in kilobits per second. Dividing a value of 10⁷ kbit/s (i.e. 10 Gbit/s) by the interface bandwidth yields a value that is used in the weighted formula. Analogously, the interface delay is a configurable static parameter expressed in microseconds. Dividing this interface delay value by 10 yields a delay in units of tens of microseconds that is used in the weighted formula.

IGRP uses the same basic formula for computing the overall metric, the only difference is that in IGRP, the formula does not contain the scaling factor of 256. In fact, this scaling factor was introduced as a simple means to facilitate backward compatility between EIGRP and IGRP: In IGRP, the overall metric is a 24-bit value while EIGRP uses a 32-bit value to express this metric. By multiplying a 24-bit value with the factor of 256 (effectively bit-shifting it 8 bits to the left), the value is extended into 32 bits, and vice versa. This way, redistributing information between EIGRP and IGRP involves simply dividing or multiplying the metric value by a factor of 256, which is done automatically.

EIGRP also maintains a hop count for every route, however, the hop count is not used in metric calculation. It is only verified against a predefined maximum on an EIGRP router (by default it is set to 100 and can be changed to any value between 1 and 255). Routes having a hop count higher than the maximum will be advertised as unreachable by an EIGRP router.

Successor

A successor for a particular destination is a next hop router that satisfies these two conditions:

• it provides the least distance to that destination
• it is guaranteed not to be a part of some routing loop

The first condition can be satisfied by comparing metrics from all neighboring routers that advertise that particular destination, increasing the metrics by the cost of the link to that respective neighbor, and selecting the neighbor that yields the least total distance. The second condition can be satisfied by testing a so-called Feasibility Condition for every neighbor advertising that destination. There can be multiple successors for a destination, depending on the actual topology.

The successors for a destination are recorded in the topology table and afterwards they are used to populate the routing table as next-hops for that destination.

Feasible Successor

A feasible successor for a particular destination is a next hop router that satisfies this condition:

• it is guaranteed not to be a part of some routing loop

This condition is also verified by testing the Feasibility Condition.

Thus, every successor is also a feasible successor. However, in most references about EIGRP the term "feasible successor" is used to denote only those routers which provide a loop-free path but which are not successors (i.e. they do not provide the least distance). From this point of view, for a reachable destination there is always at least one successor, however, there might not be any feasible successors.

A feasible successor provides a working route to the same destination, although with a higher distance. At any time, a router can send a packet to a destination marked "Passive" through any of its successors or feasible successors without alerting them in the first place, and this packet will be delivered properly. Feasible successors are also recorded in the topology table.

The feasible successor effectively provides a backup route in the case that existing successors die. Also, when performing unequal-cost load-balancing (balancing the network traffic in inverse proportion to the cost of the routes), the feasible successors are used as next hops in the routing table for the load-balanced destination.

By default, the total count of successors and feasible successors for a destination stored in the routing table is limited to four. This limit can be changed in the range from 1 to 6. In more recent versions of Cisco IOS (eg. 12.4), this range is between 1 and 16.

Active and Passive State

A destination in the topology table can be marked either as Passive or Active. A Passive state is a state when the router has identified the successor(s) for the destination. The destination changes to Active state when current successor no longer satisfies the Feasibility Condition and there are no feasible successors identified for that destination (i.e. no backup routes are available). The destination changes back from Active to Passive when the router received replies to all queries it has sent to its neighbors. Notice that if a successor stops satisfying the Feasibility Condition but there is at least one feasible successor available, the router will promote a feasible successor with the lowest total distance (the distance as reported by the feasible successor plus the cost of the link to this neighbor) to a new successor and the destination remains in the Passive state.

Advertised Distance and Feasible Distance

Advertised Distance (AD) is the distance to a particular destination as reported by a router to its neighbors. This distance is sometimes also called a Reported Distance and is equal to the current lowest total distance through a successor.

A Feasible Distance (FD) is the lowest known distance from a router to a particular destination since the last time the route went from Active to Passive state. It can be expressed in other words as a historically lowest known distance to a particular destination. While a route remains in Passive state, the FD is updated only if the actual distance to the destination decreases, otherwise it stays at its present value. On the other hand, if a router needs to enter Active state for that destination, the FD will be updated with a new value after the router transitions back from Active to Passive state. This is the only case when the FD can be increased. The transition from Active to Passive state in effect marks the start of a new history for that route.

For example, if the route to a newly discovered destination X went from Active to Passive state with a total distance of 10, the router sets the AD and FD to 10. Later this distance decreases from 10 to 8. The distance remains in the Passive state (because distance decrease never violates the Feasibility Condition) and the router updates the AD and FD to 8. Even later, the distance increases to 12 but in such a way that there is still a valid successor or feasible successor available. In this case, the AD gets updated to 12, however, the FD will remain at the value of 8. Therefore, the values of AD and FD can be different. Finally, the actual successor fails and no other feasible successor is currently identified. Therefore, the router has to transition to Active state and ask its neighbors for a new route to the destination X. Assuming that the newly found path to that destination has a total distance of 100, the router will transition back to Passive state and update both its AD and FD to the new shortest path length, in this case, 100.

Feasibility Condition

The feasibility condition is a sufficient condition for loop freedom in EIGRP-routed network. It is used to select the successors and feasible successors that are guaranteed to be on a loop-free route to a destination. Its simplified formulation is strikingly simple:

If, for a destination, a neighbor router advertises a distance that is strictly lower than our feasible distance, then this neighbor lies on a loop-free route to this destination.

or in other words,

If, for a destination, a neighbor router tells us that it is closer to the destination than we have ever been, then this neighbor lies on a loop-free route to this destination.

In exact terms, every neighbor that satisfies the relation AD < FD for a particular destination is on a loop-free route to that destination.

This condition is also called the Source Node Condition and is one of more equivalent conditions that were proposed and proven by Dr. J. J. Garcia-Luna-Aceves at SRI. The paper proposing the Source Node Condition and the Diffusing Update Algorithm algorithm itself can be found here.

It is important to realize that this condition is a sufficient, not a necessary condition. That means that neighbors which satisfy this condition are guaranteed to be on a loop-free path to some destination, however, there may be also other neighbors on a loop-free path which do not satisfy this condition. However, such neighbors do not provide the shortest path to a destination, therefore, not using them does not present any significant impairment of the network functionality. These neighbors will be re-evalued for possible usage if the router transitions to Active state for that destination.

EIGRP classification as a distance-vector

In the past, EIGRP was described in various Cisco marketing materials as a balanced hybrid routing protocol, allegedly combining the best features from link-state and distance-vector protocols. This description is not correct from a principal point of view. By definition:

• Distance-vector routing protocols are based on a distributed form of Bellman-Ford algorithm to find shortest paths. They work by exchanging a vector of distances to all destinations known to each node. No further topological information is ever exchanged. Thus, each node knows about all destinations present in the network and it knows the resulting distance to each destination via every of the node's neighbors. However, the node does not have any idea of the actual network topology, nor does the node need it.
• Link-state routing protocols are based on algorithms to find shortest paths in a graph (the most often used algorithm is Dijkstra's algorithm). They work by exchanging a description of each node and its exact connections to its neighbors (in essence, each node describes its adjacencies to neighboring nodes and this information is flooded throughout the network). Therefore, each node knows the exact network topology, i.e. it has a graph representation of the network. Using this graph, each node computes the shortest paths from itself to each available destination.

The EIGRP routers exchange messages that contain information about bandwidth, delay, load, reliability and MTU of the path to each destination as known by the advertising router. Each router uses these parameters to compute the resulting distance to a destination. No further topological information is present in the messages. This principle fully corresponds to the operation of distance-vector protocols. Therefore, EIGRP is in essence a distance-vector protocol.

It is true that EIGRP uses a number of techniques not present in naïve distance-vector protocols, notably

• the use of explicit hello packets to discover and maintain adjacencies between routers;
• the use of a reliable protocol to transport routing updates;
• the use of a feasibility condition to select a loop-free path;
• the use of diffusing computations to involve the affected part of network into computing a new shortest path

None of these techniques, however, makes any difference to the basic principles of EIGRP, which exchanges a vector of distances to each known destination network without full knowledge of the network topology, and, as a matter of fact, similar techniques have been used in other distance-vector protocols (notably DSDV and AODV). While EIGRP is indeed an advanced distance-vector routing protocol, it is not a hybrid protocol.

An example of a true hybrid routing protocol would be the multi-area Open Shortest Path First (OSPF) protocol. The intra-area routing in OSPF is done using the link-state approach, as each area knows its precise internal topology. Inter-area routing in OSPF is done using the distance-vector approach—the networks outside an area are known only by their distance, not by their exact topology.

Other details

EIGRP is able to deal with Classless Inter-Domain Routing (CIDR), allowing the use of variable-length subnet masks—one of the protocol's main advantages over its predecessor. Its main disadvantage is that it runs only on Cisco equipment, which may lead to an organization being locked in to this vendor. Also, EIGRP is not usable in applications where routers need to know the exact network topology (for example, traffic engineering in MPLS).

EIGRP can run separate routing processes for IP, IPv6, IPX and AppleTalkprotocol-dependent modules (PDMs). However, this does not facilitate translation between protocols. through the use of

Example of setting up EIGRP on a Cisco IOS router using classful IP addressing:

Router> enable
Router# config terminal
Router(config)# router eigrp ?
  <1-65535>  Autonomous system number
Router(config)# router eigrp 1
Router(config-router)# network 192.168.0.0
Router(config-router)# end

Example of setting up EIGRP on a Cisco IOS router using classless IP addressing. The 0.0.15.255 wildcard in this example indicates a subnetwork with a maximum of 4094 hosts—it is the bitwise complement of the subnet maskno auto-summary command prevents automatic route summarization on classful boundaries, which would otherwise result in routing loops in discontiguous networks. 255.255.240.0. The

Router> enable
Router# config terminal
Router(config)# router eigrp 1
Router(config-router)# network 10.201.96.0 ?
  A.B.C.D  EIGRP wild card bits
  <cr>
Router(config-router)# network 10.201.96.0 0.0.15.255
Router(config-router)# no auto-summary
Router(config-router)# end

Collision Domains

• layer 1 of the OSI model

• a hub is an entire collision domain since it forwards every bit it receives from one interface on every other interfaces

• a bridge is a two interfaces device that creates 2 collision domains, since it forwards the traffic it receives from one interface only to the interface where the destination layer 2 device (based on his mac address) is connected to. A bridge is considered as an "intelligent hub" since it reads the destination mac address in order to forward the traffic only to the interface where it is connected

• a switch is a multi-interface hub, every interface on a switch is a collision domain. A 24 interfaces switch creates 24 collision domains (assuming every interface is connected to something, VLAN don't have any importance here since VLANs are a layer 2 concept, not layer 1 like collision domains)

Broadcast Domains

• layer 2 of the OSI model

• a switch creates an entire broadcast domain (provided that there's only one VLAN) since broadcasts are a layer 2 concept (mac address related)

• routers don't forward layer 2 broadcasts, hence they separate broadcast domains

With all this information, you can say that on your diagram, there are 2 broadcast domains (1 router that separates 2 LAN segments composed by one or many switches, with only 1 VLAN per segment).

There are 8 collision domains, one per pair of devices connected to each other (switch to router, switch to switch, switch to computer etc...) since we are talking about layer 1 concept (physical connection).

Decimal-hexadecimal-binary conversion table

Dec	Hex	Bin		Dec	Hex	Bin		Dec	Hex	Bin		Dec	Hex	Bin
0	0	00000000		64	40	01000000		128	80	10000000		192	c0	11000000
1	1	00000001		65	41	01000001		129	81	10000001		193	c1	11000001
2	2	00000010		66	42	01000010		130	82	10000010		194	c2	11000010
3	3	00000011		67	43	01000011		131	83	10000011		195	c3	11000011
4	4	00000100		68	44	01000100		132	84	10000100		196	c4	11000100
5	5	00000101		69	45	01000101		133	85	10000101		197	c5	11000101
6	6	00000110		70	46	01000110		134	86	10000110		198	c6	11000110
7	7	00000111		71	47	01000111		135	87	10000111		199	c7	11000111
8	8	00001000		72	48	01001000		136	88	10001000		200	c8	11001000
9	9	00001001		73	49	01001001		137	89	10001001		201	c9	11001001
10	a	00001010		74	4a	01001010		138	8a	10001010		202	ca	11001010
11	b	00001011		75	4b	01001011		139	8b	10001011		203	cb	11001011
12	c	00001100		76	4c	01001100		140	8c	10001100		204	cc	11001100
13	d	00001101		77	4d	01001101		141	8d	10001101		205	cd	11001101
14	e	00001110		78	4e	01001110		142	8e	10001110		206	ce	11001110
15	f	00001111		79	4f	01001111		143	8f	10001111		207	cf	11001111
16	10	00010000		80	50	01010000		144	90	10010000		208	d0	11010000
17	11	00010001		81	51	01010001		145	91	10010001		209	d1	11010001
18	12	00010010		82	52	01010010		146	92	10010010		210	d2	11010010
19	13	00010011		83	53	01010011		147	93	10010011		211	d3	11010011
20	14	00010100		84	54	01010100		148	94	10010100		212	d4	11010100
21	15	00010101		85	55	01010101		149	95	10010101		213	d5	11010101
22	16	00010110		86	56	01010110		150	96	10010110		214	d6	11010110
23	17	00010111		87	57	01010111		151	97	10010111		215	d7	11010111
24	18	00011000		88	58	01011000		152	98	10011000		216	d8	11011000
25	19	00011001		89	59	01011001		153	99	10011001		217	d9	11011001
26	1a	00011010		90	5a	01011010		154	9a	10011010		218	da	11011010
27	1b	00011011		91	5b	01011011		155	9b	10011011		219	db	11011011
28	1c	00011100		92	5c	01011100		156	9c	10011100		220	dc	11011100
29	1d	00011101		93	5d	01011101		157	9d	10011101		221	dd	11011101
30	1e	00011110		94	5e	01011110		158	9e	10011110		222	de	11011110
31	1f	00011111		95	5f	01011111		159	9f	10011111		223	df	11011111
32	20	00100000		96	60	01100000		160	a0	10100000		224	e0	11100000
33	21	00100001		97	61	01100001		161	a1	10100001		225	e1	11100001
34	22	00100010		98	62	01100010		162	a2	10100010		226	e2	11100010
35	23	00100011		99	63	01100011		163	a3	10100011		227	e3	11100011
36	24	00100100		100	64	01100100		164	a4	10100100		228	e4	11100100
37	25	00100101		101	65	01100101		165	a5	10100101		229	e5	11100101
38	26	00100110		102	66	01100110		166	a6	10100110		230	e6	11100110
39	27	00100111		103	67	01100111		167	a7	10100111		231	e7	11100111
40	28	00101000		104	68	01101000		168	a8	10101000		232	e8	11101000
41	29	00101001		105	69	01101001		169	a9	10101001		233	e9	11101001
42	2a	00101010		106	6a	01101010		170	aa	10101010		234	ea	11101010
43	2b	00101011		107	6b	01101011		171	ab	10101011		235	eb	11101011
44	2c	00101100		108	6c	01101100		172	ac	10101100		236	ec	11101100
45	2d	00101101		109	6d	01101101		173	ad	10101101		237	ed	11101101
46	2e	00101110		110	6e	01101110		174	ae	10101110		238	ee	11101110
47	2f	00101111		111	6f	01101111		175	af	10101111		239	ef	11101111
48	30	00110000		112	70	01110000		176	b0	10110000		240	f0	11110000
49	31	00110001		113	71	01110001		177	b1	10110001		241	f1	11110001
50	32	00110010		114	72	01110010		178	b2	10110010		242	f2	11110010
51	33	00110011		115	73	01110011		179	b3	10110011		243	f3	11110011
52	34	00110100		116	74	01110100		180	b4	10110100		244	f4	11110100
53	35	00110101		117	75	01110101		181	b5	10110101		245	f5	11110101
54	36	00110110		118	76	01110110		182	b6	10110110		246	f6	11110110
55	37	00110111		119	77	01110111		183	b7	10110111		247	f7	11110111
56	38	00111000		120	78	01111000		184	b8	10111000		248	f8	11111000
57	39	00111001		121	79	01111001		185	b9	10111001		249	f9	11111001
58	3a	00111010		122	7a	01111010		186	ba	10111010		250	fa	11111010
59	3b	00111011		123	7b	01111011		187	bb	10111011		251	fb	11111011
60	3c	00111100		124	7c	01111100		188	bc	10111100		252	fc	11111100
61	3d	00111101		125	7d	01111101		189	bd	10111101		253	fd	11111101
62	3e	00111110		126	7e	01111110		190	be	10111110		254	fe	11111110
63	3f	00111111		127	7f	01111111		191	bf	10111111		255	ff	11111111

Class C
Mask	Notation	Subnets	Hosts
255.255.255.0	/24	1	256
255.255.255.128	/25	2	128
255.255.255.192	/26	4	64
255.255.255.224	/27	8	32
255.255.255.240	/28	16	16
255.255.255.248	/29	32	8
255.255.255.252	/30	64	4
255.255.255.254	/31	128	2
255.255.255.255	/32	256	1
Class B
Mask	Notation	Subnets	Hosts
255.255.0.0	/16	2	65,536
255.255.128.0	/17	2	32,768
255.255.192.0	/18	4	16,384
255.255.224.0	/19	8	8,192
255.255.240.0	/20	16	4,096
255.255.248.0	/21	32	2,048
255.255.252.0	/22	64	1,024
255.255.254.0	/23	128	512
255.255.255.0	/24	256	256
Class A
Mask	Notation	Subnets	Hosts
255.0.0.0	/8	1	16,777,216
255.128.0.0	/9	2	8,388,608
255.192.0.0	/10	4	4,194,304
255.224.0.0	/11	8	2,097,152
255.240.0.0	/12	16	1,048,576
255.248.0.0	/13	32	524,288
255.252.0.0	/14	64	262,144
255.254.0.0	/15	128	131,072
255.255.0.0	/16	256	65,536

Administrative distance is the measure used by Cisco routers to select the best path when there are two or more different routes to the same destination from two different routing protocols. Administrative distance defines the reliability of a routing protocol. Each routing protocol is prioritized in order of most to least reliable (believable) using an administrative distance value. A lower numerical value is preferred, e.g. an OSPF route with an administrative distance of 110 will be chosen over a RIP route with an administrative distance of 120.

The following tables gives the default administrative distances used by Cisco routers.

Protocol	Administrative distance
Directly connected route / static route using exit interface	0
Static route with next-hop IP address	1
EIGRP summary route	5
External BGP	20
Internal EIGRP	90
IGRP	100
OSPF	110
IS-IS	115
RIP	120
EGP	140
ODR	160
External EIGRP	170
Internal BGP	200
Unknown	255