Comments 52
Отличная подача материала. Прочитал на одном дыхании! Спасибо :)
Аплинк == магистральный провайдер?
А если я сидя в Киеве запросил картинку котика из Вильнюса, может так случиться, что запрос пройдя по цепочке маршрутизаторов вернется на первый киевский маршрутизатор?
Да. Более того, так как табличка маршрутизации меняется со временем, может быть так, что со второго раза маршрутизатор отправит куда надо и котик до вас таки дойдёт, но с лагами.
Для отлова бесконечно гуляющих пакетов есть TTL, который уменьшается на единицу на каждом маршрутизаторе. Достиг нуля — пакет умирает.
Для отлова бесконечно гуляющих пакетов есть TTL, который уменьшается на единицу на каждом маршрутизаторе. Достиг нуля — пакет умирает.
Маленький провокативный вброс: ни один из читателей этой статьи к Интернету не подключен. Все подключены к сети своего провайдера, и не более.
С этим я бы поспорил — все кто получают IP address (Internet Protocol Address) находятся в Интернете, так как сеть скорее обуславливается протоколом, а не проводами: http://ru.wikipedia.org/wiki/IP
Даже те, кто получил IP-адрес в локальной сети, не подключенной к интернет?
нет, так как кроме использования протокола нужно еще иметь возможность обмениваться информацией с большей частью мира — в таком случае будете частью сети Интернет
иначе же можно будет сказать что и провайдер не подключен к Интернету, а подключен к другому провайдеру и так дойти до Tier 1 и сказать что Интернет — это они. На самом деле Интернет это система обьединения сетей по всему миру на основе IP.
Тут любопытный вопрос возникает: если, к примеру, обрубить все кабеля в Америку — где будет Интернет? В Америке или в Европе, Азии и Африке?
иначе же можно будет сказать что и провайдер не подключен к Интернету, а подключен к другому провайдеру и так дойти до Tier 1 и сказать что Интернет — это они. На самом деле Интернет это система обьединения сетей по всему миру на основе IP.
Тут любопытный вопрос возникает: если, к примеру, обрубить все кабеля в Америку — где будет Интернет? В Америке или в Европе, Азии и Африке?
Не будет Интернета. Увы. Ровно так же, как если порезать город на дома и лишить их связи друг с другом, то города не будет, а будут тысячи каменных коробок.
А если обрубить все кабеля в Канаду, то в Европе уже не будет Интернета, потому что не подключена Канада? Где ж граница когда будет Интернет или когда его не будет?
Будет, конечно. Интернет для того и планировался, чтобы обрыв кабелей переживать. Если у США есть связность с миром, а у Канады с США, то будет Интернет и в Канаде.
Более того, даже если между Европой и Америкой порубить все кабели, связность сохранится. Более того, даже если обрубить все кабели между Европой, Африкой и Америкой, связность сохранится.
Вам придётся перерубить все кабели, для того, чтобы лишить сеть связности. А с учётом, что сеть — она не просто так, придётся резать очень и очень много.
Землетрясения и злые акулы, а так же якоря и т.д. периодически это устраивают — и ничего, живёт. Хоть и не очень комфортно — но это уже другой разговор.
Более того, даже если между Европой и Америкой порубить все кабели, связность сохранится. Более того, даже если обрубить все кабели между Европой, Африкой и Америкой, связность сохранится.
Вам придётся перерубить все кабели, для того, чтобы лишить сеть связности. А с учётом, что сеть — она не просто так, придётся резать очень и очень много.
Землетрясения и злые акулы, а так же якоря и т.д. периодически это устраивают — и ничего, живёт. Хоть и не очень комфортно — но это уже другой разговор.
Суть вопроса не в устойчивости Интернета, а в том чем он определяется. Например если исключить одну страну из Интернета, Интернет будет существовать? А если континент? Вот в чем момент — нет четкого определения что такое Интернет и какими масштабами он определяется. Это уже становится каким-то филосовским вопросом.
Будет два интернета, американский и европейско-африканско-азиатский…
Но сделать флуд с поддельным адресом отправителя — легче лёгкого.Кстати, а почему, собственно? Я в своей домашней локалке (2 компа, 6 vlan-ов :)) и то блокирую пакеты с некорректными source ip из всех сетей включая оба провайдера, оба wifi и виртуальную сеть используемую виртуальными машинами. Что мешает всем провайдерам, работающим с пользователями, блокировать от них пакеты с некорректным source ip, или, хотя бы, делать это если не для каждого пользователя, то для подсетей/коммутаторов?
Кто-то должен непрерывно вести таблицу актуальности и не забывать обновлять. Пакетные фильтры часто мешают нормальной работе (т.к. приходится их срочно менять). Разворачивать же централизованную инфраструктуру для защиты от спуфинга — это дороговато и сложно, особенно, на зоопарке железа.
Извините, но я всё-ещё не понимаю, можно немного подробнее?
Как минимум, любой провайдер знает свои подсети, и их обычно не так уж и много, а новые добавляются не так часто. Точек (интерфейсов), где проходит исходящий трафик этого провайдера (т.е. без транзитного трафика других AS) тоже не так много. Что мешает в этих точках добавить блокирование трафика с source ip не из сетей этого провайдера? Поддержка этого много сил не займёт. Не идеальная защита, но ведь лучше, чем ничего?
Далее, все оконечные коммутаторы и/или сервера pptp/pppoe всё-равно нужно настраивать, прописывать IP-адреса пользователей, поддерживать всё это хозяйство — неужели добавление одного лишнего правила в пакетный фильтр на одного пользователя заметно усложнит настройку или поддержку?
Я понимаю, что добавление фильтра по source ip — добавит работы по настройке/поддержке. Но на мой взгляд это «добавит» выразится в пренебрежимо малом значении относительно текущих усилий. По-моему, это не делают не потому, что это дорого обойдётся в поддержке или заметно что-то усложнит, а просто потому, что этого можно и не делать — для общей работоспособности системы это фича опциональная, а значит на неё можно забить, вне зависимости от того, насколько много или мало усилий нужно для её внедрения.
Как минимум, любой провайдер знает свои подсети, и их обычно не так уж и много, а новые добавляются не так часто. Точек (интерфейсов), где проходит исходящий трафик этого провайдера (т.е. без транзитного трафика других AS) тоже не так много. Что мешает в этих точках добавить блокирование трафика с source ip не из сетей этого провайдера? Поддержка этого много сил не займёт. Не идеальная защита, но ведь лучше, чем ничего?
Далее, все оконечные коммутаторы и/или сервера pptp/pppoe всё-равно нужно настраивать, прописывать IP-адреса пользователей, поддерживать всё это хозяйство — неужели добавление одного лишнего правила в пакетный фильтр на одного пользователя заметно усложнит настройку или поддержку?
Я понимаю, что добавление фильтра по source ip — добавит работы по настройке/поддержке. Но на мой взгляд это «добавит» выразится в пренебрежимо малом значении относительно текущих усилий. По-моему, это не делают не потому, что это дорого обойдётся в поддержке или заметно что-то усложнит, а просто потому, что этого можно и не делать — для общей работоспособности системы это фича опциональная, а значит на неё можно забить, вне зависимости от того, насколько много или мало усилий нужно для её внедрения.
От чего вся эта защита защищает провайдера? Оно ему нужно? Такие фильтры очень опасны, потому что могут приводить к массовым отказам в обслуживании. Провайдер получил себе ещё один диапазон — его надо пойти и прописать. Забыл — выдал пользователям — имеешь жалобы на неработу интернета, которую некомфортно отлаживать.
«Пренебрежительно малое значение усилий» будет только в пренебрежительно малой сети. У крупных провайдеров, с большими, постоянно меняющимися сетями, это будет постоянной головной болью. Поэтому они это и не делают.
Приведу пример.
Я — провайдер, у меня одна AS, два-три аплинка, 2-3 префикса.
У себя на бордерах (пограничных маршрутизаторах) я могу сделать (и делаю :)) фильтр — всё, что улетает от меня в мир с чужими адресами — под нож. Всё отлично, все счастливы.
Теперь посмотрим на моего аплинка. У него 100 своих префиксов и 500 клиентов. Ему уже надо делать фильтр для своих адресов плюс транзитных (адресов клиентов) — уже сложнее. А потом кто-то из его клиентов решит анонсировать префиксы еще одной AS (своего клиента), которая анонсирует еще своих клиентов… Неразбериха, в общем.
А если это Tier 1, который просто физически не может построить фильтры?
Вот так и получается.
Я — провайдер, у меня одна AS, два-три аплинка, 2-3 префикса.
У себя на бордерах (пограничных маршрутизаторах) я могу сделать (и делаю :)) фильтр — всё, что улетает от меня в мир с чужими адресами — под нож. Всё отлично, все счастливы.
Теперь посмотрим на моего аплинка. У него 100 своих префиксов и 500 клиентов. Ему уже надо делать фильтр для своих адресов плюс транзитных (адресов клиентов) — уже сложнее. А потом кто-то из его клиентов решит анонсировать префиксы еще одной AS (своего клиента), которая анонсирует еще своих клиентов… Неразбериха, в общем.
А если это Tier 1, который просто физически не может построить фильтры?
Вот так и получается.
Я думал именно для этого ведется RIPEdatabase. У вашего апстима в базе есть запись:
import: from AS12345 accept AS-EXAMPLE
В свою очередь в as-set'e AS-EXAMPLE в полях members указаны AS-члены данной as-set. А за этими AS уже закреплены какие-то сети…
Тогда, когда клиент апстрима (AS12345) решит анонсировать префиксы еще одной AS:
— клиент добавит еще одного member в as-set
— у апстрима по крону запустится какой нибудь rtconfig, который выполнив кучу рекурсивных запросов к RIPEDB сгенерирует конфигурационный файл и зальет его на маршрутизатор
Или я не прав? Я вот на днях сам только начал вникать в эту кухню…
import: from AS12345 accept AS-EXAMPLE
В свою очередь в as-set'e AS-EXAMPLE в полях members указаны AS-члены данной as-set. А за этими AS уже закреплены какие-то сети…
Тогда, когда клиент апстрима (AS12345) решит анонсировать префиксы еще одной AS:
— клиент добавит еще одного member в as-set
— у апстрима по крону запустится какой нибудь rtconfig, который выполнив кучу рекурсивных запросов к RIPEDB сгенерирует конфигурационный файл и зальет его на маршрутизатор
Или я не прав? Я вот на днях сам только начал вникать в эту кухню…
Долго вглядывался в карту, пока понял, что север на ней — снизу.
Почему-то, увидев кота, я вначале подумал, что это «та же кошка, только без проводов» ;)
Очень круто написано, спасибо!
Пишите еще. :)
Пишите еще. :)
А есть ли какой-нибудь софт который как же как и traceroute позволяет отследить путь пакета через какие AS он передался?
Вы не поверите:
# traceroute -A 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 31.28.26.100 (31.28.26.100) [AS29076] 0.162 ms 0.161 ms 0.185 ms
2 ae6-55-rt1.msk.cloud-ix.net (217.65.1.37) [AS29076] 10.447 ms 10.453 ms 10.457 ms
3 google-gw.msk.cloud-ix.net (89.188.100.46) [AS29076] 10.512 ms 10.512 ms 10.518 ms
4 209.85.250.224 (209.85.250.224) [AS15169] 25.637 ms 209.85.250.222 (209.85.250.222) [AS15169] 25.573 ms 209.85.250.224 (209.85.250.224) [AS15169] 25.662 ms
5 209.85.249.173 (209.85.249.173) [AS15169] 25.527 ms 25.540 ms 25.549 ms
6 72.14.233.172 (72.14.233.172) [AS15169] 25.404 ms 72.14.233.168 (72.14.233.168) [AS15169] 25.399 ms 72.14.233.172 (72.14.233.172) [AS15169] 25.407 ms
7 * * *
8 google-public-dns-a.google.com (8.8.8.8) [AS15169] 25.426 ms 25.439 ms 25.427 ms
Спасибо, не знал об этом ключе.
Только ключ не кросс-платформенный.
C:\Users\kyberorg>tracert -A 8.8.8.8
-A не является допустимым параметром команды.
Использование: tracert [-d] [-h максЧисло] [-j списокУзлов] [-w таймаут]
[-R] [-S адресИсточника] [-4] [-6] конечноеИмя
Параметры:
-d Без разрешения в имена узлов.
-h максЧисло Максимальное число прыжков при поиске узла.
-j списокУзлов Свободный выбор маршрута по списку узлов (только IPv4).
-w таймаут Таймаут каждого ответа в миллисекундах.
-R Трассировка пути (только IPv6).
-S адресИсточника Используемый адрес источника (только IPv6).
-4 Принудительное использование IPv4.
-6 Принудительное использование IPv6.
Только ключ не кросс-платформенный.
C:\Users\kyberorg>tracert -A 8.8.8.8
-A не является допустимым параметром команды.
Использование: tracert [-d] [-h максЧисло] [-j списокУзлов] [-w таймаут]
[-R] [-S адресИсточника] [-4] [-6] конечноеИмя
Параметры:
-d Без разрешения в имена узлов.
-h максЧисло Максимальное число прыжков при поиске узла.
-j списокУзлов Свободный выбор маршрута по списку узлов (только IPv4).
-w таймаут Таймаут каждого ответа в миллисекундах.
-R Трассировка пути (только IPv6).
-S адресИсточника Используемый адрес источника (только IPv6).
-4 Принудительное использование IPv4.
-6 Принудительное использование IPv6.
За сноску [4] в статье — отдельное спасибо. «Это же блин, поэзия!» Прочитал на одном дыхании статью по ссылке, и всем советую — весьма ладный литературный слог, и тема.
Возможно, [для всех кто в ТК-бизнесе] это уже скучная хрестоматия за 2010-год и боян. Но мне, кодеру, довелось узнать про ту интригу впервые, читалось как художественное произведение.
Возможно, [для всех кто в ТК-бизнесе] это уже скучная хрестоматия за 2010-год и боян. Но мне, кодеру, довелось узнать про ту интригу впервые, читалось как художественное произведение.
www.kipchatov.ru/blog/?p=295 — еще более давнишняя, но веселая, как раз и объяснит (если прочитать все), что Интернет делится на американский и на остальной
Ничего, что я бы не знал, но прочитал с удовольствием.
Однако, как говорили выше, что считать Интернетом — философский вопрос. «интернет» (с маленькой буквы) — это сеть сетей. А «Интернет» — это уже нечто иное, на более высоком уровне абстракции.
Мой веб-сервер, подключенный к Интернету через публичный адрес не является частью Интернета?
Однако, как говорили выше, что считать Интернетом — философский вопрос. «интернет» (с маленькой буквы) — это сеть сетей. А «Интернет» — это уже нечто иное, на более высоком уровне абстракции.
Мой веб-сервер, подключенный к Интернету через публичный адрес не является частью Интернета?
А какое оборудование используется на границах AS обычно и какая среда передачи (ведь там объем трафика огромен)?
Между AS там чаще всего коммутаторы (10G), если же стык прямой, то соответствующие маршрутизаторы (MX'ы джунипера, 6-тонники от циски, например). Т.к. аплинков много, то преимущественно там либо 1G, либо 10G, либо бонд из нескольких 10G. 40G и выше — острая экзотика из-за стоимости порта.
Что у себя tier1 в самых нагруженных местах использует, или гугль на стыках ютуба — не знаю.
Что у себя tier1 в самых нагруженных местах использует, или гугль на стыках ютуба — не знаю.
AS тоже разными по размерам бывают. Так что тут полная свобода творчества. То, что вы написали, это скорее про IX'ы.
Так же, широко используется WDM.
А Гугл не пытается сделать самые толстые в мире каналы, а вместо этого используют территориально распределенные CDN.
Так же, широко используется WDM.
А Гугл не пытается сделать самые толстые в мире каналы, а вместо этого используют территориально распределенные CDN.
А среда передачи — мультимодальная оптика или что-то другое?
они берут трафик и доносят сквозь стужу, тракторы и медведей.
Весь прошитый трафиком, абсолютно весь
O_o-медведь в Сибири есть.
Надо ещё сказать, чаще всего магистралы деньги берут за полосу, по 95% персентилю, и по тому, какого было больше — исходящего или входящего.
И платят только за одно направление? Получается что закачка фильма из дома на условный ютуб — скорее всего бесплатна всем?
Какой простор для оптимизаций. Сразу хочется регулировать симметрию трафика по аплинкам, чтобы одним направлением «подпирать» другое. На это и расчёт?
Насколько я знаю, платят за 95% персентиль. Не важно в каком направлении. Бывают специальные условия (коммерческий рынок — как договорятся, так и будет), но чаще всего именно так.
Что такое 95% персентиль? Условно говоря, полоска, разделяющая 95% и 5% трафика на графике. Входящего и исходящего трафика. То есть 5% бёрста им прощают, а вот оставшееся, даже если это было 94% 1 мегабит и 6% 1 гигабит, будут оплачены как 1Гбит/с.
Оптимизация — да, разумеется. Но чаще всего симметрии нет. У adsl-операторов входящего больше исходящего практически всегда, у хостеров исходящего всегда больше, у домашних сетей — не знаю, но слышал жалобы, что исходящего больше, чем входящего (потому что рейты на торрентах качают).
Что такое 95% персентиль? Условно говоря, полоска, разделяющая 95% и 5% трафика на графике. Входящего и исходящего трафика. То есть 5% бёрста им прощают, а вот оставшееся, даже если это было 94% 1 мегабит и 6% 1 гигабит, будут оплачены как 1Гбит/с.
Оптимизация — да, разумеется. Но чаще всего симметрии нет. У adsl-операторов входящего больше исходящего практически всегда, у хостеров исходящего всегда больше, у домашних сетей — не знаю, но слышал жалобы, что исходящего больше, чем входящего (потому что рейты на торрентах качают).
Спасибо за статью!
Sign up to leave a comment.
Повесть о настоящем Интернете