mod3-07.html

<!doctype html>
<html lang="en">

	<head>
		<meta charset="utf-8">

		<title>Advanced Networking - Module 3 Chapter 7 - EIGRP</title>

		<meta name="description" content="Abilitante alle certificazioni Cisco CCENT e CCNA">
		<meta name="author" content="Hacklab Cosenza">

		<meta name="apple-mobile-web-app-capable" content="yes">
		<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">

		<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">

		<link rel="stylesheet" href="css/reveal.css">
		<link rel="stylesheet" href="css/theme/black.css" id="theme">

		<!-- Code syntax highlighting -->
		<link rel="stylesheet" href="lib/css/zenburn.css">

		<!-- Printing and PDF exports -->
		<script>
			var link = document.createElement( 'link' );
			var link = document.createElement( 'link' );
			link.rel = 'stylesheet';
			link.type = 'text/css';
			link.href = window.location.search.match( /print-pdf/gi ) ? 'css/print/pdf.css' : 'css/print/paper.css';
			document.getElementsByTagName( 'head' )[0].appendChild( link );
		</script>

		<!--[if lt IE 9]>
		<script src="lib/js/html5shiv.js"></script>
		<![endif]-->
	</head>

	<body>

		<div class="reveal">

			<!-- Any section element inside of this container is displayed as a slide -->
			<div class="slides">
				<section>
					<h1>Advanced Networking</h1>
					<h2>Routing &amp; Switching:<h2>
					<h2>Scaling Networks</h2>
					<h3>Chapter 7: EIGRP</h3>
					<p>
						<small><a href="http://hlcs.it">Hacklab Cosenza</a> / Centro di Ricerca su Tecnologia e Innovazione</small>
					</p>
				</section>

				<section>
					<h2>EIGRP Introduction</h2>
					<p>EIGRP was released in 1992 by Cisco and until 2013 has only been available on Cisco devices.</p>
					<p>In 2013 Cisco released an informational RFC to IETF covering <strong>basic functionality</strong>, thus making EIGRP an open standard able to interoperate with non-Cisco devices. Advanced features of EIGRP remain Cisco-only.</p>
					<p>EIGRP is at the core a <strong>distance-vector routing protocol</strong>, because it learns information about the topology only from directly connected EIGRP routers, but it also <u>borrow features typical of a link-state routing protocol</u>.</p>
				</section>

				<section>
					<section>
						<h2>EIGRP Features</h2>
						<ul>
							<li>The algorithm used by EIGRP is the <strong><em>Diffusing Update Algorithm</em> (DUAL)</strong>. One of its characteristics is that it <u>holds every route learned through the protocol</u>, keeping them for backup and avoiding expensive DUAL recomputations.</li>
							<li>EIGRP routers establish <strong>adjancencies</strong>.</li>
							<li>EIGRP use its own packet delivery protocol called <strong><em>Reliable Transport Protocol</em> (RTP)</strong>.</li>
						</ul>
					</section>
					<section>
						<h2>EIGRP Features</h2>
						<ul>
							<li>EIGRP updates and routes do not expire. They are:
							<ul>
								<li><strong>Partial</strong>: when a change occurs, <u>only the information about the change</u> is propagated.</li>
								<li><strong>Bounded</strong>: the partial information is sent <u>only to the neighbors that are affected</u> by the change.</li>
							</ul>
							<li>EIGRP is able to maintain and <u>use multiple route to the same destination network</u> and do both <strong>equal and unequal load balancing</strong> of traffic between them.</li>
						</ul>
					</section>
				</section>

				<section>
					<h2>Protocol-Dependent Modules</h2>
					<p>EIGRP is <strong>network-layer agnostic</strong>:  it’s <u>able to perform a routing function for really any L3 protocol</u>, even future ones, thanks to <strong><em>protocol-dependent modules</em> (PDMs)</strong>.</p>
					<p>PDMs "translate" the L3 protocol to the DUAL algo and to store the results of DUAL into tables specific to the L3 protocol. It works as an <strong>abstraction layer</strong> for:</p>
					<ul>
						<li>maintaining protocol-specific <strong>neighbor/topology tables</strong>.</li>
						<li>Rx/Tx EIGRP packets encapsulated in the L3 protocol.</li>
						<li>handling the L3 protocol routing table for DUAL.</li>
						<li>computing the metric and handling to DUAL.</li>
						<li>handling ACLs specific to the L3 protocol.</li>
						<li>redistribution of routes to/from EIGRP.</li>
					</ul>
				</section>

				<section>
					<h2>RTP and Authentication</h2>
					<p>The <u>consequences of being L3-agnostic</u> is that EIGRP cannot use TCP and UDP, which are specific to IPv4/6.</p>
					<p>EIGRP uses its own transport protocol, the <em>Reliable Transport Protocol</em>. It obviously supports <strong>reliable delivery</strong> (requiring ACKs, similar to TCP), but <strong>it also does unrealiable delivery</strong> with no acknowledge requirements.</p>
					<p>RTP supports <strong><u>both unicast and multicast</u></strong> for sending EIGRP packets. Multicast addresses for EIGRP are 224.0.0.10 (IPv4) and FF02::A (IPv6).</p>
					<p>EIGRP <strong>supports MD5 authentication</strong> of routing packets as RIP and OSPF, but <strong>doesn’t encrypt them</strong>.</p>
				</section>

				<section>
					<h2>EIGRP Messages</h2>
					<ul>
						<li><strong>Hello</strong> - To establish and maintain neighbor adjacencies.</li>
						<ul>
							<li>Sent with unreliable RTP, as multicast if supported.</li>
						</ul>
						<li><strong>Update</strong> - To deliver routing information to neighbors.</li>
						<ul>
							<li>Sent with reliable RTP, unicast or multicast.</li>
						</ul>
						<li><strong>Acknowledgment</strong> - Used to conferm the reception of <u>any</u> EIGRP packet that was sent using reliable delivery.</li>
						<ul>
							<li>Sent with unreliable RTP, as unicast. </li>
						</ul>
						<li><strong>Query</strong> - Used to ask neighbors for certain routes.</li>
						<ul>
							<li>Sent with reliable RTP, as unicast or multicast.</li>
						</ul>
						<li><strong>Reply</strong> - Response to EIGRP queries.</li>
						<ul>
							<li>Sent with reliable RTP, as unicast</li>
						</ul>
					</ul>
					<p>IPv4/6 encapsulation uses <u>88</u> in <strong>Protocol</strong>/<strong>Next Header</strong> fields.</p>
				</section>

				<section>
					<h2>EIGRP Hello Packets</h2>
					<p>Used to <u>discover EIGRP neighbors</u> and establish and maintain adjacencies with them. They are sent:
					<ul>
						<li>with unreliable RTP (so no ACK expected).</li>
						<li>as multicast and <strong>every 5s on Ethernet networks</strong>, and <strong>every 60s on NBMA networks</strong> (X.25, Frame Relay, T1)</li>
					</ul>
					<p>An established adjacencies is considered <u>broken when no Hello packet has been received for an <strong>Hold timer</strong></u>. Default is 3x the Hello timer (15s on broadcast, 180s on NBMA).</p>
					<p><strong>After that, the routes through that neighbor are no longer viable</strong> to EIGRP, that starts to <u>search for a new path by sending query packets</u>.</p>
				</section>

				<section>
					<h2>EIGRP Update Packets</h2>
					<p>EIGRP <u><strong>routing informations</strong> are propagated</u> through its Update packets.</p>
					<p>They are <u>not periodic</u>, but instead only sent incrementally (<strong>partial</strong>) and only to the affected EIGRP-neighbors (<strong>bounded</strong>). The net effect is a <u>huge bandwidth saving</u> achievable with EIGRP.</p>
					<p>When required by a single router, they are sent as unicast, otherwise as multicast (on supported networks). In any case they use reliable delivery so <strong>acknowledge is required</strong>.</p>
				</section>

				<section>
					<h2>EIGRP Acknowledgements</h2>
					<p>Required any time reliable delivery is used.</p>
					<p>EIGRP Acknowledge packets have the form of an <strong>Hello packet without any data</strong>. They are obviously <u>sent with <strong>unreliable RTP</strong></u>, otherwise they would cause a loop of ACKs.</p>
				</section>

				<section>
					<h2>EIGRP Query and Reply</h2>
					<p>Queries and Replies are used by EIGRP and DUAL when <u><strong>searching information</strong> in other neighbors</u>.</p>
					<p>Both use <strong>reliable delivery</strong>. Queries are sent as multicast, while Replies as unicast.</p>
					<p>Replies have to be <strong>sent even for negative answers</strong>, that is when <u>a neighbor doesn’t have the required information</u>.</p>
					<p>An EIGRP router send queries <u>even for a network previously attached</u> to it that it is now down, because there’s always the possibility of another path in the topology.</p>
				</section>

				<section>
					<section>
						<h2>EIGRP Packet Format</h2>
						<img src="http://i.imgur.com/072dOCQ.gif" style="width: 800px;">
					</section>
					<section>
						<h2>EIGRP Header</h2>
						<p>EIGRP data field is called <strong>TLV (<em>Type, Length and Value</em>)</strong>. <u>There are many, but CCNA focuses on 3 of them</u>. Regardless of the TLV, <strong>the same EIGRP packet header is used</strong>.</p>
						<p>The important field in the EIGRP header are the <strong>OpCode</strong> and the <strong>Autonomous System Number</strong>.</p>
						<ul>
							<li><strong>OpCode specifies the <u>packet type</u></strong>, by using 1 for Update, 3 for Query, 4 for Reply and 5 for Hello. Acknowledgments are Hello packets with no data.</li>
							<li>The <strong>Autonomous System Number identifies the routing process</strong>, similar to OSPF Process ID.</li>
						</ul>
					</section>
					<section>
						<h2>EIGRP TLV - Parameter</h2>
						<p>The <strong>EIGRP Parameter’s TLV</strong> (also known as <em>General TLV</em>, Type 0x0001) includes:</p>
						<ul>
							<li><strong>K1, K2, K3, K4, K5</strong> fields. Through them EIGRP knows which parameters to use as <strong><em>weights</em> to compute the composite metric</strong>.</li>
							<li>The <strong>Hold timer</strong> is the time the neighor should wait <strong>before considering the adjancency broken</strong> and the sending router down.</li>
						</ul>
					</section>
					<section>
						<h2>EIGRP TLV - IP Internal</h2>
						<p>The <strong>IP Internal Route TLV</strong> (Type 0x0002) is used to <strong>advertise EIGRP routes</strong> <u>in the autonomous system</u>. It includes:</p>
						<ul>
							<li><strong>Bandwidth</strong> - The <strong>lowest</strong> configured bandwidth of an interface <u>along that route</u>.</li>
							<li><strong>Delay</strong> - Measured in units of 10 microseconds, the <strong>sum of the delays</strong> of the interfaces <u>along that route</u>.</li>
							<li><strong>Prefix Length</strong> - The subnet mask (number of bits).</li>
							<li><strong>Destination</strong> - The address of the destination network. It only contains the network portion (172.17.0.0/16 = 172.17). The minimum length is 24 bits, so <u>if necessary padding is added</u>. If prefix length is more than 24, the field is extended another 32 bits.</li>
						</ul>
					</section>
					<section>
						<h2>EIGRP TLV - IP External</h2>
						<p>The <strong>IP External Route TLV</strong> (Type 0x0003) is a message for <strong>importing external routes into EIGRP</strong>, such as a default static route.</p>
						<ul>
							<li>The first part of this TLV has <strong>fields used to track the external route</strong>.</li>
							<li>The second part has the <strong>same fields used for IP Internal TLVs</strong>.</li>
						</ul>
					</section>
				</section>

				<section>
					<h2>Autonomous System Numbers</h2>
					<p><strong>EIGRP’s autonomous system numbers are <u>unrelated to the AS numbers assigned by IANA</u>.</strong></p>
					<ul>
						<li>IANA’s AS are assigned to large collection of networks that are <u>administered by a single entity</u>.</li>
						<li>Inside an AS, IGP routing protocols are used <u>according to AS own preferences</u>, policies, network design.</li>
						<li>The <u>AS interfaces with other ASes</u>, presenting a single consistent Internet routing policy to them using <u>BGP</u> (the only routing protocol that <u>use IANA’s AS numbers</u>).</li>
						<li><strong>EIGRP AS numbers works as process IDs to distinguish different EIGRP istances</strong>. It may be advisable to run independent EIGRP instances to handle different nets.</li>
					</ul>
				</section>

				<section>
					<h2>IPv4 EIGRP Configuration</h2>
					<p>To enter <u>EIGRP configuration mode</u>, use</p>
					<pre><code class="no-highlight">Router(config)# router eigrp [autonomous_system]</code></pre>
					<p>The AS number ranges between 1-65535. <strong>It has to be the same within the desidered EIGRP routing domain</strong>.</p>
					<p>This command <strong>doesn’t start the EIGRP process</strong>, but only enters the configuration mode. The <code>no</code> version of this command stops the process and <u>delete all existing config</u>.</p>
				</section>

				<section>
					<h2>EIGRP Router ID</h2>
					<p>Everything is <strong>the same as with OSPF</strong>:</p>
					<ul>
						<li><strong>Expressed as 32 bit IPv4 addresses</strong> (not an actual IP).</li>
						<li>First, manually configured Router IDs with
							<pre><code class="no-highlight">Router(config)# eigrp router-id [id]</code></pre>
						</li>
						<li>Second, highest IP on any loopback interface.</li>
						<li>Third, highest IP on any active actual interface, EIGRP-enabled or not.</li>
						<li>Displayed with <code>show ip protocols</code> command.</li>
					</ul>
					<pre><code class="no-highlight" style="max-height: 150px;">Router(config-router)# eigrp router-id 1.2.3.4
