Archville

Хотел было расписать весь геморрой с ними, за 15 лет эксплуатации сети из более чем сорока экземпляров этого говна, но не хочу портить себе пятницу. После переезда на huawei s6730, реально начал забывать что такое траблшутинг. Год аптайма, ни единого критичного нарекания.

Ну вообще, очень странно. Если у наших клиентов возникают проблемы с VPN (или с любой другой связностью), мы заводим тикет в дежурке ГРЧЦ. Обычно просим перевести в ТСПУ в байпас для диагностики, они без проблем это делают на час.Если подтверждается проблема, мы им передаем всю инфу (IPшники, протоколы, пинги, трассировки), и, если адреса не указаны в официальных списках блокировки, то они без проблем чинят. Вся канитель занимает часа три-четыре с момента возникновения тикета. Надо отдать должное, ТСПУ в байпас они переводят в течение 5-10 минут.

Вот плюсану за Huawei. На редкость неплохие коробки. А вот экстрим даже не вздумайте брать, хоть первого, хоть какого поколения.

А зачем в туннель анонсировать всю AS, туда ж надо только "серые" адреса анонсировать. Да в принципе и пофигу... "Белые" адреса пусть анонсируются агрегатами как и положено, главное на роутерах не забыть прописать маршруты на эти сети в null 0 с большой метрикой.

Поднять между "Источником кучи /32 префиксов" и ASBRYYYYY EBGP multi-hop сессию и гонять в ней всё, что угодно. А аплинкам отдавать только агрегаты. Как вариант.... Только вот трафик "серых" адресов придется тунелировать в любом случае. 1) на роутерах поднять два лупбэка, а внутри тунеля поднять какой-нибудь ospf/bgp/да даже статик, прикрытый BFD и сессию строить между лупбэками. 2) тунель строить не между ASBR+NAT`ами, а между "Источником кучи /32 префиксов" и ASBRYYYYY Или я что-то не понял?

@stscythe 1) проверьте батарейку CMOS. 2) запустите run diag ext и посмотрите что он скажет. 3) если все норм, попробуйте декирпичинг: https://extreme-networks.my.site.com/ExtrArticleDetail?an=000083135

@Умник Вот FRR на практике как раз и не особо нужен. Основной плюс TE для "небольшого" оператора заключается в возможности балансировки. Например: допустим, есть на магистральном сегменте LAG из четырех 10G между двумя P маршрутизаторами. Допустим есть услуга vpls с полосой 15G между некими двумя точками, трафик которого должен проходить через этот LAG. Если сигналинг будет LDP, и PE оборудование не поддерживает т.н. entropy label, то трафик этой услуги пойдет только по одному из портов этого LAG. RSVP-TE позволяет сделать несколько LSP (в нашем случае четыре), привязать эти LSP к этому VPLS и все транзитное оборудование будет балансировать этот трафик по транспортной метке. Да, понятно, что костыль, да, понятно, что "в 21 веке так сети не сторят", но данная фича позволяет выйти из нехорошей ситуации и дать недешевую услугу, за которую продажники, уверен, сетевикам горло будут грызть...

В данном случае никак. Либо наращивать отказоустойчивость между коммутаторами, либо отказываться от LAG, ставить третий коммутатор перед сервером и настраивать кольцевую отказоустойчивость - ERPS там или (M)RSTP, прости, Господи... Вообще, MLAG не очень подходит для Inter-DC отказоустойчивости. Если уж прямо надо совсем стильно-модно-молодежно, то надо творить какой-нибудь оверлей, а отказоустойчивость андерлея сделал бы, как обычно, на L3.

configure vman vm222 ports 31 delete cvid 1299 Не?

Друзья, прошу прощения, что "откапываю стюардессу"! Ни у кого, случаем, не завалялся вот этот файлик: scos-v420-b700-sce8000-k9.pkg? Буду весьма благодарен! Заранее скажу, что в этом топике есть ссылка на торрент, но в списке файлов этого торрента этого файлика нет. :(

А почему бы просто не сделать BGP со встречным оператором для поднятия блэкхолинга? Для этого не обязательно иметь "белый" номер AS. Уверен, ваш встречный оператор не будет против, т.к. он сам, на основании вашего же анонса также отправит в блэкхол этот трафик своим пирам и не будет его пережовывать.

В вашем случае спасет только внешний NAT. По поводу PBR, может и не потребуется. Есть коробки, которые делают прозрачно NAT (тут эти вендоры присутствуют ;) ).   и, кстати, попробуйте отPBRить трафик с белыми адресами на интерфейс, который не ip nat outside. Должно полегчать.

У вас кончились буферы на SIP`e. Это скорее всего из за NAT. Такое часто бывает, если через ip nat inside и ip nat outside бежит трафик НЕ ПОПАДАЮЩИЙ в вашем случае в SRCNAT access-list.

Покажите настройки NAT. И еще покажите в момент перегрузки sh platform hardware slot 0 plim buffer settings slot укажите соответственно тот, на котором перегрузка. и вот это: sh platform hardware qfp active datapath utilization

NAT есть? Особенно policy-based?