<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	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/"
		>
<channel>
	<title>Comments on: Troubleshooting Lab #3</title>
	<atom:link href="http://blog.alwaysthenetwork.com/troubleshooting-labs/troubleshooting-lab-3/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.alwaysthenetwork.com/troubleshooting-labs/troubleshooting-lab-3/</link>
	<description>Just another Cisco blog</description>
	<lastBuildDate>Sat, 04 Sep 2010 09:48:48 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Colby</title>
		<link>http://blog.alwaysthenetwork.com/troubleshooting-labs/troubleshooting-lab-3/comment-page-1/#comment-584</link>
		<dc:creator>Colby</dc:creator>
		<pubDate>Thu, 18 Mar 2010 14:04:17 +0000</pubDate>
		<guid isPermaLink="false">http://blog.alwaysthenetwork.com/?p=779#comment-584</guid>
		<description>Haha, sorry. I&#039;ve been slammed at work and haven&#039;t really had the energy to put anything together. I&#039;ll try to get a lab or OEQ up today.</description>
		<content:encoded><![CDATA[<p>Haha, sorry. I&#8217;ve been slammed at work and haven&#8217;t really had the energy to put anything together. I&#8217;ll try to get a lab or OEQ up today.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: willroute4food</title>
		<link>http://blog.alwaysthenetwork.com/troubleshooting-labs/troubleshooting-lab-3/comment-page-1/#comment-583</link>
		<dc:creator>willroute4food</dc:creator>
		<pubDate>Thu, 18 Mar 2010 14:02:29 +0000</pubDate>
		<guid isPermaLink="false">http://blog.alwaysthenetwork.com/?p=779#comment-583</guid>
		<description>Ah, you&#039;ve stopped posting labs!  What am I supposed to do at work on a slow day now?!?  lol</description>
		<content:encoded><![CDATA[<p>Ah, you&#8217;ve stopped posting labs!  What am I supposed to do at work on a slow day now?!?  lol</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Colby</title>
		<link>http://blog.alwaysthenetwork.com/troubleshooting-labs/troubleshooting-lab-3/comment-page-1/#comment-582</link>
		<dc:creator>Colby</dc:creator>
		<pubDate>Fri, 12 Mar 2010 18:59:57 +0000</pubDate>
		<guid isPermaLink="false">http://blog.alwaysthenetwork.com/?p=779#comment-582</guid>
		<description>You guys are too good. I&#039;ll need to make these a lot harder, lol.

@Smail: I don&#039;t know what is causing that issue.</description>
		<content:encoded><![CDATA[<p>You guys are too good. I&#8217;ll need to make these a lot harder, lol.</p>
<p>@Smail: I don&#8217;t know what is causing that issue.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Smail</title>
		<link>http://blog.alwaysthenetwork.com/troubleshooting-labs/troubleshooting-lab-3/comment-page-1/#comment-581</link>
		<dc:creator>Smail</dc:creator>
		<pubDate>Fri, 12 Mar 2010 12:21:22 +0000</pubDate>
		<guid isPermaLink="false">http://blog.alwaysthenetwork.com/?p=779#comment-581</guid>
		<description>Hi again.

I loged in your lab. 

The problem is on the R2 router.

An incoming update filter (access-list 15) is denying the two routes (192.168.30.0 and .40.0).

R2&gt;sh ip protocols
Routing Protocol is &quot;ospf 10&quot;
 Incoming update filter list for all interfaces is 15

Standard IP access list 15
    10 permit 1.1.1.1 (2 matches)
    20 deny   192.168.14.0, wildcard bits 0.0.0.255 (2 matches)
    30 permit 192.168.31.0, wildcard bits 0.0.0.255
    40 permit 192.168.15.0, wildcard bits 0.0.0.255 (2 matches)
    50 permit 192.168.11.0, wildcard bits 0.0.0.255 (2 matches)
    60 permit 192.168.33.0, wildcard bits 0.0.0.255
    70 deny   192.168.10.0, wildcard bits 0.0.0.255 (2 matches)
    80 permit 192.168.12.0, wildcard bits 0.0.0.255 (2 matches)
    90 permit 192.168.13.0, wildcard bits 0.0.0.255 (2 matches)
    100 permit 192.168.32.0, wildcard bits 0.0.0.255
    110 deny   192.168.40.0, wildcard bits 0.0.0.255
    120 deny   192.168.8.0, wildcard bits 0.0.0.255</description>
		<content:encoded><![CDATA[<p>Hi again.</p>
<p>I loged in your lab. </p>
<p>The problem is on the R2 router.</p>
<p>An incoming update filter (access-list 15) is denying the two routes (192.168.30.0 and .40.0).</p>
<p>R2&gt;sh ip protocols<br />
Routing Protocol is &#8220;ospf 10&#8243;<br />
 Incoming update filter list for all interfaces is 15</p>
<p>Standard IP access list 15<br />
    10 permit 1.1.1.1 (2 matches)<br />
    20 deny   192.168.14.0, wildcard bits 0.0.0.255 (2 matches)<br />
    30 permit 192.168.31.0, wildcard bits 0.0.0.255<br />
    40 permit 192.168.15.0, wildcard bits 0.0.0.255 (2 matches)<br />
    50 permit 192.168.11.0, wildcard bits 0.0.0.255 (2 matches)<br />
    60 permit 192.168.33.0, wildcard bits 0.0.0.255<br />
    70 deny   192.168.10.0, wildcard bits 0.0.0.255 (2 matches)<br />
    80 permit 192.168.12.0, wildcard bits 0.0.0.255 (2 matches)<br />
    90 permit 192.168.13.0, wildcard bits 0.0.0.255 (2 matches)<br />
    100 permit 192.168.32.0, wildcard bits 0.0.0.255<br />
    110 deny   192.168.40.0, wildcard bits 0.0.0.255<br />
    120 deny   192.168.8.0, wildcard bits 0.0.0.255</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Smail</title>
		<link>http://blog.alwaysthenetwork.com/troubleshooting-labs/troubleshooting-lab-3/comment-page-1/#comment-580</link>
		<dc:creator>Smail</dc:creator>
		<pubDate>Fri, 12 Mar 2010 12:00:51 +0000</pubDate>
		<guid isPermaLink="false">http://blog.alwaysthenetwork.com/?p=779#comment-580</guid>
		<description>Hi,

the .net file is not working for me. I changed the paths, IOS file is extracting etc

This is the error:

http://img31.imageshack.us/img31/2692/80270729.png</description>
		<content:encoded><![CDATA[<p>Hi,</p>
<p>the .net file is not working for me. I changed the paths, IOS file is extracting etc</p>
<p>This is the error:</p>
<p><a href="http://img31.imageshack.us/img31/2692/80270729.png" rel="nofollow">http://img31.imageshack.us/img31/2692/80270729.png</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: JamesK</title>
		<link>http://blog.alwaysthenetwork.com/troubleshooting-labs/troubleshooting-lab-3/comment-page-1/#comment-579</link>
		<dc:creator>JamesK</dc:creator>
		<pubDate>Fri, 12 Mar 2010 06:31:38 +0000</pubDate>
		<guid isPermaLink="false">http://blog.alwaysthenetwork.com/?p=779#comment-579</guid>
		<description>R3 is filtering the VLAN 40 network from being redistributed to EIGRP
[access-list 10 deny   192.168.30.0 0.0.0.255]

R2 is filtering the VLAN 40 network from being redistributed to OSPF
[access-list 10 deny   192.168.40.0 0.0.0.255]

R2 is filtering the VLAN 30 network from being inserted into RIB from R1
list 15 - implicit deny, end of acl</description>
		<content:encoded><![CDATA[<p>R3 is filtering the VLAN 40 network from being redistributed to EIGRP<br />
[access-list 10 deny   192.168.30.0 0.0.0.255]</p>
<p>R2 is filtering the VLAN 40 network from being redistributed to OSPF<br />
[access-list 10 deny   192.168.40.0 0.0.0.255]</p>
<p>R2 is filtering the VLAN 30 network from being inserted into RIB from R1<br />
list 15 &#8211; implicit deny, end of acl</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: willroute4food</title>
		<link>http://blog.alwaysthenetwork.com/troubleshooting-labs/troubleshooting-lab-3/comment-page-1/#comment-578</link>
		<dc:creator>willroute4food</dc:creator>
		<pubDate>Thu, 11 Mar 2010 22:19:45 +0000</pubDate>
		<guid isPermaLink="false">http://blog.alwaysthenetwork.com/?p=779#comment-578</guid>
		<description>OK, I did this pretty quick...I used these commands (swear that I did not look at running configs):
sh ip protocols
sh ip access-l
sh ip route
sh route-map

I *think* these are the problems
R2&#039;s distribute list 15 *in* the ospf process is stopping the 192.168.30.x route with the implicit deny

R3&#039;s route-map is killing the 192.168.40.x route...

thats my shot :)</description>
		<content:encoded><![CDATA[<p>OK, I did this pretty quick&#8230;I used these commands (swear that I did not look at running configs):<br />
sh ip protocols<br />
sh ip access-l<br />
sh ip route<br />
sh route-map</p>
<p>I *think* these are the problems<br />
R2&#8242;s distribute list 15 *in* the ospf process is stopping the 192.168.30.x route with the implicit deny</p>
<p>R3&#8242;s route-map is killing the 192.168.40.x route&#8230;</p>
<p>thats my shot <img src='http://blog.alwaysthenetwork.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andy</title>
		<link>http://blog.alwaysthenetwork.com/troubleshooting-labs/troubleshooting-lab-3/comment-page-1/#comment-577</link>
		<dc:creator>Andy</dc:creator>
		<pubDate>Thu, 11 Mar 2010 21:33:14 +0000</pubDate>
		<guid isPermaLink="false">http://blog.alwaysthenetwork.com/?p=779#comment-577</guid>
		<description>192.168.30.0/24 is denied by the inbound OSPF distribute list on R2.  192.168.40.0/24 is denied by the redistribution route-map from RIP to EIGRP on R3.

Solution:
add &quot;access-list 15 permit 192.168.30.0 0.0.0.255&quot; on R2

and &quot;access-list 10 permit 192.168.40.0 0.0.0.255&quot; on R3</description>
		<content:encoded><![CDATA[<p>192.168.30.0/24 is denied by the inbound OSPF distribute list on R2.  192.168.40.0/24 is denied by the redistribution route-map from RIP to EIGRP on R3.</p>
<p>Solution:<br />
add &#8220;access-list 15 permit 192.168.30.0 0.0.0.255&#8243; on R2</p>
<p>and &#8220;access-list 10 permit 192.168.40.0 0.0.0.255&#8243; on R3</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jared</title>
		<link>http://blog.alwaysthenetwork.com/troubleshooting-labs/troubleshooting-lab-3/comment-page-1/#comment-576</link>
		<dc:creator>Jared</dc:creator>
		<pubDate>Thu, 11 Mar 2010 16:00:53 +0000</pubDate>
		<guid isPermaLink="false">http://blog.alwaysthenetwork.com/?p=779#comment-576</guid>
		<description>Upon rereading my answer, and talking to Colby, I realized that the bit in my first post about the 10.1.1.6 network is really irrelevant as it&#039;s a path TO the 192.168.40.0 network, so even if it was filtered it wouldn&#039;t matter much as long as R1 and R2 knew to send traffic destined for 192.168.40.0 network to R3.

R3 is directly connected to the 10.1.1.6 network and knows the .40.0 network is beyond R4, so it would forward the traffic across the link, and voila! You&#039;ve reached VLAN 40!</description>
		<content:encoded><![CDATA[<p>Upon rereading my answer, and talking to Colby, I realized that the bit in my first post about the 10.1.1.6 network is really irrelevant as it&#8217;s a path TO the 192.168.40.0 network, so even if it was filtered it wouldn&#8217;t matter much as long as R1 and R2 knew to send traffic destined for 192.168.40.0 network to R3.</p>
<p>R3 is directly connected to the 10.1.1.6 network and knows the .40.0 network is beyond R4, so it would forward the traffic across the link, and voila! You&#8217;ve reached VLAN 40!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jared</title>
		<link>http://blog.alwaysthenetwork.com/troubleshooting-labs/troubleshooting-lab-3/comment-page-1/#comment-575</link>
		<dc:creator>Jared</dc:creator>
		<pubDate>Thu, 11 Mar 2010 15:31:38 +0000</pubDate>
		<guid isPermaLink="false">http://blog.alwaysthenetwork.com/?p=779#comment-575</guid>
		<description>I&#039;ll take a stab at this one (redistribution is still something I&#039;m working on)...

The first thing that catches my eye is that on R3 there is a route-map applied to the EIGRP process, which uses ACL 10 to match IPs.  However the 10.1.1.6/31 network is not permitted in that ACL, which means (I think) it will get caught by the implicit deny at the end of the ACL, which is why we don&#039;t see that network on the upstream routers. 

This situation also applies to the 192.168.40.0/24 network as well, it is being filtered under the EIGRP process and not being passed upstream to R2.  

Hopefully that&#039;s somewhat on the right path! :P</description>
		<content:encoded><![CDATA[<p>I&#8217;ll take a stab at this one (redistribution is still something I&#8217;m working on)&#8230;</p>
<p>The first thing that catches my eye is that on R3 there is a route-map applied to the EIGRP process, which uses ACL 10 to match IPs.  However the 10.1.1.6/31 network is not permitted in that ACL, which means (I think) it will get caught by the implicit deny at the end of the ACL, which is why we don&#8217;t see that network on the upstream routers. </p>
<p>This situation also applies to the 192.168.40.0/24 network as well, it is being filtered under the EIGRP process and not being passed upstream to R2.  </p>
<p>Hopefully that&#8217;s somewhat on the right path! <img src='http://blog.alwaysthenetwork.com/wp-includes/images/smilies/icon_razz.gif' alt=':P' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
</channel>
</rss>
