Хорошо, вот моя ситуация.
Это есть в Интернете. 6224 - это маршрутизатор на этом рисунке, который физически находится в Канате.
Обе сети VLAN 1697 и 3994 предоставляются интернет-провайдером. Эти сети VLAN предоставляются через один провод Ethernet 1 Гбит / с.
Хосты Kanata напрямую подключены к 6224; два других сайта - удаленные.
VLAN 3994 представляет собой единое пространство IP-адресов, поэтому теоретически не имеет значения физически, где находятся хосты в этой подсети.
Вот в чем проблема.
У меня есть система мониторинга, которая подключена к Интернету, поэтому зонды с монитора будут попадать на эту диаграмму в 1697 VLAN.
Когда я пингую хосты в Albert или Bells Corners из Интернета, нет потерь. Связь выглядит идеальной.
Когда я пингую хосты в Канате, я теряю от 10 до 40% пингов. Потеря непредсказуема, но: когда я их теряю, я всегда теряю минимум 3, обычно 4, реже больше пинга в кучу.
Я подключил монитор непосредственно к 6224 в Канате на 3994 ..
Когда монитор отправляет эхо-запрос на интерфейс маршрутизации 6224, я вижу точно такую же картину потерь, но НЕ одновременно с потерей от удаленной системы. Время пинга составляет около 1 мс.
Когда монитор отправляет эхо-запрос на другую систему, напрямую подключенную к 6224, нет потерь. Время пинга составляет около 0,1 мс, что составляет одну десятую времени пинга маршрутизатора.
Кто-нибудь знает, что здесь происходит?
Обновите, чтобы сделать вещи менее ясными, возможно
Кажется, что происходит то, что входящий и исходящий трафик, соединение с интернет-провайдером в порядке. Трафик, идущий от мозга маршрутизатора к мозгу коммутации (или, возможно, обратно), является причиной проблемы.
Я не могу винить Интернет-провайдера, потому что доступ в Интернет к двум удаленным сайтам и с них надежен. Проблемы возникают только у хостов, напрямую подключенных к 6224.
Обновление 2
Хорошо, после того, как я долго смотрел на следы, у меня появился более конкретный симптом.
Я сделал tcpdump на vlan 3994 восходящего канала ISP в поисках моего собственного адреса, исходя из теории, что все, что я должен видеть, - это широковещательный трафик, идущий на удаленные сайты. Вместо этого я увидел пакеты, которые я ожидал увидеть на интерфейсе моей системы, идущие по TLS в этой VLAN.
Так:
По какой-то причине 6224 часто думает, что моя система находится на дальнем конце TLS.
Когда я проверяю таблицу переключения, когда все работает, моя запись выглядит так:
3994 0007.E924.F714 2/g16 Dynamic
… Что имеет смысл, поскольку он подключен к порту 16. Однако, когда он сломан, это выглядит так:
3994 0007.E924.F714 2/g22 Dynamic
Потоки неправильно направленных пакетов, похоже, управляются широковещательной рассылкой из моей системы. Однако я вижу, что одна широковещательная передача покидает мою систему, а две - в VLAN 3994 для TLS. Обычно это отчет о членстве IGMP V2 / присоединение к группе 224.0.0.251, но иногда это микросхема управления в моей системе, играющая за себя (она делает это каждые 2 секунды или около того по глупым причинам).
Это означает, что в Беллс Корнерс или Альберте есть система, которая слушает мою передачу и по какой-то причине повторяет ее. Итак, 6224 идет ах, этот Mac действительно должен быть отключен по TLS-каналу и соответствующим образом настраивает свою таблицу переключения.
Звонит ли это описание проблемы?
ОК, я разобрался и напишу здесь. Это конкретное решение вряд ли кому-то поможет, потому что это крайний случай.
Вернувшись к древней истории связи с этим провайдером, мы добавили вторую VLAN к основной. В то время провайдер затем подключил эту VLAN, поскольку оба тега и немаркированы на их стороне соединения. Их коммутатор рассматривает помеченные и немаркированные как отдельные соединения.
Итак, что происходит: моя система, подключенная к Dell, излучает широковещательную рассылку arp (интерфейс управления на этом компьютере по глупым причинам выдает пакеты arp каждые полсекунды), которую коммутатор пересылает по ссылке на удаленный сайт. Коммутатор у провайдера слышит трансляцию на немаркированном интерфейсе - и отправляет его мне в интерфейсе с тегами. Коммутатор слышит это, а затем приходит к выводу, что MAC-адрес, с которого идет трансляция, действительно доступен через ссылку провайдера. Таким образом, последующие пакеты направляются неверно.
Решение заключалось в том, чтобы поставщик изменил свою конфигурацию, чтобы она соответствовала конфигурации Dell. Все общие проблемы с подключением ушли.