Здравствуйте

Имею сборку: с двух сторон cisco 3845 с c3845-adventerprisek9-mz.151-4.M12a.bin

Сторона А:
track 20 ip sla 20 reachability
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key 12345 address 1.1.1.2
crypto ipsec transform-set ESP_3DES_SHA_HMAC esp-3des esp-sha-hmac
crypto ipsec df-bit clear
crypto ipsec profile VTI_PROF
set transform-set ESP_3DES_SHA_HMAC
set pfs group2
interface Tunnel1
ip address 5.5.1.1 255.255.255.252
tunnel source GigabitEthernet0/0
tunnel mode ipsec ipv4
tunnel destination 1.1.1.2
tunnel protection ipsec profile VTI_PROF
ip sla 20
icmp-echo 5.5.1.2 source-interface Tunnel1
ip sla schedule 20 life forever start-time now

Сторона B:
track 20 ip sla 20 reachability
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key 12345 address 1.1.1.1
crypto ipsec transform-set ESP_3DES_SHA_HMAC esp-3des esp-sha-hmac
crypto ipsec df-bit clear
crypto ipsec profile VTI_PROF
set transform-set ESP_3DES_SHA_HMAC
set pfs group2
interface Tunnel2
ip address 5.5.1.2 255.255.255.252
tunnel source GigabitEthernet0/0
tunnel mode ipsec ipv4
tunnel destination 1.1.1.2
tunnel protection ipsec profile VTI_PROF
ip sla 20
icmp-echo 5.5.1.1 source-interface Tunnel2
ip sla schedule 20 life forever start-time now

Туннели с двух сторон работают:

C3845-А#sh interfaces tunnel 1
Tunnel1 is up, line protocol is up
Hardware is Tunnel
Internet address is 5.5.1.1/30
MTU 17886 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 1.1.1.1 (GigabitEthernet0/0), destination 1.1.1.2
Tunnel Subblocks:
src-track:
Tunnel1 source tracking subblock associated with GigabitEthernet0/0
Set of tunnels with source GigabitEthernet0/0, 11 members (includes iterators), on interface <OK>
Tunnel protocol/transport IPSEC/IP
Tunnel TTL 255
Tunnel transport MTU 1446 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Tunnel protection via IPSec (profile "VTI_PROF")
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 2
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
2156 packets input, 160014 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
3643 packets output, 1836824 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out

C3845-B#sh interfaces tunnel 2
Tunnel2 is up, line protocol is up
Hardware is Tunnel
Internet address is 5.5.1.2/30
MTU 17886 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 1.1.1.2 (GigabitEthernet0/0), destination 1.1.1.1
Tunnel Subblocks:
src-track:
Tunnel2 source tracking subblock associated with GigabitEthernet0/0
Set of tunnels with source GigabitEthernet0/0, 2 members (includes iterators), on interface <OK>
Tunnel protocol/transport IPSEC/IP
Tunnel TTL 255
Tunnel transport MTU 1446 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Tunnel protection via IPSec (profile "VTI_PROF")
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
12792 packets input, 2490113 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
15258 packets output, 1950049 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out

1.1.1.1 и 1.1.1.2 друг от друга пингуются

Но не пингуется "5.5.1.2 с 5.5.1.1" и "5.5.1.1 с 5.5.1.2"

потому имеем:

C3845-A#sh track 20
Track 20
IP SLA 20 reachability
Reachability is Down
13 changes, last change 01:51:58
Latest operation return code: Timeout
Tracked by:
STATIC-IP-ROUTING 0

C3845-B#sh track 20
Track 20
IP SLA 20 reachability
Reachability is Down
13 changes, last change 01:51:58
Latest operation return code: Timeout
Tracked by:
STATIC-IP-ROUTING 0

Основная проблема в том, то все работает нормально и пинги внутри туннеля идут, то наступает ситаци описанная выше.

В какую сторону копать?

Заранее спасибо за ответы.

А что то я не увидел Cripto map и какой трафик у вас заворачивается в туннели?

Трафик заворачивается статическим маршрутом с условием, вида:
На стороне А
ip route 192.168.2.0 255.255.255.0 5.5.1.2 20 track 20
На стороне В
ip route 192.168.1.0 255.255.255.0 5.5.1.1 20 track 20

