Nik0n

Отсюда VLAN Группы VLAN: - 256 статических групп VLAN - 256 динамических групп VLAN 802.1Q Tagged VLAN GVRP

При включении порта (если на нем включен STP) рассылаеться Topology Change и свич его получив прекращает передачу пакетов (только принимает) в STP портах на время Forward Delay. Default Forward Delay зависит от протокола (STP, RSTP, MSTP).

Вы не геймер, вы сёрфер ;-)

Это же прекрасно, что работает. Но Вы опять считает только "железо", а работа по настройки все равно чего-то стоит. Даже если настраиваете тазик, уже с закрытыми глазами ;-) Но в первых раз Вы все РАВНО потратили значительное время. А бизнес в большинстве случаев выбирает что надо СЕЙЧАС деньги потратить (вложить), а не ждать когда кто-то там чему-то научиться. Поэтому я не против тазиков как таковых, но не всегда их можно применять. Можно, но в малом количестве случаев.

Ну тазик это конечно хорошо, но это если ты умеешь правильно выбрать железо и потом настроить и потом сопровождать и за зарплату штатного админа. А если нет такого, то конторе придется искать узкого спеца и возможно за высокие деньги. А относительно стандартное железо либо штатный админ освоит (который тазик возможно и не сможеть настроить), либо можно за меньшие деньги найти на стороне для решения стандартной задачи. Резюмируя. Решение с тазиком кажется только дешевым, но в последующее время может потребовать еще вложение, либо кто-то будет экспериментировать на живых абонентах ;-)

Ну дак это если CPU ОДИН, но у обсуждаемой железки их 36. И 100% это занято BGP процессом НА ОДНОМ CPU, а прерывания от портов обрабатываются ДРУГИМИ CPU и ни каких дропов.

Используем ДВА CCR1036-8G-2S+ уже полгода. Трафик суммарный (в час пик) на порт 1.5Гб/с на одном, 1.7Гб/с на другом. Выключен connection tracking. Есть [пока] три Queue Simple на трех интерфейсах. Работает исправно. На баги и глюки не нарывались. :) Используем как BGP роутер. Да конечно всегда один проц загружен на 100% и обновление маршрутов происходит не быстро (520 тыщ. минут за 10 при одновремменном старте двух FV пиров). От начальных blackhole (при холодном старте) спасает default от одного из пиров ;-) Так что имменно как бордер использовать МОЖНО! ЗЫ Железок которые могут и шейпить и натить и роутить до 5к юзеров за адекватные деньги ИМХО нет. Всегда найдется узкое место, либо ограничение. Тут только разделение труда :)

Мы это сделали сразу на этапе развертывания в далеком 2009 году. И не пожалели :) Меняли ядро, меняли магистрали (что бы 10G бьло), ставли аппартные BRAS - но ip unnumbered не изменяли ;-) Правда ни как можем победить "умных" юриков. Они хотят статический IP. Мы конечно же выдаем IP всегда один и тот же. Но им видимо ссыкотно, что IP может измениться и всякие клиент-банки, тунели и т.п. перестанут работать.

Есть конечно и оно работает - привязки IP - MAC востанавливаються при рестаре. Но при ip unnumbered свичу нужно еще прописывать маршруты (VLAN) до конкретного IP. А эта инфра НЕ ВОСТАНАВЛИВАЕТЬСЯ при загруке лиз с FTP. К сожалению, наш случай :( Поэтому следим за хорошим питанием циски и забываем команду reload ;-)

Добрый день! И личного опыта. CCR1036-8G-2S+ - 2 шт (version: 6.33.3). Настроены как BGP border, плюс по две L3 сети (IPOE) терминируються на них (мимо браса). Настроена по две simple queue на каждом. Выключен connection tracking. На одном по небходимости включал временно - все работало, но нагрузка на CPU выросла в два раза с 7 до 15 %. Запустили в работу с полоной нагрузкой их еще 25 декабря 2015 (знаю что под НГ "ни чего не трогаем", но слекга рискнули) 2 января рестартовал для включения IPv6 модуля, для будующих экспермиентов :). Первый один раз рестовал сам из-за долго выполнения команды типа /ip route print where 1.2.3.4 in dst-address. У них на каждом по 2.5М маршрутов в таблице !! Команды на изменение статических маршрутов выполняються по 3-4 секунды. Второй работает без проблем. На каждом нагрузка на CPU не превыаешь 10%, при трафике примерно по 1.2Гбит/1.4Гбит на каждом. Включены пока одним 10г портом. Но ВСЕГДА на каждом один случайный CPU загружен на 100% и полное обвноление RIB таблицы после рестарта какого-нибудь пира может занят 10 минут. Видимо у них один всего CPU обрабатывает BGP, а он для этого слабый :( В принципе довольны, т.к мы теперь можем не резать принимаемую FullView таблицу.

судя по описанию, вполне адекватный вариант. У кого-нибудь есть реальный опыт эксплуатации? 3 года отличной работы ядром сети, без нареканий. Cisco она есть Cisco ;-) Но как просто L2(+)-свич это больно жирно. Она может больше!

