RE: How Tunnels and Recursive Routing Occur

From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Fri Jul 09 2004 - 10:53:04 GMT-3


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:50 GMT-3