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...
can you put the full configuration....? I want to see the ACL.
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...
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.
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
I did miss something ;-)
Bye,
Tosh.
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
That's handy - not one that occurred to me.
Thanks.
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.
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...
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...
I tried this, but. I don't receive Hello on 1760 side, so mtu is not a
problem :-(
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 ?
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 ;-)
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.
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.
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...
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