routing О пользе знания *** - на пальцах

[amanita 0]

Привет мальчикам и девочкам.

Сижу, праздник, 23 февраля. Делать нечего, надо как то себя занять и развлечь. Озадачился - что бы сделать полезного. Когда то заходил на сайт Российских точек обмена трафиком, интересовался статистикой, видел там и Ростовскую IX. Потом забыл, а вот сегодня случайно выплыло, понадобилось посетить один ресурс на сети провайдера-конкурента (ЦТС).

Вот и решил в качестве развлечения накатать небольшой пост по статической маршрутизации, а точнее о применении ее любимой вкупе с иксами (IX, точками пиринга) и несколькими провайдерами. Ибо для тех, кто не сталкивался с маршрутизацией в сетях это просто пустой звук и. Возникает непонимание, для чего оно вообще и как ее применить например дома/на работе.

Из за чего же весь сыр-бор? Вот из за этого:

Это какой-то хост на сети ЦТС Ростов-на-Дону. Нехилые пинги, неправда ли? Больше чем до Яндекса, а город то Ростов...

Смотрим почему:

Такс, понятно. Мы к Ростовским провайдерам-конкурентам ходим через Москву . В Ростове вообще то есть точка обмена трафиком - RND-IX, однако Билайн там по каким то причинам не присутствует, а если и присутствует, то не пирится ни с кем из местных. Ну вот не комильфо Би этим заниматься... (в МСК впрочем ЕМНИП та же песня, но - могу ошибаться). Можно конечно долго рассуждать на тему политики Би в отношении строительства сетей, проектов CDN и прочего, но рассуждениями делу не поможешь. В общем, негоже нам трусы через голову одевать к себе же в город через МСК ездить, накладно. Будем исправлять это недоразумение.

Применимо сие у тех людей, у которых помимо Билайна есть еще один провайдер (запасной), как например у меня - СПАРК. Все телодвижения производятся совершенно аналогичным образом и при любых других провайдерах, просто нужно уточнить, есть ли поблизости какая-либо IX и подключен ли один из ваших провайдеров к этой самой IX-e.

И так, идем сюда и смотрим мемберов (участников) Ростовской IX. Упс , как интересно то, оказывается там присутствует СПАРК (AS44775), который сисдит у меня в качестве резервного канала и загружается только, если я обращаюсь к mirror.yandex.ru, ибо оно локально на СПАРК-е, и качать оттуда много приятнее (50-60 МБит/с), чем через Билайн.

Будем городить маршруты на Ростовских провайдеров через СПАРК, нечего каналу зря простаивать.

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

Убедимся, что хост доступен (можно было взять любой хост на сети ЦТС, лишь бы отвечал на запросы):

Живой.

Проверяем, будет ли профит от перенаправления трафика через СПАРК на ЦТС:

route add -host 77.66.144.23 178.76.237.249

178.76.237.249 - это мой шлюз в сети СПАРК-а (статика у меня, да).

Результат проверки:

Афигеть, как говорят в Интернетах... Разница на лицо таки . Посмотрим, какой дорогой ходят пакеты:

Видно, что пакеты не покидают Ростова на Дону, а идут через RND-IX туда, куда надо, только значительно быстрее. Скриншоты привожу специально из под Windows с трассой, так удобнее отслеживать маршрут, железок у меня много, так что пакеты могут ходить не совсем так, как задумывает админ

Теперь вопрос, где узнать IP-адреса (префиксы) сетей тех провайдеров, к которым мы хотим направить трафик через точку обмена, а не через жопу Москву? Это можно сделать тут например, благо дело номера автономных систем (AS) нужных нам провов у нас есть. Рассматривать полный список маршрутов не имеет смысла, т.к. все прописывается по аналогии. Сделаю для ЦТС (AS6767):

Prefix --------------- Description

77.66.128.0/20 --- CJSC "Comstar-Regions"

77.66.144.0/20 --- CJSC "Comstar-Regions"

77.66.160.0/21 --- CJSC "Comstar-Regions"

77.66.168.0/21 --- CJSC "Comstar-Regions"

77.66.176.0/20 --- CJSC "Comstar-Regions"

77.66.192.0/21 --- CTS-InterNet, Shakhty city, Rostov region

77.66.200.0/21 --- Krasnodar Branch of Comstar-Regions

77.66.208.0/20 --- CJSC "Comstar-Regions"

77.66.224.0/20 --- CJSC "Comstar-Regions"

77.66.240.0/20 --- CJSC "Comstar-Regions"

80.80.96.0/19 --- CJSC "Comstar-Regions"

94.77.128.0/18 --- CJSC "Comstar-Regions"

95.139.0.0/19 --- CJSC "Comstar-Regions"

95.139.96.0/20 --- CJSC "Comstar-Regions"

95.139.112.0/20 --- CJSC "Comstar-Regions"

213.27.0.0/19 --- IP address space for Rostov-on-Don Regional Data exchange Network

213.27.32.0/19 --- CJSC "Comstar-Regions"

213.27.64.0/18 --- CJSC "Comstar-Regions"

