From: Kenneth Wygand (KWygand@customonline.com)
Date: Sat Jul 10 2004 - 12:04:15 GMT-3
I'm guilty of this as well! When I typed out my first "quiz question of
the day", I certainly didn't think I had 4-5 errors in it!
Conceptually, as long as you understand what is going on, you will be
able to pinpoint the source of the problem because you can see what the
router is or is not doing. It's all about troubleshooting methodology.
For example, let's say you are not getting any EIGRP routes from Router
A to Router B. What's the first thing you should do? It certainly
should -not- be to start considering complex possibilities like
summarization, split horizon or redistribution. Think OSI model!
While the most structure of troubleshooting methodologies usually
include "starting from the ground up", you might not have time to start
at the very bottom level and work your way upward. Start at a
-reasonable- level and move up or down the OSI model based on the
success or failure of your test. Personally, I would start with a
"bottom of layer 3" test and ping the directly connected interface on
the other side (or your EIGRP neighbor). If that doesn't work, move
down and check to see if you see the other side as a CDP neighbor
(provided CDP is running on your interface). If the ping works, move up
the ladder a little bit and try to ping 224.0.0.10 (simulating an EIGRP
hello packet). If that works, "debug ip packet" on both sides and see
if you are sending/receiving the packets. If that works, start with
your "debug ip eigrp" commands. If eigrp updates and hellos are
working, move up from there.
This is certainly not the only way to troubleshoot this. For example,
many people would not start with a "ping" of the other side, but might
start with checking your "show ip eigrp neighbors" to see if you are
neighboring up with the remote device. Now that I think about it, this
is a quick command that I would probably use first before doing anything
else.
It's the -experience- that tells you where the statistically-best place
is to start to troubleshoot and resolve your problem in the minimal
amount of time and effort. But, nonetheless, -wherever- you start,
you'll be able to troubleshoot and successfully diagnose and repair
whatever problem you have as long as you maintain a structured, sensible
troubleshooting methodology.
I leave you with this one word of advice from real-world experience -
DON'T start changing things until you have a very good idea of what is
wrong. You don't want to break 3 other things before you actually fix
the problem, and then forget to return the non-broken items to their
original state!
And THAT'S one trait that's essential for any really good engineer... :)
Kenneth E. Wygand
Systems Engineer, Project Services
CISSP #37102, CCNP, CCDP, ACSP, Cisco IPT Design Specialist, MCP, CNA,
Network+, A+
Custom Computer Specialists, Inc.
"The only unattainable goal is the one not attempted."
-Anonymous
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Brian Dennis
Sent: Saturday, July 10, 2004 1:14 AM
To: swm@emanon.com; ccie2be; Brian McGahan; ccielab@groupstudy.com
Subject: RE: How Tunnels and Recursive Routing Occur
Typing whole configurations without pasting them into a router
can cause mistakes also ;-) I think Brian was guilty of that.
I've always said that no matter how much experience someone has
they will always make mistakes. The difference is that an experienced
engineer will be able to easily notice and fix the mistakes.
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
bdennis@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 775-745-6404 (Outside the US and Canada)
-----Original Message-----
From: Scott Morris [mailto:swm@emanon.com]
Sent: Friday, July 09, 2004 10:03 PM
To: Brian Dennis; 'ccie2be'; Brian McGahan; ccielab@groupstudy.com
Subject: RE: How Tunnels and Recursive Routing Occur
Sleep deprivation makes people type things they weren't thinking of...
Let
this be a lesson to all of you for the exam!
Be rested!!! :)
Even people who know what they are doing may still make inexplicable
costly
mistakes...
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713,
CISSP,
JNCIP, et al.
IPExpert CCIE Program Manager
IPExpert Sr. Technical Instructor
swm@emanon.com/smorris@ipexpert.net
http://www.ipexpert.net
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Brian Dennis
Sent: Saturday, July 10, 2004 12:13 AM
To: ccie2be; Brian McGahan; ccielab@groupstudy.com
Subject: RE: How Tunnels and Recursive Routing Occur
I think that this is what he meant to post.
interface Ethernet0/0
ip address 12.0.0.1 255.0.0.0
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Tunnel 0
ip address 21.0.0.1 255.0.0.0
tunnel source Loopback0
tunnel destination 2.2.2.2
!
router rip
version 2
no auto-summary
network 12.0.0.0
network 1.0.0.0
!
router eigrp 1
no auto-summary
network 21.0.0.0
network 1.0.0.0
r2:
interface Ethernet0/0
ip address 12.0.0.2 255.0.0.0
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface Tunnel0
ip address 21.0.0.2 255.0.0.0
tunnel source Loopback0
tunnel destination 1.1.1.1
!
router rip
version 2
no auto-summary
network 12.0.0.0
network 2.0.0.0
!
router eigrp 1
no auto-summary
network 21.0.0.0
network 2.0.0.0
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
bdennis@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 775-745-6404 (Outside the US and Canada)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
ccie2be
Sent: Friday, July 09, 2004 8:45 PM
To: Brian McGahan; ccielab@groupstudy.com
Subject: Re: How Tunnels and Recursive Routing Occur
Hi Brian,
Thanks very much for this example. This really helps me get the idea.
But, in studying this example, it appears to me that there are some
mistakes
unless I don't understand this quite right. See in-line comments:
----- Original Message -----
From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
To: "ccie2be" <ccie2be@nyc.rr.com>; <ccielab@groupstudy.com>
Sent: Friday, July 09, 2004 3:53 PM
Subject: RE: How Tunnels and Recursive Routing Occur
Tim,
The problem occurs when the tunnel destination is learned via a
physical interface, the tunnel comes up, and then the tunnel destination
is learned via the tunnel with a preferred metric or distance. The
following configuration demonstrates the problem between two connected
routers:
R1:
Interface ethernet0/0
Ip address 12.0.0.1 255.0.0.0
!
Interface loopback0
Ip address 1.1.1.1 255.255.255.255
!
Interface tunnel 0
Ip address 21.0.0.1 255.0.0.0
Tunnel source loopback0
Tunnel destination 2.2.2.2
!
Router rip
Version 2
No auto-summary
Network 12.0.0.0
Network 1.0.0.0
!
Router eigrp 1
No auto-summary
Network 21.0.0.0
Network 1.0.0.0
R2:
Interface ethernet0/0
Ip address 12.0.0.2 255.0.0.0
!
Interface loopback0
Ip address 2.2.2.2 255.255.255.255
!
Interface tunnel 0
Ip address 21.0.0.2 255.0.0.0
Tunnel source loopback0
Tunnel destination 2.2.2.2 <--- shouldn't this be 1.1.1.1 ??
!
Router rip
Version 2
No auto-summary
Network 12.0.0.0
Network 1.0.0.0 <---- shouldn't this be 2.0.0.0 ??
!
Router eigrp 1
No auto-summary
Network 21.0.0.0
Network 1.0.0.0 <---- shouldn't this be 2.0.0.0 ??
**********
Now, if I understand this correctly, what happens is this:
Before the tunnel comes up, R1 learns via RIP of network 2.0.0.0
But, once the tunnel comes up, R1 learns via Eigrp of network 2.0.0.0
and
since Eigrp has a lower AD than RIP, the route gets replaced in the
route
table which is how the problem begins because now, R1 route to 2.0.0.0
is
via the tunnel int but it's learning the tunnel destination via the
tunnel,
so we now have a recursive route problem. Correct?
Thanks, Tim
Try that out and see what happens.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
> -----Original Message-----
> From: ccie2be [mailto:ccie2be@nyc.rr.com]
> Sent: Friday, July 09, 2004 9:15 AM
> To: Brian McGahan
> Subject: Re: How Tunnels and Recursive Routing Occur
>
> Thanks Brian,
>
> But, I'm still wondering under what circumstances this recursive
problem
> occur. For example, if the tunnel is running one routing protocol and
the
> physical interface is running another - is this when this problem
occurs
> potentially?
>
> Tim
> ----- Original Message -----
> From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
> To: "ccie2be" <ccie2be@nyc.rr.com>; "Kenneth Wygand"
> <KWygand@customonline.com>; "Ty" <tycampbell@comcast.net>;
> <ccielab@groupstudy.com>
> Sent: Friday, July 09, 2004 9:53 AM
> Subject: RE: How Tunnels and Recursive Routing Occur
>
>
> Tim,
>
> You will know if there is a recursive error because you get the
> %TUN-5-RECURDOWN message logged. If there is a recursive routing
error
> that is not directly related to the tunnel you will see it in the
"debug
> ip routing" output.
>
> HTH,
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
>
>
> > -----Original Message-----
> > From: ccie2be [mailto:ccie2be@nyc.rr.com]
> > Sent: Friday, July 09, 2004 4:57 AM
> > To: Kenneth Wygand; Ty; Scott Morris; Brian McGahan;
> > ccielab@groupstudy.com
> > Subject: Re: How Tunnels and Recursive Routing Occur
> >
> > Hi Ken,
> >
> > Thanks for taking the time to do that write up. It was excellent.
> >
> > As I said, I understand the theory, but I'm still not 100% positive
> how I
> > would recognize a potential problem.
> >
> > Would it be possible to elaborate on your example to highlight how
> your
> > example creates a recursive routing problem?
> >
> > Thanks, Tim
> >
> > ----- Original Message -----
> > From: "Kenneth Wygand" <KWygand@customonline.com>
> > To: "Ty" <tycampbell@comcast.net>; "Scott Morris" <swm@emanon.com>;
> "Brian
> > McGahan" <bmcgahan@internetworkexpert.com>;
<ccielab@groupstudy.com>;
> > <ccie2be@nyc.rr.com>
> > Sent: Thursday, July 08, 2004 8:14 PM
> > Subject: How Tunnels and Recursive Routing Occur
> >
> >
> > Tim,
> >
> > In reply to:
> >
> > <snip>
> > PS: Have you been following the thread re: tunnels & recursive
> routing?
> > If
> > so, maybe you could give me an example of this recursive problem so
I
> can
> > recongize it and know what to look out for. I understand it
> conceptually,
> > but can't figure out how the tunnel & ip addressing would be
> configured to
> > cause this problem, so an example would be really helpful.
> > </snip>
> >
> > The theory, which I think you already understand, is as follows:
> >
> > 1) You live next to a park
> > 2) I tell you to get to the supermarket, you must go through the
park.
> > 3) Your friend tells you he lives a block past the store, so you
know
> how
> > to
> > get there.
> > 4) If anyone tells you where they are relative to the store, you can
> > figure
> > out where they are by a recursive lookup (If John lives next to the
> store,
> > I
> > know I first need to go to the store and then I take the last hop to
> > John's
> > house. Hmm... but how do I get to the store, let me look that up -
oh,
> > yes,
> > to get to the store, I must go through the park, so now I know I
must
> go
> > through the park to get to the store and then I take the last hop to
> > John's
> > house)
> > 5) The only place I can't get to relative to the store is the store
> > itself.
> > If I ask the store how to get to itself, it will say "just go to the
> store
> > and the store is right there". Now I will say "Oh, ok, well it's
> shorter
> > to
> > go to the store through my direct knowledge of where the store is -
my
> > other
> > option was to go through the park to get to the store, but its
shorter
> for
> > me to just take the single-hop route to the store via the store".
> > 6) If I make this change, I know I get to the store through the
store,
> and
> > I
> > lost the information about having to pass through the park because I
> > interpreted that path as a suboptimal path and flushed it from my
> routing
> > table. So now I say "Ok, I want to get to John's house, so first I
> have to
> > go to the store. OK, well to get to the store, I must go to the
store
> > first.
> > OK, well to get to the store, I must go to the store first. OK, well
> to
> > get
> > to the store, I must go to the store first. OK, well to..... you
get
> the
> > idea!
> >
> > Although this sounds complicated and confusing, it's really a simple
> > concept. You cannot get to the destination of the tunnel through the
> > tunnel
> > itself. This is why you have certain things when it comes to a
> tunnel.
> >
> > 1) You have IP addresses on each end of the tunnel
> > 2) You have source/destination IP addresses (inverted on each side)
to
> > create the tunnel.
> >
> > You simply must make sure you do not LEARN the destination IP
address
> of
> > the
> > tunnel THROUGH the tunnel. This can be achieve by either filtering
the
> > advertisement of the destination interface from any routing
protocols
> > running over the tunnel. Remember, the tunnel interface (tunnel IP
> address
> > now), looks like a directly connected interface. If you learn routes
> over
> > this interface, most likely they will natively be more preferred
than
> the
> > physical path required to get to the same spot.
> >
> > Here is an example:
> >
> > (4th octet of IP addresses is router number)
> > Loopback of 1.1.1.1/24 on R1, 2.2.2.2/24 on R2 and 3.3.3.3/24 on R3.
> > R1----12.12.12.x----R2----23.23.23.x----R3
> >
> > I set up a tunnel from R1 (12.12.12.1) to R3 (23.23.23.3). I create
> > tunnel0
> > on R1 with IP address 13.13.13.1 and tunnel0 on R3 with IP address
> > 13.13.13.3.
> >
> > Requirement 1: Ensure R1 does not learn of 23.23.23.3 via Tunnel0 !
> > Requirement 2: Ensure R3 does not learn of 12.12.12.1 via Tunnel0 !
> >
> > That's all there is to it!
> >
> > Make a little more sense now? I hope I didn't confuse anyone any
> more!
> > Ken
This archive was generated by hypermail 2.1.4 : Sun Aug 01 2004 - 10:11:51 GMT-3