Phsm

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

Да, но только AGG1 заблокирует один из своих портов: STP BPDU фреймы пройдут через acc1, acc2, попадут на второй порт aggr1, и тем самым заставят его перевести в состояние blocked. Если это то что Вам нужно. Перевести в blocked линк который у Вас помечен как reserv, в случае тупариков access1/2, не получится.

Отправил в личку 😏 Вообще этим жлобством на прошивки мне всегда экстримы не нравились.

#!/bin/sh LOCALFOLDER="/home/vasya" REMOTEFOLDER="/home/vaysa" REMOTESERVER="10.0.0.1" REMOTEUSER="vasya" PRIVKEY="/path/to/privkey" EMAIL="aa@bb.com" localspace=`du -s $LOCALFOLDER | cut -d' ' -f1` function get_remotespace () { space_str=`ssh -i $PRIVKEY $REMOTEUSER@$REMOTESERVER du -s $REMOTEFOLDER` if [ $? -ne 0 ] then echo "Error connecting to remote server" exit 1 fi space = `echo $space_str | cut -d' ' -f1` return space } remspace=get_remotespace if [ $remspace -gt $localspace ] then echo "ALARM ALARM" | mail -s "Achtung" $EMAIL fi

Плюсую OTRS. Несмотря на то что написана на перле, настраивается странновато, но очень удобная и достаточно надёжная вещь. 5 лет пользуемся, пережили миграцию по мажорным версиям 3 -> 4 -> 5, всё работает.

Костыльно, потому что это не рекомендуемый и не лучший способ решения задачи балансировки трафика по линкам. Это как строить сеть на тупых свичах: выполняют ли они задачу коммутации трафика? Выполняют, всё работает же. Но чуть что - куча нерешаемых проблем.

Согласно https://www.kernel.org/doc/Documentation/networking/bonding.txt это очень костыльная вещь в плане балансировки получаемого трафика: "This is handled by sending updates (ARP Replies) to all the peers with their individually assigned hardware address such that the traffic is redistributed." Похоже что оно шлёт каждому соседу по сети arp reply с маком того или иного "плеча", чтобы балансировать входящий трафик по ним. Лучше LACP или статическую агрегацию поднять, сейчас все свитчи ее умеют.

Не получилось найти что говорит джунипер по этому поводу, только косвенно здесь: https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/routing-edit-system-processes.html Если Вы поставили 64-битную версию junos: в автоматическом режиме выбора бинаря rpd используется 32-битный, если в системе меньше 16 гигов оперативы. Если больше - используется 64-битный. Но это в случае: 1. если уже установлена 64-битная ОС 2. касается х86, т.к. похоже что все RE, для которых есть 64-битная прошивка именно на этой архитектуре.

ttttt, разделяю Вашу точку зрения насчет "программисты нынче не умеют нормально": не раз встречал таких вебдевов, которые обход массива не могут без jQuery сделать. Однако с другой стороны, это яркий пример "write less, do more", которое сейчас со всех сторон. Плохо и раздуто? Да, но с этим ничего не поделать, когда _все_ так делают.

Возможно, но Вы же не возьмётесь спорить что ограничения 32-битной платформы имеют место быть? Сомневаюсь что в PowerPC есть PAE, который позволяет на 32 битах заадресовать до 32 гигов рамы. Вот кстати в зарубежном мейллисте juniper-nsp на этот счет такое сообщение: The processor can only address 4G (3.8 or so actually) of ram with a 32 bit word size. So even if you get the re's running the 32 bit code they will only register 4G of the precious 16G.

Теоретически да: по спекам проца, который стоит в MX104 - он поддерживает толи 16, толи 32 гига оперативы. Хотя, с другой стороны - в PowerPC (на нём МХ80 и МХ104 крутятся) наверное MMU и проц разнесены, а не как в современных х86. Может быть такое что проц-то может и поддерживает, а MMU-нет.. Также стоит обратить внимание на прошивку, а точнее на разрядность файла rpd. С сайта непонятно, 32 или 64 битная прошивка под 104й. Если 32-битная, то смысла нет - сколько оперативы туда ни поставь, rpd сможет зааллокейтить себе только 2 гига памяти.

