neprden

to ipaddr.ru Спасибо за ответ ! Исчерпывающе! Если раздумаем становится Lir то непременно придем ). Кстати вы не оказываете консультационных услуг подобного рода , а именно помощь в получении статуса lIR ?

Поверте, я настроен крайне дружелюбно, поэтому все что напишу ниже не принимайте на свой счет пожалуйста. Я искренне не понимаю, что заставляет людей писать подобные ответы, как вообще не лень набирать что то типо "посмотрите в интернете там должно быть". Безусловно, я читал документы RIPE. Остается поблагодарить что обратили на меня внимание. Конечно на некоторые вопросы, что я задал, я и сам уверен что ответ утвердительный, хотя мне это не кажется самочевидными: все упирается в вопрос трактовок RIPE. Однако хочется услышать мнения профи. На вопрос : удастся ли оставить за собой 2 блока PI однозначного ответа не дало ни консультация c rucentr ни переписка lir-help@ripe.net. У меня есть уверенность , что ситуация моя не уникальная, поэтому и хотелось услышать о success story. За одно и спросить о деталях. Как то так в общем.

Доброго времени суток. Ситуация: Есть AS и 2 блока pi /22 ipv4. Хотим стать LIR. Есть несколько вопросов. 1.) Возможно ли будет сохранить за собой хотябы 1 из этих блоков и перевести их в статус PA. Что для этого нужно сделать ? 2.) Сообразно вышеописанному , обязательно ли брать дополнительно блок /21 ? 3.) А правда лирам дают /32 ipv6 бесплатно , или за смешные деньги ? 4.) Приблизительные временные рамки всего этого. 5.) Автономку за нами скорее всего оставят ? 6.) Правильно ли я понимаю что ежегодная оплата в RIPE будет чтото около 1300 евро + 50 евро за ас и 50 за каждый inetnum ? 1.а) Может быть не парится и продолжать сидеть на PI ? Хотя если прогнозы по росту сбудутся , то получать новые PI будет проблемой. Дадут ли мне как не LIR кусок /32 ipv6 ? Задорого ли ?

Смотрел на cisco.com поддержку 6rd нашел только на новых 15-х иосах и то только для 38 ISR-ов. Следующая железка уже ASR 1000. Видимо на 72 и ниже поддержки 6rd не планируется ? Тогда видимо остается только linux... есть ли у кого пример рабочей конфигурации или статьи на тему поднятия 6rd border на линукс ?

кому нибудь удавалось посылать/принимать факс по т.38 без разрыва (с восстановлением голосовой сесии) ?

Кривость биллинга - это понятно, но речь то идет вообще о иерархии безопасности. Понятно, что если оператор биллинга может поменять пароль с помощью которого подписываются радиус пакеты от железки, то будет общий обвал сервиса. Поэтому оператору биллинга не даем права на такую штуку. А вот назначать ип адреса которые будут выдаватся клиентам - работа как раз его , и вот то что в рамках этого он может обрушить весь сервис - весьма удручает. Попробую конечно убедить разрабротчиков, но все же хочется быть застрахованным от такого рода штук. странно только то что при вводе команды ip route екзек процесс проверяет корректность параметров а ipcp нет. Ну и по поводу самоконфигурирования железки от имени юзера console тоже вопрос открыт.

