throughtheether

Да, и по поводу временной недоступности - я бы проверил, какие еще изменения пришлись на тот коммит. Если никаких, то это, вероятно, следствие нюансов реализации import-политик (действия по умолчанию).

Я не специалист ни в OSPF, ни в JunOS, но полагаю следующее.
Фильтрация при помощи ключевого слова 'import' производится на не-ASBRах. В LSA-5 нет поля, указывающего, откуда префикс внесен в автономную систему OSPF. Мне трудно сказать, что и как у вас матчилось в вашем policy-statement. Я полагаю, при помощи ключевого слова 'import' имеет смысл фильтровать только по вхождению префикса в какие-либо списки. См. также:

OSPF import policy allows you to prevent external routes from being added to the routing tables of OSPF neighbors. The import policy does not impact the OSPF database.

Вашу задачу (вносить только статические маршруты в виде LSA-5) я бы решал так: на каждом ASBR, который занимается редистрибьюцией внешних префиксов в данную автономную систему OSPF, вот такую политику:

policy-statement static-2-OSPF {
        term 1 {
            from protocol static;
            then accept;
        }
    }

применил бы вот так:

protocols {
    ospf {
        export static-2-OSPF;
        ...
        }
    }

Проверил на Olive, работает.

В данном отрывке, насколько я понял, исходный текст XOR-ится с ключом, к результату добавляется префикс '#obfuscate:' и результат кодируется в base64.

Если на вход данному алгоритму дать 'iliahonz@gmail.com', то результат будет такой:
I29iZnVzY2F0ZTooAF0HDyoWEQELWQcOKVYILgE=
Есть мнение, что предоставленный вами шифротекст порожден или другим алгоритмом, или этим алгоритмом с другим ключом. Можете все исходники предоставить?

За последние несколько дней сильно просела скорость интернет соедниения у оператора Ростелеком, в десятки раз.

Что такое 'скорость интернет соединения'? Скорость среды? Канальная скорость? Скорость передачи данных из точки А в точку Б по такому-то протоколу?

Хотелось бы узнать, возможно ли каким-то образом мониторить нагруженность сети, как это возможно у других операторов, подключенных к различным точкам обмена траффиком.

Если даже вы узнаете загруженность аплинков какого-либо (говоря в общем, не о ростелекоме) оператора, для того, чтобы эти данные правильно истолковать, необходимо, в общем случае, знать коммерческую сторону его взаимоотношений с апстримами - кто кому какую 'полосу' предоставляет и на каких условиях. Не думаю, что эту информацию легко достать.

Если есть другие способы, самостоятельного мониторинга нагруженности - был бы рад узнать.

Если у вас упала скорость передачи данных по tcp на разные хосты вне вашей сети, попробуйте определить, что именно изменилось (появление ошибок на ethernet-аплинке из-за несоответствия дуплекса, большое количество tcp retransmission, изменение mtu, изменение 'трассы' (traceroute)) и с этими данными обратиться в техподдержку оператора. С моей точки зрения, это более конструктивный подход, если, конечно, целью является исправление ситуации.

Если вы хотите мониторить 'качество' аплинка, то, на мой взгляд, разумно отслеживать сразу несколько параметров (пинг до внешнего сервера через аплинк, скорость передачи данных до сервера по udp, по tcp через аплинк). Но даже исходя из этих данных, выводы следует делать осторожно. Грубо говоря, на 'скорость интернета' влияет много факторов, и только некоторые из них доступны вашему наблюдению.

К какой IX (точке обмена траффиком) подключен Ростелеком Спб

Вы их имеете в виду?

На shop.nag.ru иногда попадется уцененка (например, один порт из 24 у коммутатора не работает).
Расшифровку цифр можно найти на cisco.com
По-моему, если вы только начинаете сертификацию (CCNA,ICND), то лучше пользоваться эмуляторами GNS3 (L3, крайне урезанная L2-функциональность через модули NM-*ESW) или IOU (L3 и более полная реализация L2-функциональности), или симуляторами вроде Packet Tracer. Одного маршрутизатора и одного коммутатора вряд ли хватит для внятной топологии.

>Тогда я был бы благодарен за мануал по настройке статических определений связок
Если вы решили попробовать настроить специфичные arp-записи, как я рекомендовал, то надо сделать следующее:
1) на одном из хостов пропинговать 192.168.1.2 (с целью обновить динамические arp-записи).
2) посмотреть соответствующий MAC-адрес (в windows arp -a 192.168.1.2)
3) на каждом из 'избранных' хостов добавить статическую arp-запись (в windows arp -s 192.168.1.1 aa-bb-cc-dd-ee-ff, где aa-bb-cc-dd-ee-ff - адрес из п.2)
4) удалить статическую запись можно arp -d 192.168.1.1
5) при перезагрузке статическая запись теряется, может потребоваться прописать команду в автозагрузку

Для платформы windows - Microsoft Network Monitor.
На картинке - пример трафика foobar2000.

Я так понимаю, mikrotik и linux-машина находятся в одном l2-домене (т.е. включены в один коммутатор, порты в одном влане, интерфейсы 192.168.1.1 и 192.168.1.2 могут друг друга пинговать)?

Если так, то можно поднять на linux-машине dhcp-сервер и отдавать клиентам адрес маршрутизатора (dhcp option 3) в зависимости от MAC-адреса клиента. По-моему, dnsmasq это умеет.

Я вижу два главных отличия - на 3750 можно установить 10-гигабитные трансиверы в качестве аплинков, также на 3750 более полно (RIP/OSPF) реализована маршрутизация (на 2960s только статические маршруты, около 16, и по-моему надо использовать софт LAN Base, а не LAN Lite, идущий в комплекте)

Полезные ссылки:
3750
2960

Также хотел бы добавить, провайдер может быть виноват лишь косвенно, например, если проблемный трафик (ipv6 ndp-сообщения, dhcp-сообщения и т.д.) создается вашим соседом по коммутатору.

Верить каждому автоматически генерированному письму при отсутствии других данных (дампы трафика и т.д.) считаю неконструктивным.
В случае, если это письмо первоначально создано владельцем адреса yyy.yyy.yyy.yyy, и только переслано вам автоматически, возможен следующий вариант.

Это может быть последствием SYN-флуда на сокет yyy.yyy.yyy.yyy:80 со спуфингом (подменой) адресов источников. Так могло совпасть, что был использован Ваш адрес. Чтобы полнее разобраться в ситуации, можно попросить администрацию Hetzner проанализировать flow-данные (netflow, sflow, смотря что они собирают) с целью уточнить :

а) наблюдался ли в указанное время tcp-трафик от вашего сервера (xxx.xxx.xxx.xxx) до атакуемого (yyy.yyy.yyy.yyy:80)

б) наблюдался ли в указанное время tcp-трафик от yyy.yyy.yyy.yyy:80 до xxx.xxx.xxx.xxx.

Если верно б), значит, скорее всего, атака имела место и атакуемый сервер отвечал SYN-ACK на ваши (или не ваши) SYN (это одна из возможностей). Если при этом а) неверно, имело место подмена адреса источника, вы не при чем. Если а) верно, то проблема или у вас на сервере, или в сети Hetzner (т.е. другой их клиент подделывал адреса источника, это возможно при определенных условиях).