Okazało się, że obejście problemu, polegające na dodaniu RRI z bezpośrednio podanym next-hopem poprawiło sytuację i u mnie :-) Nie mam pojęcia, dlaczego akurat tak, ale wszystko wydaje się działać bez zarzutu.

Kiedyś już miałem bardzo podobne objawy na serii 17xx, ale wtedy pomógł upgrade IOSa. Wynika mi też, że odpowiednik buga CSCtg41606 jest z nami od naprawdę dawna i pojawia się co n-tą wersję :-) I nawet ciężko to podciągnąć pod regułkę „it’s not a bug – it’s a feature” :-)

Mam w firmie pudełko, które odpowiada wyłącznie za terminowanie tuneli VPN do klientów. Nic nadzwyczajnego, ot „czarna skrzynka”, która robi swoje i się nie psuje. Ale czasami zdarza się tak, że jakiś tunel przestaje nagle działać, sam się nie umie zestawić ponownie, a „druga strona” twierdzi, że nic nie dotykała i nic nie wie. Najprostszą i najbardziej podstawową metodą diagnozowania takich problemów jest włączenie na routerze debuga (debug crypto ipsec/isakmp) i oglądanie co się dzieje podczas próby podniesienia tunelu. Problem w tym, że tuneli jest wiele, a ja tylko jeden i od ilości danych, które przelatują nagle przez ekran można dostać oczopląsu. Szczęśliwie Cisco udostępnia bardzo fajną komendę: debug crypto condition peer ipv4 A.B.C.D. Nie robi ona chyba nic więcej, jak tylko ogranicza ilość zbieranych i wyświetlanych przez router informacji do jednego tylko peer’a. I jest to dokładnie to, o co mi chodzi – na monitorze widzę, jak routerki gadają ze sobą i próbują wynegocjować jakieś wartości, które byłby dla obu akceptowalne, a jednocześnie nie muszę oglądać tony innych, w danej chwili zupełnie mi niepotrzebnych rzeczy.

Aha, takie ograniczenie wyłącza się następująco: „debug crypto condition reset”.