Phsm

Не представник провайдера, але бачу що там є Радіосистеми: http://rs.net.ua/ua/internet/home/ Вони норм.

delete

Волшебные ключики, которые можно нагуглить в инете, не работают? service unsupported-transceiver EMC 677096c7 service unsupported-transceiver wiprolabs f5047577

Однозначно vlan per user: забудете про проблемы колец, флудов, клиентов воткнувших роутер кверху задом (и запустивших dhcp сервер в сеть) навсегда. Так же плюс в том что qinq нужен только на агрегации. На аксесс свиче qinq не нужен, только поддержка обычных VLAN. Если брас софтовый - можете посмотреть в сторону accel-ppp: у него отлично работает ipoe c qinq.

https://iperf.fr/iperf-servers.php вот еще Первый из списка работает: iperf3 -c bouygues.iperf.fr -p 9200 Connecting to host bouygues.iperf.fr, port 9200 [ 5] connected to 2001:860:deff:1000::2 port 9200 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 52.6 MBytes 442 Mbits/sec 0 5.35 MBytes [ 5] 1.00-2.00 sec 75.0 MBytes 629 Mbits/sec 0 5.35 MBytes [ 5] 2.00-3.00 sec 76.2 MBytes 640 Mbits/sec 0 5.35 MBytes [ 5] 3.00-4.00 sec 75.0 MBytes 629 Mbits/sec 0 5.35 MBytes [ 5] 4.00-5.00 sec 76.2 MBytes 640 Mbits/sec 0 5.35 MBytes [ 5] 5.00-6.00 sec 75.0 MBytes 629 Mbits/sec 0 5.35 MBytes [ 5] 6.00-7.00 sec 75.0 MBytes 629 Mbits/sec 0 5.35 MBytes [ 5] 7.00-8.00 sec 75.0 MBytes 629 Mbits/sec 0 5.35 MBytes [ 5] 8.00-9.00 sec 76.2 MBytes 640 Mbits/sec 0 5.35 MBytes [ 5] 9.00-10.00 sec 75.0 MBytes 629 Mbits/sec 0 5.35 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 731 MBytes 614 Mbits/sec 0 sender [ 5] 0.00-10.04 sec 731 MBytes 611 Mbits/sec receiver

https://iperf.cc/

Если нокер так делает, то значит он сломался. Его нужно выкинуть на мороз, и нанять нового. Потому что одна из его обязанностей - решать проблемы со связностью. Глобальный роутинг устроен так, что твои проблемы со связностью могут быть вызваны другим оператором. И наоборот: проблемы связности других могут быть вызваны тобой. Поэтому посылание тикетов друг другу между разными операторами это нормальная практика. И с этим я столкнулся в первую неделю работы в ноке. Да, как быстрофикс снятие проблемного анонса это правильное решение. Но за этим должно следовать письмо проблемному аплинку и исправление. Да, это извечная печалька Проявляется в любом железе/софте и крайне редко. Дело в том что анонсы в бгп не имеют никаких keepalive. Есть update - анонс пришел, есть withdraw - анонс ушел. Если withdraw каким-то образом теряется, то анонс будет висеть вечно, до флапа сессии. Додумываются. Причем гораздо чаще чем Вы можете себе представить Как правило это всплывает когда включают второй аплинк (точку обмена, например), а потом звонят этой точке обмена и скандалят что вы нам всё сломали - только вас включаем, всё падает. Ужасная история, правда. Даже верится с трудом. Нет, я не говорю что Вы врёте, просто сложно поверить что так могло быть.

На самом деле может быть множество причин по которым оно глючит только через Гиганет, а у других нет. Вплоть до того что у вас/вашего апстрима бестпас установлен через другой аплинк, но входящий трафик прилетает с Гиганета, и при этом админ роутера подумал что reverse path forwarding это крутая штука, и его надо включить везде. Если я правильно понял, в основном проблема проявляется у тех кто клиенты клиентов гиганета, то есть напрямую не включены. Попробуйте написать на нок Гиганета с копией на вашего аплинка-участника, и сообща найдите в чем дело (и скорее всего удивитесь что Гиганет вообще оказался не причем, т.к. сложно налажать когда их зона ответственности - передать фреймы с одного мака на другой). В ноке не звери сидят, помогут. P.S. Я могу считаться заинтересованным лицом, т.к. раньше работал в Гиганете.

На самом деле если это просто хосты с кучей ipv6 адресов прям на eth0 то просто взять 1 из этих адресов и сделать его next-hop для всей подсети что он юзает. В таком случае джун просто будет слать все пакеты на мак этого хоста. А хост уже увидит "так это ж я" и ответит.

