Kucher2

Истина рядом!

С Вами опытные люди делятся мнениями, а Вы - в бутылку. "Да что там той сети!". Святая простота. Да завтра Вы тому челу с балконом - на мозоль наступите... или они там поругаются и разъёдутся... или поедут в отпуск на пол-года... и т.д. И что Вы станете делать? Десантироваться под покровом ночи и тумана на тот балкон? Ему плевать, а у Вас 10-20 абонов в затылок дышат... Делайте по уму - свитч в ящике, где удобно. Если попроще - возле своей квартиры, где ставите БП, а в сам ящик не 220, а только 48В из квартиры, перед свитчём понижалка. Потом у себя можно и ИБП поставить на это дело. Из ящика пошла разводка к абонам, витой парой. В соседние подъезды, как по мне, по фассадам тактика верная, но кабель обязательно уличный и конечно в соседних подъездах тоже в коробку под замок и обязательно удалёнка. Далее по аналогии. Разводка по абонам либо по слаботочке, либо в зависимости от архитектуры (очень нежелательно) - с улицы, со стороны подъездных окон. Для района такая схема не годится (однозначно только оптика в каждый дом), для дома как экономный вариант - сойдёт. Не бойтесь закладывать необходимые для сервиса вещи в стоимость подключения/эксплуатации/свои затраты. Делайте сразу так, чтоб потом не жалеть (или лучше не делайте совсем, ищите другой вариант), учитесь на чужих ошибках. Удачи.

http://podrobnosti.ua/podrobnosti/2010/11/14/731119.html Вы слышали? Оказывается, МЫ САМИ ЭТОГО ХОТЕЛИ!

Поживём - увидим.

Можно подумать, что будь мы на их месте - делали бы нечто иное. Они пытаются накосить денег. Ну уж если не для государства, так для себя. А наша реакция - этих денег не отдавать. Вполне нормальная такая реакция. Если вы крупная сеть - вам эти изменения пофик. Если мелкая - думайте об бъединении. Ведь были например обсуждения варианта "50 % дохода" за Инет-канал и техподдержку.

Для рапиды есть голд аккаунт. Работает через смс как часы, проверено. Гривен 10 они снимают за сутки голда. Это если срочно надо качнуть что-то по-быстрому. Тем кому надо качать что-то постоянно и нахаляву конечно здорово, если они имеют кучу халявных IP, выдающихся при переподсоединении к прову. Мысль как раз о том, что экономически выгоднее на больших объёмах не НАТить всех, ибо иногда дешевле купить блок адресов и отдавать их клиенту по PPPoE. Откровенно говоря мне на 1к клиентов видится более целеообразной связка из нескольких групп со своим внешним IP. Ну например на каждые 150-250 человек свой внешний IP. Кажется это можно сделать на IPFW NAT. Слишком уж привередливым можно выдать реальные IP. Потому что у меня по статистике использует реал IP только 1 человек на 150-170 юзверей. Я даже услугу "Реал IP" сделал (15 коп/час, активация на личной страничке, деактивация автоматически). Ну не пошла она, народ интересуется только скоростью доступа. Мой простенький двухядерный целерон сейчас НАТит порядка 50-120Мбит (120 в пиках). Думаю потянет максимум 200-250Мбит. Где-то читал за тазики, НАТящие 600-700Мбит. Так что вполне реально, если опустить возможные убытки и гемор по сравнению с пуллом реал IP. P.S. И как после этого делать подключения бесплатным?

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

