Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

opsf over ipsec tunnel problem

1 view
Skip to first unread message

Dmitry Melekhov

unread,
Jan 24, 2008, 6:31:04 AM1/24/08
to
Hello!

I had long time worked configuration with cisco 3660 on one side and
cisco 1760 on another.
There was no problems :-)

Now I replaced 3660 with 3845 and decided to switch from crypto map to
ipsec virtual tunnel and now ospf doesn't work.

Here is 1760 configuration:


crypto isakmp policy 15
encr 3des
hash md5
authentication pre-share
group 2
lifetime 3600

crypto ipsec transform-set debessy ah-sha-hmac esp-aes 256 comp-lzs

crypto ipsec profile debesy-p
set transform-set debessy

interface Tunnel0
description p100
ip address 192.168.201.6 255.255.255.252
ip route-cache policy
ip route-cache flow
ip tcp adjust-mss 1360
ip ospf message-digest-key 10
tunnel source 192.168.202.6
tunnel destination 192.168.202.1
tunnel mode ipsec ipv4
tunnel protection ipsec profile debesy-p

interface Serial0/0
description DebBKN-DebIzhcom-2048
ip address 192.168.202.6 255.255.255.252
ip access-group 190 in
ip route-cache policy
ip route-cache flow
fair-queue


The same crypto config on 3845, only difference is in interfaces:

interface Tunnel2
ip address 192.168.201.5 255.255.255.252
ip route-cache policy
ip route-cache flow
ip tcp adjust-mss 1360
ip ospf message-digest-key 10 md5
tunnel source 192.168.202.1
tunnel destination 192.168.202.6
tunnel mode ipsec ipv4
tunnel protection ipsec profile debesy-p

interface Serial3/0
no ip address
ip nbar protocol-discovery
encapsulation frame-relay
ip route-cache policy
ip route-cache flow
fair-queue
serial restart-delay 0

interface Serial3/0.201 point-to-point
description debesy
ip address 192.168.202.1 255.255.255.252
ip access-group 190 in
snmp trap link-status
frame-relay interface-dlci 201


All works OK with static routes, access list in serial interfaces
allows only ipsec traffic.

router ospf 1
network 192.168.201.4 0.0.0.3 area 0

on both sides

with debug ip ospf events
I see on 1760

Jan 24 15:27:43.351 SAMT: OSPF: Send with youngest Key 10
Jan 24 15:27:43.351 SAMT: OSPF: Send hello to 224.0.0.5 area 0 on
Tunnel0 from 192.168.201.6

And on 3845
Jan 24 15:28:33.535 SAMT: OSPF: Rcv hello from 192.168.202.6 area 0
from Tunnel2 192.168.201.6
Jan 24 15:28:33.535 SAMT: OSPF: Send immediate hello to nbr
192.168.202.6, src address 192.168.201.6, on Tunnel2
Jan 24 15:28:33.535 SAMT: OSPF: Send with youngest Key 10
Jan 24 15:28:33.535 SAMT: OSPF: Send hello to 224.0.0.5 area 0 on
Tunnel2 from 192.168.201.5
Jan 24 15:28:33.535 SAMT: OSPF: End of hello processing

