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

В этой короткой статье я опишу процесс настройки функций для переключения маршрутов между двумя провайдерами в случае, если физический линк присутствует и даже есть наличие локальной сети провайдера, но нет самого интернета.
Рассмотрим пример с 2 провайдерами:

• ISP1
  interface IP 1.1.1.100
  gateway IP 1.1.1.1
  netmask 255.255.255.0
  interface name ge-0/0/2.0
• ISP2
  interface IP 2.2.2.200
  gateway IP 2.2.2.1
  netmask 255.255.255.0
  interface name ge-0/0/2.0

Конфигурирование будет состоять из двух этапов:

1. Настройка rpm — который проверяет доступность выбранных хостов
2. Настройка ip-monitoring — который непосредственно выполняет переключения рутинга

Этап 1

Как правило выбираются хосты изначально постоянно доступные для icmp-ping в моем примере. Для примера, а не для подражания возьмем для мониторинга IP крупных провайдеров: 213.180.193.3, 209.85.148.104. Я беру 2 IP для мониторинга так как по одному возможны ложные срабатывания. В реальной обстановке можно мониторить и сеть провайдера и хопы после его граничных маршрутизаторов.
Заходим в режим редактирования конфигурации из командной строки.

Учитывая, что в операционной системе Junos используется довольно стандартный демон ssh, я осмелился предположить, что организация ssh туннелей в нём реализована. И хотя в документации о таком применении коммутаторов, маршрутизаторов или межсетевых экранов не удалось найти упоминания — это работает. Мало того, ssh туннели разрешены по умолчанию.

Приведу пример, позволяющий продемонстрировать, где это может пригодиться.

Всю собственную внутреннюю сетевую инфраструктуру и соответствующие процессы корпорация Google собирается перевести на IPv6 уже в скором времени. Эта новость стала известна благодаря докладу Ирены Николовой, занимающей в Google пост инженера по сетевым коммуникациям. Николова также заявила, что переход на IPv6 может оказаться довольно непростым, поскольку компании придется столкнуться с рядом изменений.

Началось все 1 месяц назад. Клиенты нашей компании стали испытывать проблему при доступе в интернет. Проблема проявляется только у клиентов использующих роутеры и приставки STB. В течение дня, в разное время на оборудование были зафиксированы всплески активности продолжительностью 5-10 минут. Всплески могли происходит в любое время суток утром днем и вечером. Пример такого всплеска я покажу.

Мобильные устройства, такие как смартфоны, дали возможность потребителям получить доступ к растущему числу интерактивных и полезных приложений, в любое время, в любом месте. Однако, как только пользователь садится в автомобиль, доступ к таким приложениям и их возможностям резко ограничивается – либо потому, что есть ограничение для использования некоторых приложений в автомобильных информационно-развлекательных системах (IVI) либо из-за проблем взаимодействия с небольшим экраном мобильного устройства, подключенного к док-станции.

В течение многих лет, корпоративные пользователи использовали технологии удаленного терминала, такие как Virtual Network Computing (VNC) и удаленный рабочий стол Windows для удаленного доступа к компьютерам и устранения неполадок. Не так давно удаленный терминал нашел свою нишу в смартфонах, где терминальный клиент на телефоне позволяет пользователю видеть и контролировать удаленное приложение.

В автомобильной среде, все наоборот: смартфон становится сервером, а автомобильная информационно-развлекательная система становится клиентом. TCP/IP через Bluetooth или USB, как правило выступает в качестве основного протокола связи между телефоном и автомобилем, в то время как Bluetooth Serial Port Profile (SPP) или устройство USB-связи класса (USB CDC) осуществляет коммуникации на более низком уровне связи.

Этот специфический язык программирования, представленный на днях компанией Ebay, предназначен, по словам разработчиков, прежде всего для эффективного агрегирования API-функций для HTTP. В результате «на выходе» получается единый вызов с SQL-подобным синтаксисом. Компания создала этот декларативный событийный язык программирования для увеличения эффективности и производительности написания кода разработчиками, а также для снижения общего количества строк в коде.

Сразу оговоримся, не стоит воспринимать заголовок слишком буквально. Если звезды зажигают… и так далее.

Тем не менее, семейство протоколов Spannning Tree, если не отживает свой век в качестве основного инструмента резервирования в ethernet-сетях, то как минимум плавно перетекает в узкие и специфические ниши (само собой, их обсуждение выходит за всякие рамки этой статьи, но в приветствуется в комментариях).

