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

vadius

Пользователи
 Просмотреть профиль  Активность

  • Публикации

    36

  • Зарегистрирован

  • Посещение

 Тип публикации 

Сообщения, опубликованные пользователем vadius

  2. Опубликовано · Жалоба на ответ

    Всем доброго дня.

    Господа, подскажите пожалуйста, что можно сделать, столкнулись с такой проблемой в 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

     

    Уже сломал голову...

  5. Опубликовано · Жалоба на ответ

    Как бы хороошим тоном, а то и обязательным условием нужно

    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

  7. Опубликовано · Жалоба на ответ

    WS-X4516-10GE

    у него

    Per-slot switching capacity

    6 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

  8. Опубликовано · Изменено пользователем 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 портами в шасси и заводить линки с коммутаторов уровня распределения напрямую в него.

  9. Опубликовано · Жалоба на ответ

    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.

     

    Ну тогда здорово, спасибо огромное!

  10. Опубликовано · Жалоба на ответ

    Или модули от 4500 можно поставить на шасси 4500е?

    Там куча ограничений по использованию "смесей", первое с чем столкнетесь - супервизор. в 4500-E, если мне не изменяет память, только Sup V-10GE (от старых 4500) способен завестись, либо новые (маркируются "-E").

    Производительность у Sup V-10GE для вашей ситуации более чем достаточная и запас имеется.

    http://www.cisco.com/en/US/prod/collateral/modules/ps2797/ps6033/product_data_sheet0900aecd801c5c66.html

    Отличительная особенность - можно использовать 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 докупаются отдельно?

  11. Опубликовано · Жалоба на ответ

    Спасибо всем, гляну в сторону 4500, пока почитаю про него.

    Только наверно не устаревший 4500, а 4500E.

    На модули 4500е ценники уже зашкаливают, а 4500 слабоват будет?

    Или модули от 4500 можно поставить на шасси 4500е?

  12. Опубликовано · Жалоба на ответ

    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, пока почитаю про него.

  13. Опубликовано · Жалоба на ответ

    у 3750-24 унылые SDM-профили

     

    я бы смотрел в сторону 3750-12

     

    или пару 3550-12

    интереснее было бы собрать шасси 6500 конечно, если бюджет позволяет.

    Циску, я поставил 4 штуки 3550-12T на 2к абонентов (500 абонов на устройство). Но спокойно спать боюсь, ибо проц очень слаб, и легко убивается флудом даже единственного сетевого устройства. Всё-таки, нужно что-то гораздо мощнее.

    А два 3750-12 хватит на 2000-3000 клиентов, или смотреть уже в сторону шасси 6500?

  14. Опубликовано · Жалоба на ответ

    сегментировать в коллизионные домены по 500 маков итого 4 влана на трафик и 4 влана управления и всё это только на доступе, стек разбирать не надо

    вдвоём сеть из 500 коммутаторов можно за неделю причесать

    Если не затруднит, можете поподробнее объяснить, как реализовать. недопонял.

    сегментировать в коллизионные домены

    Имелось ввиду наверное широковещательные домены?

  15. Опубликовано · Изменено пользователем 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, сгодится на эту роль?

  18. Опубликовано · Жалоба на ответ

    Всем привет.

    Решил поднять тему снова, так как зависания сервера продолжаются (раз в 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?)

  19. Опубликовано · Жалоба на ответ

    интерфейс чего? интерфейс на NAS, который один для всего (наружу)? или интерфейс на ROUTER? :) или интерфейс в сторону клиента? который ngxx и всегда разный?

    у меня на роутере весь трафик идущий с инета к NASу, заворачивается в влан. Сейчас это используется чтобы на NASах была возможность отделить инет от города, и вести учет трафика в биллинге только с инета. так у меня была идея шейпить этот трафик на NASe приходящий по влану с роутера

  21. Опубликовано · Жалоба на ответ

    Если "городские" - это серые, то их не так много и можно указать все сразу (надеюсь серые сети в инет вы не выпускаете). В своё время я долго тестил такое решение и в итоге внедрил. Нареканий нет, всё достаточно гибко и стабильно работает. Причём это без костылей в виде скриптов и т.п., работает на уровне самого mpd (т.е. на уровне ядра).

    у меня возникает один нюанс: Пока клиент не подключился к впн серверу(pptp), ip у него серый и он свободно может лазить по городским ресурсам, резать скорость не надо, в инет доступа нет. После подключения к впн клиент получает реальный ip и он уже с этим адресом лазит и в инете и в городе. В городе анонсированы и серые и белые адреса клиентов. Поэтому фильтровать город по серым адресам не получается. Вот если бы в mpd-filter можно было указать интерфейс, было бы проще.

  22. Опубликовано · Жалоба на ответ

    Благодарю за ответы.

    Немного ввел в заблуждение насчет реальных 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у и его отключении.

  23. Опубликовано · Изменено пользователем 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, то как их там формировать?

    Как лучше сделать, подскажите.

  24. Опубликовано · Изменено пользователем 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 минуты после поднятия сервера.