Палка о двух концах. - да, Белый IP не надо НАТить, это сильно снижает нагрузку на сервер ну и соответственно требования к железу. В принципе можно посчитать что выгоднее: наращивать мощности или купить подсеть белых IP. Не знаю цен, уже посчитал бы. Скажем, если надо 1000 адресов? - да, нет гемора с некоторыми играми в Инете, файлообменникими и т.д. А теперь обратная сторона. Поправьте, если я не прав. - машина имеет белый IP. Это значит, что её видно в Инете. Далеко не всякий юзер догадается правильно закрыть машину, при этом оставив доступ к своим ресурсам со стороны локалки. Получается что ему проще запретить всё, чем морочиться с разрешениями. Т.е. локалка лишается сетевых ресурсов. В общем-то в чём-то и хорошо, меньше внутреннего трафика гоняется, но смысл сетки тогда только в раздаче Инета, имеем необходимость создания и поддержки DC++ или торрент-трекера в некоторых случаях (низкие Инет-скорости + высокие нагрузки на внешний канал). - если реал-IP выдаётся динамически (каждый раз он для юзера разный), есть вероятность что многие из них в итоге будут забанены на каких-то игровых ресурсах, файлообменниках и соц. сетях. Для файлообменников, кстати (которыми пользуются сейчас всё реже, торренты рулят), даже наличие реал-ip не прибавит скорости закачки (в пределах 1Мбит, чаще 0,5Мбит). Просто меняя их при скачке очередного куска какого-то архива мы не ждём 10-60мин. Премиум не учитывает с какого IP вы заходите, он идентифицирует юзера по логину/паролю. Я например наблюдал около 40Мбит с "Рапиды" - на премиуме, находясь за НАТом.

Было бы логично найти возможность резать трафик именно на первом сервере, к которому подключены клиенты. Если он на Винде - попробуйте в виде костыля поставить простенькую прогу, например "Bandwidth Controller". Проверял на XP, правда резал 500Кбит - "подарок" сотрудникам в "неуправляемый" офис. Режет она общий канал вроде бы, не помню если честно. Посмотрите её, если интересно.

А общем нать укрупняться и переходить на легальную основу - со всеми лицензиями, разрешениями, допусками, договорами. И бухгалтерами.

На 1000 грн суммы другие будут, мне кажется, ибо налог выше. Значит и в пенсионный больше платить. Возможно пропорционально.

http://podrobnosti.ua/economy/2010/11/11/730616.html Готовят нам, чувствую, сюрпиз к НГ. Какие будут мнения на этот счёт? Только пожалуйста без истерик.

Обидно за ребят, за их труд. А ушлые люди ничего кроме отвращения не вызывают... взять чужой кабель переключить на себя.. ППЦ. Это из таких наверное, которые у меня в подъезде лампочки воруют. Тоже соседи, Бл#.

Удалено.

Я им ничего доказать не могу. Подключаю ноут к кабелю прова - даже speedtest показывает законные 50Мбит. Что ж я такое натворил, что такая Ж образовалась... Насколько я понял общие выводы - у самого сервера для потери пакетов нет никаких оснований? Он не загружен настолько, чтобы терять что-то, что и подтверждает вывод утилит? Или нет? Вот что сейчас показывает speedtest, себя любимого я не шейплю разумеется.

Тоже над этим думал. По поводу перегрузки канала. Канал 50Мбит, график привожу ниже. Инет сейчас заметно тупит, Speedtest показывает всего 3Мбит запаса, как ни странно. Может конечно count рисующий график и врёт, тем более что там масштаб в 24 часа... Изменил масштаб, второй график рисуется в масштабе 1 час - не похоже на перегруз канала и сопоставление с ifstat это подтверждает, там запас 10-15Мбит. На счёт шейпера не понял. Что значит неверная конфигурация? Вот такой у меня шейп.