Похоже что пришло время роутить подсети на ipv6-адреса клиента, чтобы не использовать NDP. Чудес нет, и два ляма v6 адресов по L2 это точно не нормально (удивительно что джуник реально их выдержал). Я не думаю что у них там 50 тысяч уникальных хостов, скорее всего они все крутятся на паре сотен машин.

По идее как-то так: interfaces { lo0.0 { family inet { address 1.2.3.0/24; } } ae0.1 { vlan-id 1; family inet { unnumbered-address lo0.0; } } ae0.2 { vlan-id 2; family inet { unnumbered-address lo0.0; } } ae0.3 { vlan-id 3; family inet { unnumbered-address lo0.0; } } } routing-options { static { route 1.2.3.1/32 next-hop ae0.1; route 1.2.3.2/32 next-hop ae0.2; route 1.2.3.3/32 next-hop ae0.3; } } Клиент в влане 1 будет иметь адрес 1.2.3.1/24, в влане 2: 1.2.3.2/24 и т.п. Возможно немного неточно (пишу по памяти), но общая концепция такая.

К тому же если хостер очень крупный, у него соответственно крупные каналы, и он может пережить какое-то время 10G флуда на клиента за 300 рублей без финансовых потерь для себя. Но будьте уверены, если Вас будут досить 3 дня к ряду на скорости 10G, то вам предложат рыночную цену за эти 10 гбит.

Вау, это прям совсем некропостинг, сообщение 2-летней давности Но что Вы имеете в виду? Любая точка обмена - это гигантский L2 домен в виду дизайна (просто вланы или же vpls - не важно): все роутеры-участники должны видеть друг друга напрямую. Есть множество методов по противодействию: port-security, storm-control, acl-и фильтрующие левый броадкаст/мультикаст, всякие проприетарные протоколы типа экстримовского ELRP. Но иногда бывает что что-то проходит все ограничения и все же прилетает в сеть.

да в общем-то всё можно, если транзакции не нужны

по сабжу, железу, не подскажу, но если у вас логи и прочая статистика, то сгружайте в clickhouse. Не мучайте бедный мускуль, кликхаус вам и сожмет, и выборка из этих лярдов строк будет за доли секунды

Зашел в тред ожидая увидеть этот вопрос Кстати действительно, что ж там такого огромного на 300 гигов?

Очевидный Cacti? Правда придётся на него совсем переехать, и больше не собирать данные mrtg. Но если уж переезжать, то уж на модные молодежные prometheus/victoria metrics + snmp_exporter + grafana

По правильному возможно так как Вы сказали, но в Гиганете все же 0:NN или 1:NN (в джуниперах, кажется, 0 не поддерживается). Хотя конечно large communities гораздо удобнее в этом плане, т.к. ext. community заграбастал себе mpls и теперь они идут бок о бок в сетевом железе.

199524 и 199995 не влазят в 16-битное поле коммьюнити (0-65535). Вы, похоже, используете Large community, что мало где еще поддерживается. Попробуйте использовать extended community target:0:199524 или target:1:199524, эффект тот же.

Повесьте ingress ACL на порты, которые смотрят в сторону абонентов, который блочит пакеты UDP source port 67

Это VIM1, на х650 если мне не изменяет память нужны VIM2

Лучше его вернуть вообще. Это старая железка, огромная, жрущая, не поддерживаемая самим экстримом уже давным-давно (версия Exos 15.3 на нее последняя) Эти 24х10г порта можно купить гораздо дешевле, взяв тот же TurboIron 24x

Экстримы х650 не работают без VIM (который может быть или 40г плата или модуль стэкирования). Если его вытащить - свитч не запустится. Да, это тупо.

Не думал что б/у циски 10/40г стоят так дешево. Еще вариант - juniper qfx5100, правда он сильно дороже, даже б/у

Не разбираюсь в MPD, но полагаю что явно нужно указать тайм-аут для LCP-пингов: set link keep-alive seconds max This command enables the sending of LCP echo packets on the link. The first echo packet is sent after seconds seconds of quiet time (i.e., no frames received from the peer on that link). After seconds more seconds, another echo request is sent. If after max seconds of doing this no echo reply has been received yet, the link is brought down. If seconds is zero, echo packets are disabled. The default values are five second intervals with a maximum no-reply time of fourty. Скорее всего раньше это было неявно указано в MPD, а теперь по умолчанию выключено. Например для пингов раз в 30 сек и отключения по неактивности через 1.5 минуты: set link-keepalive 30 90