Router(config-router)# end
Router# show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "eigrp 1"
  [output omitted]

  EIGRP-IPv4 Protocol for AS(1)
    Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
    NSF-aware route hold timer is 240
    Router-ID: 3.3.3.3

    Topology : 0 (base)
      Active Timer: 3 min
      Distance: internal 90 external 170
      [output omitted]</code></pre>
				</section>

				<section>
					<section>
						<h2>EIGRP Network Announcements</h2>
						<p>The <strong><code>network</code></strong> command works just as in any IGP routing protocol and has the same effects:</p>
						<ul>
							<li>Any interface which has an address in that network gets <u>EIGRP-enabled</u>, sending/processing EIGRP updates.</li>
							<li>That <u>network is announced</u> in EIGRP routing updates.</li>
						</ul>
						<p>There are 2 versions of the network command:</p>
						<ul>
							<li><code>network {classful_addr}</code> enables interfaces and announces subnets of that classful address.</li>
							<li><code>network {network_addr} [wildcard]</code> enables a specific subnet and the interface belonging in that subnet.</li>
							<li>In some IOS version the subnet mask can also be used.</li>
						</ul>
					</section>
					<section>
						<h2>Passive Interfaces</h2>
						<p>EIGRP also allows for <strong>passive interfaces</strong>, when we want to announce a subnet but <u>sending routing updates would be useless</u> (because there are no neighbors) <u>or undesirable</u> (because the other end of the link is not under our control).</p>
						<pre><code class="no-highlight">!!! Specific interface !!!
