VPN

Не сталкивался с такими проблемами, на сети стоят сотни 2950 с уровнями в 200 pps. BPDU все же посылаются редко (раз в 2 секунды по умолчанию). Если их очень много, то уже есть шторм и тогда storm control срабатывает весьма закономерно. Может ли он в это время подрезать bpdu - да, конечно. Но рано или поздно хотя бы одна bpdu будет поймана и порт заблокируется с помощью STP. Пусть и не сразу.

Вот этот момент можете подробнее расписать? На порт навешиваете нечто вроде такого storm-control broadcast level pps 200 200 storm-control multicast level pps 200 200 тем самым ограничивая широковещательный и мультикаст трафик до 200 pps, что спасает в случае флуда от абон. устройств, петель и прочих неприятностей. Т.е. проблему оно не решает, но позволяет избавиться от последствий.

Эмм, а что Вам по портам надо? Просто не обязательно 4900M, есть еще 4948, 4500-X. И 4900M, кстати, довольно ходовая железка на б/у рынке, очень странно, что у нага ее нет. Порой цены на них 150-200к. Не очень понимаю, как 6500 может быть дешевле. По поводу питания - шасси с 720 супом и 6708 будет потреблять в районе 600Вт, а то и больше (если верить калькулятору циски). Ну а по поводу сроков - я не знаю от кого у Вас гарантия, но как-то долго выходит. Даже с ибея быстрее можно привезти. Но тем не менее, все зависит от желаний - хотите full view в этот период, на циске дешевле 6500 пожалуй не будет (исключая софтроутеры, конечно же). Если цель как-нибудь продержаться, то имхо Catalyst 4k куда более простое решение.

Инстанс STP появляется только при создании влана. Т.е. у вас может быть включен STP для всех вланов, но инстансы будут только для созданных активных вланов. А по итогу у вас, например, есть vlan 1, который у вас native vlan на транке и при этом на нем STP отключен. У вас тогда никогда не сработает STP, можно его смело отключать при такой конфигурации, результат будет почти таким же. Если у вас подключен неуправляемый коммутатор, то петля должна обнаруживаться, если вышестоящий отправляет bpdu, но тогда они не должны быть отфильтрованы, как сделано у вас. Исключением будет являться проблема, когда широковещательный шторм привел к срыву крыши у коммутатора и он уже не в состоянии обработать BPDU, но такое, если и происходит, то редко. Вдобавок, никакой фильтрации броадкаста я у вас не наблюдаю (тот же шторм контроль на порту помог бы предостеречься не только от шторма из-за петли, но и по ряду других причин). Даже нескольких мегабит броадкаста хватает, чтобы уложить напрочь железку. А по процессору - как вы мониторите? Если вы снимаете snmp, то вы можете снимать его достаточно редко, да и у вас коммутатор недоступен в момент проблемы.

А можно ссылочку, где можно почитать, что это выполняется в софте? У меня почему-то всегда было впечатление, что acl все равно выполнялся на уровня железа. Ведь CoPP тоже может содержать в конфигураци разного рода acl.

Откровенно сказать, у вас в конфиге наворочена каша. Зачем вы отключаете STP? У вас по факту не работает STP в вланах 1, 21-22. Далее у вас на портах доступа включен BPDU filter, т.е. петли на этих портах не ловятся. Если кабель коротнет, то вся надежда на keepalive, который по дефолту проверяет раз в 10 секунд, если мне память не изменяет. Это достаточно ненадежный способ. Либо стоит подправить таймер keepalive, либо воспользоваться BPDU Guard на портах доступа. Выпадать коммутатор может как раз из-за широковещательного шторма, спровоцированного петлей. Я бы навел порядок в конфиге и логировал события stp, после этого уже смотрел бы дальше, если проблема не решится.

Если просто закрыть доступ к SNMP/SSH/Telnet/NTP, то это делается соответствующими командами для каждой фичи. SSH/Telnet - в line vty указывается access-group, SNMP при указании community можно прикрепить acl и т.д. В принципе CoPP позволит, наверное, добиться того же, только он посложнее и может иметь вагон примечаний специфичных для платформы. Но и решает куда более широкие задачи.