У меня просто кончились идеи. Нагрузка на систему действительно аномальная. Материнка ASUS P5KPL-AM SE, вот такая. Я подозреваю, что сначала надо сменить таки железку. netstat -s |grep drop 12921 connections closed (including 713 drops) 3 embryonic connections dropped 33 connections dropped by rexmit timeout 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 connections dropped by keepalive 63 dropped 25251621 dropped due to no socket 0 dropped due to full socket buffers Packet drop statistics: 0 where process_chunk_drop said break 0 number of in data drops due to chunk limit reached 0 number of in data drops due to rwnd limit reached 0 fragments dropped (dup or out of space) 2 fragments dropped after timeout 0 output packets dropped due to no bufs, etc. 0 group-source queries dropped 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 output packets dropped due to no bufs, etc. 0 messages dropped due to no socket 0 multicast messages dropped due to no socket 0 messages dropped due to full socket buffers netstat -ssp udp udp: 28591703 datagrams received 12 with bad data length field 3540 with bad checksum 543227 with no checksum 25256380 dropped due to no socket 146 broadcast/multicast datagrams undelivered 3331625 delivered 3381967 datagrams output vmstat -z ITEM SIZE LIMIT USED FREE REQUESTS FAILURES UMA Kegs: 128, 0, 91, 29, 91, 0 UMA Zones: 888, 0, 91, 1, 91, 0 UMA Slabs: 284, 0, 899, 11, 31574, 0 UMA RCntSlabs: 544, 0, 5867, 6, 5867, 0 UMA Hash: 128, 0, 3, 27, 4, 0 16 Bucket: 76, 0, 58, 42, 79, 0 32 Bucket: 140, 0, 84, 0, 107, 0 64 Bucket: 268, 0, 113, 13, 159, 13 128 Bucket: 524, 0, 1120, 0, 107466, 479 VM OBJECT: 136, 0, 58438, 9190, 86118571, 0 MAP: 140, 0, 7, 21, 7, 0 KMAP ENTRY: 72, 77910, 26, 239, 95275, 0 MAP ENTRY: 72, 0, 3506, 681, 167957112, 0 DP fakepg: 72, 0, 0, 0, 0, 0 SG fakepg: 72, 0, 0, 0, 0, 0 mt_zone: 2056, 0, 279, 0, 279, 0 16: 16, 0, 2627, 621, 31977391, 0 32: 32, 0, 2738, 1556, 11378462, 0 64: 64, 0, 5545, 8792, 31828327, 0 128: 128, 0, 86040, 11400, 104947906, 0 256: 256, 0, 1221, 1314, 2540536370, 0 512: 512, 0, 400, 184, 3945519, 0 1024: 1024, 0, 35, 145, 114634, 0 2048: 2048, 0, 361, 103, 862, 0 4096: 4096, 0, 106, 87, 5388483, 0 Files: 56, 0, 243, 494, 45056181, 0 TURNSTILE: 72, 0, 211, 29, 211, 0 umtx pi: 52, 0, 0, 0, 0, 0 MAC labels: 20, 0, 0, 0, 0, 0 PROC: 680, 0, 69, 63, 5217770, 0 THREAD: 572, 0, 183, 27, 265, 0 SLEEPQUEUE: 32, 0, 211, 143, 211, 0 VMSPACE: 232, 0, 51, 102, 5217743, 0 cpuset: 40, 0, 2, 182, 2, 0 audit_record: 816, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 0, 384, 1198, 0 mbuf: 256, 0, 16684, 2912, 5348327211, 0 mbuf_cluster: 2048, 25600, 8845, 2889, 2755792782, 0 mbuf_jumbo_page: 4096, 12800, 0, 0, 0, 0 mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 406, 119406, 0 NetGraph items: 36, 4130, 0, 177, 22, 0 NetGraph data items: 36, 531, 0, 236, 947232, 0 g_bio: 140, 0, 0, 3472, 7105865, 0 ttyinq: 152, 0, 150, 84, 15465, 0 ttyoutq: 256, 0, 80, 40, 8248, 0 ata_request: 200, 0, 0, 931, 1789133, 0 ata_composite: 180, 0, 0, 0, 0, 0 VNODE: 268, 0, 82087, 9053, 1479039, 0 VNODEPOLL: 60, 0, 0, 0, 0, 0 S VFS Cache: 72, 0, 90331, 8143, 1674598, 0 L VFS Cache: 292, 0, 197, 713, 12885, 0 NAMEI: 1024, 0, 0, 48, 78807575, 0 DIRHASH: 1024, 0, 908, 52, 973, 0 NFSMOUNT: 520, 0, 0, 0, 0, 0 NFSNODE: 464, 0, 0, 0, 0, 0 pipe: 392, 0, 9, 61, 3265184, 0 ksiginfo: 80, 0, 121, 935, 121, 0 itimer: 220, 0, 0, 0, 0, 0 KNOTE: 68, 0, 34, 358, 13659230, 0 socket: 412, 32769, 87, 264, 1382453, 0 ipq: 32, 904, 0, 339, 773, 0 udp_inpcb: 220, 32778, 38, 268, 1248689, 0 udpcb: 8, 32886, 38, 571, 1248689, 0 tcp_inpcb: 220, 32778, 25, 83, 12947, 0 tcpcb: 632, 32772, 24, 48, 12947, 0 tcptw: 52, 6624, 1, 359, 2720, 0 syncache: 112, 15365, 0, 175, 13466, 0 hostcache: 76, 15400, 23, 127, 729, 0 tcpreass: 20, 1690, 0, 338, 783, 0 sackhole: 20, 0, 0, 338, 1466, 0 sctp_ep: 848, 32768, 0, 0, 0, 0 sctp_asoc: 1460, 40000, 0, 0, 0, 0 sctp_laddr: 24, 80040, 0, 290, 10, 0 sctp_raddr: 420, 80001, 0, 0, 0, 0 sctp_chunk: 96, 400000, 0, 0, 0, 0 sctp_readq: 76, 400000, 0, 0, 0, 0 sctp_stream_msg_out: 64, 400020, 0, 0, 0, 0 sctp_asconf: 24, 400055, 0, 0, 0, 0 sctp_asconf_ack: 24, 400055, 0, 0, 0, 0 ripcb: 220, 32778, 3, 87, 50330, 0 unpcb: 172, 32775, 20, 95, 70460, 0 rtentry: 108, 0, 31, 77, 33, 0 IPFW dynamic rule: 108, 0, 0, 0, 0, 0 selfd: 28, 0, 174, 461, 1447055671, 0 ip4flow: 40, 4140, 3881, 259, 19046066, 105285 ip6flow: 64, 4118, 0, 0, 0, 0 SWAPMETA: 276, 121576, 0, 0, 0, 0 Mountpoints: 644, 0, 5, 13, 5, 0 FFS inode: 116, 0, 82050, 9096, 1478957, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 82050, 9075, 1478932, 0 netstat -w 1 -l igb1 input (Total) output packets errs bytes packets errs bytes colls 10788 0 8151785 10479 0 7888692 0 11241 0 8662970 11021 0 8522010 0 11369 0 8433869 11163 0 8342184 0 10788 0 8047539 10461 0 7808241 0 10949 0 8135217 10741 0 8004784 0 11253 0 8455210 11006 0 8323388 0 11438 0 8597379 11280 0 8481065 0 11868 0 9020864 11552 0 8851724 0 11366 0 8559007 11056 0 8351789 0 11437 0 8834409 11260 0 8770704 0 10467 0 7786539 10227 0 7644304 0 11154 0 8263959 10934 0 8139978 0 10997 0 7718177 10759 0 7587859 0 10064 0 7351179 9871 0 7218422 0 11050 0 8186555 10784 0 8031280 0 11158 0 8115181 10964 0 8027404 0 11189 0 8244352 10902 0 8002226 0 11156 0 8324024 10898 0 8181903 0 11042 0 8111127 10796 0 7977523 0 10832 0 7705592 10603 0 7610330 0

