Перейти к содержимому
Калькуляторы

Как же строить сеть. Новый топик для обсуждений

на ASR1004 с нужными модулями уже совсем другой ценник.

Вообщем я бы даже сказал некооректно сранивать ERX и ASR, тут наверное правильнее сравнение MX серия и ASR

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

на ASR1004 с нужными модулями уже совсем другой ценник.

Вообщем я бы даже сказал некооректно сранивать ERX и ASR, тут наверное правильнее сравнение MX серия и ASR

То есть ASR по вашему не дотягивает как брас по функционалу до ERX ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опять же не нужно забывать что ASR программный маршрутизатор хоть и очень мощный, а erx аппаратный. и цисковские 10GE реально 5GE фулдуплекса (если я не ошибаюсь).

ERX-310 это тоже 5GE full-duplex. :(

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

на ASR1004 с нужными модулями уже совсем другой ценник.

Вообщем я бы даже сказал некооректно сранивать ERX и ASR, тут наверное правильнее сравнение MX серия и ASR

То есть ASR по вашему не дотягивает как брас по функционалу до ERX ?

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

Субьективно IOS-XE (ASR) может тоже что и JunOSe (ERX) может даже чутоку больше, фактически на ASR софт еще сырой - утечки памяти и etc, т.к. какие-то детские болезни. В то время как JunOSe годами проверенный софт.

Не буду разводить холиваров, ибо не уполномочен, да и не объективно это. Мне как потребителю без разницы ERX или ASR, просто что было возможным пощупать, пощупал, мнением поделился, что ERX нравится пока больше чем ASR, ключевое слово "пока".

 

 

 

Опять же не нужно забывать что ASR программный маршрутизатор хоть и очень мощный, а erx аппаратный. и цисковские 10GE реально 5GE фулдуплекса (если я не ошибаюсь).

ERX-310 это тоже 5GE full-duplex. :(

по Release Notes я понял именно как по Full 10G, если же на самом деле Half 10G, то конечно печаль. Спорить не буду, может не так понял. Волнующих этот параметр, могут задать вопрос вендору или ресейлерам.
Изменено пользователем shicoy

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот что вычитал:

http://www.cisco.com/en/US/docs/ios/ios_xe...de_Chapter.html

 

General IP Session Restrictions

Packet of Disconnect (PoD) is not supported for IP subscriber sessions.

IP subscriber sessions are not supported on ambiguous IEEE 802.1QinQ (QinQ) or IEEE 802.1Q (Dot1Q) subinterfaces.

IP subscriber sessions are not supported on interfaces that receive multiprotocol label switching (MPLS) packets.

 

Если я правильно понял IOS-XE (ASR) в версии 2.6 не поддерживает схему доступа 1:1 VLAN (vlan-per-subscriber) с инкапсуляцией абонетских вланов в QinQ. JunOSe (E,ERX) умеет.

Более того PoD для IP сессий в JunOSe так же поддерживается. Про MPLS не скажу, не знаю.

Изменено пользователем shicoy

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Товарищи просили Апнуть тему.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Давно мусолится вопрос перехода с ПППоЕ/ППТП на ИПоЕ. Поэтому спрашиваю: какие преимущества есть в последнем способе предоставления трафика.

 

Добавлю свои замечания по этому.

ИПоЕ более подходит телекомам с развитым магистральным оборудованием, предоставлением только Интернет + свистульки а-ля ИПТВ (кстати кто-то реально СТБ растыкал или до сих пор пока все играются с этим, но это так, не принципиально). Для домашней сети с локальным трафиком и локальными сервисами особого плюса не предосталвяет. При ИПоЕ имеем проблему оптимального использования реальных ИП (обсуждалось не раз).

ИПоЕ удорожит саму сеть из-за мощного центрального оборудования (БРАС/БСР) и из-за этого применение в малых сетях малоприемлемо. А ведь в центр таких железок ставить надо от 2 штук... А лицензии (ведь рано или поздно лавочку прикроют)...

 

Плюсы очевидны: простота развертывания услуг, ничего не надо настраивать у клиента, нациконтроль трафика.

По поводу НАТ не НАТ тоже двояко отношусь к этому: с одной стороны при ИПоЕ логично сразу выдавать клиенту реальный ИП. С другой как-то ссыкотно на все эти зверьсиди отдавать реальник, хотя можно прикрыть 1024 и выше порты, запретить setup-пакеты к клиенту, итд итп блаблабла. Но этим ограничением можно спугнуть клиентов, им по барабану (да-да, так и есть!) как предоставляется Интернет - хоть ПППоЕ, хоть ВПНщина, хоть 1в1 НАТ, хоть реальник. И они правы. Это вам скажет любой админ, который в свое время производил миграцию PPPoE <-> VPN.

 

И еще одно.

Все мощные железяки а-ля ASR100x, Juniper MX80, ALUшки железяки имеют хороший запас прочности по к-ву сессий ПППоЕ. Напрашивается вывод: стоит ли овчинка выделки? Не продолжать ли и дальше развивать ПППоЕ путем горизонтального наращивания железяк для терминирования необходимого к-ва сессий? Ведь при ПППоЕ и громандом количестве сессий по сути упираемся в производительность БРАСов?

 

Жду ваших комментариев.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

PPPoE неплохой вариант, сформировался как промышленный стандарт и все такое, юрики визжат от него.

Различные VPN PPTP/L2TP это костыли пионернета, когда просто других доступных технологий не было. Тогда, да и сейчас многие строят L3 сети доступа, а при отсутствии вменяемого оборудования (на момент создания сети) как раз и приводило к решениям с VPN. И которых тянуться до сих пор, потому как спрыгнуть с одной технологии на другую это как капитальный ремонт в квартире (а ремонт как известно это маленький пожар).

 

Какие есть общие недостатки схем с тунелями (pppoe/pptp/l2tp)?

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

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

3) Иногда возникающие чучела с экзотическими ОС которые не умеют/не могут/нет поддержки тех самых l2tp/pptp

4) При современном скоростей, затраты на икапсюляцию и связанный с ними оверхэд становится непозволительно высоким.