Делаем:

ee /etc/rc.conf

Заносим туда маршруты:

# Route 2 CTS (AS6767) via SPARK and RND-IX
route_cts1="-net 77.66.128.0/20 178.76.237.249"
route_cts2="-net 77.66.144.0/20 178.76.237.249"
route_cts3="-net 77.66.160.0/21 178.76.237.249"
route_cts4="-net 77.66.168.0/21 178.76.237.249"
route_cts5="-net 77.66.176.0/20 178.76.237.249"
route_cts6="-net 77.66.192.0/21 178.76.237.249"
route_cts7="-net 77.66.200.0/21 178.76.237.249"
route_cts8="-net 77.66.208.0/20 178.76.237.249"
route_cts9="-net 77.66.224.0/20 178.76.237.249"
route_cts10="-net 77.66.240.0/20 178.76.237.249"
route_cts11="-net 80.80.96.0/19 178.76.237.249"
route_cts12="-net 94.77.128.0/18 178.76.237.249"
route_cts13="-net 95.139.112.0/20 178.76.237.249"
route_cts14="213.27.0.0/19 178.76.237.249"
route_cts15="213.27.32.0/19 178.76.237.249"
route_cts16="213.27.64.0/18 178.76.237.249"
static_routes="cts1 cts2 cts3 cts4 cts5 cts6 cts7 cts8 cts9 cts10 cts11 cts12 cts13 cts14 cts15 cts16"

Теперь на AS6767 (читай ЦТС) трфик будет ходить значительно быстрее. При необходимости аналогично поступаем и с остальными участниками RND-IX.

З.Ы. Бегло глянув на префиксы сетей ЦТС можно проверить - не пересекаются ли эти сети между собой, если да, то можно оптимизировать количество маршрутов.

---

Да, можно это:

77.66.128.0/20 --- CJSC "Comstar-Regions"

77.66.144.0/20 --- CJSC "Comstar-Regions"

77.66.160.0/21 --- CJSC "Comstar-Regions"

77.66.168.0/21 --- CJSC "Comstar-Regions"

77.66.176.0/20 --- CJSC "Comstar-Regions"

77.66.192.0/21 --- CTS-InterNet, Shakhty city, Rostov region

77.66.200.0/21 --- Krasnodar Branch of Comstar-Regions

77.66.208.0/20 --- CJSC "Comstar-Regions"

77.66.224.0/20 --- CJSC "Comstar-Regions"

77.66.240.0/20 --- CJSC "Comstar-Regions"

Привести к виду 77.66.128.0/17, тогда уменьшится количество записей отдельных сетей, и как следствие - сама таблица маршрутизации. Для чего таким образом анонсируются сети в ЦТС - не в курсе, возможно им так удобнее. Соответственно и эту запись:

213.27.0.0/19 --- IP address space for Rostov-on-Don Regional Data exchange Network

213.27.32.0/19 --- CJSC "Comstar-Regions"

213.27.64.0/18 --- CJSC "Comstar-Regions"

Можно записать как 213.27.0.0/17, в итоге получем:

route_cts1="-net 77.66.144.0/17 178.76.237.249"

route_cts2="-net 80.80.96.0/19 178.76.237.249"

route_cts3="-net 213.27.0.0/17 178.76.237.249"

route_cts4="-net 95.139.96.0/19 178.76.237.249"

route_cts5="-net 94.77.128.0/18 178.76.237.249"

static_routes="cts1 cts2 cts3 cts4 cts5"

Вместо 16 записей всего 5.

---

Теперь самое интересное: какой вообще профит от этого? А вот какой - например, если на сети провайдера ЦТС есть гровой сервак, который смотрит в мир. ИМХО приятнее играть, если пинг до серванта 6 мс, а не 42. VoIP опять же. В общем, профит будет там, где нужна минимальная задержка.