Router(config-router)# passive-interface [if_id]
!!! Passive by default, then exceptions !!!
Router(config-router)# passive-interface default
Router(config-router)# no passive-interface [if_id]
Router(config-router)# end
Router# show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "eigrp 1"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  Redistributing: static
  EIGRP-IPv4 Protocol for AS(1)
    Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
    NSF-aware route hold timer is 240
    Router-ID: 2.2.2.2
    Topology : 0 (base)
      Active Timer: 3 min
      Distance: internal 90 external 170
      Maximum path: 4
      Maximum hopcount 100
      Maximum metric variance 1

  Automatic Summarization: disabled
  Maximum path: 4
  Routing for Networks:
    172.16.0.0
    192.168.10.8/30
  Passive Interface(s):
    GigabitEthernet0/0
  Routing Information Sources:
    Gateway Distance Last Update
    192.168.10.10 90 02:14:28
    172.16.3.1 90 02:14:28
  Distance: internal 90 external 170

Router#</code></pre>
					</section>
				</section>

				<section>
					<h2>EIGRP Neighbors</h2>
					<p>The <strong>list of adjancencies established</strong> by an EIGRP router is <u>stored in the <strong>neighbor table</strong></u>, which can be displayed with</p>
					<pre><code class="no-highlight">Router#show ip eigrp neighbors
