shellsmith

Приобретал у Grand037 один маршрутизатор Cisco 7206 (25 000 рублей) - все прошло гладко. @vadimv2, к сведению.

Приобрел у Grand037 один маршрутизатор - все прошло гладко. Спасибо!

Если мне не изменяет память, ASIC передает в DFC только заголовки пакетов для осуществления lookup. Данные между ASIC передаются через фабрику. В случае WS-X6708-10GE это означает, что при нагрузке около 50% Вы упретесь либо в производительность каналов между FPGA и ASIC (2 x 16 Gbps), либо в производительность канала до фабрики (1 x 20 Gbps). К сожалению, мне не удалось найти подходящей картинки из авторитетных источников с пакет флоу между двумя портами 6708 с разных ASIC. Если у кого-то есть контр-примеры - буду очень признателен... Польза от переподписки, на мой взгляд, только в том, что используя WS-6708 можно агрегировать относительно много портов, где гигабита уже мало, а до 10 ГБит еще как до Луны. Как только появляются требования к нагрузке - два порта на левый асик, два порта на правый асик - вуаля, мы получили 6704 с большими пакетными буферами.

Судя по пиковой утилизации fabric channel, перегрузка возникает на одном или нескольких из FPGA. Можно сесть с карандашиком, нарисовать потоки трафика и подсчитать загрузку всех групп. Потом жонглировать портами, чтобы распределить трафик более равномерно. Большого профита от перемещения всех линков etherchannel в один модуль не будет. От etherchannel с нечетным количеством портов лучше избавиться - нагрузка распределяется неравномерно, считать неудобно. В целом, присоединяюсь к предыдущим опраторам - отключать переподписку или подключать в эти модули только ненагруженные линки...

Сможет, по умолчанию она не принимает во внимание наличие метки 802.1q.

а у вас разве 8000? не 2000? Присоединяюсь к вопросу mcdemon. Есть у кого-то положительный опыт именно с SCE8000? Сталкивался (и не только я) с абсолютно аналогичной проблемой при обновлении SCE8000 до SCOS 3.8.0. Тогда пришлось откатываться на 3.7.5. Собирался на днях обновлять одну из имеющихся SCE, но теперь как-то не хочу спешить =)

SCABB_385PP33B23_SUS.spqi - Protocol Pack 33 Я тестил native IPv6, согласно документации вроде должно нормально обрабатываться...

Прошу прощения за некропостинг, но может кто-нибудь поделиться success story про IPv6 на SCE8000? Обновились до 3.8.5. SCE8000 работает (в отличие от 3.8.0, проблемы с которой обсуждались в соседних темах), но IPv6-трафик нормально не пропускает - если для сервиса применяется правило с маркировкой трафика DSCP, то SCE умудряется как-то искорежить трафик - данные не пролазят. При включении байпаса для IPv6 или отключения маркировки - все работает. Добавил в пекадж ограничение полосы для IPv6 (при помощи зон) - полоса не ограничивается. Есть ли жизнь на Марсе у кого-то положительный опыт?

На мой взгляд - еще хуже, чем на WS-X6704: (fabric asic) #show int Te7/1 capabilities | inc ASIC Ports-in-ASIC (Sub-port ASIC) : 1,4-5,7 (1) #show int Te7/2 capabilities | inc ASIC Ports-in-ASIC (Sub-port ASIC) : 2-3,6,8 (2) (FPGA pairs) ((1,4),(5,7)),((2,3),(6,8)) The inner pairs are 16Gbits. The quadruples are 20Gbits. Переподписка 2:1, при больших объемах трафика между портами - кошмар какой-то. Можно отключить 4 порта из 8, тогда будет несколько лучше.

Номер телефона однозначно идентифицирует пользователя хотспота. Что крайне актуально в свете нынешней ситуации с охотой на ведьм.

SM не использую. Пробовал убрать IPv6-трафик - не помогло.

Stranix1979, столкнулись с этой же проблемой при обновлении до 3.8.0. Сбой происходит при достижении какой-то критической отметки по трафику - ночью сразу после обновления все было ОК, первая перезагрузка произошла ближе к утру. Откатились обратно на 3.7.5, с ней таких проблем не было ни разу.

Абсолютно такую же картину наблюдали. Причем проблема проявляется при достижении критической отметки по трафику - обновили ночью, проблему зафиксировали утром. Если трафик убрать, то все ок.

Мне пресэйлы ненавязчиво предлагали пересмотреть модель предоставления услуги =) Сложилось впечатление, что производители брасов этот наш IPoE вообще как-то недолюбливают и пилят в последнюю очередь =) То ли дело старые добрые pppoe/l2tp и т.п. Тестил и внедрял ISG около года назад. С L3 все было грустно - либо вообще только один IP (SE100), либо непрерывная подсеть (Cisco ISG). L2 до BRAS, несмотря на наличие MPLS, не рассматривали - не было ни нужды, ни желания тащить весь трафик клиентов до браса. И с резервированием вопросы все равно будут. В нашем случае у большинства сабскрайберов были небольшие подсети. Внедрили ISG на 7200, закрыв большую часть потребностей. Немногочисленные частные случаи добивали персональными полиси-мапами на точках подключения. Найти более удачное решение не удалось. Надеюсь, вам повезет больше =)

mcdemon, насколько я понимаю, нужно использовать зоны. Зона представляет из себя список подсетей.

Служебные сервисы - динамическую маршрутизацию, логи, ssh, RP и т.п. - привязывают к Loopback-интерфейсам для того, чтобы не зависеть от физических линков. Если интерфейс Vlan8 потухнет, то сеть останется без RP, что в некоторых случаях может вызвать проблемы.

Subcriber Manager не потребуется. А тестирование подключения к СУБД из SCA BB нормально проходит?

Могу предположить, что без ключевого слова unnumbered маршруты не добавляются потому, что в обычной ситуации не имеет смысла - зачем нужен маршрут на connected-хост, когда подсеть уже приземлена на интерфейсе? Согласен с dwemer, скорее всего connected-маршрут на Loopback считается лучшим и маршрутизатор не может определить, за каким интерфейсом находится подсеть. Думаю, в Вашей схеме проще всего включить на интерфейсах Unnumbered и скриптом генерировать статические маршруты на клиентов со статической адресацией. Мы вполне успешно применяли такой подход до тех пор, пока не понадобилось изолировать клиентов в VRF - внутри VRF нельзя вручную прописать статический маршрут на интерфейс (по крайней мере, на 6500 =)). Теперь для частных клиентов используем только DHCP, клиент всегда получает один и тот же IP.