5) Может что-то еще, на вскидку не вспомню

 

Какие минусы у IPoE

1) Необходимость более качественной сети доступа (более надежная защита от подмены IP/MAC и т.п.) - кажется вопрос решенный у всех

2) Более сложные схемы аутентификации абонента (либо source ip, либо mac, либо opt82) и соотвественно необходимая адаптация биллинга

3) Требуются схемы ограничения доступа (файрволы) (в отличии от классических тунелей когда достаточно было дропнуть тунель и потом отказать в авторизации).

 

На самом деле, с IPoE не все так сложно, для аккаутинга можно использовать старый добрый netflow, для ограничения доступа acl на коммутатора или iptables, ограничение скорости - статические правила формируемные раз в NN минут/часов по информации из биллинга.

И для этого не требуется мегажелезки за мегабаксы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну и успокойте про реальные IP тогда уж. Как пользователю отдать 1-2-4-6-10 реальных IP? Только IP unnumbered на вланах и спасет. Не так ли?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

4) При современном скоростей, затраты на икапсюляцию и связанный с ними оверхэд становится непозволительно высоким.
ерунда...

 

 

самый большой плюс пппое - централизация и абсолютно по барабану что на доступе стоит - хоть мыльницы! - то есть для тех кто начинает сложно купить сразу Л2 коммутатроы в необходимом количестве!

 

конечно если деньги на апаратуру есть - то ипое - то что доктор прописал! и ещё большой плюс ипое - простота настройки и то что можна врубить любую железяки которые почти со 100% увереностю работают с ип но не умеют тунелирование.

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну и успокойте про реальные IP тогда уж. Как пользователю отдать 1-2-4-6-10 реальных IP? Только IP unnumbered на вланах и спасет. Не так ли?
Давайте уж так, надо 1 IP или 2-4-6-10?

Вот с реальниками правильной таблетки нет. Либо дорого по железу, либо дорого по IP адресам, либо что-то среднее но получается pppoe. :)

 

 

4) При современном скоростей, затраты на икапсюляцию и связанный с ними оверхэд становится непозволительно высоким.
ерунда...

 

 

самый большой плюс пппое - централизация и абсолютно по барабану что на доступе стоит - хоть мыльницы! - то есть для тех кто начинает сложно купить сразу Л2 коммутатроы в необходимом количестве!

 

конечно если деньги на апаратуру есть - то ипое - то что доктор прописал! и ещё большой плюс ипое - простота настройки и то что можна врубить любую железяки которые почти со 100% увереностю работают с ип но не умеют тунелирование.

Я бы не сказал что ерунда, при скоростях свыше 10Мбит, уже чувствуется.

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