Пост не претендует на божественную откровенность или гениальность мысли. Ничего нового или сногсшибательно прогрессивного в сообщении нет. Показано, что иногда полезно заглядывать на совсем не пользовательские ресурсы (http://www.ix.ru) для решения совершенно житейских пользовательских вопросов. Просто объединение разрозненной информации воедино.

FreeBSD в данном посте взята как пример, на любых других роутерах все настраивается согласно инструкции.

С уважением, Я

[amanita 0]

В догонку Ростелеком:

До:

gate# ping 83.221.209.218
PING 83.221.209.218 (83.221.209.218): 56 data bytes
64 bytes from 83.221.209.218: icmp_seq=0 ttl=54 time=56.289 ms
64 bytes from 83.221.209.218: icmp_seq=1 ttl=54 time=56.490 ms
64 bytes from 83.221.209.218: icmp_seq=2 ttl=54 time=56.581 ms
64 bytes from 83.221.209.218: icmp_seq=3 ttl=54 time=55.961 ms
64 bytes from 83.221.209.218: icmp_seq=4 ttl=54 time=56.173 ms

После:

gate# ping 83.221.209.218
PING 83.221.209.218 (83.221.209.218): 56 data bytes
64 bytes from 83.221.209.218: icmp_seq=0 ttl=53 time=39.315 ms
64 bytes from 83.221.209.218: icmp_seq=1 ttl=53 time=40.211 ms
64 bytes from 83.221.209.218: icmp_seq=2 ttl=53 time=39.513 ms
64 bytes from 83.221.209.218: icmp_seq=3 ttl=53 time=39.622 ms
64 bytes from 83.221.209.218: icmp_seq=4 ttl=53 time=39.714 ms
64 bytes from 83.221.209.218: icmp_seq=5 ttl=53 time=40.422 ms
64 bytes from 83.221.209.218: icmp_seq=6 ttl=53 time=39.815 ms

Полегчало немного.

[Гость Nemo]

а можно то же самое только для идиотов, чайников?

[amanita 0]

а можно то же самое только для идиотов, чайников?

Можно. С картинками, так оно понятнее.

Предположим, в г. Ростове есть N-е количество провайдеров. Часть из них имеет собственные магистрали на Москву, Европу и т.д., часть - ареднует каналы, это в общем не важно. Важно другое - несколько провайдеров собрались и решили построить ГСПД - Городскую Сеть Передачи Данных (Metro-LAN), для удобства зарабатывания денег например или в целях экономии. Технология роли не играет, главное, что решили строить вместе, например по причине дороговизны строительства, или для того, что бы в ГСПД мог попасть кто угодно от какого угодно провайдера, даже если этого провайдера нет в том р-не, где есть Клиент. Клиент как водится всегда прав, ибо платит бабки.

Так вот, что бы данную затею осуществить, нужно где то построить стыки провайдерских сетей. Не будем брать финансовую сторону, нам не важно, как они (провайдеры) между собой потом рассчитываются за пропущенный трафик соседей через свои сети. Главное - построили. Так вот то самое место - стыки провайдерских сетей или точки обмена трафиком нас и интересуют. На картинке ниже нарисовано:

RND-IX это и есть тот самый стык. Таких IX - точек обмена достаточно много, основные тут описаны.

Теперь представим себе, что в Ростов заявилась компания-провайдер (Билайн), имеющая свои магистрали, и, по каким-то меркантильным интересам не желающая подключаться к Ростовской иксе. Ну может ее туда не пускают, ибо конкурент, или наоборот - Билайн например продает трафик на MSK-IX, а если подключится в Ростове - естественно часть трафика будет оседать на Ростовкой IX, в общем - не важно. Важно то, что ежели простой юзер, подключенный к Билайну сделает ping 77.66.144.23 (на картинке нарисовано - это хост ЦТС, находящийся в Ростове на дону физически), то юзер немного припухнет от ответа, ибо как писал выше:

Пинг просто заоблачный для хостов, расположенных в одном городе и на полностью рабочих сетях. Так же выше (следующая картинка) есть пояснение - почему такое происходит. А происходит это по тому, что пакет с ПК подключенного к Билайну по-умолчанию уходит на Москву, там, на московском стыке переходит обратно на ростовскую магистраль того провайдера, где расположен пингуемый хост, т.е. что бы из Ростова попасть в Ростов пакет проделывает 2400 км пути по неизвестно на сколько загруженным магистралям. Эффект известен - высокий пинг + возможны потери. Теперь допустим, что у нас есть резервный канал, на "всякий случай", который простаивает до поры - до времени (пока работает основной). Что нам это дает? А ничего не дает, если не изучить весьма полезый сайт. После изучения становится ясно, что некоторые Ростовские провайдеры (в основном старые) имеют точки подключения к той самой ГСПД Ростова-на-Дону RND-IX. А это в свою очередь значит, что если мы и сидим на Билайне, то нам совсем не обязательно ждать аж 42 мс, что бы наши данные попали на хост того же ЦТС. Мы просто можем завернуть трафик, который должен попадать в Ростов на Дону на RND-IX, только и всего.

На рисунке желтым цветом показан путь трафика из Ростова в Ростов по-умолчанию (без настроек маршрутов). А зеленым цветом - с настройками. Согласитесь, 42 мс и 6.5 мс - это таки две большие разницы, как говаривают в Одессе

Вот как то так, об этом я и написал.

З.Ы. На всякий случай напишу, почему трафик ходит именно так, а не иначе. Как минимум по той причине, что бы не загружать магистраль. Ведь понятно, что не 100% юзеров сидят на европейских сайтах или американских, проценов 70 трафика крутится в России, из этих 70 % - приличный кусок крутится в тех же городах, где он и генерируется. Таким образом проще и дешевле (особенно, если магистраль на МСК не резиновая и тем паче арендованная) пириться прямо на месте, т.е. в Ростове в данном случае.

За чем так делает не делает Билайн - тайна покрытая мраком. Возможно, как я писал выше - трафик нужен в большом количестве в МСК или СПБ. Тогда конечно нет смысла оставлять его на местах. Возможно, есть какие-то политические предпочтения - например, использование сугубо собственных магистралей. В общем, хз. Да и не важно это, главное, что при настройке сетей и нескольких провайдерах не следует забывать про возможность получить бонус в виде малого времени отклика сервисов сети, халявного трафика и прочей радости. Многие об этом даже не задумываются.

Понятно описал суть?

[Gun-13 0]

Весьма полезная информация) спасибо за лекцию Андрей :-)

