mikezzzz

cef использует tcam

коллеги, спасибо, я вас понял. подозревал, что типовых решений нет. сейчас работаю в сторону freeradius-dhcp, похоже, что все хотелки (load-balance/failover) реализуемы.

а что за девайсина? может полисер у апстрима суровый?

Привет, как у кого реализовано резервирование брасов под ISG? Схема типовая: 1) cisco asr1k 2) куча VLAN в сторону абонентов 3) все VLAN с ip unnumbered loopback 4) ip subscriber l2-connected + unclassified mac 5) freeradius dhcp + ip helper address не могу сообразить как поставить рядом второй брас, так что бы происходил failover в случае аварии одного из них? все упирается в то, что Gateway полученный клиентом умирает, а arp-запись у клиента остается - связи нет без переподключения или до протухания DHCP lease. glbp/hsrp/vrrp с unnumbered не дружат.

да я понял :) наш "зверь" )) System image file is "disk0:/c7200p-advipservicesk9-mz.152-4.S5.bin" Cisco 7201 (c7201) processor (revision B) with 917504K/65536K bytes of memory. сдается мне иос нарезает так, обновиться, не? вроде в 15 версии под BGP стало ощутимо больше уходить памяти

show start | i memory ?

по этому написано в кавычках ;)

под "энтузиастами" имею ввиду людей, занимающихся аутсорсом дополнительно к основному источнику дохода, в лс скинул чем занимаюсь сейчас

aruba (HP) умеет вроде, я так понимаю при использовании подавления идет спуфинг src mac, то есть вы увидите только маки своих точек, не более. тут интересный тред есть с предложениями по поиску - причина оказалась в кривых руках :)

нахожусь в Ижевске, возможны командировки в свободное от основной работы время :)

Работаю в "местечковом" провайдере на позиции сетевого инженера. Есть разные бумажки от одного "индийского вендора" сетевого оборудования и знания/опыт от множества других. Опыт удаленной работы имеется. Ищу доп. заработок/опыт на постоянной/разовой основе в области сис. администрирования в целом, готов присоединиться к группе таких же "энтузиастов" со "схожими интересами" :). Пишите прям в ЛС.

может быть дело в настройке FWSM? петляет трафик внутри коробки?

не совсем понятно какая связь между максимальной pps и загрузкой некоторых интерфейсов фабрик..

получается, что не наоборот Q. Will there be a performance hit on the FWSM with the no monitor session servicemodule command? A. The span session is required on the FWSM because of a hardware limitation of an ASIC for traffic replication. FWSM needs an ASIC for packet replication and the span session passes the packets to switch for that using the span session. Traffic affected by this command is Distributed EtherChannel, Multicast and GRE. It is recommended to have the span session configured and not to remove it. у FWSM вроде должен быть backplane etherchannel, глянуть бы его счетчики по пакетам - show interfaces port-channel ххх counters etherchannel

при чем тут год? там написаны релизы в которых пофикшена, вашего я там в списке не увидел..

первой строкой в гугле = http://rejohn.cuar.es/2014/08/10/high-memory-utilization-due-to-hulc-flash/ CSCth60511 and CSCua52463

рад, что нашли в чем затык к сожалению, их нежелание расширить TCAM под FIB (Up to 1024K (IPv4) Up to 512K (IPv6) убивает весь интерес к данным продуктам.

почти, только учтите, что есть ingess SPAN, а есть egress SPAN. Второй гораздо опаснее, так как без включения опции monitor session egress replication-mode distributed весь TX SPAN для аплинков будет проходить через Supervisor, а потом возвращаться обратно на модуль, где mirror порты (:sick:). При Distributed egress трафик, попадающий в категорию TX SPAN, будет реплицироваться непосредственно на принимающей плате, то есть на входе в 6500 и так же может засрать Вам фабрику. Имхо, правильнее и более предсказуемо для вас и железки будет RX аплинков принимать и отдавать по предложенной вами схеме, а TX аплинков рассматривать как RX даунлинков и по вашей же схеме разгребать на соседнем модуле. При таком раскладе distributed egerss можно и не включать.

я конечно может плохо помню, но пакеты адресованные в RP (весь роутинг,ICMP и прочий "мусор", который надо обработать непосредственно 6500) пойдут все же через фабрику непосредственно до Supervisor MSFC, то есть fabric channel до Супа не стоит забивать трафиком. Я бы перенес SPAN на линейную карту от греха.

artplanet два вопроса: 1) вы когда ддос моделировали, зловредный трафик так же зеркалировался через SPAN или это был VLAN отличный от 2 - 3 , 5 , 28 , 102 , 208 - 210 ,603 rx ? 2) есть возможность отключить SPAN на какое-то время? потери до самой железки можно объяснить кучей SPAN трафика и перегрузом на Egress канала фабрики до супервизора

покажите еще show platform hardware capacity rewrite-engine performance

вот еще интересная тема - http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/200089-Troubleshoot-Interface-Overrun-caused-by.html

прикольно, а тут чего? show monitor | b Egress show platform hardware capacity rewrite-engine drop show fabric errors show fabric drop

значит я Вас не понял. Нет не стоит - не строим. Сейчас погуглим что это и попробуем поднять (config)#control-plane (config-cp)#? Control Plane configuration commands: exit Exit from control-plane configuration mode no Negate or set default values of a command service-policy Configure QOS Service Policy (config-cp)#service-policy input PBR-PROTECT Policy PBR-PROTECT does not exist error: failed to install policy map PBR-PROTECT у нас же не шейпер - а просто PBR я понял, просто думал может у вас настроена CoPP и какой-то трафик уходил на CPU, где и подыхал, но раз CoPP нет и роста CPU в момент DDoS не было - видимо не оно

только через кактус - но ошибки на порту не снимали. только unicast packet не совсем понял Вас, на 6500 настроена Control Plane Policy? графиков по полисерам для неё не строите?