Перейти до

boroda

Сitizens
  • Всього повідомлень

    186
  • Приєднався

  • Останній візит

Сообщения додав boroda

  1. У меня обычные файберы (не HD) на 10км чуть больше 300 Мбит реального трафика тянули (75/25% в полосе 50МГц)

    Capacity в этот момент показывал 350/120 

    После этого этот же Линк переместили на другой пролёт, 23км, лучшее что могли отюстировать на быструю руку это сигналы -61 (антенны  fiber 30дб) Модуляция поднималась 6, иногда мелькала 8, Capacity в режиме 50/50 показал 150/150. Реального трафика не прогоняли. Режим 75/25 показал 240/75. 

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

     

    7426BB6C-CC66-4252-8143-6E53737828A8.jpeg

     

    • Like 2
  2. 1 час назад, BALTAR сказал:

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

    2. PTP550 в условиях загаженого эфира реально хорош (тесты и прочее скоро будут).

    3. Спасибо огромное Вячеславу и Степану из UNIDATA, ребята знают своё дело, помогли и словом и делом!

     

    Ждем тесты...

  3. В 05.05.2019 в 00:23, nik247 сказал:

    практически вычисленно, что RouterOS по L2 (pppoe) отимально раскладывает при 3(6) интерфейсах в bonding (mode=802.3ad, transmit-hash-policy=layer-2-and-3).

    тесты проводились на 2,3,4,5,6,7 интерфейсах.

    так RouterOS вычисляет хеши  и соответсвенно потом выбирает исходящий интерфейс.- оптимально кратно 3 для L2 трафика.

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

    рекомендую все равно перейти на 1036 на 10G (sfp+)

    Да, баланс выровнялся, спасибо! 

  4. 25 минут назад, nik247 сказал:

    практически вычисленно, что RouterOS по L2 (pppoe) отимально раскладывает при 3(6) интерфейсах в bonding (mode=802.3ad, transmit-hash-policy=layer-2-and-3).

    тесты проводились на 2,3,4,5,6,7 интерфейсах.

    так RouterOS вычисляет хеши  и соттветсвенно потом выбирает исходящий интерфейс.- оптимально кратно 3 для L2 трафика.

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

    рекомендую все равно перейти на 1036 на 10G (sfp+)

    Спасибо, буду пробовать. У меня нет SFP+ на CCR1036

  5. 8 часов назад, KaYot сказал:

    Я и сейчас не понимаю, что такое вход и что выход. Схему в студию.

    1. Juniper 2 порта ether —- IP трафик —- 2 порта ether CCR (тут баланс норм)

    2. Далее NAT на CCR

    3. Этот же CCR 2 порта SFP —- Dlink 3300 2 порта SFP (тут PPPoE сессии) с проблемным дисбалансом по портам

  6. 2 часа назад, KaYot сказал:

    PPPoE это не IP трафик. L3+ балансировка работать не будет, включите L2.

    Ну а трафик на входе балансирует не ccr, а вышестоящий свич.

    Вы не поняли, IP трафик на входе, там все ок с балансировкой, проблема на выходе (PPPoE) сейчас стоит L2L3, очень большой дисбаланс

  7. Подскажите по бондингу на CCR, неравномерно раскладывает трафик по портам

     

    В данный момент на входе CCR использую 2 гиговых порта, просто IP трафик, балансировка трафика по портам примерно равномерная, а вот на выходе в сеть (PPPoE трафик) сильный дисбаланс. Пробовал L3L4, L2L3 - ничего не меняется, небаланс в данный момент  500/30 мбит/с

    Как еще можно подстроить подскажите?

  8. 5 часов назад, MRS сказал:

     

     

    можно спросить, а джилонги у вас каких моделей? 

    потому что 280 сейчас что-то очень дорогой, а есть Jilong KL-280G KIT  и Jilong KL-280E KIT, но они немного иначе простой 280ки.

     

    думал и над инно, но интересно одно, их каретки могут и патчи держать, или только просто волокно?

    Инно 3 идеально подходит для всего, идеально прижимает патчи, чего нет у DVP с родными лапками. Если есть 2$, то берите инно 3, не 1, у него намного удобнее кейс. Единственный минус - слабая батарея, намного хуже чем у двп 740, хотя возможно мне попался брак батареи 

  9. Взял DVP 740 и пожалел, волокна сводит не ровно, лапки изначально для сварки патчкордов непредназначенные, заменили у депса, все прижимные, лапки, крышка - все шатается, неприятно даже просто визуально, не говоря о проценте херовых сварок. Вчера глюкнуло совсем, не фокусируются камеры, теперь все время не нравится ему скол волокна, хотя все идеально ровно. Единственный плюс - скалыватель, он хоть на вид и мрачный, но режет достаточно хорошо уже год без проворота лезвия. В  общем по сравнению с инно 3, более не с чем сравнить, реально барахло редкостное, не советую! 

  10. 2 часа назад, Pautiina сказал:

    Вот чуечка у меня, что там нет одной опции, которая помогает защитить  сервер от торрентов.

    ext_if = "{ vlanXX3 }"

    dyn_nat = "{ 35.X7.XXX0/27 }"

     

    # table <no_nat>

    #  for IPTV:  92.2XXX.121.xxx 172.16.77.0/24

    #  for management hardware: 172.17.0.0/23

    #  for DGS-3000-28SC : 10.XX.XX.XX/32

    #  for IP network : 35.XX.14.0/24

    table <no_nat> const { 92.XX121.X30 17X.16.77.0/24 172.XX.0.0/23 10.255.XX.253/32 35.47.XX0/24 }

     

    set limit states 16000000

    set optimization aggressive

    set limit frags 1000000

    set limit src-nodes 200000

    set limit table-entries 1000000

     

    #binat on ix0 from 172.16.0.1 to !<no_nat> -> 92.XX.121.XX

    #nat pass on $ext_if from 10.0.0.0/8 to any -> ($ext_if)

     

    #nat pass on $ext_if from any to 91.146.64.243 -> 92.242.121.214

    #nat pass on $ext_if from 172.17.1.252/30 to any -> 92.242.121.214

    nat pass on $ext_if from any to 1.XX.XX.2XX -> 35.4X.1XX.2XX

    nat pass on $ext_if from 172.17.1.XX2/30 to any -> 35.47.XX4.2XX

     

    nat pass on $ext_if from 10.0.0.0/8 to !<no_nat> -> $dyn_nat round-robin sticky-address

     

    # for connect to DUDE from external

    rdr inet proto tcp from any to 5.47.XX4.XX2 port 2210 -> 172.17.1.253 port 2XX

    rdr inet proto tcp from any to X.X7.1XX.252 port 2211 -> 172.17.1.253 port 2X

    rdr inet proto tcp from any to X5.X7.X4.XX2 port 8291 -> 172.17.1.253 port 82X

     

    # for connect to DUDE from external

    rdr inet proto tcp from any to 95.47.144.252 port 12210 -> 172.17.1.252 port XXX

    rdr inet proto tcp from any to 95.47.144.252 port 12211 -> 172.17.1.252 port 2XX

    rdr inet proto tcp from any to 95.47.144.252 port 18291 -> 172.17.1.252 port 8XX

     

    # for connect to GPON P3608-2TE from external

    #rdr inet proto tcp from any to 95.47.1XX.252 port 7777 -> 172.XX.0.X9 port 2X

  11. поставил в исполком, 2 этаж длинной 30-40 метров, в крайних комнатах уровень сигнала минимальный.

    1 этаж ловит только под самим устройством. 

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

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

  12. В 24.03.2015 в 19:18, kvirtu сказал:

    У меня тоже полет нормальный :) , фря 9.3 - up 20 days, 6:09, 0 users, load averages: 0.16, 0.16, 0.12

    Отдельное спасибо ZyXel.

    Так что все-таки было проблемой и как решили? 

     

    У меня сейчас проблема такая же

    FreeBSD 11.1-STABLE (GENERIC)

    Намертво зависает сервер, консоль не отвечает, только ребут. 

    Все началось с установкой нового сервера и новой фри, переносом базы. Сначала все работало отлично, через месяц-два произошло первое зависание, помозговали и решили, что это проблема бинда, обновили, проблема пропала еще месяца на 3-4, после чего снова понеслась... Сейчас виснет каждые 3-4 дня 

    Оперативку проверили.

    Что делать, куда копать? 

     

    last pid: 51840;  load averages:  3.88,  3.45,  3.29                                                                                       
    46 processes:  2 running, 44 sleeping

    .......
    CPU 19:  0.0% user,  0.0% nice,  0.0% system, 23.5% interrupt, 76.5% idle
    Mem: 553M Active, 1474M Inact, 1309M Wired, 4453M Free
    ARC: 498M Total, 226M MFU, 263M MRU, 2857K Anon, 3359K Header, 3279K Other
         457M Compressed, 1501M Uncompressed, 3.28:1 Ratio
    Swap: 4096M Total, 4096M Free

×
×
  • Створити нове...