[amanita 0]

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

Предыстория: Клиент хочет помимо всяких плюшек типа резервирования канала, IPTV, гигов порно трекера, анлима в частном доме по цене анлима в многоэтажках (читай Билайн/ТТК/СПАРК) обычный домашний телефон. История долгая, но сводится к тому, что за телефон выкатили сумму 80000 р. (ну вы поняли, кто этот провайдер).

Схемка в голове нарисовалась в общем то простая и понятная:

Решено делать проброс из квартиры Клиента по радиоканалу его домашнего номера в частный дом, тем более, что домашних телефонов у Клиента аж 2 (ЦТС и ЮТЫКА).

Из доступного железа для решения этой задачи есть например D-Link, конкретно DVG-7111S. Фото этой мыльницы можно посмотреть там же. За настройку этого китайского чудо-девайса и возьмемся:

- Первое на что стоит обратить внимание, так это не стандартный адрес самих VoIP шлюзов - 192.168.8.254

- Второе - подключение возможно только с порта LAN этого девайса.

- Кроме WEB-морды присутствует и telnet для хардкорных адептов шелла

- Ни в коем случае нельзя напрямую соединять FXO и FXS порты - от такого обращения девайсы обижаются и дохнут как тараканы от дихлофоса. Соответственно и в FXS порт втыкать патч от АТС тоже крайне не рекомендуется. Я не просто так расписываю страсти-ужастики про порты, дело в том, что комплектный бумажный мануал кардинально отличается от электронного (PDF в аттаче к посту), и, видимо рассчитан на австралийских аборигенов с синдромом дауна, которым вообще пох на цыферки и обозначения (отсканирую - выложу ради прикола).

В общем, приступаем.

1. Настраиваем WAN на железках на статический IP-адрес. Та железка, которая подключена на схеме в квартире к АТС (VoIP1[601]) на WAN-порту будет иметь адрес 192.168.1.200/24 шлюз 192.168.1.1

Та железка, которая находится у Клиента в частном доме (VoIP2[701]) будет иметь адрес на WAN-порту 192.168.1.201/24 шлюз 192.168.1.1

2. Настраиваем остальное:

VoIP1(601)Voip Setup -> Lan

VoIP2(701) Voip Setup -> Lan

VoIP1(601) Advanced -> Voip -> Phonebook

VoIP2(701) Advanced -> Voip -> Phonebook

VoIP1(601) Advanced -> Voip -> Hotline

VoIP2(701) Advanced -> Voip -> Hotline

---

Общие настройки на обоих шлюзах:

VoIP1(601) и VoIP2(701): Advanced -> Voip -> Codec

VoIP1(601) и VoIP2(701): Advanced -> Voip -> Pulse Andr DTMF

---

Настройки линий:

VoIP1(601): Advanced -> Voip -> Line

VoIP2(701): Advanced -> Voip -> Line

Если не совсем ясно из настроек на скриншотах, то объясню: VoIP шлюзы насраиваются по принципу точка-точка, т.е. для VoIP1(601) шлюзом будет VoIP2(701) и наоборот соответственно. Голосовой трафик бегает между ними.

Вся эта система проверялась в сборе на обычной локалке, как она поведет себя при выводе ее в радиоканал - неизвестно, однако полагаю, задержка в 2-3 мс не очень повредит качеству связи.

Теперь касаемо всех схемы в общем:

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

- При настройке следует учесть тот момент, что сеть может быть взломана, и Клиент попадет на 100500 тыр за секс по телефону с Испанией или звонки в Израиль . Ничего не мешает поставить аналогичный шлюз у себя и совершить звонок с домашнего телефона Клиента куда-нибудь на Кубу например, или в США. У меня был печальный опыт с одной фирмой. Там поставили АТС, VoIP оборудование, однако к настройкам всего этого железа меня не подпустили, фирма - филиал в Ростовской Области, головная контора в МСК, их админ и настраивал АТС... Забыл сменить пароли или просто прощелкал - не известно, известен результат - меня вызвали разбираться с тем, кто наговорил по телефону на НГ сумму около 300000 р. с Мексикой и на телефоны Инмарсат - тот кто решил поздравить с НГ друзей знал толк в извращениях был в курсе расценок Так что пароли по возможности ставить самые заковыристые и шифрованием радиоканала, сокрытием SSID и ACL-ами на БС и CPE тоже не стоит пренебрегать.

