Долгое время у меня была неуловимая проблема с моей сетью.
Я изменил маршрутизатор, точку доступа и сделал беспроводные соединения проводными в поисках вора производительности, не приближаясь к пониманию того, что не так с моей настройкой.
Проблема столь же расплывчата, как "сеть чувствует себя медленной", и ни одного конкретного признака проблемы не было достаточно устойчивым, чтобы я мог найти ее основную причину.
Моя текущая инфраструктура состоит из:
Виртуальная машина pfsense, работающая на esxi. В настоящее время единственная виртуальная машина, работающая на хосте (Proliant ML110, Core 2 Duo), устраняет другие виртуальные машины в качестве воров производительности. Сервер имеет две сетевые карты, одну для глобальной сети и одну для локальной сети.
Три 8- и 24-портовых коммутатора Procurve 1800/1810. Две VLAN, одна для локальной сети и одна для глобальной сети.
Один Ubiquiti Unifi UAP-AC.
Эта сеть обслуживает 20 с чем-то единиц с возможностью подключения.
Вчера был более настойчивым вопросом , где я не смог запустить фильм на Netflix, немного прибегая к помощи привел меня сюда после того , как поддержка Netflix сказать мне , что проблема не с ними , но с моим провайдером.
Описание там соответствует проблемам, которые у меня есть, запуск приложения очень медленный, воспроизведение не всегда работает.
Я попытался отключить Apple-TV и подключить свой Macbook с помощью того же кабеля. На компьютере Netflix работал безотказно. Проведя тестирование скорости на этом кабеле, я проверил пропускную способность до 100 двунаправленных мегабит. Переподключение Apple-TV Netflix отказалось работать.
Изменение vlan на порту, к которому Apple-TV подключен из локальной сети в глобальную, сделало его напрямую подключенным к Интернету с публичным IP-адресом, с помощью которого он мог без проблем транслировать фильм.
Вернуть его в режим воспроизведения по локальной сети еще раз не удалось. Я отключил все, кроме Apple-TV и коммутатора uplink от коммутатора. Пошел к коммутатору с входящим интернетом, отключил все, кроме двух портов pfsense, подключения к оптоволоконному конвертеру и восходящей линии связи к коммутатору с Apple-TV. После чего удалось начать воспроизведение.
Следовательно, я рассуждал, что должен быть в состоянии точно определить нарушителя спокойствия, переподключив все и посмотреть, какой кабель убивает воспроизведение. Ни один не сделал. Все продолжало работать, когда все снова было связано.
Таков мой опыт каждый раз, когда я пытаюсь выяснить, почему мое соединение работает плохо. На 100 двунаправленных мегабитах это должно быть довольно быстро, но я несколько раз выключал Wi-Fi на своем мобильном телефоне, потому что 4G быстрее. Speedtest всегда показывает 100 мегабит.
Потоковое управление кажется особенно сложным, зеркальное отображение моего экрана с использованием трансляции практически бесполезно. Воспроизведение музыки по той же технологии работает, но сбои при воспроизведении являются обычным делом.
Если вчера обход обхода брандмауэра, казалось, указывал на то, что во всем этом он является мошенником, сегодня результаты полностью изменены:
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..100}; do ping -c 1 -s 1600 -M dont google.se > /dev/null; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
real 2m23.383s
user 0m0.046s
sys 0m0.253s
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..100}; do ping -c 1 -s 1600 -M dont google.se > /dev/null; done
inet 10.11.12.162/24 brd 10.11.12.255 scope global eth0
real 0m52.497s
user 0m0.054s
sys 0m0.253s
Кроме того, чтобы попытаться проверить MTU для сети (согласно теории яблочного форума), я попытался пропинговать пакеты разных размеров из WAN, мои тесты показали, что большие пакеты плохо пересекали сеть:
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..2}; do ping -c 1 -s 1500 google.se ; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
PING google.se (64.233.163.94) 1500(1528) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
PING google.se (64.233.163.94) 1500(1528) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
real 0m20.015s
user 0m0.003s
sys 0m0.003s
Некоторые эксперименты, казалось, подтвердили, что MTU действительно равен 1500 в глобальной сети:
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..2}; do ping -c 1 -s 1472 google.se ; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
PING google.se (216.58.209.131) 1472(1500) bytes of data.
72 bytes from arn09s05-in-f3.1e100.net (216.58.209.131): icmp_seq=1 ttl=59 (truncated)
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.497/4.497/4.497/0.000 ms
PING google.se (216.58.209.131) 1472(1500) bytes of data.
72 bytes from arn09s05-in-f3.1e100.net (216.58.209.131): icmp_seq=1 ttl=59 (truncated)
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.454/4.454/4.454/0.000 ms
real 0m0.034s
user 0m0.003s
sys 0m0.003s
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..2}; do ping -c 1 -s 1473 google.se ; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
PING google.se (216.58.209.131) 1473(1501) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
PING google.se (216.58.209.131) 1473(1501) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
real 0m20.018s
user 0m0.001s
sys 0m0.007s
В локальной сети точка останова имеет тот же размер пакета, но я должен вручную указать, что не разрешаю фрагментацию для разрыва пакета:
$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 68:b5:99:e7:07:a8 brd ff:ff:ff:ff:ff:ff
inet 10.11.12.162/24 brd 10.11.12.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::6ab5:99ff:fee7:7a8/64 scope link
valid_lft forever preferred_lft forever
$ ping -c 1 -s 3000 google.se
PING google.se (83.255.235.35) 3000(3028) bytes of data.
3008 bytes from 83.255.235.35: icmp_seq=1 ttl=61 time=82.3 ms
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 82.324/82.324/82.324/0.000 ms
$ ping -c 1 -s 1472 -M do google.se
PING google.se (83.255.235.123) 1472(1500) bytes of data.
1480 bytes from cache.google.com (83.255.235.123): icmp_seq=1 ttl=61 time=74.7 ms
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 74.779/74.779/74.779/0.000 ms
$ ping -c 1 -s 1473 -M do google.se
PING google.se (83.255.235.35) 1473(1501) bytes of data.
ping: local error: Message too long, mtu=1500
--- google.se ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
Я не понимаю, что не так с моей сетью, и я не могу понять, как ее устранить. Помогите мне реструктурировать устранение неполадок, чтобы я мог раз и навсегда избавить сеть от привидений.
РЕДАКТИРОВАТЬ, Относительно моих настроек DNS:
Если я правильно понимаю, это означает, что распознаватели Google используются только в качестве запасного варианта, когда назначенный DHCP сервер имен от интернет-провайдера недоступен. Это верно? Или я случайно запрашиваю адреса на сервере имен далеко?
Как вы можете видеть ниже, pfsense сначала пытается обработать разрешение имен, спрашивая интернет-провайдера во-вторых и в-третьих и прибегая только к Google в качестве четвертого и пятого варианта, что мне кажется вполне разумным?
Apple TV имеет сетевые настройки, назначенные DHCP, и использует шлюз в качестве сервера имен. DHCP-сервер не имеет выделенных настроек DNS, но наследует список серверов имен, приведенный выше:
РЕДАКТИРОВАТЬ, Относительно цикла:
Причина запуска ping 100 раз, а не один раз с 100 пакетами, заключается в том, что разрешение имен выполнялось каждый раз, так как для запуска ping потребовалось довольно много времени, когда я запускал его вручную, и я подумал, может быть, я может сделать это чувство более отчетливым, умножив действие на 100.
Учитывая, что Ubuntu имеет следующий конфиг:
$ grep nameserver /etc/resolv.conf
nameserver 127.0.1.1
Эта мысль может быть немного глупой жесткой ...
РЕДАКТИРОВАТЬ, Относительно Apple TV:
Я сбросил Apple TV к заводским настройкам. Я несколько раз отключал устройство от сети (иногда с небольшой яростью в крови).
РЕДАКТИРОВАТЬ, pfSense:
Я на заводе по умолчанию установил pfSense на днях и только повторно включил более важные его части (dns, dhcp, nat, статические dhcp-аренды, несколько переадресаций портов), но вчера Netflix все еще прекратил проигрывать средний поток. Проблема снова исчезла, поэтому перезапуск фильма сработал.
Интересно, нужен ли Netflix средний поток DNS, похоже, к тому времени об этом уже позаботились.
А поскольку на сервере установлена последняя версия pfsense (2.2.2), по умолчанию используется unbound .
То, что распознаватель успешно кэширует разрешения, можно проверить, выполнив два последовательных поиска с помощью инструмента диагностики:
Различные ответы смущают меня, хотя.
РЕДАКТИРОВАТЬ, MTU:
MTU установлен на автоматический.
РЕДАКТИРОВАТЬ, тест скорости ATV:
Выполнение теста скорости на Apple TV приводит к следующему графику на pfsense:
После чего Apple TV сообщает "тест завершен успешно", но только на долю секунды, затем он меняется на:
Я могу использовать Netflix, несмотря на ошибку.