Хорошо, вот моя ситуация.
Это в интернете. 6224 — это маршрутизатор на этой картинке, который физически находится в Канате.
Оба VLAN 1697 и 3994 предоставляются интернет-провайдером. Эти VLAN предоставляются через один 1-гигабитный Ethernet-провод.
Хосты Kanata напрямую подключены к 6224; два других узла являются удаленными.
VLAN 3994 представляет собой единое пространство IP-адресов, поэтому теоретически не должно иметь значения, где физически находятся хосты в этой подсети.
Вот в чем проблема.
У меня есть система мониторинга, которая подключена к Интернету, поэтому сигналы от монитора будут поступать на эту диаграмму в VLAN 1697.
Когда я пингую хосты в 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
Потоки неправильно направленных пакетов, похоже, направляются широковещательной рассылкой из моей системы. Однако я вижу, что одна широковещательная рассылка покидает мою систему, а две — на 3994 VLAN в TLS. Обычно это отчет о членстве IGMP V2 / присоединение к группе 224.0.0.251, но иногда это чип управления в моей системе, отправляющий arping для себя (он делает это каждые 2 секунды или около того по глупым причинам).
Это подразумевает, что в Беллс Корнерс или Альберте есть система, которая слышит мою трансляцию и по какой-то причине ее возвращает. Так что 6224 говорит: «А, этот мак, должно быть, действительно находится на канале TLS», и соответствующим образом корректирует свою таблицу коммутации.
Вам знакомо это описание проблемы?
решение1
Хорошо, я разобрался с этим и напишу это здесь. Это конкретное решение вряд ли кому-то поможет, потому что это пограничный случай.
Еще в древней истории связи с этим провайдером мы добавили второй VLAN к основному. В то время провайдер подключил этот VLAN как оба тегированныхинемаркированные на их стороне соединения. Их коммутатор обрабатывает тегированные и немаркированные соединения как отдельные соединения.
Итак, что происходит, моя система, подключенная к Dell, испускает arp-трансляцию (интерфейс управления на этом компьютере испускает arp-пакеты каждые полсекунды по глупым причинам), которые коммутатор пересылает по каналу на удаленный сайт. Коммутатор у провайдера слышит трансляцию на немаркированном интерфейсе --и отправляет его мне обратно на помеченный интерфейс. Коммутатор слышит это и затем приходит к выводу, что MAC-адрес, инициирующий трансляцию, действительно доступен по ссылке провайдера. Последующие пакеты, таким образом, направляются неправильно.
Решением было заставить провайдера изменить свою конфигурацию так, чтобы она соответствовала конфигурации Dell. Все общие проблемы с подключением прекратились.