EIGRP-IPv4 neighbors for AS(1)
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   192.168.12.2            Fa0/0             11 00:06:06   19   200  0  27
0   172.17.87.3             Se0/0/1           14 01:35:12   16   120  0  18</code></pre>
					<ul>
						<!-- HARDCODED -->
						<small>
						<li><strong>H</strong> - The <u>order</u> in which the neighbor were discovered</li>
						<li><strong>Address</strong> - IP of the neighbour</li>
						<li><strong>Interface</strong> - <u>Local</u> interface receiving neighbor's Hello packets.</u></li>
						<li><strong>Hold</strong> - Hold time, if 0 is reached the neighbor is considered down; reset to Hold timer value if an Hello packet is received.</li>
						<li><strong>Uptime</strong> - Time since the entry was added to the table.</li>
						<li><strong>Smooth Round Trip Timer</strong> and <strong>Retransmission Timeout</strong>, used by RTP.</li>
						<li><strong>Queue Count</strong> - EIGRP packets waiting to be sent. Should always be 0.</li>
						<li><strong>Sequence Number</strong> - Tracking number for updates, queries and replies.</li>
						</small>
					</ul>
				</section>

				<section>
					<h2>EIGRP AD and Summarization</h2>
					<p>EIGRP is the <strong><u>preferred IGP routing protocol</u></strong> on Cisco devices. Its routes have an <strong>AD of 90</strong> for internal routes and 170 for external ones (imported from non-EIGRP sources).</p>
					<p>There is also an AD of 5 for EIGRP summary route. However, <strong>EIGRP autosummarization is disabled by default since IOS 15.0</strong>. On previous IOS version, it can be disabled with</p>
					<pre><code class="no-highlight">Router(config-router)# no auto-summary</code></pre>
				</section>

				<section>
					<h2>EIGRP Adjacencies</h2>
					<p>For 2 EIGRP-enabled routers to establish an adjancency, <strong>several parameters must match</strong>. Among them there are <strong>metric weights</strong> and <strong>AS number</strong>.</p>
					<p><strong>Hellos exchange</strong>s to establish adjacency goes as follows:</p>
					<ul>
						<li>R1 sends an Hello packet on all of its EIGRP interfaces.</li>
						<li>R2 receive the Hello packet and sends an Update packet with its routing information, <u>except for routes learned through that interface</u> (<em>split horizon</em> technique).</li>
						<li>However at this stage R1 and R2 are stil not neighbour. <strong>Only when R2 sends an Hello packet and R1 receives it the adjancency is established</strong> and neighbor tables updated.</li>
					</ul>
				</section>

				<section>
					<h2>EIGRP Topology Table</h2>
					<p>The content of EIGRP Update packets received from neighbors is included in routers’ <strong>topology table</strong>.</p>
					<p>It is different from the routing table because <strong>it contains every route to every destination network learned by EIGRP</strong>, <u>even the ones that won’t be installed</u> in the RT. The <strong>exchange of routing information</strong> goes as follows:</p>
					<ul>
						<li>R1 receives the Update packet from R2 and updates the topology table with destinations and respective metrics.</li>
						<li>R1 sends an Acknowledgment packet to R2.</li>
						<li>R1 sends an Update packet to R2 with its complete routing information except those learned from R2.</li>
						<li>R2 acknoledges the Update packet received from R1.</li>
					</ul>
				</section>

				<section>
					<section>
						<h2>EIGRP Composite Metric</h2>
						<p>EIGRP uses a <strong>composite metric</strong>: this means the cost of a path is the <strong>result of a formula</strong> that <u>uses several combined parameters</u> (<strong><em>weights</em></strong>).</p>
						<p>For the composite metric to make sense, <strong>every EIGRP routers in the routing domain have to agree on the same weights</strong> to compute it. They do so with the K1, K2, K3, K4 and K5 parameters in the General TLV.</p>
						<p>The <strong>general EIGRP composite metric formula</strong> is:</p>
						<img src="http://i.imgur.com/vArSqGv.png" style="width: 700px;">
					</section>
					<section>
						<h2>Parameters and Weights</h2>
						<img src="http://i.imgur.com/vArSqGv.png">
						<ul>
							<li><strong>Bandwidth</strong> - The <u>slowest bandwidth of any exit interface</u> along the route path. The value is used scaled (10000000 / actual bandwidth). <u>Weighted by default</u> (<strong>K1</strong> = 1).</li>
							<li><strong>Load</strong> - The <u>worst load on any link on the routing path</u>, computed as exponential average over 5 minutes between bandwidth and packet rate of the interfaces. Ranges from 0 to 255 (255 is 100% load). <u>Not weighted by default</u> (<strong>K2</strong> = 0).</li>
							<li><strong>Delay</strong> - The s<u>um of all exiting interfaces’ delay</u> along the routing path. Measured in 10s of microseconds (it takes a packet to travel that route). <u>Weighted by default</u> (<strong>K3</strong> = 1).</li>
						</ul>
					</section>
					<section>
						<h2>Parameters and Weights</h2>
						<img src="http://i.imgur.com/vArSqGv.png">
						<ul>
							<li><strong>Reliability</strong> - The likelihood a packet will successfully be transmitted on a link on the routing path, <u>based on previous keepalives</u>. Measured in the range of 0 (completely unreliable) to 255 (perfect reliability). <u>Not weighted by default</u> (<strong>K4</strong> = 0, <strong>K5</strong> = 0).</li>
							<li><strong>MTU</strong>, while included in routing updates, is <strong>not a metric weight</strong>.</li>
						</ul>
						<p>With the default weights, the general formula becomes</p>
						<img src="http://i.imgur.com/GCCffGo.png">
					</section>
					<section>
						<h2>Altering the Weights</h2>
						<p>The <u>K parameters can be altered</u> with the command</p>
						<pre><code class="no-highlight">Router(config-router)# metric weights {tos k1 k2 k3 k4 k5}</code></pre>
						<p>and verified with <code>show ip protocols</code>. Nevertheless, modifying them is <u>not advisable</u> because <strong>normally not weighted parameters will result in frequent recalculation of the metric</strong>, and hence the topology table.</p>
						<p>All of the metric parameters can be displayed with:</p>
						<pre><code class="no-highlight">Router# show interfaces Fa0/1
