Сетевые технологии *

Компания Cisco запустила интерактивную карту, показывающую процент внедрения IPv6 в различных странах:

Не так давно мне довелось беседовать с разработчиком, не понимавшим, почему полностью резервированная связь между ЦОДами не может гарантировать 100% доступность сервиса.

В этой статье мы постараемся описать текущее состояние поддержки и варианты внедрения IPv6 в домашних сетях. Статья написана осенью 2012 года, вполне возможно, что уже через год она будет совершенно неактуальной, но всё-таки мы опишем статус IPv6 на сегодняшний день. Информация ориентирована в первую очередь на провайдеров домашних сетей, соответственно, под определение «провайдер» в данной статье магистралы не подпадают.

Месяц назад я написал статью о зонде, который я принес с конференции ENOG-4. Побочным эффектом от статьи был скачек заказанных зондов, который можно видеть на графике статистики распределения зондов по пользователям.

Основных вопросов, которые возникли в процессе созерцания устройства, было два: что внутри и как его можно использовать на практике?

Итак, внутри там довольно дорогое и относительно гибкое устройство Lantronix Xport-Pro собственной обвязкой питания по USB. Устройство стоит больше 60 долларов без корпуса и обвязки, а фактически оплачивают их LIR'ы. За эти деньги мы получаем маленький linux-компьютер, который в принципе может делать множество измерений.

UPD:

Ребята, взамен помершего Tunlr мы подняли свой DNS Proxy для Pandora и Spotify. Работает, понянтно, на всех платформарх и практически не требует настройки — habrahabr.ru/post/215889/. Велкам!

Если вам, как мне, надоело подключать VPN-туннель на штаты каждый раз, когда вы хотели бы послушать знающее ваши музыкальные вкусы радио Pandora или увидеть видео по ссылке на hulu.com, вам помогут два волшебных адреса (проверьте на сайте, они периодически меняются):

142.54.177.158

209.141.56.79

Это адреса DNS-сервера сайта tunlr.net который проделывает хитрую магию с заголовками помогает вам избежать проверки на страну пребывания для вашего IP.

Сервис поддерживает только определенный список сайтов, для которых это будет работать. В случае всех остальных запросов он будет работать как обычный честный DNS-сервер.

С каждым годом скорость интернета — как последней мили, так и магистральных каналов становится все выше. Лишь одно неизменно — латентность уже уперлась в физические ограничения: скорость света в оптоволокне — около 200тыс километров в секунду, и соответственно, быстрее чем за ~150ms ответ от сервера через атлантический океан не получить в обозримой перспективе (хотя конечно есть изыски, вроде оптоволокна с воздушной сердцевиной или радиорелейной связи, но это для простых смертных едва-ли доступно).

Когда мы пытаемся например из России открыть web-сайт, расположенный в США (его NS сервера вероятно там же), и домен не нашелся в DNS-кэше вашего провайдера — то ждать придется долго даже на гигабитном интернете, возможно даже целую секунду: пока мы через океан получим имена NS серверов домена, пока разрезолвим их IP, пока отправим и получим собственно сам DNS запрос…

Пару лет назад Google завела свои публичные DNS сервера, а для агитации перехода на них — они разработали утилитку NameBench, которая прогоняет тесты DNS по вашей истории серфинга и показывает, насколько Google DNS быстрее DNS сервера вашего провайдера.

Но мне удалось сделать свой DNS сервер, который работает быстрее Google Public DNS, и в этой краткой заметке хочу поделится результатами.

Учёные из университета Северной Каролины разработали и протестировали алгоритм, позволяющий, по данным экспериментов, в несколько раз увеличить пропускную способность беспроводных сетей под критически большой нагрузкой, там, где ими пользуется много людей одновременно — в кафе, аэропортах, конференц-залах. В таких условиях резко возрастает число потерянных пакетов, что быстро приводит к лавинообразному уменьшению пропускной способности (иногда в десятки раз).

Модификация прошивки точки доступа, названная WiFox, позволяет снизить число коллизий при высоких нагрузках, тем самым избегая заторов в перегруженной сети. Подробное описание алгоритма будет представлено на конференции по экспериментальным сетевым технологиям CoNEXT, которая пройдёт во Франции с 10 по 13 декабря.

Вот такое замечательное системное сообщение показал Hamachi после обновления. Основных нововведения два:

• Смена диапазона IP адресов на 25/8. И это хорошо — Hamachi перестанет конфликтовать например с серверами Hetzner на 5.x.x.x
• Запуска клиента как сервиса отныне относится к платным возможностям.

Т.о. с 19 ноября компьютер с установленным клиентом Hamachi становится доступным, только если на нем залогинен пользователь и запущен Hamachi UI. Поздравляю всех с этим знаменательным событием и предлагаю всем дружно перейти на NeoRouter. Или выбрать что-нибудь из habrahabr.ru/post/150151/.

Дано: современный телевизор, модель не играет большой роли, главное чтобы был сетевой плеер.
Требуется: подцепить его к домашней сети чтобы он проигрывал хранящиеся на серваке фильмы.