Насчет строительства сетей, не встречал последние 3 года тех кто начинает с 0, у всех за плечами или уже опыт + пионернет, либо инвестиции с интеграторами.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну и успокойте про реальные IP тогда уж. Как пользователю отдать 1-2-4-6-10 реальных IP? Только IP unnumbered на вланах и спасет. Не так ли?
Давайте уж так, надо 1 IP или 2-4-6-10?

Вот с реальниками правильной таблетки нет. Либо дорого по железу, либо дорого по IP адресам, либо что-то среднее но получается pppoe. :)

а что в пппое гладко когда надо 2-4-10 реальников ?

или несколько соединений - что тупо - либлибо маршрутизировать подсеть на интерфейс пользователя....

 

в ипое с иннамберед более нормально оно выглядит - а замаршрутизировать подсеть ещё проще - если статические адреса выдаются

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

либлибо маршрутизировать подсеть на интерфейс пользователя....
Именно, причем это правильно и в варианте с IPoE. Идеологически правильно иметь только точка-точка с абонентом т.е. /32, а все остальное при необходимости роутить через эту точку.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

либлибо маршрутизировать подсеть на интерфейс пользователя....
Именно, причем это правильно и в варианте с IPoE. Идеологически правильно иметь только точка-точка с абонентом т.е. /32, а все остальное при необходимости роутить через эту точку.

то есть с реальниками больше одного - получается абсолютно одинаково

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ситуации разные бывают, иногда какой нить юрик просит скажем /28 и без всяких доп. шлюзов /30, вот тут начинаются извраты.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

про мыльнице на доступе нет, воткну я в такую мыльницу свой pppoe который отвечает акцептом на любой запрос, соберу за вечер логин/пароли соседей и за чирик продам знакомым.
ну типа да - но это уже надо немножко разбираться - а поменять адрес если ипое + тупари - любой вася сможет!

поэтому тупари пРи ппое - с натяжечкой но можна - при ипое - категорически нельзя

 

 

Ситуации разные бывают, иногда какой нить юрик просит скажем /28 и без всяких доп. шлюзов /30, вот тут начинаются извраты.
иииии как ?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Какие минусы у IPoE

1) Необходимость более качественной сети доступа (более надежная защита от подмены IP/MAC и т.п.) - кажется вопрос решенный у всех

 

Ситуации разные бывают, иногда какой нить юрик просит скажем /28 и без всяких доп. шлюзов /30, вот тут начинаются извраты.
иииии как ?

По разному, как правило vlan от абонента до центра и какие-то полиси на l2 уровне. С аккаутингом сложнее, но netflow пока спасает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я вот что не понял. В споре про "пионерский" NetFlow и "крутой" Радиус Акаунтинг.

 

Радиус - это хорошо. Считать деньги (время сессии, объемы переданных/принятых байт).

Но он же подробную статистику IP source-destanation вам не даст?

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

Хорошо.

Неужели органы не требуют хранить подробную статистику посещений год или даже три?

СОРМ - это хорошо - но только выборочно кого-то прослушивать (я имею ввиду, что записывать такие объемы никто не будет, поэтому либо по ключевым словам , адресам, либо слушать конкретных "подозреваемых")....

Статистику посещений по всем юзерам они не собирают....

 

И второе - что за хрень - кто-то предоставляет в пользу BRAS "весомый" аргумент, если органы прикажут СОРМить локальный траф - весь ваш "халявный" "неконтролируемый" локальный траф мимо БРАСА идет лесом. Это бред нереальный. Такие локальные объемы файлопомйоные СОРМИТЬ..... Лучше пусть органы застреляться : ))))

Их интересует внешняя деятельность потенциальных шпионов...: ) , мошенничество с кредитками и т.д....

А точечно прослушать локальный траф - это не проблема , начиная от штатных Port Mirror или врезки грубо в кабель юзера, заканчивая штуками, которые цепляются на кабель аккуратненько и электормагнитне излучения им в помошь....

 

Или я тупой?

Изменено пользователем white_crow

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

опять же плюс пппое в том что момент поднятия интерфейса тунеля и есть моент поднятия сессии - всё понятно и достаточно всё просто! и делай всё что угодно в этот момент - маршрутизация и тд

с ипое - хуже если брас не достаточно интелектуален (я о ИСГ) особенно если адреса динамические и сессия определяется по том идут пакеты или нет - то этот момент сложно вычисляем....

 

со статикой в ипое всё намного проще ....

 

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

 