FastEthernet0/1 is up, line protocol is up
[output omitted]
  MTU 1500 bytes, BW 10000 Kbit, DLY 100000 usec, rely 255/255, load 1/255
[output omitted]</code></pre>
					</section>
					<section>
						<h2>Bandwidth and Delay</h2>
						<p><strong>Bandwidth and delay are not measured dynamically</strong>, and are instead pre-determined values that can be tuned.</p>
						<ul>
							<li>Bandwidth is altered with <pre><code>Router(config-if) bandwidth [kbps_value]</code></pre> This is especially important for serial links, because a speed of T1 (1544 Kbps) is often the default.</li>
							<li>Default <strong>Delay values depend on the type of link</strong> (eg: 1000 for FastEthernet, 20000 for Serial links)</li>
						</ul>
					</section>
				</section>

				<section>
					<h2>DUAL Overview</h2>
					<p>EIGRP uses <strong>both split horizon and hold-down timers</strong> (an interval after a network goes down in which the router will refuse routes to that network, to avoid potential instability) <strong>to avoid routing loops</strong>.</p>
					<p><u>The main loop-avoiding mechanism</u> in EIGRP is <strong>DUAL</strong>. When there is a topology change, DUAL make sure that <strong>affected router re-synchronize at the same time</strong> while excluding unaffected routers from the topology recomputation.</p>
				</section>

				<section>
					<h2>DUAL FSM</h2>
					<p>DUAL makes its decision about route recomputations with a <strong>workflow model</strong> known as <strong><em>DUAL Finite State Machine</em> (FSM)</strong>, which is made up of:</p>
					<ul>
						<li>A certain, finite, number of stages (<em>states</em>)</li>
						<li>Transition between states.</li>
						<li>Operations</li>
					</ul>
				</section>

				<section>
					<h2>DUAL: Successor and Feasible Distance</h2>
					<ul>
						<li><strong>Successor</strong> - A neighboring router that is the <u>next hop for a certain destination network</u>. Its IP is shown in the routing table after the "<strong>via</strong>" keyword.</li>
						<li><strong>Feasible Distance (FD)</strong> - It’s the <u>lowest metric available</u> for a route to a certain destination network. It’s the second number in the square brackets in an EIGRP entry.</li>
					</ul>
					<pre><code class="no-highlight">Router# show ip route