Хочу поделится весьма презабавнейшим случаем, постигшим давеча мою циску 7206 настроенную в качестве BRAS; терминируем pppoe. есть настройки VT : interface Virtual-Template1 description cl ADSL mtu 1492 ip unnumbered Loopback10 ip access-group ADSLBLOCK in ip verify unicast reverse-path allow-self-ping ip flow ingress ip ospf network point-to-point no logging event link-status timeout absolute 1440 0 snmp trap ip verify drop-rate no peer default ip address keepalive 20 ppp max-bad-auth 3 ppp authentication pap Method1 ppp authorization Method1 ppp accounting Method1 ppp ipcp username unique ppp ipcp address required ppp ipcp address unique ppp timeout retry 3 ppp timeout authentication 15 ppp timeout idle 3600 end Существует также радиус сервер, на котором есть учетные записи для pppoe клиентов, ну и также в оных можно указать ip адрес и маску которую должен получить сей клиент при авторизации. Все это работает себе до тех пор пока по ошибке не был заведен клиент с адресом допустим 1.1.1.1 и маской ВНИМАНИЕ 0.0.0.0 т.е с пустым полем. Дальше самое интересное, клиент логинится : 000700: Apr 8 17:44:04.671 MSD: RADIUS: Framed-IP-Address [8] 6 1.1.1.1 000701: Apr 8 17:44:04.671 MSD: RADIUS: Framed-IP-Netmask [9] 6 0.0.0.0 000702: Apr 8 17:44:04.671 MSD: RADIUS: Service-Type [6] 6 Framed [2] 000704: Apr 8 17:44:04.671 MSD: pppx PPP: Phase is FORWARDING, Attempting Forward 000705: Apr 8 17:44:04.671 MSD: pppx PPP: Send Message[Connect Local] 000706: Apr 8 17:44:04.675 MSD: pppx PPP: Bind to [Virtual-Access102] далее смотрим на IPCP : 000730: Apr 8 17:44:04.711 MSD: Vi102 IPCP: O CONFACK [ACKrcvd] id 1 len 22 000731: Apr 8 17:44:04.711 MSD: Vi102 IPCP: Address 1.1.1.1 000732: Apr 8 17:44:04.711 MSD: Vi102 IPCP: PrimaryDNS 5.5.5.5 000733: Apr 8 17:44:04.715 MSD: Vi102 IPCP: SecondaryDNS 5.5.5.6 000734: Apr 8 17:44:04.715 MSD: Vi102 IPCP: State is Open 000735: Apr 8 17:44:04.719 MSD: Vi102 IPCP: Install route to 1.1.1.1 и ! сюрприз : 000736: Apr 8 17:44:04.903 MSD: %PARSER-5-CFGLOG_LOGGEDCMD: User:console logged command:ip route 0.0.0.0 0.0.0.0 1.1.1.1 т.е циска сама конфигурит дефолтный маршрут причем с метрикой connected указывающий на только что подключившегося клиента. На роутере болтается full view, а если бы не было, то инет отвалился бы у всех клиентов. с общей точки зрения , циску понять можно. Если бы не проверялись параметры, передаваемыые комманде ip route, то такой эффект при использовании 0-й маски понятен. После завершения сессии маршрут удаляется. Вопрос : можно ли защитится средсвами циски от подобного рода казусов ? Допустим принудительно выставлять 32 маску на VT или подменять присылаемый Framed-IP-Netmask ? Cisco IOS Software, 7200 Software (C7200-ADVENTERPRISEK9-M), Version 12.4(24)T, RELEASE SOFTWARE (fc1) И еще чрезвычайно любезно со стороны циски было уведомить меня о произошедшем посредством сислога, в котором была вышеприведенная запись, в которой же было указано , что команду ip route 0.0.0.0 0.0.0.0 1.1.1.1 а также ее отмену при завершении сессии издавал пользователь "console". Любопытно какие еще в принципе изменения могут самовольно вносится в конфиг , где об этом почитать ?

моя разобрался, все дело было в сумеречном состоянии души и ip unnumbered Loopback1 на virtual-template. На loopback1 ессно висит адрес который анонсится по ospf. Видимо при падении/поднятии virtual-access одним из концов которого является адрес из 1.1.1.0/24 сети, оспф считает своим долгом пересчитатся. Спасибо за помощь и участие.

в том то и дело что при поднятии пересчета нет. при завершении есть . порядковые номера lsa не увеличиватся. deb ip ospf spf deb ip ospf events 000173: Apr 7 09:57:40.908 MSD: OSPF: Interface Virtual-Access40 going Down 000174: Apr 7 09:57:41.408 MSD: OSPF: Schedule SPF in area 0 Change in LS ID 1.1.1.100, LSA type R, spf-type Full 000175: Apr 7 09:57:41.408 MSD: OSPF: forcing SPF in area 0 000176: Apr 7 09:57:41.904 MSD: OSPF: Address removed from Virtual-Access40: 0.0.0.0 000177: Apr 7 09:57:41.908 MSD: OSPF: Address added to Virtual-Access40: 0.0.0.0 data1# 000178: Apr 7 09:57:42.408 MSD: OSPF: Schedule SPF in area 0 Change in LS ID 1.1.1.100, LSA type R, spf-type Full 000179: Apr 7 09:57:42.408 MSD: OSPF: forcing SPF in area 0 data1# 000180: Apr 7 09:57:43.416 MSD: OSPF: Rcv hello from 1.1.1.101 area 0 from FastEthernet0/1.777 1.1.1.130 000181: Apr 7 09:57:43.416 MSD: OSPF: End of hello processing data1# 000182: Apr 7 09:57:46.408 MSD: OSPF: running SPF for area 0, SPF-type Full 000183: Apr 7 09:57:46.408 MSD: OSPF: Initializing to run spf 000184: Apr 7 09:57:46.408 MSD: OSPF - spf_intra() - rebuilding the tree It is a router LSA 1.1.1.100. Link Count 3 000186: Apr 7 09:57:46.408 MSD: Processing link 0, id 1.1.1.100, link data 255.255.255.255, type 3, cost 1 и т.д.

