Hello!
Ну вот... Эпопею борьбы с Аскендом можно считать завершенной (не всю
конечно, некий ее этап :)
Что при этом было обнаружено:
1) Некая несогласованность в протоколе договора LCP. Ascend пытался
согласовать наличие LQM на линии, получал отказ от Cisco (я не сразу
нашел где это включается, почему-то в IOS'овском Interactive Help
команда ppp quality % отсутствовала, хотя и была понята нормально,
если ее набрать руками, не пользуясь подсказками. :) и валил коннект.
Кто при этом был неправ, мне судить трудно, я не знаю логики протоколов
в этом месте, и поэтому интересно мнение специалистов.
Вопрос: "Корректно ли закрывать коннект, получив отказ на запрошенный
тип QUALITYTYPE или по протоколу нужно было уйти на коннект без LQM,
если peer на него не соглашается?"
Еще вопрос: "Должны ли совпадать выставленные проценты ошибок для LQM
с двух сторон?"
2) CHAP аутентификация при звонке по ISDN Cisco->Ascend.
Работает, если в Cisco на интерфейсе поставлено ppp chap authenticaion callin.
3) Обнаружено забавно-неприятное свойство Ascend (видимо конкретного).
Даже при прошедшей аутентификации линк валится Ascend'ом, с формулировкой
"Unknown or unnegotiated protocol Link = ip" ;))) или вообще без всякого
объяснения причин, просто присылается LCP TERMREQ.
Повторные прозвонки (идущие подряд) приводят к тому, что с пятого-восьмого
раза коннектится нормально без каких-либо действий с какой-либо стороны.
Удалось заметить зависимость такого поведения от времени суток (вечером
коннектится с первого раза).
Единственное, что я могу предположить, что данный конкретный Ascend Max 4000
забит под завязку (в нем стоит 3(!) PRI) и при большом количестве активных
коннектов (такое поведение наблюдалось, когда было 48 активных соединений и
не наблюдалось, когда их было 15-16) у него просто не хватает мощности, чтобы
обработать negotiation нормально и он выходит из этого положения просто
закрывая коннект.
4) Еще некое свойство Ascend, невыгодно отличающее его от Cisco ;)
Если в Ascend прописан /30 на интерфейсе, и прописан статиком роутинг на /24
(было даже на /23, на самом деле :), то в OSPF пропагейтится только
most-specific route, то есть /30. А та сетка, к которой принадлежит этот
роут не пропагейтится в OSPF _вообще_. Причем, поскольку статика была на /23,
то вторая сетка из этого блока нормально ушла в OSPF, а /24, к которому
принадлежал этот /30, оказался просто _вырезанным_. Мне это не кажется
правильным, но опять-таки я не спец в OSPF.
Посему вопрос: "Верно ли такое поведение?"
5) Ну, и до кучи...
Поменяли адреса, чтобы /30 был из другой сетки (так, конечно, правильнее ;).
Так чтобы Ascend перестал пропагейтить старый /30 в OSPF, (которого у него
уже не было час как), пришлось этот Ascend перегружать. Хм... :)
--------------------------------------
Basil (Vasily) Dolmatov dol@east.ru +7-095-956-4951
[BVD12, VVD2-RIPN] [BVD11, VVD1-RIPE]
East Connection ISP, Moscow, Russia. ()
=============================================================================
"inet-admins" Internet access mailing list. Maintained by East Connection ISP.
Mail "unsubscribe inet-admins" to Majordomo@east.ru if you want to quit.
List archive is accessible at
