vadius
-
Публикации
36 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные пользователем vadius
-
-
Всем доброго дня.
Господа, подскажите пожалуйста, что можно сделать, столкнулись с такой проблемой в iptv.
Коммутаторы доступа DES-3526(fw 6.20.B18), DES-3200(fw 1.81.B005), в ядре DGS-3627G.
Iptv (мультикаст) берем у вышестоящего провайдера, и на DGS-3627G маршрутизируем через PIM SM в нашу сеть.
Через ISM vlan идет передача iptv клиентам.
Все в общем работало прекрасно несколько лет, пока не появились у клиентов роутеры DIR-615 ревизий K2. Прошивки перепробовали разные.
Через роутер показывает несколько каналов, а большая часть не показывает совсем.
Хотя смотрю на коммутаторе подписка на группу проходит и мультикаст поток льется на порт, к которому подключен роутер. Но через роутер не проходит.
Если подключить к компьютеру, то все работает замечательно.
В то же время если смотреть иптв через роутеры DIR-300,DIR-320,DIR-615(первых ревизий) и через компьютер все работает замечательно.
Вот настрока IGMP snooping на DES-3526:
enable igmp_snooping create igmp_snooping multicast_vlan v100 100 config igmp_snooping multicast_vlan v100 state enable replace_source_ip 10.100.0.30 member_port 1-24,26 source_port 25 config igmp_snooping v100 host_timeout 260 router_timeout 260 leave_timer 2 state enable config igmp_snooping querier v100 query_interval 60 max_response_time 10 robustness_variable 2 config igmp_snooping querier v100 last_member_query_interval 1 state disable config router_ports v100 add 25 create multicast_range tv_media_al from 239.192.0.0 to 239.192.100.255 create multicast_range m_roters from 224.0.0.2 to 224.0.0.2 config limited_multicast_addr ports 1-26 add multicast_range tv_media_al config limited_multicast_addr ports 1-26 add multicast_range m_roters config limited_multicast_addr ports 1-24,26 access permit state enable config limited_multicast_addr ports 25 access deny state disable config igmp access_authentication ports 1-26 state disable
Уже сломал голову...
-
да мне она в глаза и бросилась, что новая :) Я бы для теста постарее какую-нить накатил
на предыдущих прошивках была проблема с dhcp relay, поэтому поставил эту.
-
А прошивку не меняли?
Ну вроде одна из последних 6.20B18.
-
Как бы хороошим тоном, а то и обязательным условием нужно
1.Изолировать управляющий влан от клиентских.
2.Доступа туда у клиентов быть не должно.
у нас управляющий влан вынесен отдельно от клиентских. Доступа у клиентов нет, есть только с серверов с билингом и мониторинга.
как показывает практика - это либо проблемы с медью, либо умирают порты.
Вчера на одном коммутаторе DES-3526 (прошивка 6.20B18) обнаружилась подобная проблема как у ТС, позвонил клиент, что у него не работает инет, но адрес по dhcp успевает получить. Все логи на свитче забиты сообщениями линк ап, линк доун. Чтобы исключить проблему с проводкой до клиента, на чердаке напрямую воткнули ноутбук в коммутатор. Та же ерунда: порт включится, выключится, включится, выключится ..., за минуту раз 5-6. И такое на любом порту 1-24, включаешь в 26 порт (аплинк на 25) все нормально. Коммутатор перезагружали не помогает. Если скорость перевести в 10мбит тоже все нормально. Глянул на других коммутаторах, на некоторых тоже в логах похожее есть, но клиенты не жаловались.
Попробуем еще отключить всех клиентов и аплинк от коммутатора и проверим с ноутом как будет он себя вести.
Вот кстати кусочек лога когда подключаются к нему клиенты, как видно в конце скорость переключилась на 10мбит, и дальше все работает:
3927 2013/02/09 11:09:55 Port 6 link up, 10Mbps FULL duplex
3926 2013/02/09 11:09:53 Port 6 link down
3925 2013/02/09 11:09:52 Port 6 link up, 100Mbps FULL duplex
3924 2013/02/09 11:09:46 Port 6 link down
3923 2013/02/09 11:09:45 Port 6 link up, 100Mbps FULL duplex
3922 2013/02/09 11:09:41 Port 6 link down
3921 2013/02/09 11:09:40 Port 6 link up, 100Mbps FULL duplex
3920 2013/02/09 11:09:38 Port 6 link down
3919 2013/02/09 11:03:53 Port 6 link up, 10Mbps FULL duplex
3918 2013/02/09 11:03:44 Port 6 link down
3917 2013/02/09 11:03:43 Port 6 link up, 100Mbps FULL duplex
3916 2013/02/09 11:03:36 Port 6 link down
3915 2013/02/09 11:02:43 Port 6 link up, 10Mbps FULL duplex
3914 2013/02/09 11:02:37 Port 6 link down
3913 2013/02/09 11:02:36 Port 6 link up, 100Mbps FULL duplex
3912 2013/02/09 11:02:29 Port 6 link down
3911 2013/02/09 11:02:28 Port 6 link up, 100Mbps FULL duplex
3910 2013/02/09 11:01:13 Port 6 link down
-
cibris
Подскажите, удалось побороть проблему? У себя на некоторых коммутаторах наблюдаю подобное.
-
WS-X4516-10GE
у него
Per-slot switching capacity6 Gbps
если нужна неблокируемая архитектура, то я уверен, что на 6500 будет дешевле собрать оптический агрегатор
http://shop.nag.ru/catalog/02392.Cisco/06753.Moduli-6500/00107.WS-SUP720-3B
http://shop.nag.ru/catalog/02392.Cisco/06753.Moduli-6500/02980.WS-X6724-SFP
понятно, тогда пока оставим sfp на 3627
-
Опубликовано · Изменено пользователем vadius · Жалоба на ответ
Сейчас прикидываю шасси 4500Е, гляньте пожалуйста.
1. Шасси: WS-C4507R-E
2. Блоки питания. Какой мощности брать, если шасси в итоге забить линейными модулями с SFP портами?
3. Управляющий модуль: WS-X4516-10GE (пока один, чуть попозже взять второй резервный).
Смутил один момент в описании модуля:
1 GE non-blocking Fiber Ports - 48, Получается если поставить линейные модули с SFP, с суммарным количеством больше 48 портов, то уже не получим неблокируемую архитектуру? Нужен будет sup помощнее?
4. Модуль 10GBASE-CX4: X2-10GE-CX4, для подключения DGS-3627
5. Еще не понятный момент с компановками IOS - Basic/Enhanced. Какая версия идет по умолчанию в модуле? Что стОит проапгрейдить?
что еще понадобится?
В будущем планирую отказаться от DGS3627G, а вместо них взять линейные модули с SFP портами в шасси и заводить линки с коммутаторов уровня распределения напрямую в него.
-
Te1/1 connected trunk full 10G 10GBase-CX4
Te1/2 connected trunk full 10G 10GBase-CX4
Gi1/3 connected trunk full 1000 1000BaseLH
Gi1/4 connected trunk full 1000 1000BaseLH
Gi1/5 connected trunk full 1000 1000BaseLH
Gi1/6 connected trunk full 1000 Unknown GBIC
#sh inv | inc Sup
NAME: "Linecard(slot 1)", DESCR: "Supervisor V-10GE with 2 10GE X2 ports, and 4
1000BaseX SFP ports"
все работает, без проблем.
te1/1, te1/2 по cx4 уползают к 3627 и 3120.
Ну тогда здорово, спасибо огромное!
-
Или модули от 4500 можно поставить на шасси 4500е?
Там куча ограничений по использованию "смесей", первое с чем столкнетесь - супервизор. в 4500-E, если мне не изменяет память, только Sup V-10GE (от старых 4500) способен завестись, либо новые (маркируются "-E").
Производительность у Sup V-10GE для вашей ситуации более чем достаточная и запас имеется.
Отличительная особенность - можно использовать microflow policing. Про эту фишку можно почитать тут: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps4324/prod_white_paper0900aecd8041691c.html
В свое время microflow policing позволили "мягко" модернизировать сети, когда на сети еще оставалась полудохлая медь, но уже в обиход пошли серые пиринги и массовый p2p файлообмен.
В среднем, этого мозга хватит вашей сети вплоть до 8-10к активных абонентов (или даже значительно больше, смотря сколько функционала задействуете). Если изначально собирать в шасси 4500E, вы сможете вполне спокойно модернизировать ядро в дальнейшем (докупить линейные карты и более производительный суп). Но если в ваших планах нет "переходного периода", имеет смысл посмотреть сразу в сторону 4900M.
- один 4900M может вполне спокойно держать на себе до 30-40к пользователей. http://www.cisco.com/en/US/products/ps9310/index.html
Спасибо за подробные разъяснения.
Появились новые вопросы :)
А если в шасси 4500-E поставить только Sup V-10GE, без дополнительных линейных модулей, будет работать? Есть мысля по 10Gе соединить со стеком DGS-3627G, а на гигабитные порты повесить NAS-ы. А чуть попозже при необходимости докупить линейные модули.
Т.е схема такая:
Пользователи -> DES-3526(3200) -> DGS-3100 (DES-3200) -> DGS-3627G (Стек из 3х) <-10ge-> 4500E <-1ge-> NAS
Будут ли какие-нибудь подводные камни при соединении длинка с циской по 10ge?
И еще вопросик, модули 10ge на sup докупаются отдельно?
-
Только наверно не устаревший 4500, а 4500E.Спасибо всем, гляну в сторону 4500, пока почитаю про него.
На модули 4500е ценники уже зашкаливают, а 4500 слабоват будет?
Или модули от 4500 можно поставить на шасси 4500е?
-
IP unnumbered у вас на базе dhcp-snooping или connected host polling (arp polling) ? если второе, шеститонник не для вас (6500/7600 не умеют CHP) - для роста тут можно смотреть в сторону 4500/4500E платформы, в том числе и 4900M.
3550 - 3750, в случае пока у вас 2к абонентов, может и хватит, но для них это уже близко к пределу (особенно со всякими ip unnumbered). Самый дешевый вариант - держать несколько 3550 (в том числе и парочку в прозапас, на случай выхода из строя). Но лучше уже начать присматриваться к более современным и производительным платформам, чтобы в одночасье не сгинуть под необходимостью новых фич (например pimv2, mld, и прочий ipv6).
IP unnuberred на базе CHP.
Спасибо всем, гляну в сторону 4500, пока почитаю про него.
-
у 3750-24 унылые SDM-профили
я бы смотрел в сторону 3750-12
или пару 3550-12
интереснее было бы собрать шасси 6500 конечно, если бюджет позволяет.
Циску, я поставил 4 штуки 3550-12T на 2к абонентов (500 абонов на устройство). Но спокойно спать боюсь, ибо проц очень слаб, и легко убивается флудом даже единственного сетевого устройства. Всё-таки, нужно что-то гораздо мощнее.
А два 3750-12 хватит на 2000-3000 клиентов, или смотреть уже в сторону шасси 6500?
-
сегментировать в коллизионные домены по 500 маков итого 4 влана на трафик и 4 влана управления и всё это только на доступе, стек разбирать не надо
вдвоём сеть из 500 коммутаторов можно за неделю причесать
Если не затруднит, можете поподробнее объяснить, как реализовать. недопонял.
сегментировать в коллизионные домены
Имелось ввиду наверное широковещательные домены?
-
Опубликовано · Изменено пользователем vadius · Жалоба на ответ
Приветствую всех.
Нужен совет.
Схема сети такая:
Пользователи -> DES-3526(3200) -> DGS-3100 (DES-3200) -> DGS-3627G (Стек из 3х) -> NAS
Клиентов порядка 2000. На данный момент все в одном влане. Нужно сегментировать сеть.
Есть планы сделать влан на свитч доступа, но пока нет возможности, планируем после того как всех клиентов переведем на белые ip.
Сейчас рассматриваю схему traffic segmentation на свитчах доступа, и поднять local proxy arp в ядре.
по типу
Но после тестов и глюков отказались от идеи прокси арпа на 3627.
Сейчас есть мысли взять бу циску в ядро, раскидать стек из 3627 на отдельные свитчи, и через LACP завести в циску. Ну и поднять local proxy arp на ней.
Подскажите, у кого-нибудь работает нормально подобная схема с traffic segmentation и proxy arp?
Порекомендуйте пожалуйста, что лучше взять из цисок с 24 гигабитными интерфейсами, которая потянет 4-5 тыс арп (в перспективе поднять на ней ip unnumbered на 300-400 вланов со свитчей доступа).
Ранее с цисками дел не имел. Пока присмотрел WS-C3750G-24TS, сгодится на эту роль?
-
С net.inet.ip.fastforwarding=0 сервер перезагрузился через 3 дня, корка не создалась.
-
Пробовал ставить net.inet.ip.fastforwarding=0, с полгода назад эксперементировал, не помогало.
Надо будет попробовать сейчас, может после обновления ядра, что поменялось.
-
Всем привет.
Решил поднять тему снова, так как зависания сервера продолжаются (раз в 5-6 дней). Ни обновления, ни тюнинг не помогают.
Удалось получить корку ядра.
В отладке ядра несилён, так что если нужна какая инфа пишите.
ns# kgdb kernel.debug /var/crash/vmcore.0
...
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 6; apic id = 32
fault virtual address = 0xffffffff00040061
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff805121ab
stack pointer = 0x28:0xffffff823b9948c0
frame pointer = 0x28:0xffffff823b994940
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 0 (em2 taskq)
trap number = 12
panic: page fault
cpuid = 6
KDB: stack backtrace:
#0 0xffffffff80460a2e at kdb_backtrace+0x5e
#1 0xffffffff8042f5d7 at panic+0x187
#2 0xffffffff806f4ba0 at trap_fatal+0x290
#3 0xffffffff806f4ef1 at trap_pfault+0x201
#4 0xffffffff806f53af at trap+0x3df
#5 0xffffffff806dcd24 at calltrap+0x8
#6 0xffffffff805128ef at icmp_error+0x24f
#7 0xffffffff80508d10 at ip_fastforward+0x810
#8 0xffffffff804dc2a8 at ether_demux+0x198
#9 0xffffffff804dc64d at ether_input+0x17d
#10 0xffffffff8028111a at em_rxeof+0x1ca
#11 0xffffffff8028159b at em_handle_que+0x5b
#12 0xffffffff8046c335 at taskqueue_run_locked+0x85
#13 0xffffffff8046c4ce at taskqueue_thread_loop+0x4e
#14 0xffffffff80404a7f at fork_exit+0x11f
#15 0xffffffff806dd26e at fork_trampoline+0xe
Uptime: 5d5h1m10s
Dumping 1454 out of 8119 MB:..2%..12%..21%..31%..41%..51%..61%..71%..81%..91%Attempt to write outside dump device boundaries.
offset(12884921344), mediaoffset(4294999552), length(65536), mediasize(8589934592).
Dump map grown while dumping. Retrying...
Dumping 1474 out of 8119 MB:
Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /boot/kernel/coretemp.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/coretemp.ko
Reading symbols from /boot/kernel/blank_saver.ko...Reading symbols from /boot/kernel/blank_saver.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/blank_saver.ko
#0 doadump () at pcpu.h:224
224 __asm("movq %%gs:0,%0" : "=r" (td));
(kgdb) list *0xffffffff805121ab
0xffffffff805121ab is in icmp_reflect (../../../netinet/ip_icmp.c:702).
697 */
698 ifp = m->m_pkthdr.rcvif;
699 if (ifp != NULL && ifp->if_flags & IFF_BROADCAST) {
700 IF_ADDR_LOCK(ifp);
701 TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) {
702 if (ifa->ifa_addr->sa_family != AF_INET)
703 continue;
704 ia = ifatoia(ifa);
705 if (satosin(&ia->ia_broadaddr)->sin_addr.s_addr ==
706 t.s_addr) {
(kgdb) bt
#0 doadump () at pcpu.h:224
#1 0xffffffff8042f120 in boot (howto=260) at ../../../kern/kern_shutdown.c:441
#2 0xffffffff8042f5c1 in panic (fmt=Variable "fmt" is not available.
) at ../../../kern/kern_shutdown.c:614
#3 0xffffffff806f4ba0 in trap_fatal (frame=0xc, eva=Variable "eva" is not available.
) at ../../../amd64/amd64/trap.c:824
#4 0xffffffff806f4ef1 in trap_pfault (frame=0xffffff823b994810, usermode=0) at ../../../amd64/amd64/trap.c:740
#5 0xffffffff806f53af in trap (frame=0xffffff823b994810) at ../../../amd64/amd64/trap.c:477
#6 0xffffffff806dcd24 in calltrap () at ../../../amd64/amd64/exception.S:228
#7 0xffffffff805121ab in icmp_reflect (m=0xffffff00291ba000) at ../../../netinet/ip_icmp.c:702
#8 0xffffffff805128ef in icmp_error (n=0xffffff002a871c00, type=689676512, code=0, dest=0, mtu=0) at ../../../netinet/ip_icmp.c:313
#9 0xffffffff80508d10 in ip_fastforward (m=0xffffff002a871c00) at ../../../netinet/ip_fastfwd.c:402
#10 0xffffffff804dc2a8 in ether_demux (ifp=0xffffff0002707800, m=0xffffff002a871c00) at ../../../net/if_ethersubr.c:830
#11 0xffffffff804dc64d in ether_input (ifp=0xffffff0002707800, m=0xffffff002a871c00) at ../../../net/if_ethersubr.c:753
#12 0xffffffff8028111a in em_rxeof (rxr=0xffffff0002780c00, count=1999, done=0x0) at ../../../dev/e1000/if_em.c:4311
#13 0xffffffff8028159b in em_handle_que (context=Variable "context" is not available.
) at ../../../dev/e1000/if_em.c:1489
#14 0xffffffff8046c335 in taskqueue_run_locked (queue=0xffffff0002783e00) at ../../../kern/subr_taskqueue.c:250
#15 0xffffffff8046c4ce in taskqueue_thread_loop (arg=Variable "arg" is not available.
) at ../../../kern/subr_taskqueue.c:387
#16 0xffffffff80404a7f in fork_exit (callout=0xffffffff8046c480 <taskqueue_thread_loop>, arg=0xffffff8000834748, frame=0xffffff823b994c50)
at ../../../kern/kern_fork.c:876
#17 0xffffffff806dd26e in fork_trampoline () at ../../../amd64/amd64/exception.S:602
#18 0x0000000000000000 in ?? ()
#19 0x0000000000000000 in ?? ()
#20 0x0000000000000000 in ?? ()
#21 0x0000000000000000 in ?? ()
#22 0x0000000000000000 in ?? ()
#23 0x0000000000000000 in ?? ()
#24 0x0000000000000000 in ?? ()
#25 0x0000000000000000 in ?? ()
#26 0x0000000000000000 in ?? ()
#27 0x0000000000000000 in ?? ()
#28 0x0000000000000000 in ?? ()
#29 0x0000000000000000 in ?? ()
#30 0x0000000000000000 in ?? ()
#31 0x0000000000000000 in ?? ()
#32 0x0000000000000000 in ?? ()
#33 0x0000000000000000 in ?? ()
#34 0x0000000000000000 in ?? ()
#35 0x0000000000000000 in ?? ()
#36 0x0000000000000000 in ?? ()
#37 0x0000000000000000 in ?? ()
#38 0x0000000000000000 in ?? ()
#39 0x0000000000000000 in ?? ()
#40 0x0000000000000000 in ?? ()
#41 0x0000000000000000 in ?? ()
#42 0xffffffff809b1a00 in affinity ()
#43 0x0000000000000000 in ?? ()
#44 0x0000000000000000 in ?? ()
#45 0xffffff000271d460 in ?? ()
#46 0xffffff823b994140 in ?? ()
#47 0xffffff823b9940e8 in ?? ()
#48 0xffffff0002b858c0 in ?? ()
#49 0xffffffff80453bc2 in sched_switch (td=0xffffffff8046c480, newtd=0xffffff8000834748, flags=Variable "flags" is not available.
) at ../../../kern/sched_ule.c:1860
Previous frame inner to this frame (corrupt stack?)
-
интерфейс чего? интерфейс на NAS, который один для всего (наружу)? или интерфейс на ROUTER? :) или интерфейс в сторону клиента? который ngxx и всегда разный?
у меня на роутере весь трафик идущий с инета к NASу, заворачивается в влан. Сейчас это используется чтобы на NASах была возможность отделить инет от города, и вести учет трафика в биллинге только с инета. так у меня была идея шейпить этот трафик на NASe приходящий по влану с роутера
-
Сможет. У нас так и делается, количество клиентов больше.
спасибо, пошел по этому пути, уже накатал скрипты.
-
Если "городские" - это серые, то их не так много и можно указать все сразу (надеюсь серые сети в инет вы не выпускаете). В своё время я долго тестил такое решение и в итоге внедрил. Нареканий нет, всё достаточно гибко и стабильно работает. Причём это без костылей в виде скриптов и т.п., работает на уровне самого mpd (т.е. на уровне ядра).
у меня возникает один нюанс: Пока клиент не подключился к впн серверу(pptp), ip у него серый и он свободно может лазить по городским ресурсам, резать скорость не надо, в инет доступа нет. После подключения к впн клиент получает реальный ip и он уже с этим адресом лазит и в инете и в городе. В городе анонсированы и серые и белые адреса клиентов. Поэтому фильтровать город по серым адресам не получается. Вот если бы в mpd-filter можно было указать интерфейс, было бы проще.
-
Благодарю за ответы.
Немного ввел в заблуждение насчет реальных ip, так что извините.
Суть такая. По dhcp клиент получает адрес из диапазона "городских" серых адресов, по которым он может ходить по "городским" ресурсам (около 40 других городских сетей), без доступа в инет. После подключения по pptp он получает реальный ip, в этом случает доступ на все ресурсы не ограничен. Вот здесь и надо резать скорость только на инет.
mpd5 умеет шейпить сам. То, что "в трубе" зашейпит mpd5, всё остальное шейпить на ipfw (к примеру) или вообще не шейпить ...читайте про mpd-filter, mpd-limit, mpd-input-acct и mpd-output-acct
у меня таким способом шепится согласно тарифу всё что в трубе учитывая с каких сетей считать трафик, а с каких не считать (опять же согласно тарифу) клиент просто перекидывается из группы в группу. группа привязана к тарифу, т.е. сменили тариф - сменилась группа, в которую включён клиент, всё на PgSQL, включайте фантазию и всё получится :)
пытался и так реализовать, но здесь как я понимаю в mpd-filter нужно перечислять с каких сетей трафик шейпить, а у меня в пиринге порядка 40 городских сетей, список ip-адресов постоянно меняется, таблицы маршрутизации строятся на роутере через bgp. Хотя не исключаю, что я где-то не врубился :)
Шейпинг через таблицы и dummynet: http://forum.nag.ru/...showtopic=54379Два правила ipfw, две таблицы, по две трубы на каждый тариф, по одной записи в двух таблицах на каждого клиента.
спасибо, почитаю приведенную ветку. А если всех клиентов (~4тыс.) активных и не активных, засунуть в таблицы на роутере (с периодическим обновлением), dummynet сможет переварить их нормально? А то может я зря ищу способ как на роутере изменять таблицы при подключении клиента к NASу и его отключении.
-
Опубликовано · Изменено пользователем vadius · Жалоба на ответ
Подскажите пожалуйста, не могу придумать как грамотно разрулить шейпера.
Имеем в упрощенном виде:
inet город
\ /
ROUTER
/ \
NAS1 NAS2
|||| ||||
клиенты
ROUTER:
FreeBSD 8.2
Bgp, ospf.
NAS:
FreeBSD 8.1
Mpd5(pptp), Radius.
Нужно настроить шейпера, чтобы скорость интернета у клиентов была согласно тарифному плану,
а городские ресурсы без ограничений. У клиентов реальные IP.
На данный момент шейпер(dummynet) висит на ROUTER на входящем интернет интерфейсе.
На каждый тарифный план выделена своя подсеть и есть несколько правил типа:
00011 pipe 1 ip from any to 111.222.333.0/24 in via eth1
00011 pipe 2 ip from 111.222.333.0/24 to any out via eth1
где eth1 смотрит в инет.
Есть желание все это перевести на таблицы, и уйти от привязки ip адреса к тарифному плану.
Думал перенести шейпера на NASы, и формировать таблицу через radius аттрибут mpd-table с tablearg, или шейпить
через ng_car. Но во всех этих случаях скорость ограничивается и на интернет и на город. Есть вариант,
на роутере заворачивать трафик пришедший из инета в влан, а на NASе только его шейпить, но не понятно как
шейпить исходящий, опять будет действовать и на город и на инет.
Если поднимать таблицы на ROUTER, то как их там формировать?
Как лучше сделать, подскажите.
-
Опубликовано · Изменено пользователем vadius · Жалоба на ответ
А что там такое на 3-4 ядрах ?не знаю, я ничего к ним не привязывал
HT отключен.
egrep '^[[:space:]]*cpu' /var/run/dmesg.boot
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 2
cpu2 (AP): APIC ID: 18
cpu3 (AP): APIC ID: 20
cpu4 (AP): APIC ID: 32
cpu5 (AP): APIC ID: 34
cpu6 (AP): APIC ID: 50
cpu7 (AP): APIC ID: 52
cpu0: <ACPI CPU> on acpi0
cpu1: <ACPI CPU> on acpi0
cpu2: <ACPI CPU> on acpi0
cpu3: <ACPI CPU> on acpi0
cpu4: <ACPI CPU> on acpi0
cpu5: <ACPI CPU> on acpi0
cpu6: <ACPI CPU> on acpi0
cpu7: <ACPI CPU> on acpi0
флоу кеш из ядра удалить нафик - пересобрать ядро без него.
flowtable из ядра убран был сразу, с ним сетевая подсистема вставала колом буквально через 1-2 минуты после поднятия сервера.
-
да уже думал что надо было ставить i386 на роутер.
nmbclusters поставил в 61000 буду смотреть.
IPTV через клиентские роутеры
в Активное оборудование Ethernet, IP, MPLS, SDN/NFV...
Опубликовано · Жалоба на ответ
triam спасибо за совет, есть подозрение что действительно в ttl проблема. Сейчас с провайдером обсудим.