Гайджин
-
Всього повідомлень
3 201 -
Приєднався
-
Останній візит
-
Дней в лидерах
39
Тип контенту
Профили
Форум
Календарь
Сообщения додав Гайджин
-
-
1. Либо вы сквозь натилки более 4Г пускаете. (Можно в личку объем внешних каналов?)
а в чем проблема?
Так в том то и оно, что нет проблем...
Маркетологи отдельной жизнью живут что ли?а это как правило так и есть - еще не привыкли?
Нет - не привык, у нас не так...
-
Никаких PPP, тупо NAT. Точную конфигурацию и про аггрегацию не скажу, я не админ а скромный программист и доступа туда у меня нет.
Хм... Ну тут я если честно диву даюсь, тут похоже одно из:
1. Либо вы сквозь натилки более 4Г пускаете. (Можно в личку объем внешних каналов?)
2. Либо Коры2Дуо у Вас какие то детские.
3. Либо админы чего то недоадминивают.
Про тарифы можно тут глянуть. Пока не размазалась никак, т.к. это акционные тарифы и на них подключают, на сколько я знаю, только новых абонов.
Так на "сотке" выдается 300Г в месяц (суммарного?) и на дни трафик не режется? Т.е. пока не выбереш скорость не понижается?
Да, акксессы были перед этим в "предзагибочном" состоянии, но только ж никто об этом не подумал - главное тарифы было ввести. В общем ненависть и презрение ко всему этому маркетологическому сброду.
Маркетологи отдельной жизнью живут что ли?
-
Порядка 8к "живых" абонов.
Живых - это имеется ввиду абонентское ядро? - Т.е. Живых в течении месяца.
Или же разговор идет о 8К онлайновых абонентов в текущий момент времени?
Сервера на C2D и гигабитных интелловских сетевушках (либо несколько одинарных, либо 4-головая).
3 NAT'а загибались, на 4 пока более-менее, но это ж начало месяца. Не все еще оплатили.
У вас сеть IPoE или IP other чего то? Т.е. сервера - "резалки" и "натилки", или же они еще ppp терминируют?
Насколько я понял, пара гигабитов вверх и пара вниз? - агрегируете как?
C2D какие?
Да и тарифы только ввели.
Если не секрет - то какие? Т.е. какие скорости и как "пациентская" база по тарифам размазалась.
p.s. пишу не из праздного любопытства, самому такое сделать предстоит буквально в этом месяце. Но настоящий момент пока проблем с NATом не вижу, но у меня и сервера похоже по мощнее будут.
-
Может юзерам и нравится, но нужно нормально продумать нагрузку на канал и железо. У нас ввели без консультации с админами и наступил маленько ...
Даже с учетом того что у нас часть юзеров сечас на белых IP сидят 4 NAT-сервера загружены обработкой SoftIRQ по самое немогу. Потери нереальные, абоны жалуются, на начало месяца статистика по "живым" удручающая.
А о каком кол-ве абонентов, канальной емкости и серверах идет речь (плюс минус килограмм)?
-
ip-up.local спасет отца Русской демократии.
-
[-RaY' date=13 Март 2010 - 01:47' timestamp='1268434041' post='153479]
Если тестирование пройдет успешно от себя предложу тему:
PPPOE БРАС 3 гбит, с резервацией N+1 за 3 тыс уе, легко масштабируемое решение на базе FreeBSD+MPD .
3 Гбит/с суммарно? Или 3 туда и 3 оттуда?
-
Как показывает практика, в Украине не прецедентное право...
-
Микротик активно используется на многоядерных маршрутизаторах.
Не 16 ядерные (не проверял), но 2-4 ядра полноценно и правильно работают.
Вот тут на тему микротиков показательно...
2. Микротик для таких задач выход для тех кто этот самый тюнинг сделать не может.Насколько видно из постов, ТС не будет делать тюнинг.
Хм... В и где это видно? - я как то не заметил...
Посоветуй ему еще собрать генту с патчами для mppe и mppc
Ну для того что бы выжать из сервера все до суха, женту как раз бы и сгодилось. Что же касается mppe и mppc - на nas-е оно нах?
-
Микротик не в счет - он только для "детского" NASа годиться...
почему? в чем отличие от взрослого?
В размерах... Ставить микротик на могопроцессорный многояерный сервер смысла нет...
jugernault, а чем отличается pptpd линуксовый от pptp serverа в микротике?
Я думаю что ничем, что там что там - poptop. Хотя конечно может быть и accel-pptp - но не факт.
Но не про pptp речь. Я четко вопросы задал - ответов 0...
mpd? разница версий тоже существенно влияет.
Причем тут версии?
или ставить последнюю фрю на старый комп?
и долбаться с тюнингом чтобы работало все адекватно?
однозначно микротик разрулит все что нужно на менее производительном железе.
1. Почему фрю?
2. Микротик для таких задач выход для тех кто этот самый тюнинг сделать не может.
-
PPPoE не получится сделать так как dlink 2100 не пропускает данный протокол.
Это почему же?
И даже если убрать dlink, я не очень понимаю как этот PPPoE шейпить. Ведь он работает под сетевым уровнем IP, т.е. по IP адресам шейпить не получится. А как тогда?
Легко и непринужденно - шейпить на тунельном интерфейсе, там ip есть.
p.s. Такой впечатление, что Вы pptp собрались по "несущей" сети шейпить...
-
хочешь сразу хороший и бесплатный совет? если хочешь сделать NAS - возьми либо фрибсд+мпд либо микротик
да и смотри в сторону пппое Ну pptd vs pppoe понятно - производительность.
А вот что волшебного даст связка freebsd+mpd vs linux+rp-pppoe+pppd?
Микротик не в счет - он только для "детского" NASа годиться...
-
-
Да, поставил на сервер терминирующий pppoe(и кроме этого занимающийся шейпингом и НАТом) карточку на 82576, включил RSS в виде 4 очереди прием/4 передача.
Очереди были совмещенные? Ядро было какое?
Адаптер смотрящий на внешний мир раскидал прерывания на все ядра, все красиво и равномерно.
Похоже что все же совмещенные очереди - потому как мне не удалось равномерно загрузить TX-овые очереди на интерфейсе смотрящем в сторону ядра.
Итоговая загрузка сервера даже выше чем на паре бортовых intel pro pt.
Ну тут я пожалуй не соглашусь - выше она не была, но вот цель не была достигнута.
У себя уберу ET с сервера, вместо него поставлю двухголовую pt + включу бортовые. 4 сетевки как раз загрузят 4ех ядерную систему более-менее равномерно, благо у pppoe проблем с добавлением интерфейсов нет никаких
Пошли по аналогичной схеме - два гигабита в ядро, два в сторону клиентов.
По сути проблему решили - но неудовлетворенность осталась.
Может быть кто то добивался положительных результатов при помощи VMQ?
-
Есть такое, igb распараллеливает нагрузку лишь на уровне tcp/udp, для pppoe вообще не работает. Был печально удивлен как хреново оно работает на pppoe терминаторе..
Так и я про что (Вы кстати через RSS заводить ее пытались?) - не понятно нах на микротик поддержку 82576 если в условиях задачи pppoe.
p.s. Кто нибудь добивался он новомодных интеловских карт распределения нагрузки (pppoe) по очередям?
-
У микротика еще проблема в том, что до текущей версии плата Intel 1000ET не поддерживается (ядро без поддержки igb), cтандартные драйвера для Intel 1000pt не поддерживают разброс прерываний по ядрам. В итоге поставив Mikrotik на CoreI7 количество задействованных процессоров будет = количеству сетевых карт, остальные будут курить..
А что вам даст Intel 1000ET (под linux+igb) в разрезе PPPoE BRAS? - Насколько я понял, то pppoe там хрен распаралелиш по ядрам.
-
Господа, что то у меня полный ступор - не едут лыжи, хоть ты убейся. Может кто чего подскажет?
Ситуация следующая:
В наличии имеется софтовый PPPoE BRAS - CentOS 5.4, ядро ванильное 2.6.31.13, четыре гигабитных интерфейса (два в сторону ядра - Intel 82574L, два в сторону клиентов - Intel 82576, на всех по две раздельных очереди rx и tx).
На BRASе zebra+ospfd (quagga-0.99.15-2009082801), в сторону ядра еqual-cost multi-path routing:
[root@xxx~]# ip route...
...
default proto zebra src XXX.YYY.ZZZ.17 metric 11
nexthop via AAA.BBB.CCC.65 dev eth0 weight 1
nexthop via AAA.BBB.CCC.69 dev eth1 weight 1
...
К BRASу коннектиться клиент (PPPoE сервера живут на интерфейсах eth2 и eth3, IP адресов интерфейсы не имеют) и живет себе припеваючи:
[root@xxx~]# ip addr show dev ppp6414756: ppp641: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc htb qlen 3
link/ppp
inet XXX.YYY.ZZZ.17 peer 10.195.12.97/32 scope global ppp641
[root@xxx~]# ip route get 10.195.12.97
10.195.12.97 dev ppp641 src XXX.YYY.ZZZ.17
cache mtu 1400 advmss 1360 hoplimit 64
Однако при пристальном наблюдении за клиентом выясняется что от него приходят пакеты (с адресом отправителя, который мы ему не выдавали) в сторону наших ДНС серверов (XXX.YYY.ZZZ.9 и XXX.YYY.ZZZ.10):
[root@xxx ~]# cat /var/log/kernel | grep PROTO=UDP | grep SPT=53 | awk '{print $5, $6, $7, $8, $9, $15, $16, $17}' | tailkernel: IN=ppp641 OUT=eth0 SRC=192.168.0.1 DST=XXX.YYY.ZZZ.10 PROTO=UDP SPT=53 DPT=53
kernel: IN=ppp641 OUT=eth0 SRC=192.168.0.1 DST=XXX.YYY.ZZZ.9 PROTO=UDP SPT=53 DPT=53
kernel: IN=ppp641 OUT=eth0 SRC=192.168.0.1 DST=XXX.YYY.ZZZ.10 PROTO=UDP SPT=53 DPT=53
kernel: IN=ppp641 OUT=eth0 SRC=192.168.0.1 DST=XXX.YYY.ZZZ.9 PROTO=UDP SPT=53 DPT=53
kernel: IN=ppp641 OUT=eth0 SRC=192.168.0.1 DST=XXX.YYY.ZZZ.10 PROTO=UDP SPT=53 DPT=53
kernel: IN=ppp641 OUT=eth0 SRC=192.168.0.1 DST=XXX.YYY.ZZZ.9 PROTO=UDP SPT=53 DPT=53
kernel: IN=ppp641 OUT=eth0 SRC=192.168.0.1 DST=XXX.YYY.ZZZ.10 PROTO=UDP SPT=53 DPT=53
kernel: IN=ppp641 OUT=eth0 SRC=192.168.0.1 DST=XXX.YYY.ZZZ.9 PROTO=UDP SPT=53 DPT=53
kernel: IN=ppp641 OUT=eth0 SRC=192.168.0.1 DST=XXX.YYY.ZZZ.10 PROTO=UDP SPT=53 DPT=53
kernel: IN=ppp641 OUT=eth0 SRC=192.168.0.1 DST=XXX.YYY.ZZZ.9 PROTO=UDP SPT=53 DPT=53
Пакеты достигают ДНС серверов, ну а те в свою очередь их отвергают - не используем мы диапазон 192.168.0.0/16.
И это происходит не смотря на то, что reverse path filtering включен по дефолту для всех интерфейсов, кроме eth0 и eth1 (они смотрят в ядро и на них еqual-cost multi-path routing):
[root@xxx~]# sysctl -a | grep '\.rp_filter' | less...
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0
net.ipv4.conf.eth2.rp_filter = 1
net.ipv4.conf.eth3.rp_filter = 1
...
net.ipv4.conf.ppp641.rp_filter = 1
Таблица маршрутизации выглядит вот так:
[root@xxx~]# ip route...
10.195.12.97 dev ppp641 proto kernel scope link src XXX.YYY.ZZZ.17
...
AAA.BBB.CCC.64/30 dev eth0 proto kernel scope link src AAA.BBB.CCC.66
AAA.BBB.CCC.68/30 dev eth1 proto kernel scope link src AAA.BBB.CCC.70
...
default proto zebra src XXX.YYY.ZZZ.17 metric 11
nexthop via AAA.BBB.CCC.65 dev eth0 weight 1
nexthop via AAA.BBB.CCC.69 dev eth1 weight 1
...
А маршрут на не верный адрес, который приходит в виде адреса отправителя в пакете от клиента, выглядит так:
[root@dxxx~]# ip route get 192.168.0.1192.168.0.1 via AAA.BBB.CCC.69 dev eth1 src XXX.YYY.ZZZ.17
cache mtu 1500 advmss 1460 hoplimit 64
Т.е. это дефолтный маршрут.
Перерыл пол Интернета, пробовал устанавливать значения rp_filter = 0, 1, 2 - все бес толку...
Не выходит каменный цветок и все тут...
Если у кого будут какие либо мысли, что еще можно покрутить - буду очень благодарен.
-
хочется узнать у вас лично, что тут в строчке опасного скажите ? или чем опасно, то что есть сквид в системе.
Какой Вы однако прямолинейный
- Можно даже сказать не гибкий... А если поглядеть вот с этой точки зрения:
...у них есть "squid:x:23:23::/var/spool/squid:/sbin/nologin"...
... В Морали, спецы приблизительно как в мин образования и науки...
...Ребят, Национальной экспертной комиссии по вопросам защиты общественной морали насрать на ваши проблемы с отсутствием технической возможности...
...И заставить их фильтрировать ХТТП траффик это равнозначно дибильно заставить операторов мобильной связи пускать "пиии" вместо мата. Тем более всем наср@ть на техническую возможность... а может все таки у них в "верхах" все ище используют прокси для доступа?...
...
100% будет список из отдельных страничек отдельных сайтов.
а может еще и хостинг с одним ипом на толпу попадется.
и все. никого не будет волновать есть у вас техническая возможность анализировать гигабитный траффик или нет...
Засада в том, что с вероятностью 99% данная комиссия не в курсе что такое IP-адреса.
В лучшем случае их хватит на URL. В вот получить "официальный список урлов" сильно бы не хотелось - напрягать железо на тему анализа http трафика как то не сильно хочется...
Что прослеживается? - Верно! Они знают что такое прокси-сервер!
А если знают в минобразования, то и в нацкомиссии тоже...
Вывод: задрочат они нас фильтрацией на L7 - как пить задрочат...
Ну и кто они после этого?
p.s. не знаю как Вам, но мне как то в голову ничего умного не приходит, на тему, чем можно профильтровать на L7 (заглядывая внутрь пакета) несколько Г/с не за дорого (5-10К$)...
-
Боже! Это шутка или они идиоты?! О_о
Ну а как Вы думаете? - Если у них есть "squid:x:23:23::/var/spool/squid:/sbin/nologin", то кто они?
-
Нет не решают...
Единственное что может как то разнообразить жизнь это поставить rate=9Mbit/s...
Но в случае если провайдер недольет, получится казус.
-
100% будет список из отдельных страничек отдельных сайтов.
а может еще и хостинг с одним ипом на толпу попадется.
и все. никого не будет волновать есть у вас техническая возможность анализировать гигабитный траффик или нет.
Вот в этом и западло...
-
Маразм.
Это называется пиринговая политика. Ну вот например зачем РЕТН сделал бесплатный пиринг с УТ? Все очень просто. У УТ грубо говоря 1млн абонентов + нехилый ДЦ. Допустим, что в часы наибольшей нагрузки потребляемый клиентами УТ траффик клиентов РЕТН (небольших сетей, ДЦ, транзит) составляет 5Гбит. В этом случае этот траффик будет грузить внешние каналы и УТ и РЕНТ. От сюда логичное решение - пиринг. То есть создавая пиринги операторы разгружают свои внешние каналы, не даст УТ бесплатный пиринг один оператор, ему его даст другой, но в этом случае первый нагрузит свои внешние каналы траффиком абонентов УТ... Это только один простенький пример.
Все верное, тольно не стоит забывать, что в приведенном примере (при отсутствии пиринга) УТ нагрузит нисходящую составляющую своих внешних каналов, в вот РЕТН - восходящую. А это все же разные вещи.
Из этого следует - перетоки трафика должны быть взаимными, что бы пиринг был интересен.
-
В принципе, если будет официальный список IP, которые надо блокировать на уровне провайдера, это будет прекрасно.
Засада в том, что с вероятностью 99% данная комиссия не в курсе что такое IP-адреса.
В лучшем случае их хватит на URL. В вот получить "официальный список урлов" сильно бы не хотелось - напрягать железо на тему анализа http трафика как то не сильно хочется...
-
клева)))
в регионах росия 40-50 мс.
В регионах скорее вот так:
[xxx@xxx ~]$ ping mail.ru -A -c 10 PING mail.ru (217.69.128.43) 56(84) bytes of data. 64 bytes from mail.ru (217.69.128.43): icmp_seq=1 ttl=115 time=33.5 ms 64 bytes from mail.ru (217.69.128.43): icmp_seq=2 ttl=115 time=33.5 ms 64 bytes from mail.ru (217.69.128.43): icmp_seq=3 ttl=115 time=34.1 ms 64 bytes from mail.ru (217.69.128.43): icmp_seq=4 ttl=115 time=33.5 ms 64 bytes from mail.ru (217.69.128.43): icmp_seq=5 ttl=115 time=33.6 ms 64 bytes from mail.ru (217.69.128.43): icmp_seq=6 ttl=115 time=33.4 ms 64 bytes from mail.ru (217.69.128.43): icmp_seq=7 ttl=115 time=33.5 ms 64 bytes from mail.ru (217.69.128.43): icmp_seq=8 ttl=115 time=33.7 ms 64 bytes from mail.ru (217.69.128.43): icmp_seq=9 ttl=115 time=33.5 ms 64 bytes from mail.ru (217.69.128.43): icmp_seq=10 ttl=115 time=33.4 ms --- mail.ru ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 1807ms rtt min/avg/max/mdev = 33.490/33.639/34.125/0.181 ms, ipg/ewma 200.790/33.615 ms [xxx@xxx ~]$ ping ua-ix.net.ua -A -c 10 PING ua-ix.net.ua (212.40.43.2) 56(84) bytes of data. 64 bytes from mail.inau.org.ua (212.40.43.2): icmp_seq=1 ttl=59 time=12.8 ms 64 bytes from mail.inau.org.ua (212.40.43.2): icmp_seq=2 ttl=59 time=12.6 ms 64 bytes from mail.inau.org.ua (212.40.43.2): icmp_seq=3 ttl=59 time=12.6 ms 64 bytes from mail.inau.org.ua (212.40.43.2): icmp_seq=4 ttl=59 time=12.7 ms 64 bytes from mail.inau.org.ua (212.40.43.2): icmp_seq=5 ttl=59 time=12.8 ms 64 bytes from mail.inau.org.ua (212.40.43.2): icmp_seq=6 ttl=59 time=12.8 ms 64 bytes from mail.inau.org.ua (212.40.43.2): icmp_seq=7 ttl=59 time=12.7 ms 64 bytes from mail.inau.org.ua (212.40.43.2): icmp_seq=8 ttl=59 time=13.0 ms 64 bytes from mail.inau.org.ua (212.40.43.2): icmp_seq=9 ttl=59 time=12.5 ms 64 bytes from mail.inau.org.ua (212.40.43.2): icmp_seq=10 ttl=59 time=12.6 ms --- ua-ix.net.ua ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 1807ms rtt min/avg/max/mdev = 12.571/12.755/13.016/0.169 ms, ipg/ewma 200.805/12.766 ms [sva@p16 ~]$
Так что мы еще повоюем...
-
на канале в 200мбит безлимитных хомячков netflow за полтора месяца занимает 200гиг
Позвольте усомниться. - Или у Вас там сплошные синфлудеры, или Вы его как то странно храните.
- Можно даже сказать не гибкий... 
Актуальный тариф у провайдеров
в Питання по Stargazer
Опубліковано:
Опа - динамические шейперы...
Здравствуй ЕвропаОнЛайн
- новое это хорошо забытое старое...