I can't understand why 1760 doesn't receive HELLO from 3845 . :-(

IOS is 12.4.17a on both routers.

Do you have any ideas?

btw, I have two ethernet links from 3845 to 2801 with the same tunnel
configuration, ospf works...

Juan Carlos

unread,
Jan 24, 2008, 10:06:23 AM1/24/08
to

can you put the full configuration....? I want to see the ACL.

Dmitry Melekhov

unread,
Jan 24, 2008, 1:03:02 PM1/24/08
to
On 24 янв, 19:06, Juan Carlos <jspichi...@gmail.com> wrote:
> can you put the full configuration....? I want to see the ACL.
full configration is too large

acl on serial interface 1760

access-list 190 permit tcp host 192.168.202.1 host 192.168.202.6 eq 22
access-list 190 permit icmp host 192.168.202.1 host 192.168.202.6
access-list 190 permit icmp host 192.168.202.2 host 192.168.202.6
access-list 190 permit icmp host 192.168.202.5 host 192.168.202.6
access-list 190 permit esp host 192.168.202.1 host 192.168.202.6
access-list 190 permit ahp host 192.168.202.1 host 192.168.202.6
access-list 190 permit udp host 192.168.202.1 eq isakmp host
192.168.202.6 eq isakmp
access-list 190 deny ip any any

acl on serial 3845 is almost the same.
anyway, if I remove them there is no changes and ipsec works...


Tosh

unread,
Jan 24, 2008, 11:53:09 PM1/24/08
to
> Now I replaced 3660 with 3845 and decided to switch from crypto map to
> ipsec virtual tunnel and now ospf doesn't work.
>

Do I miss something or ipsec doesn't support multicast, wich is needed i
order to run ospf?
Doesn't you need gre over ipsec for that?
Bye,
Tosh.


Bo...@hotmail.co.uk

unread,
Jan 25, 2008, 4:28:46 AM1/25/08
to

Thsh,
This is gre over ipsec.

OP,
I presume that you can ping across the link?

ping 192.168.201.5

Here is one I have working:- (but you have one
working too)

crypto isakmp key 123456 address 1.1.6.131

crypto ipsec profile tunnels
set transform-set TS.2

crypto ipsec transform-set TS.2 esp-3des esp-md5-hmac

interface Tunnel0
ip address 10.1.1.2 255.255.255.252
ip mtu 1400
ip ospf cost 1
tunnel source 1.1.10.68
tunnel destination 1.1.6.131
tunnel protection ipsec profile tunnels

router#sh ip ospf nei

Neighbor ID Pri State Dead Time Address Interface
1.1.6.131 0 FULL/ - 00:00:34 10.1.1.1 Tunnel0

Note that I do NOT have:

interface Tunnel0
description p100

tunnel mode ipsec ipv4

Don't know what it does.

I have crypto up.

router#sh cry ip sa

interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 1.1.10.68
<..snipped..>
#pkts encaps: 210099, #pkts encrypt: 210099, #pkts digest: 210099
#pkts decaps: 224121, #pkts decrypt: 224121, #pkts verify: 224121

Tosh

unread,
Jan 26, 2008, 3:38:03 AM1/26/08
to
>This is gre over ipsec.

I did miss something ;-)
Bye,
Tosh.


Merv

unread,
Jan 26, 2008, 5:07:46 AM1/26/08
to
OP,

post output of


! from 3745

ping ip 224.0.0.5 source 192.168.201.5


! from 1700

ping ip 224.0.0.5 source 192.168.201.6

Merv

unread,
Jan 26, 2008, 5:21:22 AM1/26/08
to
Could also try RIPv2 over the VTI to see if issue is a generic
multicast issue or an OSPF-specific issue on 1700

Bo...@hotmail.co.uk

unread,
Jan 27, 2008, 5:31:27 AM1/27/08
to

That's handy - not one that occurred to me.

Thanks.

Bo...@hotmail.co.uk

unread,
Jan 27, 2008, 5:40:02 AM1/27/08
to
On 26 Jan, 10:21, Merv <merv.hr...@rogers.com> wrote:
> Could also try RIPv2 over the VTI to see if issue is a generic
> multicast issue or an OSPF-specific issue on 1700

debug ip ospf hello
should show the hellos arriving and being sent at both ends.

if you havent used debug before make sure that
you have it configured so that you can see some
output.

e.g.
no logg con
logg mon deb
logg buff deb

! then you can either

deb this and that
sh log

! or

telnet to router ! not console
deb this and that
term mon ! off with "term no mon"

Console debuging works but I wouldn't bother.
It is also recommended that you disable console logging
for production since it can consume a lot of cpu.


Bjarne Jorgensen

unread,
Jan 29, 2008, 4:19:43 PM1/29/08
to
Hello.

I have a OSPF problem with tunnel betwin 2 3640 at IOS 12.2

The problem was resolved with this stmt in both tunnels.

Interface Tunnel 0
ip ospf mtu-ignore
.
.
end

Bjarne


"Dmitry Melekhov" <d...@belkam.com> skrev i en meddelelse
news:cdb3778a-5be7-4bbb...@q77g2000hsh.googlegroups.com...

Dmitry Melekhov

unread,
Jan 30, 2008, 1:52:07 AM1/30/08
to

Hello!