Что делать если необходимо узнать логин-пароль установленные на PPPoE в роутере? Вопрос был задан в habrahabr.ru/qa/28217 и я из природной любознательности решил поэкспериментировать. Предположим что доступа к админке у нас нет. Модель роутера не так важна (в моём случае для тестов был взят D-Link DIR-300)

Решение под катом

В содружестве HP и 3Com родилось аббревиатурное имя для активного сетевого оборудования — H3C. В золотой середине из гигабитной линейки коммутаторов производителя оказался H3C S5120SI.
Не смотря на подробное и захватывающее чтиво User Guide и Command Reference в объеме 800 страниц каждая, настройку и управление можно уложить в 4 листа, доступно для обывателя.
Советы по первичной настройке, под катом.

Среди сетевых специалистов не утихают споры: возможно (и стоит ли) готовиться к экзамену CCNA самостоятельно или нужно идти на платные курсы? В этой статье мы бы хотели дать несколько полезных советов тем, кто выбрал путь самостоятельной подготовки к экзамену компании Cisco CCNA.

Итак, возможно или нет?

• Что такое домен коллизий?
• Сколько пар используется для Ethernet и почему?
• По каким парам идет прием, а по каким передача?
• Что ограничивает длину сегмента сети?
• Почему кадр не может быть меньше определенной величины?

Если не знаешь ответов на эти вопросы, а читать стандарты и серьезную литературу по теме лень — прошу под кат.

Всем привет!

В одном из моих проектов используется нечто, немного похожее на частное облако. Это несколько серверов для хранения данных и несколько — бездисковых, отвечающих за виртуализацию. На днях я похоже что наконец поставил точку в вопросе выжимания максимальной производительности дисковой подсистемы данного решения. Это было довольно интересно и даже в некоторые моменты — довольно неожиданно. Поэтому и хочу поделиться своей историей с хабрасообществом, которая началась в далёком 2008м году, ещё до появления «Первого облачного провайдера России» и акции по рассылке бесплатных счётчиков воды.

Архитектура

Экспорт виртуальных жёстких дисков осуществляется через отдельную гигабитную сеть по протоколу AoE. Если коротко — это детище компании Coraid, которая предложила реализовать передачу ATA-команд по сети, напрямую. Спецификация протокола занимает всего десяток страниц! Главная особенность — это отсутствие TCP/IP. При передаче данных получается минимальный оверхед, но как плата за простоту — невозможность роутинга.

Почему именно такой выбор? Если опустить перепечатывание официальных источников — в т.ч. и банальный lowcost.

Соответственно, в хранилищах мы использовали обычные SATA-диски с 7200 rpm. Их недостаток известен всем — низкий IOPS.

Пару дней назад мой начальник дал мне задание — пробежаться по всем девайсам в нашей сети и посмотреть каким образом можно улучшить безопасность сети в целом. Я человек далёкий от security, routing&switching — наше всё. Но тем не менее, я взялся за дело. Товарищи по работе подсказали, что стоит погуглить способы защиты management plane (имя в виду, конечно, MPP), я случайно погуглил «MOP cisco» и хорошо, что не сразу понял, что ошибся…

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

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

Каждый, кому приходится заниматься хоть немного IP-сетями представляет основы IP-маршрутизации.
Можно не знать протоколов динамической маршрутизации, или знать, но не до тонкостей. Можно не быть гуру OSPF, BGP и иже с ними, но тот алгоритм, по которому уже из сформированной route-таблицы (сформированной тем или иным способом, вручную или благодаря динамике) выбирается next-hop представляют многие.

Предистория

Рано или поздно системный администратор сталкивается с необходимостью распределить трафик по нескольким каналам, при этом естественно желание чтобы каждый канал использовался по максимуму. Столкнувшись с подобной необходимостью, и решив не изобретать велосипед, обратился к помощи поисковиков. Так как сервер у меня на Ubuntu, то обратил свое внимание на статью http://help.ubuntu.ru/wiki/ip_balancing. Реализовал «Способ 1», но при тесте были замечены следующие критичные проблемы: при использовании ссылок на некоторых сайтах они не открывались (например при попытке включить музыку на ресурсе «ВКонтакте»). Причина очевидна — запрос шел через другой канал. Обдумав ситуацию, решил скомбинировать подход к балансировке. Логика проста — больше всего съедает трафика торренты и им подобные программы, поэтому разделяем трафик. В итоге трафик с портами до 11000 распределяем приблизительно равномерно по количеству абонентов — подсетями, трафиком с портами 11000-60000 выравниваем загрузку каналов.

Изучаю документацию NAS производства NETGEAR. Наткнулся на любопытный документ (внизу страницы). Обратил на себя внимание шрифт — очень мелкий, с рассчетом, что не прочтет никто.

Но этот документ прекрасен от начала и до конца. Позволю себе привести текст полностью. Наиболее удивившие меня части я выделил. Не поленитесь прочесть, это лучше любого анекдота.