Amarao ([info]amarao_san) wrote,
@ 2008-09-27 00:55:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Компьютерные сети - простейшие основы принципов работы (часть 6)
краткая суть предыдущих уроков: уровни. 1,2.

Сегодня мы чуть-чуть поговорим о ppp.

Предыдущая беседа просто-таки наводила всеми силами на мысль, что есть второй уровень. И есть мак-адреса на нём.

Так вот, это не так. Второй уровень есть. А мак-адреса, может есть, а может и нет... Дело в том, что ethernet (и производные от него стандарты) обширны, могучи, популярны... - но не единствены. Помимо ethernet-семейста есть и другие протоколы второго уровня. С ethernet'ом совершенно не совместимые. Большинство из них (ATM, Frame Relay, IDSN) нас, как домашних пользователей (и даже админов, ура), не касаются. Хотя есть один весьма и весьма важный протокол второго уровня, который активно используется. Это PPP. Point to Point протокол. Протокол точка-точка.

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

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

ATZ
OK
ATM0L0+MS=11&N60
OK
ATDP3333333
OK

И только после такого (хорошо, если такого, бывает и хуже) шаманства модем начинает передавать байтики. Или не начинает, если вместо OK мы получим, например, NO CARRIER. Или CARRIER LOST. Или LOL GTFO. Или NO DIAL TONE. Или ещё какую ошибку.

Обычный™ протокол вышестоящего уровня совершенно не имеет намерения разбираться что там случилось и что модему надо говорить. Так что приходится использовать протокол, который понимает, что связи просто так не бывает, что она может рваться. Это, собственно, PPP. Заодно там есть место и для пароля (того самого, что на интернет-карточках печатают).

Важно понимать, что все эти особенности (а их у PPP по сравнению с ethernet'ом очень много) остаются на втором уровне. Третий (нам пока неизвестный) уровень работает так, как нам нужно. Это главная заслуга ppp.

Данные в ppp помещаются в кадры, но помимо кадров с данными, ppp ещё передаёт управляющие кадры. Например, вопрос "ты хто?" и ответ на него. Или сообщение "PNH", означающее окончание сессии. При этом, от узла, который делает сессию, ppp хочет много данных. (например, номер телефона, логин, пароль).

В случае шнурка LPT-LPT, примерно то же самое, только без "номера телефона". Кстати, можно с паролем (паранойя) или без.

PPP был бы умирающим стандартом, если бы не нашлись идиоты, которые бы его не прикрутили в обычные (нормальные) сети.

И назвали это PPPoE. Пыпыпы-о-малое-Е. PPP over Ethernet. Суть этого кошмара: мы вместо капризного модема используем существующий второй уровень (родимые маки, коммутаторы и прочие хорошо работающие вещи), и используем его как обычный модем. Т.е. устройство, которое принимает/передаёт данные. Не доверяя ему, мы помещаем данные не сразу в ethernet-кадры, но в собственные кадры, которые в свою очередь, помещаются во внутрь ethernet-кадров.

В замен мы получаем геморрой, возможность шифровать трафик на канальном уровне (ppp позволяет это) и (главное, ради чего ppp прикручивали к ethernet'у) - возможность спросить (передать) логин/пароль.

Так что в случае использования PPPoE работа выглядит так: компьютер, используя Ethernet, ищет сервер PPPoE в канальном сегменте. Находит его. Пытается установить соединение, в ходе соединения говорит логин/пароль, устанавливает соединение. Теперь, у нас вместо нормального ethernet есть ненормальный ppp, с которым всё-таки можно возлежать как с канальным протоколом (чтобы там насчёт этого не говорила Библия).

Обратите внимание: так же, как WiFi не совместим на физическом уровне с Ethernet, так же и PPP не совместим с Ethernet'ом. Он его может использовать - но не может сосуществовать (просто потому, что не использует адресацию Ethernet'а).

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



(Post a new comment)

браво.
[info]elektronik
2008-09-27 04:06 am UTC (link)
с нетерпением ожидаю каждой следующей серии. модель OSI для чайников c картинками. кстати общественность требует соответствующих картинок :-)