From 3845:


p100-cr3845-1#ping ip 224.0.0.5 source 192.168.201.5

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.0.0.5, timeout is 2 seconds:
Packet sent with a source address of 192.168.201.5

Reply to request 0 from vpn.p98.belkam.com (192.168.22.203), 1 ms
Reply to request 0 from hryak-p100-tun.net200.belkam.com
(192.168.200.30), 44 ms
Reply to request 0 from debyosy-p100.net201.belkam.com
(192.168.201.6), 16 ms
Reply to request 0 from nsk-p100-backup.net200.belkam.com
(192.168.200.214), 8 ms
Reply to request 0 from ps15-p100.net200.belkam.com (192.168.200.210),
4 ms
Reply to request 0 from s171a-p100.net201.belkam.com (192.168.201.2),
4 ms
Reply to request 0 from vkptus-p100.net200.belkam.com
(192.168.200.230), 4 ms
Reply to request 0 from k183-p100.net200.belkam.com (192.168.200.253),
4 ms
Reply to request 0 from 192.168.200.14, 4 ms
Reply to request 0 from p100-cr3660-1.p98.belkam.com (192.168.22.253),
1 ms
Reply to request 0 from p98a-cc3550t-1.p98.belkam.com
(192.168.22.218), 1 ms
Reply to request 0 from p100-cc3550g-1.p98.belkam.com (192.168.22.5),
1 ms

There is reply from 192.168.201.6

From 1760:

deb-abk-cr1760-1#ping ip 224.0.0.5 source 192.168.201.6

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.0.0.5, timeout is 2 seconds:
Packet sent with a source address of 192.168.201.6

Reply to request 0 from 192.168.201.5, 20 ms


So multicast works...

Dmitry Melekhov

unread,
Jan 30, 2008, 1:53:52 AM1/30/08
to
On 30 янв, 01:19, "Bjarne Jorgensen" <bjd...@hotmail.com> wrote:
> Hello.
>
> I have a OSPF problem with tunnel betwin 2 3640 at IOS 12.2
>
> The problem was resolved with this stmt in both tunnels.
>
> Interface Tunnel 0
> ip ospf mtu-ignore
> .
> .
> end
>

I tried this, but. I don't receive Hello on 1760 side, so mtu is not a
problem :-(

Merv

unread,
Jan 30, 2008, 5:51:03 AM1/30/08
to

One would typically see OSPF adjacency stuck in Exstart for the MTU
mismatch issue to apply

What is the transport network between the two routers ?

Did you try switching back to the original crypto setup - i.e in case
there is a bug in VTI ?

Dmitry Melekhov

unread,
Jan 31, 2008, 1:32:30 AM1/31/08
to
On 30 янв, 14:51, Merv <merv.hr...@rogers.com> wrote:
> One would typically seeOSPFadjacency stuck in Exstart for the MTU
> mismatch issue to apply
>

I have stuck in INIT.

> What is the transport network between the two routers ?
>

I don't know whole network ;-)
I know that it is shdsl between us an server provider on both sides,
an I know that provider use mpls.


> Did you try switching back to the original crypto setup - i.e in case
> there is a bug in VTI ?

No, just because static routing is enough for now, but we plan to
build backup channel, fortunately not very soon ;-)

Merv

unread,
Jan 31, 2008, 3:54:04 AM1/31/08
to
On Jan 31, 1:32 am, Dmitry Melekhov <d...@belkam.com> wrote:

> On 30 ÑÎ×, 14:51, Merv <merv.hr...@rogers.com> wrote:
>
> > One would typically seeOSPFadjacency stuck in Exstart for the MTU
> > mismatch issue to apply
>
> I have stuck in INIT.

The state makes sense given hellos have not been exchanged in both
directions


At this point, I would try configuring the command "ip ospf neighbor
<IP address of nei>
on both routers to see if the adjacency will come up

! 3845

int tu 2
ip ospf nei 192.168.201.5


! 1760

int tu 0
ip ospf nei 192.168.201.6


pull the digest key until you have an adjacency form

Please post output of "show ip ospf interface <tunnel>" for the
relevant tunnel interface on both routers


OBTW IOS releases 12.4(7) thru 12.4(7e) have been deferred ( read
junked ) by Cisco.