Добрый день! Тему прочитал, но все равно осталься вопрос в совместимости xSTP протоколов Cisco и D-Link . В стенде работают все варианты MSTP + RSTP(rapid-pvst) на любых свичах, даже с MSTP c двумя регионами. Собирал Cisco 3550-12G, Cisco 4507R (V-GE10), D-Link 3420 в кольцо. В реальной сети топология сложная (получаеться где-то 4 совмещеных кольца), но в узлах магистралей только D-Link 3420 (9 штук) и одна Cisco (root), другая Сisco просто в цепочке между D-Link. На обоих Cisco IOS не старше двух лет. С независимыми кольцами (все идут в один D-Link) все просто (Restricted TCN/Role и fbpdu enable т.п.). Выбираю между: 1) Везде MSTP - только 0 инстанс 2) Cisco rapid-pvst только для 1 VLAN, D-link RSTP Склоняюс к первому, но уже было два неудачных запуска кольца MSTP на всех свичах, правда в конфигурации были еще 3 MSTP инстанса. Сейчас решили убрать их (пожертвовать балансировкой, главное надежность). И все так же какой вариант самый надежный (без балансировки)? Какие могут быть проблемы при втором варинате ?

У меня почти 3FV (Реально 2 аплинка FV + локальные пирринги) Entry Type Count Memory Network 527433 44645824 Path 1479561 53264196 #sh memory Memory: Total 802716k, Used 734508k, Free 31720k, Reserved 24k 3 дня назад, сразу после последнего аварийного рестарте коробки руками, когда bgp процесс умер из-за недостатка памяти, рестартовал (причем два раза), но не захотел поднимать все peer (они застряли в состоянии Idle и были так 9 часов) Free было около 70000к - теперь вот 31000к, я так понимаю аккуратно к НГ еще раз грохнется :( subscribers (IPOE, non-dhcp) пока около 70 (подопытные)

L3-Connected DCLIPS (настроена non-DHCP service policy) Трафик идет нормально, первым делом проверял traceroute c/на клиента. В хопах видны IP интерфейсов context-ов SE100. Подтверждением этого является то что повешенная qos policy на pvc выходящий в паблик интернет ограничивает согласно настройкам policy. Так же проверял зеркалирование VLAN между L3 ядром(cisco) и SE100 в порт - трафик идет только там. UPDATE:Собрал схему еще раз, проверил маршруты, перестал передавать параметры qos через VSA 196 (указал policy в subscriber default) - ЗАРАБОТАЛО.

продолжил собирать проблемы :( Subscriber авторизуется через RADIUS который возвращает настройки QoS через VSA 196. show subscriber active username и show qos username показывают что параметры применены: НО трафик в сторону клиента идет без ограничений (300-330 мбит/с, мерял из speedtest.net), от клиента видимо упирается в шейпер на старом брасе (он +border) в 30мбит/с

сессия не обрывалась и самое удивительное сейчас sh ip route subscriber в поле UpTime показывает пусто и соответственно маршрут в другом контексте держится постоянный (sh ip route поле UpTime уже больше часа) делал debug isis redistribution видел что маршрут добавляется и удаляется, но это следствие. А каким debug можно посмотреть описываемую проблему? Update: Нашел почему последний раз заработало - я добавил в isis инстансе redistribution ospf (анонсит сети которые больше subscriber ) и все стало корректно :)

Еще проблема с анонсом subscriber между контекстами. Когда subscriber становится активным то в таблице маршрутизации появляется запись: # sh ip route subscriber Type Network Next Hop Dist Metric UpTime Interface > SUB A XXX.XX.224.9/32 XXX.XX.224.9 15 0 00:00:09 Loopback1 Так вот UpTime не доходит до более чем 10 секунд и потом несколько секунд это поле вообще пустое. Затем цикл повторяется (UpTime бежит от 0 до 10, далее пусто 2 секунды). В результате redistribution через isis каждые 10 секунд прерывается на 2-3 секунды (пока поле UpTime пустое). Что это такое и как этого избежать ?

Непроверенная идея: В конфигурации BGP для neighbor использовать update-source Сам IP на интерфейсе зарезервировать через VRRP на разных SE100 Вопрос: а не будет ли SE100 сыпать в логи ошибки из context backup на неактивном интерфейсе?

Интересная вот особенность :) СПАСИБО! PS IS-IS маршрутизацию поднял через intercontext интерфейсы по примеру из мануала.

