From: Schwimer, Greg (CAP, ITS, US) (Greg.Schwimer@xxxxxxxxxxxxx)
Date: Tue Dec 28 1999 - 13:51:33 GMT-3
I did consider this. However, the reply packets are what need to be routed
back along the same path. I would think that the tags would be lost,
resulting in the same situation all over again.
Another item I did consider was if there was some way to redistribute the
route cache from R1 to R2 similar to redistributing a routing protocol or
static routes. I've not heard of any way to do this though. If only you
could write scripts...
Although I've been trying to avoid it, perhaps something with BGP, as others
have mentioned?
-----Original Message-----
From: Richard Mott [mailto:richpmott@hotmail.com]
Sent: Tuesday, December 28, 1999 9:19 AM
To: Greg.Schwimer@gecits.ge.com
Subject: RE: Forcing return IP route
Greg,
How about using a route map on r1 to add a TAG to traffic sent through the
tunnel to r2, and then on r2 have a route map to send packets that are
tagged out the tunnel interface.
Rich Mott
CCIE # 5234
Network Engineer
Jannon Solutions
>From: "Schwimer, Greg (CAP, ITS, US)" <Greg.Schwimer@gecits.ge.com>
>Reply-To: "Schwimer, Greg (CAP, ITS, US)" <Greg.Schwimer@gecits.ge.com>
>To: "'dameon@aracnet.com'" <dameon@aracnet.com>
>CC: "CCIE Lab group (E-mail)" <ccielab@groupstudy.com>
>Subject: RE: Forcing return IP route
>Date: Mon, 27 Dec 1999 16:21:11 -0600
>
>You hit the nail on the head. I did get it to work, sort of... I used the
>following config on R2, where 172.16.25.2 is the remote (r1) end of the
>tunnel:
>
>route-map MAP1 permit 10
> match interface tun0
> set ip next-hop 172.16.25.2
>
>int e0/0 (this is the internal network)
> ip policy route-map MAP1
>
>The problem is that with this config, ALL traffic goes down the tunnel
>interface.
>
>The trick to this is that you cannot configure any policies based upon the
>source address of the packet, as that will always be an unknown when
>dealing
>with clients dialing-in to the internet.
>
>
>
>
>-----Original Message-----
>From: Derek A. Buelna [mailto:dameon@aracnet.com]
>Sent: Monday, December 27, 1999 2:24 PM
>To: 'Schwimer, Greg (CAP, ITS, US)'
>Subject: RE: Forcing return IP route
>
>
>Hi,
>
>Let me see if I understand this correctly:
>
>1. R1 and R2 are each connected to the Internet.
>2. There is an IP tunnel between the two sites that is encrypted/using
>IPSec.
>3. Traffic on R1 that is destined for any of the networks at the R2 site
>gets routed through the tunnel to R2 and vice versa.
>4. The network has been configured to allow IPSec clients to connect to R1,
>which works fine for accessing any network at the R1 site but when trying
>to access a network at the R2 site, the replies are not sent through the
>tunnel back to R1 (thus using IPSec) but are sent unencrypted directly to
>the IP address of the IPSec client somewhere on the Internet which, of
>course, doesn't work.
>
>Let me know if I understand - I'm pondering this one - I have time to
>research and this one is kind of interesting.
>
>-Derek
>
>
>-----Original Message-----
>From: Schwimer, Greg (CAP, ITS, US) [SMTP:Greg.Schwimer@gecits.ge.com]
>Sent: Monday, December 27, 1999 8:31 AM
>To: CCIE Lab group (E-mail)
>Cc: Mitchell, Tim (CAP, ITS, US); Vohs, Todd M (CAP, ITS, US)
>Subject: Forcing return IP route
>
>Does anyone know of a way to force a router to route IP reply packets (as
>in
>a ping, for example) through the same interface the request came in on?
>Static routes are not an option. Here is the scenario:
>
>
>
> IPSec Client
> !
> !
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:22:00 GMT-3