Поллинг выключен и вообще выкинут из ядра, т.к. стоит сетевая Intel двухголовая. ifstat -bi igb0 Kbps in Kbps out 29538.57 32567.03 27824.76 29472.26 26665.32 29232.82 28348.63 35206.67 29320.35 31845.23 33039.57 30827.58 30806.07 32500.48 30298.16 33006.48 30034.11 33646.15 28354.57 34425.53 28079.93 32097.64 26523.55 32525.14 30895.39 34709.90 27648.48 35777.17 27251.39 34492.13 27995.45 33320.69 27723.84 30988.97 27858.69 30926.13 25976.54 32575.26 28588.74 32604.11 27886.45 35328.21 25322.13 32181.69 netstat -w 1 -d input (Total) output packets errs bytes packets errs bytes colls drops 12151 0 9174157 11964 0 9117579 0 0 12204 0 9105880 12068 0 9109103 0 0 12198 0 9328634 11991 0 9276049 0 0 11977 0 8946527 11786 0 8903867 0 0 12159 0 9224388 12019 0 9196752 0 0 12113 0 9165911 11782 0 8979819 0 0 12229 0 9090506 12046 0 9123520 0 0 12161 0 8868137 11925 0 8741512 0 0 11748 0 8780555 11464 0 8628909 0 0 11809 0 8758810 11539 0 8609003 0 0 12376 0 9051216 12116 0 8957422 0 0 11651 0 8455918 11521 0 8479200 0 0 12411 0 9084297 12191 0 8948253 0 0 11757 0 8456806 11567 0 8433097 0 0 11666 0 8751484 11408 0 8609047 0 0 11608 0 8654554 11399 0 8564594 0 0 11000 0 7839972 10836 0 7748067 0 0 11687 0 8499644 11487 0 8472204 0 0 11731 0 8493201 11452 0 8334278 0 0 12564 0 8757841 12234 0 8576710 0 0 netstat -w 1 -l igb0 input (Total) output packets errs bytes packets errs bytes colls 11472 0 8330377 11314 0 8310082 0 11613 0 8624010 11440 0 8551662 0 12418 0 8992147 12085 0 8784117 0 11280 0 8376651 11157 0 8340652 0 11903 0 8670950 11790 0 8717275 0 12595 0 9333740 12276 0 9152489 0 12402 0 9058609 12181 0 8894729 0 11565 0 8889805 11263 0 8783651 0 11604 0 8475820 11436 0 8442891 0 11985 0 8925220 11689 0 8663824 0 11307 0 8466162 11247 0 8599252 0 11997 0 8994348 11860 0 8993543 0 11384 0 8678503 11098 0 8477892 0 11453 0 8709887 11272 0 8636005 0 11470 0 8901509 11367 0 8916036 0 Пинг вырос с 1 до 6-10мс, ну и дропы пакетов идут. Бл#. Причём поблемы с дропом и высоким пингом толко наружу, из сетки я свой шлюз пингую - всё ок.

