On Mon, 2010-03-15 at 19:47 -0500, Rakesh Hegde wrote:
You can use VTI GRE mode on your side and crypto map on the remote end
device . The remote router with crypto map needs to use the same
source and destination IP for GRE and the VPN tunnel.
I got around to testing this, and I can't make it
I got around to testing this, and I can't make it work. It seems VTI
doesn't use GRE, and I can't figure out how to make it. Since the other
end (not under our control) uses IP-in-GRE-in-IPSec I need the GRE
part.
Furthermore, the setup has both the inner (tunnel) and outer (IPSec
On Thu, 2010-03-18 at 08:31 -0300, Ray Burkholder wrote:
This vrf-lite solution may help somewhat with your inner / outer vrf stuff.
When throwing MPLS in, I'm not sure how it will react.
http://www.oneunified.net/blog/Cisco/vrflite.article
Yeah, that's kind of how we do it now. The inside
On Thu, 2010-03-18 at 12:12 +0100, Peter Rathlev wrote:
Would anyone happen to have a working config for VTI tunnelling using
GRE and working on MPLS enabled interfaces on a 7200?
Ah, I couldn't see the forest for the trees! :-)
VTI isn't the right answer at all. VTI isn't GRE (actually most
On Thu, 2010-03-18 at 20:24 +0100, Peter Rathlev wrote:
OTOH the tunnel protection, i.e. the alternative to using a crypto
map, is exactly what I needed. I have the setup working now with traffic
entering and exiting via an MPLS link.
And to give credit where due: This page helped me
Hi Peter,
You can use VTI GRE mode on your side and crypto map on the remote end
device . The remote router with crypto map needs to use the same source and
destination IP for GRE and the VPN tunnel.
-Rakesh
On Thu, Mar 11, 2010 at 11:53 AM, Peter Rathlev pe...@rathlev.dk wrote:
Hi Rakesh,
Hi,
On Thu, Mar 11, 2010 at 06:53:46PM +0100, Peter Rathlev wrote:
Yes, and though I would like to use VTI the other end are not able to.
So that's a no go.
This surprises me somewhat. The config variant you use to configure the
IPSEC stuff on your end should be completely transparent to the
On Sat, 2010-03-13 at 12:30 +0100, Gert Doering wrote:
On Thu, Mar 11, 2010 at 06:53:46PM +0100, Peter Rathlev wrote:
Yes, and though I would like to use VTI the other end are not able to.
So that's a no go.
This surprises me somewhat. The config variant you use to configure the
IPSEC
In my knowledge VTI IPSEC simplifies the tunnel management and creation and
provides a routable interface Cisco IOS Software IPSec VTIs can support all
types of IP routing protocols, and is completely transparent to the other side
of the Tunnel.
Hope this help
Paolo
On 03/10/2010 05:44 PM, David Prall wrote:
You could do MPLSoGREoIPSec
Maybe, if you control both the design and feature set of both ends.
But still, it seems pretty clear this is a bug or feature limitation to
me. IP/IPSEC/GRE packets are arriving at/leaving the router. The next
hop
encryption.
David
--
http://dcp.dcptech.com
-Original Message-
From: Phil Mayers [mailto:p.may...@imperial.ac.uk]
Sent: Thursday, March 11, 2010 4:48 AM
To: David Prall
Cc: 'Peter Rathlev'; 'cisco-nsp'
Subject: Re: [c-nsp] IPSec crypto map on MPLS enabled interface?
On 03/10/2010
On Thu, 2010-03-11 at 08:39 -0500, David Prall wrote:
I've done this a couple times where the crypto interface was the vrf
interface, and we decrypted/encrypted there and then put the traffic
onto a core labeled interface without encryption.
This is basically what I ended up doing, and it
On 11/03/10 16:14, Peter Rathlev wrote:
On Thu, 2010-03-11 at 08:39 -0500, David Prall wrote:
I've done this a couple times where the crypto interface was the vrf
interface, and we decrypted/encrypted there and then put the traffic
onto a core labeled interface without encryption.
This is
forgot to hit reply all..
On Thu, Mar 11, 2010 at 10:39 AM, Rakesh Hegde rake...@gmail.com wrote:
Since you are using crypto maps, the unencrypted (GRE) IP traffic has to
hit the physical interface that the cryprto map is applied to get
encrypted. If the interface is MPLS enabled the
On Thu, 11 Mar 2010, Peter Rathlev wrote:
On Thu, 2010-03-11 at 08:39 -0500, David Prall wrote:
I specifically tested if the router would MPLS tag the packets
correctly, and could see that it would. And I also tested the whole
stack (IP/GRE/IPSec/MPLS), but only with traffic originated by the
Hi Rakesh,
On Thu, 2010-03-11 at 10:39 -0600, Rakesh Hegde wrote:
VTI tunnel protection (with or without GRE) should work as they don't
use crypto map and the IPSEC tunnel is built beforehand.
The encrypted packets will be label switched just like any other IP
packet.
Yes, and though I
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers
Sent: Thursday, March 11, 2010 8:55 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] IPSec crypto map on MPLS enabled interface?
On 11/03/10 16:14, Peter Rathlev wrote
On Tue, 2010-03-09 at 13:35 +0100, Peter Rathlev wrote:
And the encrypted traffic leaves the box tagged too.
I assumed a little too much here. :-)
It turns out that the traffic leaves the box unencrypted unless it
originated on the box itself. So ping inside the tunnel interface works
fine, but
] IPSec crypto map on MPLS enabled interface?
On Tue, 2010-03-09 at 13:35 +0100, Peter Rathlev wrote:
And the encrypted traffic leaves the box tagged too.
I assumed a little too much here. :-)
It turns out that the traffic leaves the box unencrypted unless it
originated on the box itself. So
I the tried changing the ISAKMP profile VRF, et voila, it worked. :-)
I have reloaded the box to make sure it's not just good luck that it
works now. It seems to work fine after a reload, with MPLS on the core
facing interfaces.
Interesting. Are the packets arriving at the box labelled?
FWIW
On Tue, 2010-03-09 at 10:49 +, Phil Mayers wrote:
I the tried changing the ISAKMP profile VRF, et voila, it worked. :-)
I have reloaded the box to make sure it's not just good luck that it
works now. It seems to work fine after a reload, with MPLS on the core
facing interfaces.
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Peter Rathlev
Sent: March-09-10 7:36 AM
To: Phil Mayers
Cc: cisco-nsp
Subject: Re: [c-nsp] IPSec crypto map on MPLS enabled interface?
On Tue, 2010-03-09 at 10:49 +
I'm too stupid to make this work. :-)
What I'm trying is:
- NPE-G1 running 12.4(25c) Ent. IPSec 3DES (c7200-jk9s-mz.124-25c.bin)
- Configured as standard MPLS PE in our network
- Loopback-interface to terminate GRE tunnel on outside VRF
- Tunnel-interface in inside VRF
- No other interfaces
On 08/03/10 15:27, Peter Rathlev wrote:
I'm too stupid to make this work. :-)
What I'm trying is:
- NPE-G1 running 12.4(25c) Ent. IPSec 3DES (c7200-jk9s-mz.124-25c.bin)
- Configured as standard MPLS PE in our network
- Loopback-interface to terminate GRE tunnel on outside VRF
-
On Mon, 8 Mar 2010, Peter Rathlev wrote:
crypto isakmp profile Crypto-Profile-TEST
vrf INSIDE-VRF
keyring Crypto-Keyring-TEST
match identity address 172.16.0.1 255.255.255.255 OUTSIDE-VRF
initiate mode aggressive
!
not sure, but maybe you should put this profile in vrf OUTSIDE-VRF ?
On Mon, 2010-03-08 at 18:47 +0200, John Kougoulos wrote:
On Mon, 8 Mar 2010, Peter Rathlev wrote:
crypto isakmp profile Crypto-Profile-TEST
vrf INSIDE-VRF
keyring Crypto-Keyring-TEST
match identity address 172.16.0.1 255.255.255.255 OUTSIDE-VRF
initiate mode aggressive
!
not sure,
(Hit the send key combo a little too fast, continuing)
On Mon, 2010-03-08 at 18:33 +0100, Peter Rathlev wrote:
In the mean time I found this article:
http://blog.ioshints.info/2009/09/encrypting-p-to-p-router-traffic.html
As I read that article, it suggests that MPLS and IPSec don't mix. I'm
: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Peter Rathlev
Sent: Monday, March 08, 2010 7:27 AM
To: cisco-nsp
Subject: [c-nsp] IPSec crypto map on MPLS enabled interface?
I'm too stupid to make this work. :-)
What I'm trying is:
- NPE-G1 running 12.4(25c
On Mon, 2010-03-08 at 10:34 -0800, Leah Lynch (Contractor) wrote:
Wow! That's a lot of encapsulation for each packet (Eth, GRE, MPLS,
IPSec)!
It's a brave new world. :-) Having the configuration on a standard PE in
our core greatly simplifies the routing and configuration. And the
GRE-in-IPSec
Ramcharan
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers
Sent: Monday, March 08, 2010 11:18 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] IPSec crypto map on MPLS enabled interface?
On 08/03/10 15:27
Peter,
The VRF statement in the ISAKMP profile does refer to the inside VRF . In
other words, its the VRF the decrypted packets are placed in. Since these
packets are GRE encapsulated in your case, it has to match the vrf that the
tunnel iinterface is using to build the gre tunnel (tunnel vrf
31 matches
Mail list logo