[omitted]

D 10.18.12.0/24  [90/3012096] via 172.17.87.3, 02:11:10, Serial0/0/0</code></pre>
					<p>DUAL is why EIGRP routes are marked as <strong>"D" in the routing table</strong>.</p>
				</section>

				<section>
					<section>
						<h2>DUAL: Feasibility Condition</h2>
						<ul>
							<li><strong>DUAL stores every learned route</strong>, to <u>use them as backup</u> paths and quickly achieve convergence with no need for recomputation, after a topology change.</li>
							<li>A <strong><em>Feasible Successor</em> (FS)</strong> is a backup route to a certain destination network that satisfies a certain condition known as <strong><em>Feasibility Condition</em> (FC)</strong>. If the FC is met, the backup route is <strong>guaranteed to be loop-free</strong> and so can be a FS.</li>
							<li>The <strong><em>Reported Distance</em> (RD)</strong> to a destination network is simply the FD that a neighbor of a local router says it has to the same destination network.</li>
						</ul>
					</section>
					<section>
						<h2>DUAL: Feasibility Condition</h2>
						<ul>
							<li>The <strong><u>FC is satisfied if the neighbour’s RD is less than the local router’s FD</u></strong>.</li>
							<li>Why? If the RD is less than the FD, then <strong>it’s impossible that the local router is part of the path</strong> that the neighbor is advertising, <u>which is the definition of a loop</u>.</li>
						</ul>
					</section>
				</section>

				<section>
					<section>
						<h2>Display EIGRP FS</h2>
						<p><strong>EIGRP topology table contains both successors and feasible successors</strong>. To display main and sub-entries:</p>
						<pre><code class="no-highlight">Router# show ip eigrp topology