- остальное железо, планируемое к установке: роутер MikroTik RB750G или GL (какой получится купить). Обзор этой (и подобных ей в том числе) железки тут, вобще MikriTik штука весьма серьезная, как говорят некоторые админы "Микротик это маленькая Циска" . Свитчи - тупые мыльницы, например от TP-Link (D-Link не рекомендую, т.к. они "позеленели" - стали использовать ф-цию энергосбережения, как на счет экономии не в курсе, но глюки эта технологии в работу сети привносит просто космические). STB и телик - на вкус и цвет как говорят фломастеры разные - выбор весьма широк, тот же Билайн предлагает штук 5 ЕМНИП разных приставок для IPTV. Канальное оборудование - по необходимости (сильно зависит от того, какое расстояние и какую скорость нужно получить в канале под нагрузкой), но в любом случае - либо UBNT либо опять же - MikroTik (купить можно у меня ).

Вот как то так... Будет время и настроение, расскажу как правитльно настроить RB750 и его аналоги для рабты в сети Билайн и не только.

С уважением, Я

З.Ы. Как и обещал, выкладываю фото руководства, которое идет в комплекте к DVG-7111S (сканнер правда что то не завелся, сфоткал на фотоаппарат, но, от этого смысл написанного там не изменился ).

DVG-7111S_Manual.pdf

[amanita 0]

Возвращаясь к нашим баранам теме пиринговых войн. (удивительно, но наш местный Пифия/Нострадамус оказался прав)

Пинг на ТТК Ростов с Билайна:

C:\Windows\system32>ping 188.244.128.1

Обмен пакетами с 188.244.128.1 по с 32 байтами данных:
Ответ от 188.244.128.1: число байт=32 время=126мс TTL=117
Ответ от 188.244.128.1: число байт=32 время=125мс TTL=117
Ответ от 188.244.128.1: число байт=32 время=159мс TTL=117
Ответ от 188.244.128.1: число байт=32 время=159мс TTL=117

Статистика Ping для 188.244.128.1:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 125мсек, Максимальное = 159 мсек, Среднее = 142 мсек

C:\Windows\system32>

Трасса на ТТК Ростов с Билайна:

C:\Windows\system32>tracert 188.244.128.1

Трассировка маршрута к 188.244.128.1 с максимальным числом прыжков 30

 1	<1 мс	<1 мс	<1 мс  192.168.1.1
 2	<1 мс	<1 мс	<1 мс  vpn255-lo0.rnd.corbina.net [85.21.230.15]
 3	<1 мс	<1 мс	<1 мс  dolm185-rs1-giga2-0-2.rnd.corbina.net [85.21.230
.55]
 4	 1 ms	<1 мс	<1 мс  62.141.95.125
 5	56 ms	67 ms	56 ms  64.208.222.201
 6	62 ms	62 ms	73 ms  cjs-company-transtelecom.ethernet16-1.ar4.fra4.gblx.net [208.178.194.174]
 7   124 ms   138 ms   124 ms  rdn15.transtelecom.net [217.150.41.110]
 8   126 ms   125 ms   124 ms  188.244.128.1

Трассировка завершена.

Легким движением руки штаны преврщаются...превращаются отклик меняется на:

C:\Windows\system32>ping 188.244.128.1 -t

Обмен пакетами с 188.244.128.1 по с 32 байтами данных:
Ответ от 188.244.128.1: число байт=32 время=39мс TTL=116
Ответ от 188.244.128.1: число байт=32 время=38мс TTL=116
Ответ от 188.244.128.1: число байт=32 время=39мс TTL=116

Статистика Ping для 188.244.128.1:
Пакетов: отправлено = 3, получено = 3, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 38мсек, Максимальное = 39 мсек, Среднее = 38 мсек
Control-C
^C
C:\Windows\system32>

Трасса:

C:\Windows\system32>tracert 188.244.128.1

Трассировка маршрута к 188.244.128.1 с максимальным числом прыжков 30

 1	<1 мс	<1 мс	<1 мс  192.168.1.1
 2	 1 ms	<1 мс	<1 мс  178.76.237.249
 3	 1 ms	 1 ms	 1 ms  core-west-vlan6.spark-rostov.ru [86.110.173.113]

 4	 1 ms	 1 ms	 1 ms  178.76.213.109
 5	<1 мс	<1 мс	<1 мс  noc-ix-vlan11-10g.spark-rostov.ru [86.110.173.9]

 6	<1 мс	<1 мс	<1 мс  jmx80-xe0-0-0.10.rst.electro-com.ru [86.110.185.2]
 7	<1 мс	<1 мс	<1 мс  jmx80-xe1-2-0.110.rst.electro-com.ru [86.110.185.18]
 8	21 ms	21 ms	21 ms  mx480-ae0-u303.electro-com.ru [178.76.255.109]
 9	22 ms	21 ms	21 ms  msk-m9-b1-ge0-0-6.fiord.ru [93.191.9.9]
10	21 ms	21 ms	21 ms  217.150.44.66
11	38 ms	38 ms	38 ms  rdn15.transtelecom.net [217.150.41.110]
12	40 ms	44 ms	38 ms  188.244.128.1

Трассировка завершена.

Таки 125 и 38 мс это действительно "две большие разницы" © Одесса мама

Это СПАРК как можно понять из трассировки... Я писал, что ЧСВ руководства провайдеров до добра не доводит.

