Archville

Ну вот по поводу "смысла" это не ко мне. Ошибаются все включая разрабов и админов ТСПУ. Могли просто сказать, что "это не мы". Однако ж нет. А у них скорее всего работает. GGC билайновский жив и льется с него много. Да и из личного опыта техподдержка Большой Тройки-Четверки-Пятерки сильно сдала последнее время. Не удивлюсь, что им просто лень... Вы им тикет пробовали завести на эту тему?

Да как обычно в саппорт фризило уже на 720p. Сейчас 4к нормально едет. Я тут уже где-то писал по-моему, что IMHO не так страшен ТСПУ, как его малюют (пока, по крайней мере). Не знаю у кого как, но нам ни разу не отказывали ни в заведении тикета, ни в тестовом байпасе. Да, ребята, конечно не быстрые, но опять же в случае серьезной проблемы всегда звонком можно ускоить, если как следует поныть им в трубку. Да и тикетов за полтора года эксплуатации было, наверное, штуки три.

Пока написали только: "Проверяйте" ТСПУ стоит на нашей сети. Байпас я бы увидел в логах.

Сегодня ТСПУшникам завел тикет. Ютуб починили без проблем.

Это плохо, вам в любом случае придется с этим разбираться. Если при каждом рассыпании вы будете искать человека, который вам это все починит.... Сами понимаете - фигня получится. Если модулятор подключить напрямую к порту, мимо 3750, видео на модуляторе появляется?

Модулятор отсылает IGMP Join? Если модулятор подключить напрямую к порту, мимо 3750, трафик идет?

Документация, по крайней мере, на 6730 доступна даже без регистрации. Вот специально зашел с "не засвеченного" браузера и первой ссылке в яндексе было вот это: https://support.huawei.com/enterprise/en/switches/cloudengine-s6730-s24x6q-pid-250538970 Все, что не под "замочком" открывается.

Хотел было расписать весь геморрой с ними, за 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.