И да, конечно, никто не отменял Spanning Tree как технологию защиты от человеческой ошибки.

В связи с ожидающим нас в скором времени событии: дне, точнее ночи, «не перехода на зимнее время», хочется рассказать про обновление базы временных зон на оборудовании компании Juniper Networks, Inc. исполняющем операционную систему Junos.

Сама процедура великолепно описана в документации представленной на сайте компании, в документе: "Setting a Custom Time Zone on Routers Running JUNOS Software". Я лишь расскажу о ней на родном языке и уточню отдельные детали.

Доброго времени суток! Не так давно «Билайн» организовал экскурсию-выезд для хабражителей — показать, как происходит подключение клиентов к Интернету по FTTB. Я постарался составить краткий конспект по рассказанному на встрече. Тем, кто близко знаком с работой домашних интернет-провайдеров вообще и Домашнего Интернета «Билайн» в частности, думаю, будет не очень интересно. А всем остальным — добро пожаловать под хабракат!

Недавно у нас были небольшие обучающие курсы для повышения нашей компетенции в сетевой части нашей инфраструктуры. Основную идею этих курсов, покрывающую OSPF/BGP/MPLS я тут повторять не буду ибо:

• Пока ещё явно недостаточно компетентен.
• Есть много более объективные ресурсы рассказывающие об этих темах.

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

Ссылки на вики зачастую более примечательны секциями «External links» и «References» нежели самим содержанием

Преамбула

Наверное, у каждого из нас дома немало цифровых медиа-устройств, общающихся по WiFi или подключённых к сети с помощью обычной витой пары. У меня, к примеру — КПК, нетбук, пара ноутбуков, пара компьютеров и ещё пара смартфонов. Последние (парочка Nokia 5800 Xpress Music), благодаря тому, что даже в ванной или в постели постоянно находятся под рукой, оказались самыми часто используемыми девайсами. Благо и серфинг, и общение через GTalk/Skype, и простенькие игрушки-убийцы времени — всё доступно. Вот только памяти у девайсов всего по 8 Гб, так что фильмов туда не шибко накидаешь, да и конвертировать, а потом заливать на смартфон каждый фильм — на это нужно время, а ведь есть ещё такая штука, как лень! Одним словом, захотелось иметь возможность как-то просматривать медиаконтент (и в первую очередь — видео) с домашнего сервера в любой момент, не конвертируя и не совершая лишних телодвижений.

• Почему в трейсроуте после узла X идут звездочки?
• Сервис не работает, а трейсроут обрывается на узле X — значит проблема в узле X?
• Почему одинаковые трейсроуты с Windows и Unix показывают разные результаты?
• Почему трейсроут показывает большие задержки на определенном узле?
• Почему трейсроут показывает «серые» адреса при трассировке через интернет?
• Почему маршрутизатор отвечает на трейсроут не тем адресом, каким я хочу?
• Почему трейсроут показывает какие-то «не такие» доменные имена?
• Почему вообще вывод трейсроута отличается от интуитивно ожидаемого чаще, чем хотелось бы?

Сетевые инженеры и администраторы в отношениях с трейсроутом делятся на две категории: регулярно задающие себе и окружающим эти вопросы и заколебавшиеся на них отвечать.

Сей топик не дает ответов на вышепоставленные вопросы. Или почти не дает. Но предлагает подумать, нужно ли их вообще задавать, и если да, то когда и кому.

Суть проблемы

Целью жизни коммутатора сетевого (он же свитч) является неустанная пересылка пакетов от отправителя получателю. Для оптимизации работы, свитч содержит т.н. CAM-таблицу, содержащую в себе адреса устройств, пакеты от которых он когда-то получал, и номера физических портов, из которых эти самые пакеты были получены.

Иными словами, если свитч недавно получил пакет от компьютера А в порт 1, то в таблицу заносится соответствие «комп. А» -> «порт 1», и дальнейшие пакеты, адресованные компьютеру А, автоматически пересылаются только в порт 1, и никуда больше, что экономит пропускную способность сети и делает неэффективными пассивные перехватчики траффика.

Но что делать свитчу, если приходит широковещательный пакет (broadcast)?
Логично предположить, что такие пакеты пересылаются во все порты, кроме того, откуда изначально были получены.
Что, при определённой конфигурации сети, может привести к весьма печальным последствиям…

Суть проблемы

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

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

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