(Reply to this) (Thread)

Re: браво.
[info]amarao_san
2008-09-27 06:56 am UTC (link)
Это не модель OSI. Я не написал, но ppp на самом деле работает на двух уровнях NCP/LCP, отсутствующих в модели OSI и засунутых в модель TCP/IP задним числом.

(Reply to this) (Parent)(Thread)

ну ясно-понятно...
[info]elektronik
2008-09-27 05:59 pm UTC (link)
мну в общем. пафосное название. но картинки... где картинки ???

(Reply to this) (Parent)(Thread)

Re: ну ясно-понятно...
[info]amarao_san
2008-09-27 06:15 pm UTC (link)
См. фиг. 1.

(Reply to this) (Parent)


(Anonymous)
2008-09-27 02:42 pm UTC (link)
Кстати, неплохо бы проставить ссылки между частями...

(Reply to this)


[info]evg_krsk
2008-09-27 03:32 pm UTC (link)
Недурственно, недурственно...

(Reply to this)


[info]xellh
2008-09-29 08:32 am UTC (link)
Есть мнение, что PPPoE уже не модно :) Сейчас всё чаще используют L2TP. BTW, кто вам сказал, что главное, для чего прикручивается ppp - авторизация? :) Для этого уже несколько лет, как есть 802.1x. До этого был (местами и сейчас работает) веб-интерфейс, в котором вводился логин-пароль, после чего юзера пускало в инет.
На самом деле, IMHO, используя РРРоЕ или L2TP или любой другой метод инкапсуляции гораздо проще строить и администрировать сеть, и прилагать меньше усилий для построения "последней мили".

(Reply to this) (Thread)


[info]amarao_san
2008-09-29 09:11 am UTC (link)
моё личное мнение - для разрграничения доступа существуют замки на шкафы и виланы. Всё остальное - извращение, которое надо жечь калёным железом. Нафига что-то там туннелировать, когда можно просто маршрутизировать?

(Reply to this) (Parent)(Thread)


[info]xellh
2008-09-29 09:16 am UTC (link)
Вы никогда не думали про ограничения, накладываемые производителями оборудования по максимальному количеству виланов на устройстве? ;) А если юзеры захотят обмениваться файлами - запрещать? :) Да, виланы тоже можно инкапсулировать, но это будет такой пипец при последующем администрировании, что лучше туда не лезть... L2TP в свою очередь, работает гораздо эффективнее, чем PPPoE и на практике кушает значительно меньше процессорного времени на шлюзах доступа. Вообщем в настоящее время - must have.

(Reply to this) (Parent)(Thread)


[info]amarao_san
2008-09-29 09:23 am UTC (link)
Если юзвери захотят меняться файлами, они это будут делать на сетевом уровне, а не на канальном. Виланы нужны для разграничения канальных сегментов - всё последующее идёт через маршрутизацию. Хочу заметить, маршрутизация всяко выполняется быстрее (дешевле в рассчёте на порт), чем приём и разворачивание любых тунелей. Про такую мелочь, как тормоза на пользовательской машине вообще никто не думает (а заворачивать поток этак в 10-15Мбит/с это не так уж и просто, особенно, если включена шифрация).

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

Я откровенно не понимаю, что, кроме желания "введите пароль в интернет" и требований ФАПСИ может сподвигнуть на замену простого решения на сложное. Заметим, сложное для обоих сторон.

(Reply to this) (Parent)(Thread)