...Завернул 188.168.0.0/16 и 83.234.9.0/24 на СПАРК... Если в предыдущих трассах еще можно сомневаться на счет перекрытия кислорода на наших IX, то трасса до 83.234.9.0/24 ставит все по местам - мы в Питер ходим через Амстердам:

C:\Windows\system32>tracert 83.234.9.55

Трассировка маршрута к 83.234.9.55 с максимальным числом прыжков 30

 1    <1 мс    <1 мс    <1 мс  192.168.1.1
 2    <1 мс    <1 мс    <1 мс  vpn255-lo0.rnd.corbina.net [85.21.230.15]
 3    <1 мс    <1 мс    <1 мс  dolm185-rs1-giga2-0-2.rnd.corbina.net [85.21.230
.55]
 4    <1 мс    <1 мс    <1 мс  62.141.95.125
 5    58 ms    56 ms    66 ms  ethernet2-2.ar1.arn2.gblx.net [64.208.170.101]
 6    56 ms    55 ms    55 ms  ae10.csr2.arn3.gblx.net [67.17.74.45]
 7    57 ms    57 ms    57 ms  ae1.ar9.ams2.gblx.net [67.16.130.182]
 8    57 ms    57 ms    57 ms  208.178.194.178
 9    91 ms    91 ms    91 ms  217.150.39.218
10    94 ms    94 ms    95 ms  b57-atlac-1.spb-teleport.ru [217.148.211.61]
11    98 ms    99 ms    98 ms  83.234.9.55

Трассировка завершена.

C:\Windows\system32>ping 83.234.9.55

Обмен пакетами с 83.234.9.55 по с 32 байтами данных:
Ответ от 83.234.9.55: число байт=32 время=99мс TTL=115
Ответ от 83.234.9.55: число байт=32 время=98мс TTL=115
Ответ от 83.234.9.55: число байт=32 время=98мс TTL=115
Ответ от 83.234.9.55: число байт=32 время=98мс TTL=115

Статистика Ping для 83.234.9.55:
   Пакетов: отправлено = 4, получено = 4, потеряно = 0
   (0% потерь)
Приблизительное время приема-передачи в мс:
   Минимальное = 98мсек, Максимальное = 99 мсек, Среднее = 98 мсек

Пизданулись на всю голову, вспоминаю 90-е годы...

[amanita 0]

IPTV сквозь роутер MikroTik RB450G. Варианта всего 2:

1. один из портов бриджем объединить с т.н. WAN - тем портом, который светит в локалку Билайна, и к нему совать приставку.

2. попробовать таки завести приставку не прямо с локальной сети Би, а из домашней - за NAT.

Первй вариант подходит тем, кому пох на все и хочет только смотреть ТВ без заморочек - таким путем пошли в Билайне и выпустили в мир чудо китайской инженерной мысли - роутер DIR-300 с прошивой Билайна. Там именно так реализована схема включения приставки.

На мой взгляд - костыль, ибо приставка не видит в таком случае сеть за NAT и медиа-ресурсы в "домашней" сети - 100500 гигов порно музыку и фотографии. На ПК за роутером врядли получится посмотреть бесплатные каналы. Плюс - потенциальный геморой с блокировкой порта, когда при вываливании нескольких MAC на порт происходит блокировка (а DIR***, как и некоторые другие представители китайской фауны грешат тем, что вываливают MAC-адреса всех устройств, находящихся за NAT в случае сбоя девайса)* Серега, поправь меня если не прав - может сеть за кучу MAC на порту уже не блокируют? Я хз, давно ACL не видел - не в курсе... Короче - херня, а не схема.

Второй вариант подходит всем, т.к. лишен указанных недостатков, плюс имеет некоторые плюсы, но, увы, не любой маршрутизатор из категории до 2500 тыр умеет такое проделывать. Короче, мы простых путей не ищем, реализуем п.2.

Методом сложнейшего анализа:

сука, медитировал над зеркалированием порта и снифером часа 3 , не меньше - потом выяснилось, что Микротик сам умеет показывать все что нужно не хуже отдельного снифера блиать!!! И зеркалировать ниче не надо было!!! Ну, как говорится - дурак на своих ошибках учится. Мануал надо было почитать сначала

выяснил как настроить IPTV на MikroTik RB450/450G/750/750G и аналогах. Все просто как

1. IGMP Proxy жизненно необходим. Ставим пакет Multicast.npk (льется с сайта Микротика).

2. После установки и включения пакета Multicast ребутаемся, пакет переходит в активное состояние.

3. В консоли пишем:

/routing igmp-proxy interface add alternative-subnets=0.0.0.0/0 disabled=no interface=ether1-gateway threshold=1 upstream=yes
/routing igmp-proxy interface add disabled=no interface=bridge threshold=1 upstream=no

где routing igmp-proxy interface add alternative-subnets=0.0.0.0/0 disabled=no interface=ether1-gateway threshold=1 upstream=yes как становится ясно из написанного, говорит, что IPTV будет идти с интерфейса ether1-gateway