Топикстартеру: Если уж бросаться умными цитатами, я отвечу такой: "Не стоит множить сущности без необходимости". В данной ситуации: яваскрипт используют не потому что хотят вам повесить ноут, не потому что им наплевать на то как сайт будет работать у пользователей, даже наоборот - чтобы сделать удобнее своё веб-приложение более удобным. Нынче сложно разрабатывать веб-приложения без JS. Попробуйте, например, реализовать на чистом html список из двух дропдаунов: сначала в одном пользователь должен выбрать страну, а в другом - город из этой страны. Единственное решен

А ведь пациент не так уж и неправ. Во многих случаях такой "разветвитель" действительно будет работать, проверяли как-то в офисе - работало. Теоретически, если сетевухи старые, и помнят времена CSMA/CD, заработает. Запустится в полудуплексе и эта шина будет одним доменом коллизии, которые будут гаситься этим самым CSMA/CD.

Как-то у Вас форматирование вывода tcpdump поломалось. Можно косвенно. Например, слушать интерфейс на предмет входящего трафика не на мак-адрес вашего сервера. Таким образом будет ловиться весь BUM-трафик (Broadcast, Unknown unicast, Multicast) трафик- тот, которого должно быть чем меньше тем лучше: tcpdump -i eth0 -nn -e not ether host <мак-адрес сетевухи сервера> Впрочем я уверен что с тупыми свичами его будет много, и с этим ничего не поделать. В вашем случае выхлоп tcpdump слишком маленький чтобы сказать петля или флуд (скорее всего пет

В случае когда свитчи неуправляемые, единственное что остается - узнать на сервере мак, с которого идёт флуд: tcpdump -e -i eth0 -nn arp После этого выяснить клиента с этим маком, который флудит. Хотя по симптомами (огромные потери) - это кольцо в сети, а арп-флуд его следствие. В общем нормальное решение только управляемые свитчи с loopback detection.

А зачем вообще его перепрошивать?

Да это просто proxy-arp на циске провайдера включён. Но вопрос почему сам абонент делает arp-запросы на адреса 2.x.x.x так, будто считает что у него с этими адресами direct-сеть.

В первом видео невооруженным взглядом виден баттхёрт авторши. Видимо, ей этих замечаний много делали

Не знаю, это вам представители ua-ix должны рассказать. В Гиганете такой проблемы нет, во всяком случае у меня ютуб работает нормально и жалоб от участников не поступает.

Ну, это как раз киевская нода гугла + перегруженный стык гугл-uaix.

На протяжении последних нескольких дней периодически была проблема у Гугла - они перебрасывали клиентов на свою киевскую ноду (которая, полагаю, перегружена более чем полностью). Вчера к вечеру решили проблему с их noc-ом, повторений этого бага не должно быть.

Причем здесь оплата трафика? Я плачу за их мобильный интернет исправно. Они перехватывают коды ошибок самого сайта и показывают мне свою рекламу вместо того что на самом деле отдаёт сайт.

Да, вот от этого у меня тоже бомбит. Мало того - они перехватом кодов ошибок ломают возможность зайти на сайты за популярными анти-ддос сервисами, например Cloudflare: там используется код 503 на странице проверки, который они перехватывают и радостно рапортуют: "сайт не работает, но вы не расстраивайтесь - посмотрите нашу рекламу".

I find it disturbing that I cannot find many discussion about this. It's also obvious that this does not affect only a few users but that it's rather general. A simple ping from a remote location to 194.60.69.115 (www.lanet.ua) shows that RTTs are very unstable throughout the day. At around 10 p. m. local the RTT increase significantly and packets are dropping on a simple icmp ping. I suspect lanet.ua to voluntarily maintain congested links to avoid paying bandwidth. Anyone else reported this? I doubt in Lanet having overloaded uplinks. More likely there is a congestion somewhere

Кстати да. Если топикстартеру нужна работоспособность только одного мтс-номера, а инфраструктуры для ip-телефонии нет, то репитер будет лучшим решением.