So you may very well have stepped on a bug ...

I would give serious consideration to upgrading the IOS version after
looking at some of the newer releases and doing a thorough bug scrub.

Bo...@hotmail.co.uk

unread,
Jan 31, 2008, 4:33:18 AM1/31/08
to
On 30 Jan, 06:52, Dmitry Melekhov <d...@belkam.com> wrote:
> So multicast works...- Hide quoted text -

Well that's all you need.

I have not gone through this all really thoroughly but
it loks like maybe a bug or you have missed some
tiny detail somewhere.

As Merv suggests lose the ospf security.

I did notice:


interface Tunnel2
ip address 192.168.201.5 255.255.255.252

...


ip ospf message-digest-key 10 md5

interface Tunnel0


description p100
ip address 192.168.201.6 255.255.255.252

ip ospf message-digest-key 10 ! < -- NO "md5"

Lose also the route cache policy etc.

If there is a bug maybe "no ip route cache"
might workaround. (Has once for me).

Do your ACLs allow OSPF? Ah!, they are on the physical
int so don;t need to.

You need the hellos and then another group for
LSA exchange IIRC.

Dmitry Melekhov

unread,
Feb 1, 2008, 12:51:17 AM2/1/08
to
On 31 янв, 12:54, Merv <merv.hr...@rogers.com> wrote:

> On Jan 31, 1:32 am, DmitryMelekhov<d...@belkam.com> wrote:
>
> > On 30 ÑÎ×, 14:51, Merv <merv.hr...@rogers.com> wrote:
>
> > > One would typically seeOSPFadjacency stuck in Exstart for the MTU
> > > mismatch issue to apply
>
> > I have stuck in INIT.
>
> The state makes sense given hellos have not been exchanged in both
> directions
>
> At this point, I would try configuring the command "ipospfneighbor
> <IP address of nei>
> on both routers to see if the adjacency will come up
>
> ! 3845
>
> int tu 2
> ipospfnei 192.168.201.5

>
> ! 1760
>
> int tu 0
> ipospfnei 192.168.201.6

Sorry, I it is impossible to write ospf neighbor on interface.
I tried to do this in router ospf 1, this doesn't help.

>
> pull the digest key until you have an adjacency form
>

This doesn't help too :-(

> Please post output of "show ipospfinterface <tunnel>" for the


> relevant tunnel interface on both routers
>

1760:

deb-abk-cr1760-1#sh ip ospf interface tunnel 0
Tunnel0 is up, line protocol is up
Internet Address 192.168.201.6/30, Area 0
Process ID 1, Router ID 192.168.202.6, Network Type POINT_TO_POINT,
Cost: 11111
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:07
Supports Link-local Signaling (LLS)
Index 2/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 0
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
Message digest authentication enabled
No key configured, using default key id 0


3845:
p100-cr3845-1#sh ip ospf interface tunnel 2
Tunnel2 is up, line protocol is up
Internet Address 192.168.201.5/30, Area 0
Process ID 1, Router ID 192.168.22.251, Network Type POINT_TO_POINT,
Cost: 11111
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:04
Supports Link-local Signaling (LLS)
Index 9/9, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 0
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
Message digest authentication enabled
No key configured, using default key id 0


> OBTW IOS releases 12.4(7) thru 12.4(7e) have been deferred ( read
> junked ) by Cisco.
>

flash:c1700-advsecurityk9-mz.124-17a.bin"
flash:/c3845-adventerprisek9-mz.124-18.bin


> So you may very well have stepped on a bug ...
>

I think so too...

johan

unread,
Mar 15, 2008, 11:11:42 AM3/15/08
to

Hi,

I am looking for good open source netflow collector and analyser for
monitoring mpls-router + 3 l3-switches in some 15 locations. Anybody has
an idea ? I tried netflow, but isn't good solution for more locations.

Greetz,
Johan

fugettaboutit

unread,
Mar 16, 2008, 8:49:55 AM3/16/08
to
You might try ntop...however, I've always been a bit skeptical of
NetFlow stats. I know my network traffic mix pretty well, and I see all
kinds of traffic classes that I know don't exist on our network. I'd
appreciate any feedback as to other people's experience with the
accuracy of the reported traffic mixes.
0 new messages