И второе - что за хрень - кто-то предоставляет в пользу BRAS "весомый" аргумент, если органы прикажут СОРМить локальный траф - весь ваш "халявный" "неконтролируемый" локальный траф мимо БРАСА идет лесом. Это бред нереальный. Такие локальные объемы файлопомйоные СОРМИТЬ..... Лучше пусть органы застреляться : ))))
хм а если сеть БОЛЬШААЯ, а если вы кроме того хостингом занимаетесь неслабо ?
Изменено пользователем Lynx10

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ситуации разные бывают, иногда какой нить юрик просит скажем /28 и без всяких доп. шлюзов /30, вот тут начинаются извраты.
иииии как ?

L2 VPN.

 

опять же плюс пппое в том что момент поднятия интерфейса тунеля и есть моент поднятия сессии - всё понятно и достаточно всё просто! и делай всё что угодно в этот момент - маршрутизация и тд

с ипое - хуже если брас не достаточно интелектуален (я о ИСГ) особенно если адреса динамические и сессия определяется по том идут пакеты или нет - то этот момент сложно вычисляем....

 

со статикой в ипое всё намного проще ....

 

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

 

И второе - что за хрень - кто-то предоставляет в пользу BRAS "весомый" аргумент, если органы прикажут СОРМить локальный траф - весь ваш "халявный" "неконтролируемый" локальный траф мимо БРАСА идет лесом. Это бред нереальный. Такие локальные объемы файлопомйоные СОРМИТЬ..... Лучше пусть органы застреляться : ))))
хм а если сеть БОЛЬШААЯ, а если вы кроме того хостингом занимаетесь неслабо ?

Ну ответ очевиден: пока не сталкивались - пока и не хранят статистику (проверено на собственном опыте).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я вот что не понял. В споре про "пионерский" NetFlow и "крутой" Радиус Акаунтинг.

 

Радиус - это хорошо. Считать деньги (время сессии, объемы переданных/принятых байт).

Но он же подробную статистику IP source-destanation вам не даст?

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

 

Неужели органы не требуют хранить подробную статистику посещений год или даже три?

СОРМ - это хорошо - но только выборочно кого-то прослушивать....

Статистику посещений по всем юзерам они не собирают....

Даже если не у всех, на современных аппаратных BRAS Netflow можно делать выборочно не для всех абонентов, а можно просто отзеркалить трафик на какой нить linux/bsd сервер c включенным сенсором netflow и все. у нас так и сделано, прожевывает до 2Гбит трафика (в обоих направлениях разумеется), к тому же можно выборочно сэмплировать, для органов и лимитчиков хватит. Дальше нетфлоу хранится для органов и спорных клиентов.

В биллинг идет чистый радиус-аккаутинг (точнее скоро будет идти, пока схема обкатывается). Что как мы понимаем после наступления некоторого значения X Гбит/сек гораздо более экономичный и масштабируемый способ чем netflow.

 

И второе - что за хрень - кто-то предоставляет в пользу BRAS "весомый" аргумент, если органы прикажут СОРМить локальный траф - весь ваш "халявный" "неконтролируемый" локальный траф мимо БРАСА идет лесом. Это бред нереальный. Такие локальные объемы файлопомйоные СОРМИТЬ..... Лучше пусть органы застреляться : ))))

Их интересует внешняя деятельность потенциальных шпионов...: )

А точечно прослушать локальный траф - это не проблема , начиная от штатных Port Mirror или врезки грубо в кабель юзера, заканчивая штуками, которые цепляются на кабель аккуратненько и электормагнитне излучения им в помошь....

Ну СОРМИТЬ локальный трафик могут начать заставлять, у нас уже были попытки предпринять слушать локальный p2p трафик, но вроде разум возобладал, но кто знает...

вообще БРАС это ж не способ слушать локальный трафик, и даже не способ загнать весь трафик в этот БРАС. Это способ более менее централизованным способом предоставить сервис абоненту. БРАС может быть как аппаратным решением (сиски, алу, джуны, смартэджи и т.д.) так и самодельным решением под линухом/фрей с кучей самописных скриптов. Вопросы качества и удобства пропущу, дабы не провоцировать холивары.

 

 

 

опять же плюс пппое в том что момент поднятия интерфейса тунеля и есть моент поднятия сессии - всё понятно и достаточно всё просто! и делай всё что угодно в этот момент - маршрутизация и тд

с ипое - хуже если брас не достаточно интелектуален (я о ИСГ) особенно если адреса динамические и сессия определяется по том идут пакеты или нет - то этот момент сложно вычисляем....