Представьте себе коммутаторы, системы обнаружения и предотвращения вторжений, межсетевой экран и ещё кучу пряников внутри одной коробки.
Под катом рассказ о том, как это всё работает и какие преимущества даёт такая архитектура.

Возникла необходимость настроить себе дома удалённый доступ к рабочему компу (WinXP SP3). Обычное дело — с кем не бывает.
Для этого нужно настроить VPN соединение через L2TP. Тоже ничего особенного (интернет у меня сейчас напрямую провод в комп, без рутеров, VPN'ов и прочего шаманства). Все настройки и ключи получил у админа. Делаю всё буква в букву — а в ответ ошибка 678 — «Удалённый компьютер не отвечает».

RIPE NCC предложил два варианта оплаты используемых ресурсов на 2012 год. Данное предложение вынесено на публичное обсуждение в связи с тем, что изменения затронут всех владельцев автономных систем (AS) и PI (PA) блоков.
Основная суть предложений сводится к двум вариантам оплаты.
1. Независимо от размера организации, любой может получить статус LIR. При этом заключается прямой договор с RIPE NCC и производится соответствующая присвоенной категории оплата напрямую на счет RIPE в Нидерландах. В этом варианте не предусмотрено отдельных платежей за каждый выделенный ресурс.
2. Так же, независимо от размера организации, можно получить статус LIR. Отличие от первого варианта заключается в увеличении стоимости поддержки выделенного ресурса до 100 евро.

Для реализации данных вариантов расширено количество категорий LIR и добавлены XXS (extra-extra small) с ежегодным платежом 250 евро и XXL (extra-extra large) с ежегодным платежом 15000 евро (при использовании первой модели) либо 12500 евро (при использовании второй модели)

В мире высокочастотного трейдинга время пинга к серверу приобретает особое значение. Здесь каждая миллисекунда ценится на вес золота, и даже дороже. Очередное свидетельство тому — мегапроект компании Hibernia Atlantic по прокладке кабеля через Атлантический океан (подрядчик — Global Marine Systems). Стоимость проекта — более $300 млн. Инвестиции окупятся с лихвой, потому что за счёт более короткого маршрута этот кабель позволит клиентам Hibernia Atlantic совершать сделки на фондовой бирже за океаном на 6 миллисекунд быстрее, чем конкурентам.

Оптоволоконный кабель Hibernian Express длиной 6021 км свяжет Лондон и Нью-Йорк. Маршрут для прокладки вычисляли 18 месяцев с учётом рельефа морского дна и экономии каждого километра. Новый канал планируют подключить в 2013 году.

Нынешний лидер на рынке каналов для высокочастотного трейдинга, компания Global Crossing, обеспечивает пинг в 65 мс по трансатлантическому каналу AC-1. В новом Hibernian Express этот показатель уменьшат до 59 мс. По предварительной оценке, клиенты готовы платить за аренду полосы Hibernian Express в 50 раз больше, чем за AC-1.

P.S. В последний раз оптоволокно по дну Атлантического океана прокладывали во времена бума доткомов в конце 90-х.

via The Telegraph

Отказ от ответственности.

В данной статье пойдёт речь о логике выбора Root порта на коммутаторах выполняющих роль CIST Regional Root в мультирегионной имплементации протокола MST. В случае использования дельных советов и преступных выводов из этой статьи в производственных сетях предприятий, автор не несёт ответственности за ваши последующие действия, возможные сбои в функционировании вычислительной сети, частичную потерю данных и порчу оборудования.

Введение

Практически перед каждым администратором сети встает задача учета трафика. Либо это нужно для биллинга, либо просто для мониторинга активности.
Для решения этой задачи можно использовать стандартный протокол NetFlow (RFC 3954), который поддерживается производителями сетевого оборудования (Cisco, Juniper, 3Com и др.), а также Linux, *BSD и прошивкой DD-WRT. Netflow позволяет передавать данные о трафике (адрес отправителя и получателя, порт, количество информации и др.) с сетевого оборудования (сенсора) на коллектор. Коллектор, в свою очередь, сохраняет полученную информацию. В качестве коллектора можно использовать обычный сервер. Проиллюстрирую схему картинкой из википедии:



Когда я взялся настраивать NetFlow, оказалось что opensource решения для реализации коллектора плохо работают с Cisco ASA, а в Интернете очень мало информации, что в этом случае делать. Я решил восполнить этот пробел: подружить FreeBSD / Linux с Cisco ASA можно за 20 минут.