Jump to content
Калькуляторы

tnega

Пользователи
  • Content Count

    38
  • Joined

  • Last visited

Posts posted by tnega


  1. 8 часов назад, jffulcrum сказал:

    Если скорость на выходе и на выходе различается - коммутатору нужно буферизировать. Буферизировать у DGS-1100-08  просто нечем - буфер пакетов там 256 кб. Вообще, посмотрите в 

     там полным ходом обсуждение причин и решений. Технически может помочь включение flow-control на всех устройствах и на портах коммутатора - тогда коммутатор будет источнику отправлять сигнал пауза, если приемник уже не может принять или переполнен буфер самого коммутатора. Проблема в том, что этим заниматься будет CPU, а у данной балалайки он тоже символический - неизвестно, что будет хуже работать.

     

    Спасибо! включение flow control помогло, по факту выше 150 мегабит через него пролетать не будет, так как магистраль идет с радиомоста. Посмотрим как будет себя вести.

     

    UPD: спустя несколько минут начал проверять снова тестами, то нормально показывает, то снова 50 мегабит, но чувствуется большой приоритет по исходящей скорости от конечного устройства.

     

    расстроился) 

  2. Приветствую всех.

    Имеем такую схему:
    ... Mikrotik SXT 6 -> Mikrotik SXT 6 -> DGS-1100-08 -> Mikrotik Omnitik

    SXT 6 имеют гигабитные порты, данный радиомост без проблем передаёт нам 150 мегабит
    Омнитик имеет 100 мегабитный порт

    Разумеется в коммутаторе порт приемного моста работает на гигабите а омнитик на 100 мегабитах

    Проблема следующая - при Бандвич тесте встроенном в микротик и вообще, мы не можем передать на Омнитик больше 50 мегабит, как буд-то порт работает в пол силы, но когда мы переводим принудительно порт приемного моста с гигабита в 100 мегабит - мы без проблем до омнитика прогоняем 100 мегабит.

    По статусу у всех портов Фулдуплекс, но проблему это видим конкретно на этой железке, это нас расстраивает, так как она очень компактная и в ней есть всё что нам нужно.

    В итоге, чтобы у нас была полноценная магистраль в 150 мегабит нам нужно поставить какой нибудь 3028 или любой коммутатор где есть на борту и гигабитные и 100 мегабитные порты, в этом случае проблем со скоростью мы не видим.

    Кто что подскажет?

    Очень расстраивает такая не стыковка устройств.

  3. 45 минут назад, alibek сказал:

    Безвозмездный договор в муниципалитете? Зачем им подобный геморрой?

     

    Сами предложили, сказали для них это лучший вариант.

     

    На самом деле действительно взаимовыгода.

     

    Кабель проходит через весь город, волокнами из этого кабеля мы можем объединить другие части города, в свою очередь нам ничего не стоит помочь им с безопасным городом с vlan до камер.

     

    сейчас мы берем волокна у других операторов, чтобы с этими другими частями состыковаться, а так будет резерв.

  4. всех приветствую.

     

    намечается работа с администрацией, взаимовыгодная, безвозмездная.

     

    администрация передает нам в пользования волокна в своем кабеле, мы же в свою очередь помогаем ей в организации vlan по безопасному городу.

     

    может у кого нибудь есть примеры каких нибудь похожих соглашений о безвозмездной передачи ресурсов или о безвозмездном обмене ресурсами? чтобы по данному документу мы что-то разумеется поправили и сделали своё соглашение.

     

    благодарю заранее

  5. Всем привет.

    Все же как я понимаю проблема была в аплинке.

     

    Поставили промежуточный коммутатор между аплинком и сервером доступа, загрузка была в этот момент на аплинк 600 мегабит.

    Подключили к промежуточному коммутатору напрямую клиентскую машину минуя сервер доступа и увидели такое же поведение.

     

    Полагаю тему можно закрывать.

    Всем спасибо.

  6. Завтра попробуем не напрямую в сервер аплинк подключить ,а через коммутатор, и к коммутатору подключить стороннюю клиентскую машину, тут я думаю уже видно будет, кто все-таки скорость режет :-)

  7. Друзья товарищи, давайте забудем про критику друг друга? все с чего-то начинали, и наверное не каждый уже родился со знаниями в голове.

     

    У каждого своё видение и своя специфика работы.

     

    Вернусь к теме:

    Поставили в ядро 3627G, результата никакого не принесло.

     

    Повторюсь:

    В вечернее время при трафике 500-600 мегабит - скорость на клиентских машинах не поднимается больше 100 мегабит. в торренте - 10-12 мегабайт. спидтест показывает 70-80.

    С исходящей скоростью ситуация лучше: тот же спидтест выжимает 300 мегабит.

     

    Когда нет нагрузки на канал (ночью например) на торрентах видим большую скорость и на спидтесте естественно.

     

    Типы подключения разные (PPPoE, snat, ип на прямую + proxyarp), результат один и тот же.

     

    Может все же что-то надо в сервере подтюнить? или все же вышестоящий где-то темнит. Писали ему по поводу этого, сказали что никаких ограничений нет.

  8. 1 минуту назад, LostSoul сказал:

    Понятно.

    Запустите себе IP Mac Binding на DES-3526 и забудьте про pppoe как про кошмарный сон.

    ( для DGS-1100-08 и DIR-100F делайте привязку на последнем управляемом порту )

     

    Абонентам давать статику?

  9. Только что, LostSoul сказал:

    в устройства какой модели  подключаются кабели непосредственно к абонентам

     

     

    DES-3526, DGS-1100-08 в основном, есть кое где даже DIR-100F :-)

    сеть подроблена на VLAN, обычно - VLAN на коммутатор.

    На коммутаторах делаем сегментацию трафика, абоненты друг друга не видят. ЗА исключением естественно DIR100F :-)

  10. Только что, LostSoul сказал:

    из представленных примерно настройки этого не следует.

    зачем в 2019 году такое извращение с pppoe , что у вас на конечном доступе?

     

     

    1. Выдаем ип адреса по PPPoE - используя accel-ppp + включаем proxy arp на аплинк интерфейсе. 

     

    я ведь написал это в теме :-)

     

    нам так проще.

     

    не сосем понял про конечный доступ

  11. Вот дискуссию тут развели :-)

    не ожидал такого из за своей темы.

     

    По поводу PPPoE - он есть.

    accel-ppp используем.

    И в основном используем именно его, как основной способ авторизации.

     

    А Proxy arp + iproute - тем, кому нужно ип выдать напрямую на интерфейс, не туннелем. Юр лица просят такое у нас :-)

    Какие нибудь большие организации, банки, магниты, пятёрочки :-)

     

    Следящим за темой - коммутатора еще не дождались :-) но думаем приобрести для теста 3627G

  12. 2 минуты назад, TriKS сказал:

    Я лишь парировал Ваше:

    Чес слово, плакал. Я вчера купил 3 бушных ноута И3 и И5 для монтажников примерно за эту же сумму :) Чтоб они к абонам ездили и скоростя меряли, бедненькие :)

    тогда проще взять решение от СНР за 35, новое)

     

  13. 6 часов назад, passer сказал:

    А какой смысл ставить в ядро ДОМОВОЙ свитч с 4-мя гигабитными портами и кучей 100М SFP ?
    Но и в озвученный бюджет впишется только что-то подобное )))

     

    возможно это была просто шута)

  14. Что можно поставить на ядро в пределах 10-25 т.р. ?

    Посоветуйте пожалуйста что нибудь для трафика 1-2 гигабита.

     

    Нам желательно наличии множества SFP портов.

     

    Может обойдемся без СНРовского коммутатора за 35 т.р. 

  15. 3 часа назад, NiTr0 сказал:

    практика показывает, что именно он и причем будет. даже без переходов 100-1г. запустите пинг пакетами по 20-30кб (а лучше по 60кб) - и увидите чудо, как при трафике на порту метров 500-700 будут начинаться дропы.

     

    да, надеюсь flow control же отключен? с ним вообще все печально будет...

     

    Вас понял.

     

    flow control - отключен естественно

     

    В общем ждем нового коммутатора на ядро.

  16. 15 минут назад, Butch3r сказал:

    Если у вас все скорости на 3100 1G, т.е. нету перехода скоростей, то причём тут он?

    А вот если много 100м линков, то да.

    Все линки оптические 1G, медные так же кроме одного, к которому подключен наш wi-fi роутер.

  17. 52 минуты назад, TriKS сказал:

    Вам тогда о будущем нужно думать в ключе разделения и резервирования.

    Куда лучше будет поставить 2 тазика по 300 баксов и разделить нагрузку и в случае выхода из строя одного из НАСов не поиметь простой, который ой как юрики не любят.

     

    К чему вланы на камеры к НАСу - мне тоже не ясно. Можно ж запихать этот умный город в отдельные вланы и сливать мимо НАСа в серверную этого города. 10Г на НАСе тут тоже мимио. Ну разве что камерам инет дать, чтоб это китайское говно ддосило потом людей, а вас блекхолили бы магистралы с последующими воплями админов умного города, что НЕРАБОТАЕТ камера\ы. Но тут дело ваше.

     

    Много юрлиц - хорошо, тогда точно про разделение думайте. 2НАСа с ЛАСПами по 2-4Г(по факту меньше получится из-за самой технологии) по 300 баксов это куда лучше, чем слушать вопли от юриков. Ну и да, сейчас 700 абонов. В какой временной перспективе вы забьете 2-3 Гб(если ЛАСП). Это, на сикундочку, около 2-3 тыщ абонов.

     

    Я еще понимаю, если это вынос, где с волокнами пичаль, а если в пределах стойки\здания, то сваять ЛАСП ваще не проблема. Но дело ваше. Некуда денег деть - ставьте 10Г карты на древние, жрущие 200-250Вт железяки с процами 10 летней давности.

     

    А вот это интересно. Вы арендуете сеточку у апстрима, при этом другие операторы берут у вас стыки? Кхм. Без бгп? Это что ж там за операторы такие?

     

    Резервный есть, простои - минимальные, буквально несколько минут.

    Конфиги бэкапим два раза в день.

     

    Я не имел ввиду проносить трафик через НАС, как раз имел ввиду то, о чем Вы пишите.

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

     

    Операторы берут у нас стыки от своих узлов до своих корпоративных клиентов, где у них нет своих коммуникаций. Так же вилан.

    Говорить о них не буду, но одни из наших крупных российских :-)

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

     

    Вы не думайте, что мы не думаем о плохих вещах и живем одним днем :-)

    год назад мы не думали, что будем так развиваться. 

     

    Просто где-то не совсем подкованы и не обладаем достаточными знаниями, поэтому и обратились на форум.

    Испытываем все на своей шкуре, учимся на своих ошибках.

  18. 32 минуты назад, TriKS сказал:

    А вам виднее что лучше. Я ж перспектив не знаю. Нафига вам ваще 10Г при 700М и рядом стоящей 4-х дырочной сетевке и свиче - для меня загадка.

    Даже в варианте нынешнем, 5% оверхеда по спинлоку это вовсе не оверхед, на котором стоит заострять внимание. ДАнное железо ОБЯЗАНО жевать без проблем и тюнинга 1,5-2 Гб даже с НАТом и даже с RPS(пппое в смысле). То что у вас уже при 700М грусть получается, то тут либо перемудрено с сервером и софтом на нем, либо аплинк играет шутку, либо на его ДГС свиче дропы. Попросите аплинка поднять iperf сервак как можно ближе к вам и дуньте с него что есть сил. Дальше глядите дропы на свичах и,скорее всего, пинайте аплинка.

     

     

    Думаем о будущем, поэтому и 10G вставили, да и коммутаторы как видим сейчас с 10G идут нормальные.
    Помимо трафика внешнего, по сети гуляет еще немного трафика внутреннего, другие операторы и организации берут стыки VLAN у нас.

    Оператор мы относительно молодой, но за пару лет много построили, практически весь город в оптике.

    Абоненты преимущественно в частном секторе, в квартирах не много, конкуренция большая + пром района и тц, много юр лиц. + намечается работы с администрацией по безопасному городу, так же стыки vlan до камер и разнообразных точек.

     

    Поэтому решили сразу о 10G думать.

     

    Обсудив тут со всеми проблему свою, приходим все же к мысли что действительно наша DGS -ка не вытягивает.

    Будем сначала копать в эту сторону, поменяем коммутатор и посмотрим как будут обстоять дела.

  19. В сервере у нас стоит еще одна, помимо 10 гигабитной 2-х портовой

    Стоит резервом i340-T4

    Стоит ли на нее посадить аплинк а 10 гигабитную подключить к внутренней сети используя при этом 10 гигабитный внутренний линк, и 1 гигабитный внешний? или разницы нет?

     

    Сейчас как видите висит всё на 10 гигабитной сетевушке, но с гигабитными модулями.

  20. 6 часов назад, NiTr0 сказал:

    все понятно. выкинуть каку. если кака аплинка - сменить аплинка, т.к. у него вся сеть из говна и веток.

    эти поделки нормально более 500-600 мбит в порт не отдают.

     

    нет. выкиньте каку.

    Вас понял.

    Тогда жду того момента как приедут SNR и отписываюсь по теме

  21. Нормальное ли поведение самого верхнего процесса?

     

    Цитата

       5,28%  [kernel]                 [k] _raw_spin_unlock_irqrestore
       4,84%  [kernel]                 [k] tpacket_rcv
       3,13%  [kernel]                 [k] _raw_spin_lock_irqsave
       2,74%  [kernel]                 [k] __sk_run_filter
       2,56%  [kernel]                 [k] prb_fill_curr_block.isra.56
       2,25%  [kernel]                 [k] _raw_spin_lock
       2,16%  [kernel]                 [k] fib_table_lookup
       2,09%  [kernel]                 [k] try_to_wake_up
       1,79%  [kernel]                 [k] __memcpy
       1,75%  [kernel]                 [k] task_waking_fair
       1,73%  [kernel]                 [k] ipt_do_table
       1,60%  [kernel]                 [k] get_nohz_timer_target
       1,59%  [kernel]                 [k] irq_entries_start
       1,57%  [kernel]                 [k] sock_def_readable
       1,40%  [kernel]                 [k] __schedule
       1,32%  [kernel]                 [k] ixgbe_clean_rx_irq
       1,27%  [kernel]                 [k] __netif_receive_skb_core
       1,26%  [kernel]                 [k] __wake_up_common
       1,25%  [kernel]                 [k] enqueue_task_fair
       1,10%  [kernel]                 [k] ixgbe_poll
       1,02%  [kernel]                 [k] idle_cpu
       1,00%  [kernel]                 [k] dev_queue_xmit_nit
       0,96%  [kernel]                 [k] __x86_indirect_thunk_rax
       0,96%  [kernel]                 [k] _raw_spin_lock_bh
       0,87%  [kernel]                 [k] nf_iterate
       0,86%  [kernel]                 [k] ratelimit_mt
       0,83%  bandwidthd               [.] 0x0000000000003254
       0,82%  [kernel]                 [k] cpu_startup_entry
       0,79%  [kernel]                 [k] native_read_tsc
       0,74%  [kernel]                 [k] tcp_packet
       0,71%  [kernel]                 [k] ixgbe_xmit_frame_ring
       0,69%  [kernel]                 [k] packet_rcv
       0,66%  [kernel]                 [k] resched_task
       0,66%  [kernel]                 [k] kmem_cache_free
       0,66%  bandwidthd               [.] 0x0000000000003240
       0,63%  [kernel]                 [k] check_leaf.isra.6
       0,60%  [kernel]                 [k] __switch_to
       0,57%  [kernel]                 [k] kfree_skb
       0,57%  [kernel]                 [k] kmem_cache_alloc
       0,57%  [kernel]                 [k] __nf_conntrack_find_get
       0,56%  [kernel]                 [k] ip_finish_output
       0,56%  [kernel]                 [k] poll_schedule_timeout
       0,55%  [kernel]                 [k] ip_route_input_noref
       0,54%  [kernel]                 [k] __tick_nohz_idle_enter
       0,53%  [kernel]                 [k] datagram_poll
       0,53%  [kernel]                 [k] ip_forward
       0,52%  [kernel]                 [k] __copy_skb_header
       0,52%  [kernel]                 [k] finish_task_switch
       0,50%  [kernel]                 [k] pick_next_task_fair
       0,46%  [kernel]                 [k] skb_copy_bits
       0,44%  [kernel]                 [k] conntrack_mt
       0,44%  [kernel]                 [k] __hrtimer_start_range_ns
       0,43%  [kernel]                 [k] rcu_eqs_enter_common
       0,42%  [kernel]                 [k] dequeue_task_fair
       0,42%  [kernel]                 [k] ip_rcv
       0,41%  [kernel]                 [k] nf_conntrack_in
       0,41%  [kernel]                 [k] schedule
       0,37%  [kernel]                 [k] net_rx_action