ilgizk

Анатолий, проводилось тестирование нового железа на действующей сети оператора, а не реализация проекта. Цель была выяснить будет ли вообще работать 100Г и как проявят себя на этих скоростях существующие ВОЛС и оборудование DWDM и MPLS. Два разных города были выбраны для реалистичности испытаний и удобства перенаправления 100Г по разным трассам магистральной ВОЛС. Мог быть и не Стерлитамак :)

Если RPF не знает nexhop к источнику, то значит не все в порядке. Очевидно ситуация вот такая: при отправке Join маршрутизаторы строят SPT до источника и начинают отсылать трафик от источника к получателю. Т.к. spt-treshhold стоит по умолчанию, то SPT сразу же разваливается. По какой-то причине последующие joinы от приемника не могут быть обработаны должным образом - т.е. не проходят по цепочке маршрутизаторов. Тогда - в соответствии с таймером на такие случаи - multicast идет 3 минуты после чего прунится - таблица mroute чистится от (S,G) маршрутов. После этого следующий Join от приемника инициирует весь процесс заново - снова строится SPT, multicast снова идёт итп. Причину проблемы по приведенным данным трудно диагностировать. Можно попробовать поставить infinity для spt-treshhold. Если в этом случае multicast будет нормально работать, значит надо смотреть маршрутизацию - RPF-то не кажет соседа.

Конечно. Иначе оно бы и без, и с, таймером бы не работало. Команды `show ip route 192.168.15.123`, `show ip pim rp` на раутерах что показывают? И еще, как настроен spt-treshhold ?

RPF nbr 0.0.0.0 Все маршрутизаторы знают маршрут до источника 192.168.15.123 ?

Хм, это пожалуй повод открыть кейс в Cisco TAC.

Повключать "Block the flow" для всех rules в Unknown Subscriber Package - может даст желаемый эффект? Сразу говорю, я не пробовал :)

Со слов инженеров вендора: это ограничение чисто "бумажное", ограничений на реальные абонентские сессии не накладывается. Суть лицензирования сугубо денежная - подразумевается, что вы как честный покупатель отслеживаете сколько трафика приходится на одного абонента и приобретаете соответствующие лицензии. Эта честность в дальнейшем пригодится при общении с саппортом, который честному покупателю не откажет в поддержке, а нечестному - может законно отказать. Как-то так.

Memory leaks? Память мониторите?

если вы про virtual-template/virtual-access - то да. Уточнение: работает, но не саппортится.

Маршрут до источников multicast имеется? И что кажет sh ip mroute ?

PIM включен на интерфейсах? Маршрут до источников multicast имеется?

А немного подробней не расскажете? Сколько сессий шейпите? Какая загрузка CPU/PXF? Сколько трафика бежит через железку? Если не можете сказать точные цифры, то хотя бы порядок. Давно уже не шейпим. Шейпили на нескольких тысячах сессий с соответствующим трафиком - сотни mbps или единицы gbps. Сейчас уж не упомнишь.

10k с pre3 и pre4 шейпит нормально. Про pre2 нечего сказать.

Удобно, что освещение комбинировнное - общее + местное. И помещение хорошо освещено, и внутренности шкафа, не придётся в шкаф головой соваться, чтобы надпись на наклейке прочитать. Охлаждение судя по фотке тоже весьма неплохое - вместо системы "холодный-горячий коридор" применено боковое охлаждение-теплоотвод внутри шкафов. Это поэффективнее холодного коридора будет, для заявленных уровней потребления каждой стойкой это наиболее подходящий рецепт.

что это даст клиентам, у которых подняты PPPoE-сессии на RB? я поясню: когда в влане один RB, он нормально работает. и с киской тоже нормально работает. киска с ним не работает, RB ей гадит! так вот, задача стоит заставить RB и киску предоставлять сервис клиентам в одном влане. В этом случае будут созданы условия, при которых RB неоткуда будет "узнавать" MAC-адрес c7301. PPPoE кадры от cisco к нему приходить не будут. Трафик PPPoE-сессии установленной между клиентом и cisco, если нет проблем на коммутаторе, тоже не будет проходить на порт RB. Возможны проблемы на коммутаторе, например, переполнение кеша MAC адресов, тогда трафик установленной PPPoE сессии может попадать на порт RB, и тогда RB "увидит" MAC-адрес Cisco. Но в нормальной ситуации у RB не будет нужной информации для генерации PADT-кадров c src MAC cisco.