[omitted]
P 10.18.12.0/24, 1 successors, FD is 3012096
      via 172.17.87.3 (3012096/2816), Serial0/0/0
      via 192.168.43.1 (41024256/2170112), Serial0/1/0
[omitted]</code></pre>
						<ul>
							<li><strong>P</strong> - Stands for <strong>passive state</strong>, which means that the <strong>route is stable</strong> and not subject to <strong>DUAL recomputations</strong>. When DUAL is recomputing metric or searching for alternate paths, the route is in an <strong>active (A) state</strong>.</li>
							<li>The <strong>destination network</strong> and the number of alternative paths to it (before the “successors” keyword).</li>
							<li>The <strong>FD</strong> to the destination network.</li>
						</ul>
					</section>
					<section>
						<h2>Display EIGRP FS</h2>
						<pre><code class="no-highlight">Router# show ip eigrp topology
[omitted]
P 10.18.12.0/24, 1 successors, FD is 3012096
      via 172.17.87.3 (3012096/2816), Serial0/0/0
      via 192.168.43.1 (41024256/2170112), Serial0/1/0
[omitted]</code></pre>
						<p>First subentry content:</p>
						<ul>
							<li>The <strong>next-hop address of the successor</strong>, shown <u>in the routing table</u>.</li>
							<li>The <strong>FD</strong> to the destination, shown in the first line and <u>in the routing table</u>.</li>
							<li>The <strong>RD of the successor</strong> to reach that destination.</li>
							<li><strong>Output interface</strong>, shown <u>in the routing table</u>.</li>
						</ul>
					</section>
					<section>
						<h2>Display EIGRP FS</h2>
						<pre><code class="no-highlight">Router# show ip eigrp topology
[omitted]
P 10.18.12.0/24, 1 successors, FD is 3012096
      via 172.17.87.3 (3012096/2816), Serial0/0/0
      via 192.168.43.1 (41024256/2170112), Serial0/1/0