Добрый день! Не получается настроить intercontext interface. Настройки делаю но не работает вот это. context ipoe ! interface ipoe2bgp intercontext lan 1 ip address AAA.BBB.228.57/30 [ipoe]BRAS1#sh ip int br Fri Nov 28 15:45:04 2014 Name Address MTU State Bindings ipoe2bgp AAA.BBB.228.57/30 1500 Up (inter-cxt-lan) context bgp ! interface bgp2ipoe intercontext lan 1 ip address AAA.BBB.228.58/30 [bgp]BRAS1#sh ip int br Fri Nov 28 15:44:17 2014 Name Address MTU State Bindings bgp2ipoe AAA.BBB.228.58/30 1500 Up (inter-cxt-lan) [ipoe]BRAS1#ping AAA.BBB.228.58 PING AAA.BBB.228.58 (AAA.BBB.228.58): source AAA.BBB.228.57, 36 data bytes, timeout is 1 second ..... ----AAA.BBB.228.58 PING Statistics---- 5 packets transmitted, 0 packets received, 100.0% packet loss [bgp]BRAS1#ping AAA.BBB.228.57 PING AAA.BBB.228.57 (AAA.BBB.228.57): source AAA.BBB.228.58, 36 data bytes, timeout is 1 second ..... ----AAA.BBB.228.57 PING Statistics---- 5 packets transmitted, 0 packets received, 100.0% packet loss Пробовал intercontext p2p 1 (в обоих context) - результат такой же, не пингуеться ;-( Что я делаю не так ??? PS SE100, SEOS-12.1.1.8-Release

РЕШЕНО! Я не туда копал ;-) Надо сменить distance у OSPF маршрутов. Static убрать. router ospf 101 distance external 14 И сразу становиться вот так: Type Network Next Hop Dist Metric UpTime Interface > S 0.0.0.0/0 1 0 1d06h > O E2 CC.DDD.249.0/24 AAA.BBB.228.65 14 20 00:05:28 IPOE-User3 > SUB A CC.DDD.249.11/32 CC.DDD.249.11 15 0 07:36:11 Loopback8 Работает. Спасибо всем :)

Дак понятно почему пропадает! У "connected" маршрутов metric = 0 , у static еще и Dist меньше чем у "connected" = 1 А у OSPF metric всего 20 и она перекрывается "connected" маршрутом А ну и да не понятно зачем вообще поднимается этот маршрут после активирования первого subscriber-а в сети: C 91.221.249.0/24 18 0 Loopback8 Не понятно как это побороть ??? Как у маршрутов через interface Loopback8 multibind увеличить metric и dist??? А как известно без multibind интерфейсов subscriber-ы не поднимутся :(

Добрый день! Есть SE100, схема обработки subscriber - non-dhcp clips service clips auto-detect context ipoe service-policy IPOE-Users При настройке залетел на ограничение LAG access ;-( [local]BRAS(config)#link-group CORE access [local]BRAS(config-link-group)#maximum-links 3 % maximum-links must be 2 for access type link-group with current PPA card [local]BRAS(config-link-group)# Убрал LAG для access, настроил просто 3 порта port ethernet 2/1 no shutdown medium-type copper encapsulation dot1q dot1q pvc 821 bind interface IPOE-User1 ipoe service clips auto-detect context ipoe service-policy IPOE-Users ! остальные 2 другие VLAN и interface На ядре настроил балансировку 0.0.0.0 маршрута через 3 IP (делал все в VRF) На SE100 так же через 3 IP для клиентской сети на ядро Залетел с тем что когда пакет с src клиента идет на разные порты, то SE100 генерирует разные clips id и соответственно RADIUS не дает SE100 поднять второй clips (читай вторую radius-сессию) т.к. IP занят от первой сессии. Покурил технологии от Cisco, понял что меня спасет PBR для привязки трафика клиента к next-hop (на ядре). Пока не настроил. Направил трафик пока через ОДИН маршрут. Решил за одним настроить OSPF для удобства анонса сетей и типа отказоустойчивости от условной потери порта. Опять залетел :( Маршруты ДО поднятия subscriber Type Network Next Hop Dist Metric UpTime Interface > S 0.0.0.0/0 1 0 21:01:46 > O E2 CC.DDD.249.0/24 AAA.BBB.228.65 110 20 00:00:04 IPOE-User3 > C AAA.BBB.228.64/30 0 0 20:21:32 IPOE-User3 Маршруты ПОСЛЕ поднятия subscriber > S 0.0.0.0/0 1 0 21:03:00 > C CC.DDD.249.0/24 18 0 00:00:05 Loopback8 > SUB A CC.DDD.249.11/32 CC.DDD.249.11 15 0 00:00:05 Loopback8 > C AAA.BBB.228.64/30 0 0 20:22:46 IPOE-User3 И усе, трафик не идет ;-( Добавляем маршрут РУКАМИ [ipoe]BRAS(config)#context ipoe [ipoe]BRAS(config-ctx)#ip route CC.DDD.249.0/24 AAA.BBB.228.65 [ipoe]BRAS(config-ctx)#end Cмотрим маршруты: > S 0.0.0.0/0 1 0 21:00:35 > S CC.DDD.249.0/24 AAA.BBB.228.65 1 0 11:14:49 IPOE-User3 > C AAA.BBB.228.64/30 0 0 20:20:21 IPOE-User3 Вауля! Трафик побежал. Проблема в том что metric маршрута из OSPF 20, и маршрут на miltibind интерфейс ПЕРЕКРЫВАЕТ маршрут из OSPF. Помогите люди добрые, кто знает есть варианты это побороть (перенастроить)???