[info]xellh
2008-09-29 09:52 am UTC (link)
Если мы рассматриваем маршрутизацию на L3-свичах - это вообще ппц. Свич просто сдохнет от нагрузок на маршрутизацию. Если этим загрузить роутер, то мало того, что сдохнет от нагрузки сам роутер, так мы ещё и загрузим все магистрали до свичей. Конечно, можно пользоваться QoS, но это всё по-моему лишние пляски с бубном.
L2TP - не шифрует трафик. Он просто не предусмотрен для этого. Для его шифрации он заворачивается в IPSEC, но это делают исключительно при Enterprise применении, но никак не в домосетках.
про колиство виланов - я же правильно понял, что вы сторонник идеологии "каждому юзеру по вилану"? Смотрим банальный юзерский 48+2 портовый свич D-Link с гигабитным портом, на котором строятся домосетки: http://www.dlink.ru/products/prodview.php?type=13&id=85. И видим, что он поддерживает 64 статических VLAN, 255 динамических VLAN. Динамические виланы в метросети никто в трезвом уме применять не будет. А ядро нашей небольшой сети, предположим, построим на любимом админами гигабитном каталисте Cisco 2960 http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps6406/product_data_sheet0900aecd80322c0c.html у которого Up to 255 VLANs per switch. Т.е. мы не сможем подключить к нему больше 255 юзеров. :)
На самом деле, для включения L2TP провайдеру ничего не нужно кроме шлюза доступа и радиус-сервера. И после начальной настройки можно расслабиться и практически забыть о том, где и какие свичи стоят и какие на них настройки. Т.е. лучше следить за шлюзом и радиус-сервером, чем за большим зоопарком свичей.
Кстати, ФАПСИ откровенно пофиг на то, использует провайдер ppp или нет.

(Reply to this) (Parent)(Thread)


[info]amarao_san
2008-09-29 10:00 am UTC (link)
А, собственно, почему коммутатору с 48 портами нужно больше 48 виланов? Или у вас пользователи на неуправляемых коммутаторах сидят? В чём тогда смысл вилана?

L3 коммутаторы (вроде бы) маршрутизируют со скоростью среды. Во всяком случае, мне такое обещали в описании моего 3COM 4200G. Надо сказать, при загрузках до 2-3гигабит на коммутатор (маршрутизация) он вполне справляется. Если я неправ, ткни в пруфы.

В моём представлении (я никогда в провайдерстве не работал) красивая схема работы выглядит так:

user -100Mb- VLAN ----- 1Gb (uplink) ---- L3 commutator ~~~~ честная маршутизация.

Т.е. пользователи подключаются к управляемому коммутатору, коммутатор прокидывает пользователей к маршрутизирующему коммутатору, дальше идёт чистая маршрутизация.

Что в этой схеме работает не так?

(алсо, у меня провайдер дома - тиерра) примерно так работает. Без всяких тунелей. Да ещё и со статическими адресами у пользователей.

(Reply to this) (Parent)(Thread)


[info]xellh
2008-09-29 10:17 am UTC (link)
На скорости среды не маршрутизируют даже маршрутизаторы. Нормальные коммутаторы L3 КОММУТИРУЮТ на скорости среды. Про твой 3COM4200G - Сделай ему небольшой спуффинг SNMP-запросами и посмотри на загрузку проца. Подозреваю, что 1-2 хостов хватит, чтоб загрузка возросла на десяток-другой процентов. Надеюсь, что не нужно объяснять, что для маршрутизации используется процессор? Для ускорения маршрутизации, конечно, есть разные технологии типа цискиного CEF и это спасает... до определённого момента...
Что касается количества виланов - в твоей схеме при подключении к корневому L3 свичу 6-ти свичей, на нём (корневом свиче) кончатся виланы после подключения 255-го юзера. Что-нибудь ещё объяснить? ;)

(Reply to this) (Parent)(Thread)


[info]amarao_san
2008-09-29 10:24 am UTC (link)
Я понимаю, что он коммутирует. А SNMP-запросы у меня открыты только в managment VLAN.

Вот насчёт виланов, да. Проблема. 256 шт. И всего 8 (максимум) интерфейсов. SAD. Да, железки подкачали...

(Reply to this) (Parent)(Thread)