[omitted]</code></pre>
						<p>Other subentries are present <u>if there are FSs</u>:</p>
						<ul>
							<li>The <strong>next-hop address of the FS</strong>.</li>
							<li>The <strong>local router’s hypotetical new FD and metric</strong>, if this became the successor.</li>
							<li>The <strong>RD of the FS</strong>. <u>It meets the FC, so it is listed as FS</u>.</li>
							<li><strong>Output interface</strong> to reach the FS.</li>
						</ul>
					</section>
					<section>
						<h2>EIGRP Non-Feasible Successors</h2>
						<p>It could happen that <strong>a backup route it’s actually available, but that it doesn’t meet the FC</strong>.</p>
						<p>If so, that backup route <strong>doesn’t enter the topology table</strong>. To display every link <u>regardless of the FC</u> requirements, use <strong><code>show ip eigrp topology all-links</code></strong>.</p>
						<p>Being a distance-vector routing protocol, <strong>EIGRP doesn’t build a map of the network topology</strong>. <u>DUAL only way to guarantee no routing loop is to respect the FC</u>. <strong>A non-FS route can still be used</strong>, but further processing by DUAL is required and a delay is inevitable.</p>
					</section>
				</section>

				<section>
					<section>
						<h2>DUAL FSM</h2>
						<img src="http://i.imgur.com/WO8lCHq.png" style="width: 720px;">
						<small>DUAL route calculation engine is known as <strong><em>Finite State Machine</em></strong>, an abstract model used to descrive how a router react to input events to make decisions about routes.</small>
					</section>
					<section>
						<h2>DUAL FSM</h2>
						<p>FSM study is <u>not part of CCNA</u>.</p>
						<p>To understand how DUAL is operating, the output of the FSM can be enabled with the command <strong><code>debug eigrp fsm</code></strong>.</p>
						<p>When DUAL cannot find a FS meeting the FC, it <strong>puts the route into active state</strong>. The router <strong>queries its neighbors</strong> for a route to that destination network and waits for replies. If the replies contain a route to that network, it can become a new successor.</p>
					</section>
				</section>

				<section>
					<h2>IPv4 vs IPv6 EIGRP</h2>
					<p>IPv6 EIGRP has been available since IOS 12.4(6)T, by <strong>adding the IPv6 PDM</strong>. It runs <strong>independently from IPv4 EIGRP</strong>. The <strong>differences are minimal</strong>. DUAL and FSM, RTP, EIGRP packet types, the composite metric are <u>common traits</u>.</p>
					<ul>
						<li><strong>EIGRP-IPv6 still uses IPv4-like router IDs</strong>. On IPv6-only networks it’s important to manually set the router ID.</li>
						<li><strong>EIGRP-IPv6 messages are sourced from IPv6 link-local addresses</strong>. Multicast address is FF02::A.</li>
						<li><strong>EIGRP-IPv6 config mode</strong> is entered with</li>
						<pre><code class="no-highlight">Router(config)# ipv6 router eigrp {as_number}</code></pre>
						<li>It’s <strong>enabled directly on the interface</strong> config:</li>
						<pre><code class="no-highlight">Router(config-if)# ipv6 eigrp {as_number}</code></pre>
					</ul>
				</section>

				<section>
					<h2>Troubleshooting EIGRP</h2>
					<p>EIGRP simply cannot operate correctly <strong>if the right adjacencies are not formed</strong>. By default, <u>every adjacency change is displayed in the terminal</u> thanks to the command</p>
					<pre><code class="no-highlight">Router(config-router)# eigrp log-neighbor-changes
%DUAL-5-NBRCHANGE: EIGRP-IPv6 2: Neighbor FE80::1
(Serial0/0/0) is up: new adjacency</code></pre>
					<p>If an adjacency isn’t formed like it’s supposed to, <strong>first verify network connectivity to that neighbor</strong>. Then, check that both routers have the <strong>same AS number</strong> and that neighbor's network is <strong>included in <code>network</code> statements</strong>.</p>
					<p>For EIGRP-IPv6, <strong>manually set the link-local addresses</strong> to more easily identify the interfaces in debug/config (eg. FE80::2 for R2).</p>
				</section>

				<section>
					<h1>End of Lesson</h1>
				</section>
			</div>

		</div>

		<script src="lib/js/head.min.js"></script>
		<script src="js/reveal.js"></script>

		<script>

			// More info https://github.com/hakimel/reveal.js#configuration
			Reveal.initialize({
				controls: true,
				progress: true,
				history: true,
				center: true,

				transition: 'slide', // none/fade/slide/convex/concave/zoom

				// More info https://github.com/hakimel/reveal.js#dependencies
				dependencies: [
					{ src: 'lib/js/classList.js', condition: function() { return !document.body.classList; } },
					{ src: 'plugin/markdown/marked.js', condition: function() { return !!document.querySelector( '[data-markdown]' ); } },
					{ src: 'plugin/markdown/markdown.js', condition: function() { return !!document.querySelector( '[data-markdown]' ); } },
					{ src: 'plugin/highlight/highlight.js', async: true, callback: function() { hljs.initHighlightingOnLoad(); } },
					{ src: 'plugin/zoom-js/zoom.js', async: true },
					{ src: 'plugin/notes/notes.js', async: true }
				]
			});

		</script>

	</body>
</html>