После выполнения алгоритма, мы получим, что кратчайшее расстояние до второй вершины равно 10.Вот здесь непонятно, поясните вашу мысль.
Как проверить что происходит без подключения к монитору?Вы можете подсоединить ноутбук к маршрутизатору (в один из коммутируемых портов) и при помощи анализатора трафика (wireshark, tcpdump) посмотреть, отсылает ли Raspberry PI сообщения DHCPDISCOVER (они рассылаются широковещательно). Если нет - то проблема где-то на самом устройстве. Если да - надо будет далее анализировать DHCP-трафик и настройки DHCP-сервера (и, вероятно, клиента).
>>> line='\n\n\n641717\n\site.ru\n60\n\nАктивен\n\n\n2005\n\n\n61%\n\n\n\n8%\n\n\n\n\n\n 12.59\n\n\n\n\n 414.63\n\n\n\n 4 712.49\n\n\n\n\n\n'
>>> line
'\n\n\n641717\n\\site.ru\n60\n\n\xc0\xea\xf2\xe8\xe2\xe5\xed\n\n\n2005\n\n\n61%\n\n\n\n8%\n\n\n\n\n\n 12.59\n\n\n\n\n 414.63\n\n\n\n 4 712.49\n\n\n\n\n\n'
>>> import re
>>> re.split(r'\s+',line)
['', '641717', '\\site.ru', '60', '\xc0\xea\xf2\xe8\xe2\xe5\xed', '2005', '61%', '8%', '12.59', '414.63', '4', '712.49', '']for item in re.split(r'\s+',line):
if item:
pass>>> re.split(r'\s+',line.strip())
['641717', '\\site.ru', '60', '\xc0\xea\xf2\xe8\xe2\xe5\xed', '2005', '61%', '8%', '12.59', '414.63', '4', '712.49']for elem in oko_planet.doc.select('//*[@id="dle-content"]/table//span[@class="ntitle"]/a'):
print elem.text()1. Какие основные метрики стоит снимать?Состояние самого коммутатора: утилизация CPU, памяти, показания датчиков температуры, обороты вентилятора, входное/выходное напряжение блока питания.
2. Как стоит мониторить коммутаторы доступа, мониторить только магистральные порты? Или все?См. предыдущий абзац, полагаю, лучше мониторить все интерфейсы. На главную страницу (dashboard), конечно, лучше выводить отобранные графики.
после подключения VPN пользователя у него отваливается интернет, но внутр сети на cisco доступны.Проверьте таблицу маршрутизации клиента до и после подключения VPN. Если изменяется маршрут по умолчанию (0.0.0.0 0.0.0.0), то поддерживаю совет, который дал вам Ринат Гарипов.
Подскажите в каком направлении двигаться.В направлении точного описания проблемы и выяснения и, по возможности, устранения ее причины.
Происходит частая потеря пакетов между клиентами внутри сети.Каких именно пакетов? Как вы проводите диагностику?
Клиенты работают по Ethernet.Обратите внимание на состояние релевантных проблеме портов (ошибки, дуплекс).
https://cloud.mail.ru/public/3VZDQKLZM2Wb/cap_eth0.pcap - слушал eth0 (интернет)
https://cloud.mail.ru/public/2MTN9apktN8U/cap_eth1.pcap - слушал eth1 (локальная сеть)
gateway - https://cloud.mail.ru/public/5VsPnm4QmaRp/gateway.pcap
computer - https://cloud.mail.ru/public/yy6WtAZgbKc5/computer.pcap
Проблема кроется где-то в пересылке кадров в eth1 из ppp0 на программном уровне.С этой проблемой я вам вряд ли помогу. В качестве попытки ухватиться за соломинку - у вас случайно qos/tc не настроен на шлюзе?
Меня интересует как настроить путти для работы через eth-порт на компьютере и RS-232 на устройстве.Сомневаюсь, что этот путь приведет вас к успеху. Переходник RS-232/8p8c, как правило, используется для соединения COM-порта компьютера (или USB, через USB/RS232 адаптер) со специальным "консольным" 8p8c("RJ-45" на сленге)-разъемом сетевого устройства.
из-за чего оноУ маршрутизатора, видимо, есть более важные дела, чем генерировать ответы на ICMP запросы (если mtr шлет их, конечно). Или на нем есть специальная функция ограничения такого трафика с целью минимизации вероятности возникновения ситуации отказа в обслуживании (DoS).
как сие побороть?Если на рабочий трафик это не оказывает влияния, то бороться с этим не нужно.
Нужно сделать модельВ каком окружении предполагается моделирование и тестирование?
какой-то вариант новой модели на основе классической модели OSIЧто такое "классическая модель OSI"? Если есть классическая, то есть и модернистская или я чего-то не понял?
Мне советовали обратить внимание на маршрутизацию, делать ее более гибкой, что ли.Я бы на вашем месте обратил внимание на SDN (Software-defined networking, стильно, модно, молодежно). Один контроллер общается с несколькими маршрутизаторами (не только в L3-смысле) и каждому устанавливает специфические записи в таблицу маршрутизации/форвардинга. Из плюсов - гибкость, программируемость, отсутствие проблем типа "ships in the night". Я бы даже предположил, что в сетях датацентров SDN применять наиболее логично (по сравнению,скажем, с WAN-сетями). Но и минусы присутствуют.
В какую еще сторону можно копать?Сети Клоса (не уверен, корректный ли это термин, англоязычное название Clos network/fabric). Задание постоянного размера фрейма (проще прогнозировать утилизацию буферов). Отказ от вычисления контрольной суммы (передача этой обязанности высшим уровням "классической модели OSI"). Отказ от STP (или добавлением поля hop count в ethernet-фрейм, или назначением неравноценных ролей в смысле форвардинга портам коммутаторов, порты из одной категории могут направлять трафик только в порты другой категории)