а /routing igmp-proxy interface add disabled=no interface=bridge threshold=1 upstream=no говорит завернуть IPTV в бридж (в микротиках т.н. LAN не существует изначально, так что если нам надо получить например из 5 портов 1 WAN + 4 LAN, то мы просто 2-5 порты объединяем бриджом и говорим, что это у нас свитч).

4. Прописываем маршрутик на 233.33.0.0/16 сеть. Отпраляем ее опять же на ether1-gateway (в ту дырку, куда воткнут провайдерский кабель):

/ip route add comment="IPTV" dst-address=233.33.0.0/16 gateway=ether1-gateway

5. Прописываем (у кого ip получается по DHCP - не прописываем) маршрут на сетку 78.107.196.0/24 (я хз если честно 24-я она или нет, но на всякий случай дал /24) - это видимо серваки, откуда собственно сыпется IPTV:

/ip route add dst-address=78.107.196.0/24 gateway=ether1-gateway

6. Добавляем правила для Firewall:

/ip firewall filter add chain=input action=accept protocol=udp src-address=78.107.195.0/24 in-interface=ether1-gateway

Разрешили UDP с адресов 78.107.195.0/24

/ip firewall filter add chain=input action=accept protocol=igmp in-interface=ether1-gateway

Разрешили IGMP.

Вроде ничего не забыл... Наслаждаемся IPTV на ПК, IPTV на приставке за NAT, слушаем музЫчку на приставке с домашнего DLNA-серванта или шары и смотрим фотографии. Я таки надеюсь, нет - просто верю, что возможность смотреть фильмы на приставке появится рано или поздно, ибо приставка IPTV от Билайна - просто зверь, дело лишь в программном ограничении возможностей приставки.

З.Ы. Почему собственно MIkrotik? *совсем сильно опечалил* мыльницы т.н. SOHO своим непредсказуемым поведением, ну и цена/качество (не реклама, взята пара для примера с ценами и производительностью):

Характеристики 450G

Характеристики 750GL

[amanita 0]

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

Собственно:

- Компания, крупная. 3 офиса. Третий офис ввиду малозначительного влияния не рассматривается.

- Оборудование в офисах - шлюзы IDECO (2 штуки), система СКУД, IP-телефония (Asterisk, АГАТ, хз чего то там еще - внешняя и внутренняя), IP-камеры наблюдения+регистраторы, ПК в количестве от 40 до 100+ в каждом офисе, всякая активная IP-мелочевка.

- 1 провайдер, дающий в разных офисах Интернет оптикой. Офис 1 - 5 мБит/с, офис 2 - 10 мБит/с.

- Между офисами VPN через внешку, разруливается IDECO. В VPN гуляет IP-телефония, доступ к БД, RDP и прочая бухгалтерско-офисная-бизнес-радость...

------------------------------------

Звонок от счастливого Клиента:

- Здравствуйте, вы настраиваете микротик?

- Да, настраиваем. Стоимость работ 800 р/час.

- Отлично, у нас есть 3 офиса, их нужно объединить между собой. Нам провайдер дал VLAN между 2-мя из 3-х офисов 20 мБит шириной. Это возможно?

- Какое у вас оборудование?

- 3 черных металлических коробки с белой надписью MikroTik. (догадываюсь, что это RB450 или аналог).

- У вас есть свой админ?

- Да, но он что то не разобрался с железками...

- Не вижу проблем, могу настроить [идиот, не видя схемы сети даю согласие!!!].

........

Приезд в офис, разговор:

- Можно глянуть на схему сети?

-

- обрисуйте в общем что и как расключено...

- ну у нас на IDECO красиво рисуются графики и все тут заведено. В общем, IDECO периодически глючит, будем отказываться от него. А между IDECO-ами у нас VPN, там бегает SIP ну прочая ерунда...

- ладно, что хотим то получить?

- что бы все работало

- ладно, начнем в ...[дважды идиот, опять схемы нет - соглашаюсь, еще и сроки даю...]

-------

Приезд и начало работы:

Познакомился с админом (весьма толковый админ к слову). Схемы сети нет, ибо никому в голову не приходило, что может понадобиться (вот в этом месте мне стоило взять 800 р за приезд, и откланяться до того момента, пока схема не будет предоставлена, но нет ведь, русский авось меня заборол...).

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

Тот самый ахтунг нарисован на схеме 2-мя желтыми молниями-стрелками, адресное пространство то однако в офисах - одинаковое.

Второй по значимости ахтунг - в случае подачи того самого VLAN, внешка так же будет приходить отдельным VLAN-ом (до этого просто VLAN, но Untag на концах). В случае подачи канала между офисами трафик весь тегирован. Соответственно задача по разруливанию VLAN-ов ложится на микротики, ибо 2 железки, способные это сделать есть, но стоят ЗА IDECO в качестве тупых свитчей (CISCO-чего-то там и DLink DES-1210-52) - обе L2, но на них, как на многопортовых железяках-свитчах висит банально вся локалка офисов за маршрутизаторами...

Ахтунг номер 3 - адресацию в офисах менять нежелательно...