Да не, тоже все в порядке, если конечно не нужно фиксировать посекундное время окончания сессии.

В случае если инициируется сессия по DHCP, то лиз тайм ~ 5 минут, если по IP Source, время простоя теже 5 минут.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Но все же разве не рационально оставить огромный локальный траф в локалке? (И к тому же "халявный" локальный траф снижает нагрузку на аплинки, на ядро..")

Как там в книжках про cisco 90-х годов - 80% трафика должно остаться в отделе, 20% - пусть уходят..(Я утрирую про кампузные сети, а не сети операторов эзернета - с тех пор книжки переписали и продают они ...БРАСы).

А Кто говорит - что это халявный локальный траф и поэтому плохо?. Мы локальный траф открываем юзеру - как доп услугу за доп плату.

Кто говорит, что он неконтролируемый? Умный доступ у нас везде без исключений (Zyxel MES-3528) - всякие инсинуацмии с мак спуфингом, флудом, подделкой IP, ложным DHCP, Вещанием в сеть мультикаста - не прокатывают. Также закрыты дырявые порты Microsoft. А так же нет возможности "перепродавать" мультикаст - ограничение на количесвто одновременных мультикаст групп на каждый порт.

Далее - приоритезация Инет трафа над локальным. (DSCP, CoS, ToS)

Все это конечно красиво при однотипном оборудовании на доступе. Но я не вижу реальных проблем с этим.

 

Да, единтсвенный недостатко этой схемы с децентрализацией, который в страшном сне может присниться - сормить локальный траф....

Ну или если вдруг Zyxel закроет свой бизнес в области сетевого оборудования . Но я думаю - сеть уже будет построена. И про запас взято на резервирование несколько свичей.....: )))) (Я , кончно, утрирую, но был такой случай - наши коллеги строили сеть на HP Procurve И плевались на Zyxel, DLink и т.д., но их заманили интеграторы низкми ценами на партию. Так длинк им спец прошивку написал, для совместимости , речь, наверное шла об Option82 и других не сложных алгоритмах...)

 

А уж если изначально сеть на длинках - то длинк нас всех переживет....

 

P.S. Я ничего против не имею гнать все в центр, но мне иделогически это не катит.

ВОт я ищу оправдания схемы антиBRAS.... ^ ))))

 

Да, и забыли важную штуку - в случае схемы антиBRAS - выдача белых IP - тунели.

Да нет никаких с этим проблем - l2tp/pptp вполне себе неплохо справиться с этой задачей.

Потому что не все хотят белый IP. Всего 1-3% физиков от силы у нас (услуга платная)

 

И я сам сделаю вывод - такая схема вполне рациональная для мелких и средних провайдеров. Крупняк (в моем понимании) от 40-50 тысяч рыл - пусть брасы и покупает (и в резере пусть стоит один штука : ))))))

Изменено пользователем white_crow

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

white_crow, вы совершенно правильно сделали, причесали локальный трафик и пустили в свободное плаванье. тащить локальный трафик в брас, не нужно только если другого выхода нет (например схема vlan-per-user).

на самом деле и отсормить его в принципе можно, многие коммутаторы агрегации sflow поддерживают, худо бедно но деталку вытащить можно. но надеюсь до этого дело не дойдет.

 

при хороших заказах любой китайский вендор напишет нужную прошивку :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да не, тоже все в порядке, если конечно не нужно фиксировать посекундное время окончания сессии.

В случае если инициируется сессия по DHCP, то лиз тайм ~ 5 минут, если по IP Source, время простоя теже 5 минут.

а маршруты реальников - подсети ? если статика - то не вопрос ... раз маршруты накрутили, адрес статику всегда выдавать один и тот же - всё работает

а тепер представим что по ипое выдаются динамически адреса + вам надо подсеть дать абоненту .... как ? я не знаю как это в апаратных сискоджуновалу брасах сделано - но в линуксах фряхе так со старта не придумаю.. разве что писать какую то свою приблуду (можна конечно подправить под свои задачи DHCPD который сразу завернёт подсеть) которая время от времени будет смотреть не появился ли у нас пользователь которому мы должны сеть дать - вычислять адрес текущий его и заворачивать

 

кстате с DHCP в разы проще как по мне а вот с ип сорс - если опять же апаратно - то не вопрос наверное - а на фряхлинуксах - вопрос.... разве что Умник допишет свой ИСГ

Изменено пользователем Lynx10

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.