Увы, ipfw -d show не подходит, но всё равно спасибо. Я б не завязывался, но существует подозрение что кол-во сессий сильно нагружает сервер сети. Т.к. резать сессии всем подряд не хочется - думаю может как-то можно отследить их число для каждого. Может вирусня какая-то или ещё чего.

Эта какой-то ППЦ. Трафик 4-8Мбайт входящего и 2-4Мбайт исходящий. 3000-5000pps. Потери пакетов (пингую с сервера - шлюз провайдера) до 10%. Выходит зря промучался. Конечно если не считать побеждённый IPFW NAT. Судя по графику загрузки системы - это связано именно с нагрузкой на тазик, т.е. медный линк (5-7метров) между мегабитной сетевой картой и медиаконвертером тут ни при чём, равно как и провайдер не виноват. Не виноват и софтовый роутер на FreeBSD, тем более что он ничем кроме роутинга не занят и по идее может прокачать дохрени трафа (старенький пень 2,8ГГЦ и 2ГГБ ОЗУ, 3 реалтека и одна встроенная гигабитная карточка). Гложет мысль, что валится это всё числом сессий, но пока не нашёл способа выяснить как всё же посмотреть такую статистику на ipfw nat (на pf это можно было делать, но не догадался глянуть в своё время). А счастье было так близко. Придётся таки менять железку. ipfw nat 1 show nat 1: icmp=7, udp=16490, tcp=35463, sctp=0, pptp=0, proto=0, frag_id=1 frag_ptr=0 / tot=51961

