<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>.::&#124;Dide(3)d&#039;s Blog::. &#187; IGRP</title>
	<atom:link href="http://www.dide3d.com/category/cisco-stuff/routing/igrp/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.dide3d.com</link>
	<description>Get Tech&#039;d...!                                              </description>
	<lastBuildDate>Wed, 28 Jul 2010 09:50:26 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
		<item>
		<title>Redistribution: Default Seed Metric</title>
		<link>http://www.dide3d.com/2009/05/redistribution-default-seed-metric/</link>
		<comments>http://www.dide3d.com/2009/05/redistribution-default-seed-metric/#comments</comments>
		<pubDate>Wed, 06 May 2009 18:33:09 +0000</pubDate>
		<dc:creator>Divin John</dc:creator>
				<category><![CDATA[BGP]]></category>
		<category><![CDATA[Cisco *STUFF*]]></category>
		<category><![CDATA[EIGRP]]></category>
		<category><![CDATA[IGRP]]></category>
		<category><![CDATA[OSPF]]></category>
		<category><![CDATA[RIP]]></category>
		<category><![CDATA[Routing]]></category>
		<category><![CDATA[default seed metric]]></category>
		<category><![CDATA[metric infinity]]></category>
		<category><![CDATA[redistribution]]></category>
		<category><![CDATA[rip redistribution]]></category>
		<category><![CDATA[seed metric]]></category>

		<guid isPermaLink="false">http://www.dide3d.com/?p=1181</guid>
		<description><![CDATA[Redistributed routes are treated differently depending on which routing protocol they are being redistributed into. On IOS, each routing protocol has its own seed metric which is assigned by default to redistributed routes when no metric is configured manually. Below is a table listing the default behavior when no metric is defined with the metric [...]]]></description>
			<content:encoded><![CDATA[<p>Redistributed routes are treated differently depending on which routing protocol they are being redistributed into. On IOS, each routing protocol has its own <em>seed metric</em> which is assigned by default to redistributed routes when no metric is configured manually. Below is a table listing the default behavior when no metric is defined with the <code>metric</code> argument on the <code>redistribute</code> command.</p>
<table style="margin: 0px auto 16px;" border="0" cellspacing="0" cellpadding="4">
<tbody>
<tr>
<td style="background-color: #f4e990; font-weight: bold; width: 90px; text-align: center;">Source</td>
<td style="background-color: #d7ce7f; font-weight: bold; width: 90px; text-align: center;" colspan="5">Into</td>
</tr>
<tr>
<td style="background-color: #f4e990;"></td>
<td style="background-color: #d7ce7f; font-weight: bold; width: 90px; text-align: center;">RIP</td>
<td style="background-color: #d7ce7f; font-weight: bold; width: 90px; text-align: center;">EIGRP</td>
<td style="background-color: #d7ce7f; font-weight: bold; width: 90px; text-align: center;">OSPF</td>
<td style="background-color: #d7ce7f; font-weight: bold; width: 90px; text-align: center;">ISIS</td>
<td style="background-color: #d7ce7f; font-weight: bold; width: 90px; text-align: center;">BGP (MED)</td>
</tr>
<tr>
<td style="background-color: #f4e990; font-weight: bold; text-align: right;">Connected</td>
<td>1</td>
<td>Interface metric</td>
<td>20 (E2)</td>
<td>0</td>
<td>0</td>
</tr>
<tr>
<td style="background-color: #f4e990; font-weight: bold; text-align: right;">Static</td>
<td>1</td>
<td>
<table style="margin: 0px auto 16px; height: 20px;" border="0" cellspacing="0" cellpadding="4" width="91">
<tbody>
<tr>
<td>Int Metric</td>
</tr>
</tbody>
</table>
</td>
<td>20 (E2)</td>
<td>0</td>
<td>0</td>
</tr>
<tr>
<td style="background-color: #f4e990; font-weight: bold; text-align: right;">RIP</td>
<td style="background-color: #e0e0e0;"></td>
<td>Infinite</td>
<td>20 (E2)</td>
<td>0</td>
<td>IGP metric</td>
</tr>
<tr>
<td style="background-color: #f4e990; font-weight: bold; text-align: right;">EIGRP</td>
<td>Infinite</td>
<td style="background-color: #e0e0e0;"></td>
<td>20 (E2)</td>
<td>0</td>
<td>IGP metric</td>
</tr>
<tr>
<td style="background-color: #f4e990; font-weight: bold; text-align: right;">OSPF</td>
<td>Infinite</td>
<td>Infinite</td>
<td style="background-color: #e0e0e0;"></td>
<td>0</td>
<td>IGP metric</td>
</tr>
<tr>
<td style="background-color: #f4e990; font-weight: bold; text-align: right;">ISIS</td>
<td>Infinite</td>
<td>Infinite</td>
<td>20 (E2)</td>
<td style="background-color: #e0e0e0;"></td>
<td>IGP metric</td>
</tr>
<tr>
<td style="background-color: #f4e990; font-weight: bold; text-align: right;">BGP</td>
<td>Infinite</td>
<td>Infinite</td>
<td>1 (E2)</td>
<td>0</td>
<td style="background-color: #e0e0e0;"></td>
</tr>
</tbody>
</table>
<p>As illustrated in the table, routes being distributed from another routing protocol into RIP or EIGRP must have a configured metric to be eligible for placement in the RIP database or EIGRP topology. Also interesting to note is that BGP will automatically assigned the IGP-learned metric of a redistributed route to the route&#8217;s MED in the BGP table.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.dide3d.com/2009/05/redistribution-default-seed-metric/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Behavior of RIP and IGRP When Sending and Receiving Updates</title>
		<link>http://www.dide3d.com/2009/04/behavior-of-rip-and-igrp-when-sending-and-receiving-updates/</link>
		<comments>http://www.dide3d.com/2009/04/behavior-of-rip-and-igrp-when-sending-and-receiving-updates/#comments</comments>
		<pubDate>Thu, 02 Apr 2009 13:28:28 +0000</pubDate>
		<dc:creator>Divin John</dc:creator>
				<category><![CDATA[Cisco *STUFF*]]></category>
		<category><![CDATA[IGRP]]></category>
		<category><![CDATA[RIP]]></category>
		<category><![CDATA[Routing]]></category>
		<category><![CDATA[Static Routes]]></category>
		<category><![CDATA[Classful routing Decisions]]></category>
		<category><![CDATA[Discontiguous Networks]]></category>
		<category><![CDATA[IGRP.Classful Routing]]></category>
		<category><![CDATA[Rip]]></category>

		<guid isPermaLink="false">http://www.dide3d.com/?p=824</guid>
		<description><![CDATA[Send Updates When RIP or IGRP send an update, they perform certain checks before they advertise the update. This list shows the sequence of events that occurs before Router 1 sends updates to Router 2. The network diagram allows you to examine the sequence of events more closely. Is the subnet information part of the [...]]]></description>
			<content:encoded><![CDATA[<h3><a name="topic2">Send Updates</a></h3>
<p>When RIP or IGRP send an update, they perform certain checks before 	 they advertise the update. This list shows the sequence of events that occurs 	 before Router 1 sends updates to Router 2. The network 	 diagram allows you to examine the sequence of events more 	 closely.</p>
<ul>
<li>Is the subnet information part of the same major net as the interface 		that sources the update?
<ul>
<li><strong>No:</strong> Router 1 summarizes at the major net boundary 		  and advertises the network.</li>
<li><strong>Yes:</strong> Does the network have the same subnet mask as 		  the interface that sources the update?
<ul>
<li><strong>Yes:</strong> Router 1 advertises the 			 subnet.</li>
<li><strong>No:</strong> Does the network have a /32 mask ?
<ul>
<li><strong>Yes:</strong> If it is RIP, then the network is 				advertised. If it is IGRP, then Router 1 drops the network.</li>
<li><strong>No:</strong> Router 1 drops the 				network.</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
</ul>
<h3><a name="receivingup">Receive Updates</a></h3>
<p>When RIP or IGRP receive an update, they perform certain checks before 	 they accept the update and apply the subnet mask. This is the sequence of 	 events that occurs before Router 2 accepts an update from Router 1:</p>
<ul>
<li>Is the subnet received in the update on the same major net as the 		interface that received the update?
<ul>
<li><strong>Yes:</strong> Router 2 applies the mask of the interface 		  that received the update. If the advertised network has a host bit set in the 		  host portion of the update, Router 2 applies the host mask (/32). In the case 		  of RIP, it continues to advertise the /32 route to the subsequent router, but 		  IGRP does not.</li>
<li><strong>No:</strong> Do any subnets of this major net already exist 		  in the routing table, known from interfaces other than the one that received 		  the update? The network in this update should be a major net unless the link 		  between the two routers is an unnumbered link, in which case it is possible for 		  the update to contain subnet information.
<ul>
<li><strong>Yes:</strong> Router 2 ignores the 			 update.</li>
<li><strong>No:</strong> Router 2 applies a classful mask. If the 			 update came across an unnumbered link and contains subnet information (bits in 			 subnet portion of network are set), then Router 2 applies a host mask. Refer to 			 Understanding 			 and Configuring the ip unnumbered Command for unnumbered case 			 examples.</li>
</ul>
</li>
</ul>
</li>
</ul>
<p><a name="nd"> </a></p>
<p style="text-align: center;"><img class="size-full wp-image-823 aligncenter" title="54a" src="http://www.dide3d.com/wp-content/uploads/2009/04/54a.gif" alt="54a" width="556" height="137" /><a name="specificcase"></a></p>
<h2><span class="content"></p>
<p style="text-align: left;"><a name="specificcase">Specific Case</a></p>
<p></span></h2>
<p><span class="content"> <a name="nd"> </a></span></p>
<h3><a name="sendup">Send Updates</a></h3>
<p>When Router 1 sends an update to Router 2, it performs these checks:</p>
<ul>
<li>Is 131.108.5.0/24 part of the same major net as 131.108.2.0/24, which 		sources the update?
<ul>
<li><strong>Yes:</strong> Does 131.108.5.0/24 have the same subnet mask 		  as 131.108.2.0/24, which sources the update?
<ul>
<li><strong>Yes:</strong> Router 1 advertises the 			 network.</li>
</ul>
</li>
</ul>
</li>
<li>Is 137.99.88.0/24 part of the same major net as 131.108.2.0/24, which 		sources the update?
<ul>
<li><strong>No:</strong> Router 1 summarizes 137.99.88.0/24 at the 		  major net boundary and advertises the route as 		  137.99.0.0.</li>
</ul>
</li>
</ul>
<p>This process results in Router 1 including 131.108.5.0 and 137.99.0.0 	 in its update to Router 2. You can see this in the <strong> debug 	 ip rip </strong> command output shown on Router 1:</p>
<pre>*Mar 25 00:22:46.177: <strong>RIP: sending v1 update to 255.255.255.255 via Serial0 (131.108.2.2)  </strong>
*Mar 25 00:22:46.178: <strong>RIP: build update entries</strong>
*Mar 25 00:22:46.182: <strong>subnet 131.108.5.0, metric 1</strong>
*Mar 25 00:22:46.185: <strong>network 137.99.0.0, metric 1</strong></pre>
<h3><a name="receiveup">Receive Updates</a></h3>
<p>When you issue the <strong> debug 	 ip rip </strong> command, you can see the routing update received on 	 Router 2 from Router 1:</p>
<pre>*Mar 25 00:22:46.201<strong>: RIP: received v1 update from 131.108.2.2 on Serial0</strong>
*Mar 25 00:22:46.203:<strong>131.108.5.0 in 1 hops</strong>
*Mar 25 00:22:46.205:<strong>137.99.0.0 in 1 hops</strong></pre>
<p>Look at the checks Router 2 performs in order to determine what mask to 	 apply on a received network.</p>
<ul>
<li>Is the received major net 137.99.0.0 the same as 131.108.2.0, which 		is the address assigned to the interface that received the update?
<ul>
<li><strong>No:</strong> Do any subnets of this major net already exist 		  in the routing table known from other interfaces?
<ul>
<li><strong>No:</strong> Router 2 applies the natural mask (/16) 			 because 137.99.0.0 is a class B address.</li>
</ul>
</li>
</ul>
</li>
<li>Does subnet 131.108.5.0 belong to the same major net as subnet 		131.108.2.0, which is the interface that received the update?
<ul>
<li><strong>Yes:</strong> Router 2 applies the mask /24, which is the 		  mask of the interface that received the 		  update.</li>
</ul>
</li>
</ul>
<p>This process results in these networks and masks in the routing table 	 of Router 2, displayed with the <strong> show 	 ip route </strong> command:<br />
<a href="http://www.cisco.com/en/US/tech/tk364/technologies_tech_note09186a0080093fd8.shtml" target="_blank"></a></p>
<blockquote>
<pre><strong>R    137.99.0.0/16 [120/1] via 131.108.2.2, 00:00:07, Serial0
     131.108.0.0/24 is subnetted, 3 subnets
R    131.108.5.0 [120/1] via 131.108.2.2, 00:00:08, Serial0</strong>
C    131.108.2.0 is directly connected, Serial0
C    131.108.3.0 is directly connected, Ethernet0</pre>
</blockquote>
<h2><a name="topic2">Solution</a></h2>
<p>In some situations, discontiguous networks are unavoidable. In these 	 situations Cisco recommends that you do not use RIPv1 or IGRP. Routing 	 protocols like EIGRP or OSPF are better suited for this situation.</p>
<h3><a name="Solution2">Establish Connectivity</a></h3>
<p>In the event that you use RIPv1 or IGRP with discontiguous networks, 	 you must use static routes to establish connectivity between the discontiguous 	 subnetworks.</p>
<p>Original Document @ <a href="http://www.cisco.com/en/US/tech/tk364/technologies_tech_note09186a0080093fd8.shtml" target="_blank">http://www.cisco.com/en/US/tech/tk364/technologies_tech_note09186a0080093fd8.shtml</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.dide3d.com/2009/04/behavior-of-rip-and-igrp-when-sending-and-receiving-updates/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