Если вы хотите зарезервировать бордер в холодном режиме, то я вообще не очень понимаю, зачем вам 6500. Вам и Catalyst 4k почти любой подойдет. Приняли дефолты или partial view + IX (если там около 100к), в той же 4900M прекрасно уживется, только ценник более разумный, по электричеству ест в разы меньше. Но это если вы ее держите на пару недель в случае выхода mx80 из строя и ожидания прихода замены оного.

А кто-нибудь NAT у себя развернул? Может кто поделится впечатлениями? Как производительность, баги и т.д.

Приветствую! На каких коммутаторах Cisco Catalyst можно поменять MAC-адрес на SVI или на Port-Channel? Я так понимаю только на 6500? Особенно, интересует 4500-x, но если кто-то может подсказать какие-то другие (Catalyst 3k/4k в первую очередь) - буду благодарен. Для пытливых умов - это для того, чтобы сделать петлю между двумя интерфейсами в разных vrf. :) Заранее благодарен.

А на 6509 как группировать трафик по слотам? А разве имеет значение какое шасси? Исключение по-моему только одно - 6513, там не все модули подключаются двойными соединениями к фабрике.

Это с линейными картами с DFC? Т.е. проблемы не связаны с перегрузкой шины или чего-то в таком духе? До корня проблемы не получилось докопаться?

если используется много портов, например все 8, - группировать так что бы ingress и egress порты для основных потоков трафика были в одних и тех же группах портов (1,4,5,7 и 2,3,6,8) . Так же, не допускать что бы подгруппы портов 1/4, 5/7, 2/3, 6/8 в сумме имели больше 16 Gbps full duplex Меня больше 6708 интересует, в 6704 смысла не вижу (буферы + отсутствие dfc по дефолту и куча жалоб на дропы от страждущих). Поправьте меня, если я неправильно понимаю, пожалуйста. Я вроде не тупой, но тут уже подвисаю, хочется до конца осознать все, чтобы не поймать в будущем веселых сюрпризов. Сразу оговорюсь, что под Full Duplex я подразумеваю, когда мы имеем указанную пропускную способность одновременно в двух направлениях. Т.е. когда мы говорим о 16Gbps full duplex подразумеваем, что это 16 в две стороны или маркетинговых 32Гбит/с. Ниже все цифры буду приводить подразумевая full duplex. Итак, имеем 2 FIRE ASIC, каждый из которых подключен к фабрике по 20 Гбит/с соединению, а также к FGPA Mux двумя каналами по 16 Гбит/с. Т.е. получается 32Гбит/с на один FIRE ASIC. Что означает, что 4 порта, находящихся в одной группе в теории могут обмениваться данными на 32Гбит/с, но с другими портами (в том числе, и внутри этой же линейной карты) могут обмениваться только на скорости 20Гбит/с (ведь никаких связей между группами портов внутри линейки нет?). Таким образом, я могу включить 4 порта, которые шлют трафик только между собой в одну группу портов и получить переподписку 1:1,25. Но только с одним исключением, каждое подключение 16 Гбит/с дается на два порта в отдельности. Таким образом, идеальная схема это включение двух групп по 2 порта между которыми бежит трафик по 16Гбит/с. Ну а если нам нужно пойти на фабрику, то лишь 20Гбит/с из 32Гбит/с пролезут туда, оставляя 12 Гбит/с для локальной коммутации. Верно? Для такого кейса порты были в рамках одного fpga, но потом ушли на сплитеры, так как mirroring на c6500 это гибель полная. А можно поподробней про проблему с mirroring? А то очень многие жалуются, что все очень плохо, тут есть мысли перейти на 6500 и там понадобиться mirror, причем, скорее всего с policy map на выходе, поэтому, было бы интересно послушать про грабли.

Спасибо за схему. Ну вот у меня остается сомнение. Исходя из нее получается, что таки 40G достижимо на линейке, а 32 это между определенными группами портов. Сомнение, что не указано - эти 32 это маркетинговые 32 (т.е. 16) или нормальные (не умноженные на два). Т.к. если их умножили, то тогда 40 не очень получается, а только 32 с линейки можно снять.

А можно про это поподробней, пожалуйста? Т.е. те fpga, которые подключают группы по 2 порта и имеют пропускную способность якобы 16 Гбит/с на самом деле пропускают только 8 Гбит/с? Откуда ограничение в 32 Гбит/с берется?