Статус: Офлайн
Реєстрація: 15.10.2005
Повідом.: 31402
Реєстрація: 15.10.2005
Повідом.: 31402
ориентировочно в ближайшем будущем.
Обсуждение провайдера Beeline
- Автор теми anis
- Дата створення
ориентировочно в ближайшем будущем.
Статус: Офлайн
Реєстрація: 15.10.2005
Повідом.: 31402
Реєстрація: 15.10.2005
Повідом.: 31402
зря сомневаешься.
если нет на сайте - включение не возможно.
если на сайте есть - то и ответ дадут сразу, и заявку на включение оставишь
Статус: Офлайн
Реєстрація: 15.10.2005
Повідом.: 31402
Реєстрація: 15.10.2005
Повідом.: 31402
судя по последним слухам - с сессиями полегчает уже в течении следующей недели, а с выдачей айпишников - в течении недели-двух.
Статус: Офлайн
Реєстрація: 15.10.2005
Повідом.: 31402
Реєстрація: 15.10.2005
Повідом.: 31402
в общем брендом занимаются люди, которые в принципе не пнимают чего от них хотят. поэтому интернетом дома не занимаются вообще.
рекламной поддержки - ноль.
технической - ноль.
организационной - ноль.
пока не мешали, было терпимо, сейчас уже не понятно с какого боку хвататся за некоторые вопросы.
единственная надежда на кризис.
в кризис раздутый штат сокращают и в первую очереть выкидывают неадекватный балласт.
Статус: Офлайн
Реєстрація: 15.10.2005
Повідом.: 31402
Реєстрація: 15.10.2005
Повідом.: 31402
брасы локальные
не просто для каждого города, а для каждого узла ядра сети.
балансеры же на впн.билайн.уа - общие на всю украину, и нагрузки на них понт, смысла разводить по областям нет.
в отличии от брасов, к которым подымаются pptp сессии, и которые гонять по всей стране чревато.
Статус: Офлайн
Реєстрація: 15.10.2005
Повідом.: 31402
Реєстрація: 15.10.2005
Повідом.: 31402
ты читать па-русскама языка можешь?
железо изначально закуплено уже полтора или два года назад на весь проект в 70-80% разворачивании (читай на 4 или 5 лет вперед)
основная сложность выписать железо для установки.
Статус: Офлайн
Реєстрація: 15.10.2005
Повідом.: 31402
Реєстрація: 15.10.2005
Повідом.: 31402
ps хотя никто и никогда правду не скажет, естественно - что происходит на самом-то деле. К примеру вопрос в пустоту - какая у брасов "интернет вдома" проектная загрузка (в клиентах/брас)? какая реальная? насколько безболезненно (по данным эксплуатации на реальной сети) брасы выдерживают заявленную производителем (а проектная наверняка равна заявленной производителем) нагрузку?
чё ж не скажет.
сколько или мегабит или клиентов вытянит одна 73 циска было написано ещё в "библии от корбины" так что +- эта цыфра была известна ещё до стройки свитонлайна. в течении года эксплуатации свитонлайна эта цыфра в целом подтвердилась.
а на текущий момент при 100% утилизации пропускной способности по мегабитам каждая из семисяттретих по клинтам нагружена на 130%
заметные проблемы начались при 115-120 процентах по людям.
сложнее с заявленным производителем - там же сферические кони в вакууме, без конктретных технологий.
сейчас отобрали ещё одну +где-то в пути ещё одна.
соответственно с запуском третей получим равномерную разгрузку по мегабитам до 65% а по людям до 87%
и самое главное это за месяц отобрать брас, который сейчас в пути, иначе опять начнется перегруз по людям.
alex444
staff (вахтьор)
Статус: Офлайн
Реєстрація: 12.09.2007
Повідом.: 41783
Адреса: м.Харків
Реєстрація: 12.09.2007
Повідом.: 41783
Адреса: м.Харків
в том, что балансер "сбалансировал" нагрузку на брасы так, что на первом брасе избыток "свободных коннектов", а у второго и третьего они закончились? И в самом деле, дрю прав - (клиенту) пофик - закончились коннекты (брас загружен "по самое нехочу"), или у браса закончился адресный пул, отконфигурённый ему админподразделением...
alex444
staff (вахтьор)
Статус: Офлайн
Реєстрація: 12.09.2007
Повідом.: 41783
Адреса: м.Харків
Реєстрація: 12.09.2007
Повідом.: 41783
Адреса: м.Харків
Вы забыли ещё упомянуть какой-нить биллинг ко всему этому, и зачем-то указали БД
Итак. "nas" + "auth and accounting (aaa)" + "billing". SQL (БД - хоть мускль, хоть постгрес, хоть оракл, хоть db2 - не суть важно) болтается в этой схеме отдельно и "невидимо" , с ним работают модули aaa и billing, но не nas-ы
Так вот, уважаемый, чья функция выдавать динамические адреса и следить за их распределением в рамках nas, а? Правильно, nas-а, и только его (модуль aaa может, конечно, выгрузить nas-у статический адрес для клиента (и так и происходит, если у клиента заказан статический реальный адрес), но заниматься в модуле aaa ещё и динамикой, следить за занятием и освобождением адресов клиентов - зачем? если это превосходно делает любой nas - это его базовая функция). Зачем городить (согласно Вашему предложению) лишнее звено (динамические адреса координировать модулем aaa), увеличивающее ненадёжность алгоритма?
Останнє редагування:
Вы забыли ещё упомянуть какой-нить биллинг ко всему этому, и зачем-то указали БД
Итак. "nas" + "auth and accounting (aaa)" + "billing". SQL (БД - хоть мускль, хоть постгрес, хоть оракл, хоть db2 - не суть важно) болтается в этой схеме отдельно, с ним работают модули aaa и billing.
Так вот, уважаемый, чья функция выдавать динамические адреса и следить за их распределением в рамках nas, а? Правильно, nas-а, и только его (модуль биллинга может, конечно, выгрузить модулю "auth + accounting" для передачи nas-у статического адреса для клиента, а заниматься ещё и динамикой, следить за занятием и освобождением адресов - зачем? если это превосходно делает любой nas - это его базовая функция). Зачем городить (согласно Вашему предложению) лишнее звено (динамические адреса координировать модулем биллинга), увеличивающее ненадёжность алгоритма?
Я ничего не забыл. Я не знаю что у вас и где "болтается", но у FreeRadius (ужасно нестабильная реализация, ни одна уважающая своих клиентов компания его не испльзует) есть модуль, который позволяет хранить локальную информацию о клиентах в базе данных (например MySQL). Да, действительно НАС МОЖЕТ выдавать адрес клиенту из собственного пула, если его не назначил радиус-сервер. Но эту схему можно применять в какой нибудь небольшой локальной сети. По-типу вашей c одним единственным брасом. Для сети масштаба города, страны с центализованной системой авторизации и десятками NAS - такой вариант не является масштабируемым (например, необходимо добавить пул адресов, добавить нас для снятия нагрузки с пересекающимся пулом, изменить пул адресов, выдавать статические адреса из диапазона пересекаюшегося с динамическим, выдавать адрес в зависимости от выбранного пакета/предоставляемой услуги.... да в конце-концов просто производить мониторинг, и хранить информацию по ip адресам/клиентам в биллинге), в этом случае в Radius введена возможность назначения системой авторизации/аутентификации ip адреса. Согласно таких принципаов работают 99% промышленных биллинговых систем в мире, а соответственно и телекоммуникационных компаний. Так работает Велтон, УТ, Стрим, по всей видимости биллинг ГТ также опирается на эти принципы... Для этих целей наряду с информацией о насе, в биллинг заносятся пулы адресов И ЦЕНТРАЛИЗОВАННО производится управление такой информацией. Вы бы посетили хотя бы для общего развития пару специализированных выставок, если не имеете возможность работать с промышленными а не кустарными системами. Запомните раз и навсегда - выдавать динамический адрес из пула наса - это дилетантское и потенциально сложно масштабируемое решение.
Останнє редагування:
Статус: Офлайн
Реєстрація: 15.10.2005
Повідом.: 31402
Реєстрація: 15.10.2005
Повідом.: 31402
а когда на холодной горе будет ?
ХГ большая. конкретики побольше.
Статус: Офлайн
Реєстрація: 15.10.2005
Повідом.: 31402
Реєстрація: 15.10.2005
Повідом.: 31402
Статус: Офлайн
Реєстрація: 10.06.2008
Повідом.: 748
Реєстрація: 10.06.2008
Повідом.: 748
Это только уменя так? :/
mtr *******.ru
mtr *******.ru
Код:
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 94.27.124.3 - 15 | 27 | 23 | 31 | 61 | 78 | 78 |
| 94.27.124.29 - 15 | 27 | 23 | 32 | 61 | 78 | 63 |
| 94.27.124.37 - 23 | 27 | 21 | 46 | 67 | 109 | 62 |
| 94.27.127.134 - 30 | 27 | 19 | 78 | 121 | 141 | 125 |
| 94.27.127.134 - 19 | 27 | 22 | 78 | 117 | 156 | 125 |
| te-6-2-ar1-co10.kv.sovam.net.ua - 41 | 27 | 16 | 94 | 121 | 141 | 140 |
| te-1-2-br0-co15.kv.sovam.net.ua - 12 | 27 | 24 | 109 | 123 | 157 | 125 |
| 195.35.65.88 - 23 | 27 | 21 | 94 | 121 | 141 | 125 |
| 213.180.208.94 - 19 | 27 | 22 | 94 | 139 | 171 | 156 |
| 77.88.56.125 - 12 | 26 | 23 | 94 | 148 | 250 | 157 |
| 213.180.210.181 - 24 | 26 | 20 | 109 | 150 | 250 | 219 |
| 213.180.204.11 - 16 | 26 | 22 | 109 | 141 | 172 | 156 |
|________________________________________________|______|______|______|______|______|______|
WinMTR - 0.8. Copyleft *2000-2002 Vasile Laurentiu Stanimir ( stanimir*cr.nivis.com )так это странная контора у тех кто подключает.