собсно up

собсно настройки оспф на обоих железках одинаковые : router ospf 1 log-adjacency-changes passive-interface default no passive-interface FastEthernet0/1.777 network 1.1.1.0 0.0.0.255 area 0 сеть 1.1.1.0/24 поделена на 4 подсети в одой из которых лупбеки в другой транспортная сеть. на fa 0/1.777 всех железок адреса из 1.1.1.128/26 сети клентов ну допустим 2.2.0.0/22 настройки бгп в общем тоже простые : router bgp XXX bgp log-neighbor-changes redistribute connected route-map CLIENTS redistribute static route-map CLIENTS neighbor 1.1.1.101 remote-as XXX neighbor 1.1.1.101 update-source Loopback1 neighbor 1.1.1.101 next-hop-self no auto-summary no synchronization route-map CLIENTS, permit, sequence 10 Match clauses: ip address prefix-lists: CLIENTS ip prefix-list CLIENTS: seq 5 permit 2.2.0.0/22 le 32 видим, что редистрибъюции никакой в оспф нет. однако, что видно из дебага, при падении любого virtual-access происходит пересчет SPF, причом только на brasе. Cisco IOS Software, 7200 Software (C7200-ADVENTERPRISEK9-M), Version 12.4(24)T, RELEASE SOFTWARE (fc1)

Есть Bras на cisco 7206, на котором терминируются pppoe клиенты. НА ней же поднят ospf и ibgp. по ibgp анонсируются клиентские префиксы по ospf ТОЛЬКО ! лупбеки серверов доступа и соотв лупбек этого браса. НА брасе вижу достаточно большое кол-во пересчета spf (на несколько порядков больше чем на других ospf соседях, на прочих оно вообще замерло). 72-я то и дело плюется трапами что-то типо : enterprise=1.3.6.1.2.1.14.16.2, enterprise_mib_name=ospfTraps, agent_ip=x.x.x.x, generic_num=6, specificTrap_num=16, specificTrap_name=ospfIfStateChange, version=Ver1, ospfRouterId=x.x.x.100, ospfIfIpAddress=0.0.0.0, ospfAddressLessIf=151, ospfIfState=down enterprise=1.3.6.1.2.1.14.16.2, enterprise_mib_name=ospfTraps, agent_ip=x.x.x.100, generic_num=6, specificTrap_num=16, specificTrap_name=ospfIfStateChange, version=Ver1, ospfRouterId=x.x.x.100, ospfIfIpAddress=0.0.0.0, ospfAddressLessIf=151, ospfIfState=pointToPoint Подозреваю что трапы и пересчет оспф зависят от поведения виртуальных интерфейсов, однако в оспф настроено так, что все интефейсы, кроме смотрящих в магистраль, пассивные. Подскажите: как избавится в данном случае от частого пересчета ?

а версию софта и настройки можно узнать ?

Есть несколько linksys spa 2102. подключенные как к софтсвичу (mvts) . Факсы по t.38 ходят и на прием и на отправку однако восстановление голосовой сессии не происходит. Если 2 линксиса зацепить напрямую - тоже самое. Из дебагов видно что не один из них (подключенных на прямую) не шлет реинвайт на восстановление голосовой сессии. Из дебагов также видно что когда с мвтс приходит реинвайт на восстановление сессии то линксис отвечает 488 ошибкой. Крутил вроде все что мог но результата не добился. У кого нибудь сессия восстанавливается после т38 ? spa2102 вообще это могут? прошивка последняя 5.2.10 .

хммм . видимо путаю ).