В общем, про секс с 13-00 одного дня до 4 утра следующего рассказывать не буду, ибо это просто вынос мозга вчистую. Вкратце напишу:

- Микротики оказались таки 450G, славная железка, но отчего то полноценный роутинг во VLAN на них не завелся. Собираюсь купить себе пару таких и поковырять (если Клиент отдаст по сходной цене конечно).

- В порт Ether1 обоих в обоих офисах заведен кабель прова и привязаны VLAN c VID=xx и yy соответственно, где xx - это ID VLAN-а по которому приходит Интернет, yy - ID VLAN-а между офисами.

- На интерфейсе VLAN xx поднят NAT, пакеты бегают, Интернет пашет. Однако, почему то забегают во VLAN yy, последствия такого "забегания" - ниже...

- На интерфесйсе VLAN yy при поднятии NAT (ибо подсети переекаются) - пакеты бегают, но, БЛИЯТЬ, не работает SIP с АТС АГАТ...Отечественная разработка, куле... При убиении NAT на одном из микротиков появляется односторонняя слышимость, что тоже не утраивает, ибо связь таки не пашет. При убиении NAT на обоих микротиках связь работает, SIP пашет на ура, однако, видимо образуется петля через сеть прова и VLAN между офисами (на схеме - Black Hole), ибо сеть начинает так штормить и штырить, что достучаться до самих микротиков становится невозможно... Я молчу уже про то, что железки одного офиса получают IP из другого офиса (пока не поднимается шторм) со всеми вытекающими... Остановились на схеме с 1-м NAT как на временном промежуточном варианте.

В 04-00 утра я отвалил спать домой.

----------

В 12-30 позвонил Клиент и сказал, что все глючит дико, и хорошо бы вернуть все как было.

Приехал, повыдергивал микротики, поставил с обеих сторон (в обоих офисах) DLink DIR-100 пошитые свитчами. Разрулил по дыркам DIR-100 отдельно внешку, отдельно локалку (тот самый злосчастный VLAN, из за которого весь сыр-бор начался). Клиент в одном из офисов сменил таки адресацию, сеть стала плоской, теперь не /24 а /20 - на всякий случай. С портов внешка уходит на IDECO, с IDECO уходит на обоих сторонах во VLAN. Дабы железки из одного офиса не получали IP из другого офиса на свитче DES-1210 админу рекомендовано повесить ACL на тот порт, куда входит шнурок от DIR-100 с правилом [drop UDP 67, 68] (рубить DHCP во VLAN-е между офисами).

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

Вывод:

- Всегда, даже если сеть из 2-х железок - 100 раз подумать и 200 раз нарисовать на бумаге, ибо не факт, что потом не появится 3 (4, N-я железка) и вся схема, работавшая хоть как то перестанет работать чуть менее чем полностью.

- Всегда, даже при строительстве сети кажется, что проект железобетонный и не будет меняться - думать наперед, ибо если придется перестраивать, то не факт что это выйдет сделать с минимальными усилиями (я например отводил на всю настройку с учетом разъездов по офисам 3,5 часа времени - а хер там, не уложился )

- И на старуху бывает проруха (это я про себя - нех говорить, что сделаю не ознакомившись с мероприятием полностью и досконально) - сам себе злобный буратин блиять, сколько раз зарекался без схемы не работать!!!

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

Короче - кому хочется, учитесь на моих ошибках, а не на своих.

-----------------------------

З.Ы. Хотелось бы узнать, коллеги, кто практиковал эдакий анальный дзен-шамаизм с объединением 2-х сеток с полностью пересекающимся адресным пространством и наличием в обоих сетях необходимых для доступа ресурсов? Есть мнение, что нужно юзать встречный NAT в общую подсеть с более широким адресным пространством, а маршруты к нужному шлюзу дергать исходя из DNS-имени того или иного ресурса в той или иной сети... Мысль крутится в голове, но - пока не оформилась. Может кто пнет в нужную сторону?

[amanita 0]

Хвастаюсь:

[Allexis 0]

Спасибо за статейку, разобрался с адресами, прописал, пометил через mangle. Всё работает, но по поводу профита хотел бы добавить, что на том же дом.сру куча вареза расположенна никак не в Ростове. Значит чудо профит мы получим, лишь для сегмента сети каждого провайдера, а не для всей сети в целом (в случае дом.сру).

[amanita 0]

Спасибо за статейку, разобрался с адресами, прописал, пометил через mangle. Всё работает, но по поводу профита хотел бы добавить, что на том же дом.сру куча вареза расположенна никак не в Ростове. Значит чудо профит мы получим, лишь для сегмента сети каждого провайдера, а не для всей сети в целом (в случае дом.сру).

Ну про варез как бы речь и не шла... В случае Дом.ру (на данный момент) ЕМНИП юзаются магистрали ТТК (для Ростова), со всеми вытекающими плюсами и минусами. А уж вам решать, как пойдут пакеты например до Германии - через Би или ТТК. Речь то о приложениях, для которых критическим параметром является например время отклика (игрушки), голос/видео (стабильность канала) а не толщина канала до сервака.