throughtheether

Я не работал с AP от Cisco, но разве gi1/0/3 не должен быть транком с тегированным 4 вланом?

ловит петлю и отключает порт

Вы уверены, что порт отключается из-за формирования петли (т.е. он переходит в режим blocking/alternate), а не из-за срабатывания, к примеру, root guard?

Кроме того, стоит проверить, нет ли в настройках маршрутизаторов (router 1, router 2) какого-либо форвардинга фреймов (бриджинг, например, или форвардинг BPDU) между портами, указанными на схеме (т.е. не является ли один из маршрутизаторов причиной, по которой root считает, что в наличии петля).

Изобразил нечто в силу своих способностей.
Вот так (не) работает 'прямой' кабель. Приемник соединяется с приемником, передатчик с передатчиком. Связи, грубо говоря, нет.

Вот так работает cross-кабель. Приемник соединяется с передатчиком противоположной стороны. Стороны способны обмениваться сигналами.

На маркировку разъемов не обращайте внимания, контакты подписаны (pin 1-3,6).

Физический смысл (пока рассматриваем подключение MDI к MDI, компьютер/маршрутизатор к компьютеру/маршрутизатору). На устройстве A передатчик подключен к контактам 1,2 на разъеме 8p8c (rj-45 в просторечии), приемник - к контактам 3 и 6. Аналогично на устройстве B. При использовании 'прямого' кабеля, передатчик устройства A фактически подключается к передатчику устройства B. Аналогично, приемник устройства A подсоединяется к устройству B. Вполне логично, что сигнал от передатчика A не доходит до приемника B.

Для решения проблемы используется 'кросс-кабель'. Контакты 1 и 2 одной стороны кабеля соединены с контактами 3 и 6. Таким образом, передатчик устройства A соединен с приемником B и наоборот. Соответственно, устройство B успешно принимает сигнал от устройства A и далее обрабатывает его.

Аналогичная картина для MDI-X (хабы, коммутаторы)

Если вы готовитесь к экзамену уровня CCNA (где этот вопрос актуален), то можно разделить типы устройств на две группы. В одной будут маршрутизаторы и компьютеры/серверы, в другой - комутаторы и хабы. При соединении устройств из разных групп (маршрутизатор и коммутатор, компьютер и хаб) используется прямой кабель (straight-through), при соединении устройств внутри группы (маршрутизатор и компьютер, хаб и коммутатор) используется кросс-кабель (crossover).

Есть технология MDI/MDI-X autosense, которая автоматически распознает "распиновку" порта соседа. Насколько я понимаю, для ее работы порт должен быть настроен в режиме автоопределения как скорости среды, так и дуплекса. В последнее время эта технология используется практически везде.

Предлагаю с маршрутизатора запустить пинг до интересующего вас сервера. Затем посмотреть, формируются ли соответствующие записи в ARP- и MAC-таблицах. В случае с Cisco IOS CLI это можно сделать так

ping 192.168.0.2
show arp
show mac address-table

В вашем случае синтаксис может немного отличаться.

Я вообще полагаю, что из отсутствия ответа на ICMP Echo-request еще не обязательно следует неполадка в маршрутизации. Насколько мне известно, в некоторых случаях (ОС Windows) встроенный фаерволл (брандмауэр) запрещает входящие пинги.

сам не работал, но слышал про такой форк: VyOS

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

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

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

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

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

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

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

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

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

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