Использую ipfw nat. Пробовал ipfw pipe show - хрень какую-то паказывает. Как посмотреть кол-во сессий, открытых в мир с конкретного IP на шлюзе FreeBSD? Только не через trafshow, хотелось бы просто число получить в текстовом файле, вида: IP - NN. Спасибо.

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

Рад за Вас. По поводу Вашей проблемы - я могу ошибаться, но по-моему pf плохо справляется с нарезкой исходящего трафика. Возможно отсюда все беды. Во всяком случае именно поэтому я им и не стал ничего резать, а воспользовался ipfw. Сейчас конечно может уже сделали чего-то, давно было. По поводу ADSL - можно попробовать поиграться настройками модема и потестить. Возможно изменение модуляции даст свои плоды ещё какие-нибудь настройки. Как крайняя мера - снижение скорости соединения. На двух мегабитах, особенно с исходом в 512К - пинг и будет расти, от этого никуда не денешься. Ясное дело, что если у Вас забит исходящий - будет та же свистопляска (вот почему я заговорил на счёт pf, сомнения у меня что он режет исход). Приоретизация и нарезка трафика на такой скорости естественно повысит пинги (особенно если ICMP у Вас имеет низкий приоритет), ибо механизм того же шейпа подразумевает дроп (отброс) пакетов, когда переполняется очередь шейпа. Чем уже канал, тем это заметнее. Повышение пинга на более узком канале по сравнени с широким - закономерность. Я у себя это наблюдаю, когда тестирую нарезку, допустим, 256Кбит. Разница в пингах между 256К и 2048К - довольно существенная. Я не настолько хорошо разбираюсь в этом, чтоб конкретно к Вашей ситуации советовать применить тот или иной способ: у меня до сих по существует проблема в работе сервера, как сегодня оказалось. Но на Вашем канале пожалуй это нормально будет работать и никаких заморочек с правилами. Смысл в том, чтобы оставить за pf право натить внутренню сеть в Инет и заниматься пробросом портов/адресов, а ipfw прикрутить как шейпер. Почитайте это: http://local.com.ua/forum/topic/20228-помогите-с-pf/page__p__149597__hl__ipfw%2Bpf__fromsearch__1#entry149597 и ещё тут: http://local.com.ua/forum/topic/20234-шейпер-на-pf/page__p__149645__hl__ipfw%2Bpf__fromsearch__1#entry149645 Там кстати человек пишет, что pf по дефолту шейпит только в одну сторону. PF не работает с gre-пакетами, которые нужны для работы VPN. Лечится пробросом портов, но работать сможет одновременно только одна машина (подключаться к мировым VPN) или проброс белого IP на машину в сеть. Я натыкался на ешё один способ, в котором рассматривалась проблема работы связки ipfw+nat и настройка VPN через это всё, но у меня не заработало почему-то. Так и промучался, пока не вернулся на родной NAT.

Сделал вот так как здесь описал, но сомнения гложат. Выложите пожалуйста образец OnConnect и OnDisconnect для IPFW NAT, на основе таблиц. И кусочек скрипта фаерволла, относящегося к этому вопросу. Для самопроверки.

Поскольку у Вас канал мал и несимметричен и скорее всего ещё и ADSL (или я не прав? ), то "уложить" его банальным speedtest, а уж тем более торрентами - раз плюнуть. А Вы пробовали просто подкинуть машину на Windows и сделать то же самое, например speedtest, при этом замеряя пинг? Может дело не в сервере? И потом, Вы уверены, что pf правильно режет трафик? У меня была проблема порезать именно исходящий трафик на pf. Стоит та же операционка, что и у Вас - FreeBSD 8. Тоже почти ничего не трогал. Она с небольшой нагрузкой обычно по-умолчанию замечательно работает.