Но дело до этого не доходит
не пингуется "5.5.1.2 с 5.5.1.1" и "5.5.1.1 с 5.5.1.2", для этого я так понимаю маршруты и не нужны

Cripto map не используется

interface GigabitEthernet0/0
ip address 12.12.12.12 255.255.255.0
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
media-type rj45

Прошу пояснить для чего в данной структуре нужен Cripto map.
Заранее спасибо.

Мимокрокодил....

Да не работают у вас туннели...

Начните с простого:

interface Tunnel1
ip address 5.5.1.1 255.255.255.252
tunnel source GigabitEthernet0/0
tunnel destination "WAN IP R2"


interface Tunnel2
ip address 5.5.1.2 255.255.255.252
tunnel source GigabitEthernet0/0
tunnel destination "WAN IP R1"


Ping 5.5.1.1 - 5.5.1.2

Проходит? -> Вешаем шифрование (tunnel protection profile)
Проходит?((sh cr se b) -> вертим ваш трекинг

j_vw, спасибо за ответ
похоже действительно туннели не работают,
но я пошел другим путем

на 3845 сторона А, кроме interface GigabitEthernet0/0
есть еще
interface Cellular0/1/0
ip address 7.7.7.7 255.255.255.0
ip flow ingress
ip flow egress
ip nat outside
ip virtual-reassembly in
encapsulation ppp
dialer in-band
dialer idle-timeout 0
dialer string gsm
dialer-group 1
async mode interactive
ppp chap hostname 123
ppp chap password 123
ppp ipcp dns request

и туннель с него на 1.1.1.2
с аналогичными настройками

записываем пинги из компьютера подсети А, на компьютер подсети В (идут через туннель с маршрутизацией)

через GigabitEthernet0/0
вырубается примерно 7 раз в день, причем каждый раз на 58 или 115 минут, потом включается
перезагрузка маршрутизатора на стороне А заставляет работать тут же

через Cellular0/1/0
есть свои проблемы, но вырубаний нет

получается что проблема у провайдера GigabitEthernet0/0 сторона А

какие настройки можно покрутить, чтобы дать жизни системе?
у ip sla 20 с обоих сторон сделал простукивание 1 раз в 1 секунду - не помогло

схожая тема тут viewtopic.php?f=2&t=565

всем заранее спасибо

Получил интересный результат

С обоих сторон на туннель через GigabitEthernet0/0 добавил

простукивание туннеля раз в секунду
ip sla 20
icmp-echo 5.5.1.2 source-interface Tunnel1
threshold 1000

уменьшил передаваемый блок
interface Tunnel1
ip address 5.5.1.1 255.255.255.252
tunnel source GigabitEthernet0/0
tunnel mode ipsec ipv4
tunnel destination 1.1.1.2
tunnel protection ipsec profile VTI_PROF
ip mtu 550
ip tcp adjust-mss 500

вырубания туннеля прекратились
но идеально не стало

теперь бывают периоды с пингом около 25 ms (норма) и периоды с пингом 500 - 1000 ms
работу с пингом 1000 ms удовлетворительной назвать нельзя

но при работе через Cellular0/1/0
была примерно такая же картина
я думал, что туннель через радио модем быстрее работать и не будет
но может и так

куда копать дальше?

К сожалению вырубания не прекратились.

Заметил интересную зависимость
имеются равные периоды работы / не работы по 58 минут
может быть любая последовательность, например 2 периода работы, потом один не работы, потом один работы, потом три не работы
при перезагрузке обязательно будет рабочий период, но он продлится не 58 минут, а судя по всему до конца периода, если бы циска не перезагружалась

поменял 3845 на другу на всякий случай
не помогло

думаю что проблема в провайдере

но не понимаю как сформулировать ему претензию
может кто подскажет что написать?

IP SLA?

Проблема решена

Проблемы была на стороне провайдера.

Перед моей 3845 стоял Eltex 1404, который работал в режиме моста и преобразовывал оптику в медь.
Вот он и создавал эти проблемы.
Подсоединил оптику, непосредственно в 3845, настроил подключение - все работает идеально.

Бойтесь Элтехов в сети находящихся...

на днях по МСК поднимал 120 туннелей
4 точки не видели друг друга - пришлось звонить прову
порешали