[info]xellh
2008-09-29 10:40 am UTC (link)
Ну вообще не всё так плохо. Существуют технологии специально для метро-сетей по инкапсулированию виланов, мультитегированию и т.п. Вообщем представь, что пакет можно обозначить как "это пакет от 2-го вилана, который в 10-м вилане". :)
Я вообщем не про сами SNMP-запросы, я скорее про оценку производительности процессора.
Вообще, по своему личному опыту, могу посоветовать не городить даже на L3-свичах маршрутизацию, а использовать её только как вспомогательную функцию, когда без неё уж совсем никак... Из последних фишек - включение полного дебага STP на корневом cisco 3560G и скромном прокачивании ~200Мбит даёт загрузку проца под 50%. Что было бы с сетью, если бы я на него повесил ещё OSPF, я боюсь подумать.
А ты про какое ограничение в 8 интерфейсов?

(Reply to this) (Parent)(Thread)


[info]amarao_san
2008-09-29 10:45 am UTC (link)
у 4200G ограничение на 8 интерфейсов для маршрутизации. (т.е. он может иметь не больше 8 адресов).

Насчёт "не городить"... У меня сейчас в сети (локальной, не считая всяких тунелей) 4 сегмента сети (серверный и пользовательские). С серверного на пользовательские идёт просто охрененный трафик от видео-наблюдения (те самые гигабиты). STP у меня просто некуда прикручивать - у меня чистая звезда (почти чистая), в которой все коммутаторы на одной стойке. Так что резервировать нечего.

Пока люди сидят в режиме сегмент=вилан, хочу сделать кучу виланов (у меня меньше 200 портов), по вилану на человека.

А про лаги при отладке... no ip cef кладёт циску (1841). Просто реально кладёт. Загрузка 100%, по ssh не подключиться, на пинги не отвечает.

(Reply to this) (Parent)(Thread)


[info]xellh
2008-09-29 10:58 am UTC (link)
Про STP - есть идиоты-пользователи, которые включают свич к 2-портам розеток. Неплохо бы от них обезопаситься. И не будем заыбвать, что если ляжет корневой свич, и такого же не окажется у поставщика, но мы можем запасаться вазелином. Т.е. корневых свича в правильной сети ДОЛЖНО быть 2.
Про каждому юзеру по вилану - а нафига? Обычно по отделам разбивается. Чего ты хочешь добиться то? Или искусство ради искусства? :) Дык не оценят...

(Reply to this) (Parent)(Thread)


[info]amarao_san
2008-09-29 11:13 am UTC (link)
У меня хитрее. У меня ДВА 4200G, при этом один из них занимается маршрутизацией, а второй на подхвате (как неуправляемый гигабитный коммутатор). Если один умирает, ценой небольшого торможения нескольких серверов, на его место встаёт второй :)

Во-первых, у пользователей нет двух розеток с ethernet'ом для свичей. Во-вторых, на 4200G стоит broadcast supression if >10%. (т.е. сетка не ляжет, но начнёт себя фигово вести - я прийду и надаю по ушам).

А виланы по отделам точно не нужны. Так что это действительно, искусство ради искусства, плюс тренировка (ради чего и работаем :).

(Reply to this) (Parent)(Thread)


[info]xellh
2008-09-29 11:24 am UTC (link)
Т.е. чтобы заменить предположительно убитый основной 4200G, ты должен будешь сначала на втором актуализировать прошиву, залить конфигурацию и потом переткнуть все патч-корды? Ну если производство позволяет, то почему бы и нет. А если 24х7 - то это далеко не лучший вариант...

(Reply to this) (Parent)(Thread)


[info]amarao_san
2008-09-29 11:31 am UTC (link)
Если бы у нас речь шла о 24х7, то всё было бы совсем по-другому. Как именно не знаю (на практике ни разу 24х7 не делал), но по-другому 100%.

У меня задача иметь аптайм, близкий к 100% в рабочее время. Пока удаётся - сервер БД и терминальный сервер уже более полу-года в рабочее время не перегружались ни разу.

Для замены 4200Г надо будет переткнуть порядка 10 проводов и загрузить конфигурацию. Умирание центрального коммутатора считается достаточной экзотикой, чтобы пользователи перетерпели 5 минут. Прошивки у них синхронные :)

(Reply to this) (Parent)


Create an Account
Forgot your login?
Login w/ OpenID
English • Español • Deutsch • Русский…