ingvarrwvw

Вообще 2000, но сейчас сняли совсем - разницы нет,картина не меняется.

Не,точно циска косячит, прям 100%. Терминация на пачке серверов, там и рррое и ипое, уже много лет,все работает без проблем. Как циску поставили - проблемы полезли

Коллеги,добрый день. NAT на ASR 1006 наблюдаем такую штуку каждый день - в одно и тоже время падает трафик процентов на 30 кратковременно,потом снова восстанавливается. При этом потерь и задержек в это время нет, но в целом есть жалобы на услугу, появились именно с вводом в эксплуатацию 1006. Версия текущая asr1000rp2-adventerprisek9.03.16.08.S.155-3.S8-ext.b Только NAT BGP на ней. Настройки нат: ip nat settings mode cgn no ip nat settings support mapping outside ip nat settings pap limit 60 ip nat translation timeout 3600 ip nat translation tcp-timeout 3600 ip nat translation pptp-timeout 3600 ip nat translation udp-timeout 60 ip nat translation icmp-timeout 30 ip nat translation max-entries 4000000 no ip nat service all-algs В acl для nat отдельно протоколы - tcp udp и т.д. В пики количество сессий около 1 млн. В логах пусто. Может прошивку поменять? Поделитесь стабильной,если имеется. Спасибо заранее

Пардон за оффтоп, это ESP одна сдохла.

ASR 1006 asr1000rp2-adventerprisek9.03.16.08.S.155-3.S8-ext.b Только NAT BGP Вылетает ESP: 5AE cpp_sbs:7F947FA06000+11104 cpp_sbs:7F947FA06000+B4C5 cpp_sbs:7F947FA06000+B8D6 cpp_sbs:7F947FA06000+B7EE cpp_gic_ea_lib:7F948A99F000+17080 cpp_gic_smc_lib:7F948ABE0000+4768 cpp_common_os:7F9473C79000+11C20 cpp_common_os:7F9473C79000+12306 evlib:7F94729EB000+B937 evlib:7F94729EB000+E200 Apr 26 05:20:35.942: %CPPOSLIB-3-ERROR_NOTIFY: F0: fman_fp_image: fman-fp encountered an error -Traceback= 1#bed20821c50ab9f3ad4d5b358f8cb5e0 errmsg:7F642B7FE000+121D cpp_common_os:7F64053BE000+DA3C cpp_common_os:7F64053BE000+1B5AE cpp_plutlu_common:7F6407F35000+1050B cpp_plutlu_common:7F6407F35000+E28B cpp_cef_mpls_common:7F640707C000+2601F :400000+7B856C :400000+39F420 aobjman:7F64348CC000+D82C :400000+55E57A evlib:7F6409BE2000+BB8F evlib:7F6409BE2000+E200 :400000+55E29B c:7F63F4E29000+1E514 :400000+1AE Apr 26 05:20:40.945: %CPPOSLIB-3-ERROR_NOTIFY: F0: fman_fp_image: fman-fp encountered an error -Traceback= 1#bed20821c50ab9f3ad4d5b358f8cb5e0 errmsg:7F642B7FE000+121D cpp_common_os:7F64053BE000+DA3C cpp_common_os:7F64053BE000+1B5AE cpp_plutlu_common:7F6407F35000+10A4A cpp_plutlu_common:7F6407F35000+FD67 cpp_plutlu_common:7F6407F35000+E28B cpp_cef_mpls_common:7F640707C000+2601F :400000+7B856C :400000+39F420 aobjman:7F64348CC000+D82C :400000+55E57A evlib:7F6409BE2000+BB8F evlib:7F6409BE2000+E200 :400000+55E Apr 26 05:20:43.347: %CPPOSLIB-3-ERROR_NOTIFY: F0: cpp_cp: cpp_cp encountered an error -Traceback= 1#a6e96745f34c063378b2307acc47321f errmsg:7F94707F2000+121D cpp_common_os:7F9473C79000+DA3C cpp_common_os:7F9473C79000+1B5AE cpp_sbs:7F947FA06000+11104 cpp_sbs:7F947FA06000+B4C5 cpp_sbs:7F947FA06000+B8D6 cpp_sbs:7F947FA06000+B7EE cpp_gic_ea_lib:7F948A99F000+17080 cpp_gic_smc_lib:7F948ABE0000+4768 cpp_common_os:7F9473C79000+11C20 cpp_common_os:7F9473C79000+12306 evlib:7F94729EB000+B937 evlib:7F94729EB000+E200 Apr 26 05:20:45.947: %CPPOSLIB-3-ERROR_NOTIFY: F0: fman_fp_image: fman-fp encountered an error -Traceback= 1#bed20821c50ab9f3ad4d5b358f8cb5e0 errmsg:7F642B7FE000+121D cpp_common_os:7F64053BE000+DA3C cpp_common_os:7F64053BE000+1B5AE cpp_plutlu_common:7F6407F35000+BB76 cpp_plutlu_common:7F6407F35000+107DC cpp_plutlu_common:7F6407F35000+FD67 cpp_plutlu_common:7F6407F35000+E28B cpp_cef_mpls_common:7F640707C000+2601F :400000+7B856C :400000+39F420 aobjman:7F64348CC000+D82C :400000+55E57A evlib:7F6409BE2000+BB8F Apr 26 05:20:50.947: %CPPOSLIB-3-ERROR_NOTIFY: F0: fman_fp_image: fman-fp encountered an error -Traceback= 1#bed20821c50ab9f3ad4d5b358f8cb5e0 errmsg:7F642B7FE000+121D cpp_common_os:7F64053BE000+DA3C cpp_common_os:7F64053BE000+1B5AE cpp_plutlu_common:7F6407F35000+10A4A cpp_plutlu_common:7F6407F35000+FD67 cpp_plutlu_common:7F6407F35000+E28B cpp_cef_mpls_common:7F640707C000+2601F :400000+7B856C :400000+39F420 aobjman:7F64348CC000+D82C :400000+55E57A evlib:7F6409BE2000+BB8F evlib:7F6409BE2000+E200 :400000+55E Apr 26 05:20:51.070: %IOSXE-6-PLATFORM: F0: cpp_cdm: Shutting down CPP MDM while client(s) still connected Apr 26 05:20:51.070: %CPPHA-3-CDMDONE: F0: cpp_ha: CPP 0 microcode crashdump creation completed. Apr 26 05:20:51.072: %IOSXE-6-PLATFORM: F0: cpp_ha: Shutting down CPP MDM while client(s) still connected Apr 26 05:20:51.072: %IOSXE-6-PLATFORM: F0: cpp_ha: Shutting down CPP CDM while client(s) still connected Apr 26 05:20:51.148: %PMAN-3-PROCHOLDDOWN: F0: pman.sh: The process cpp_ha_top_level_server has been helddown (rc 69) Apr 26 05:20:51.201: %PMAN-3-PROCHOLDDOWN: F0: pman.sh: The process cpp_cdm_svr has been helddown (rc 69) Apr 26 05:20:55.177: %CPPOSLIB-3-ERROR_NOTIFY: F0: cpp_cp: cpp_cp encountered an error -Traceback= 1#a6e96745f34c063378b2307acc47321f errmsg:7F94707F2000+121D cpp_common_os:7F9473C79000+DA3C cpp_common_os:7F9473C79000+1B5AE cpp_sbs:7F947FA06000+11104 cpp_sbs:7F947FA06000+B4C5 cpp_sbs:7F947FA06000+B8D6 cpp_sbs:7F947FA06000+B7EE cpp_gic_ea_lib:7F948A99F000+17080 cpp_gic_smc_lib:7F948ABE0000+4768 cpp_common_os:7F9473C79000+11C20 cpp_common_os:7F9473C79000+12306 evlib:7F94729EB000+B937 evlib:7F94729EB000+E200 Apr 26 05:20:55.569: %IOSXE_OIR-6-OFFLINECARD: Card (fp) offline in slot F0

Обновлю статистику - на данный момент на этом сервере достигли 16 гбит (примерно 6 млн pps). Задачи прежние - bgp 6 аплинков, nat, логирование nat states для запросов из органов. По прогнозу запас еще на пару гигабит имеется.

Тюнинг стандартный - увеличены разные буферы. На одном Е5-2690 с натом получается примерно 12.5 гбит, 4.4 mpps. Загрузка процессора 96-98%, дропов и ошибок нет, задержек тоже. Не подскажут ли уважаемые знатоки, если перевести все это дело на linux - получится ли какой-то выигрыш по производительности на этом же железе?

Спустя год трафика стало ~9.5 гбит, сервер используется HP g8 2x2690 Xeon ,сетевая - Intel 520, одна штука. FreeBSD 12. Загрузка проц в пиках - 30-32%. Красота! Планируем дожить на этом железе до ~30-35 гбит, а дальше перейти на 16-ти ядерные процессоры и сетевые mellanox.

Такая же проблема. Любой браузер D - 500-800, U - больше 70 не поднимается.

С почином )

ТД в итоге хватило одной на площадку. В дальних вагончиках по периметру все же пришлось поставить репитеры с внешней антенной(обычная штырьковая),чтобы торчала над вагончиком. Тут надо просто считать что дешевле, вторую точку или репитеры. (Репитеры бытовые, по 2 .т.р штука.tp-link, dlink) Unifi - в соседнем вагончике уже ничего не ловило. Cambium CN pilot 500 - через три вагончика сигнал был на грани вымирания ) Все тесты уровня сигнала мы проводили одинаковым набором клиентского оборудования - ноутбуком, тремя смартфонами и одним планшетом.

Конечно. Поставили в итоге Rukus t310d. Работает даже в минус 48. В железном вагончике на расстоянии ~70 метров на любом смартфоне 2 деления. Если брать рукусы даже не сильно большой партией, дают скиду 50% легко. Два типа прошивки: 1.Стандартная - в ней функционал как у любого wifi рутера 2.Unleashed - куча всяких плюшек, например можно сделать авторизацию на точке через MS AD,ldap. Доступна бесплатно на сайте производителя. Обращу внимание что при смене типа прошивки настройки сбрасываются все в дефолт, поэтому при настройке удаленно имейте ввиду. Из минусов - система управления централизованная очень не бесплатная.

Надо было protocol direct добавить,разобрался.

Да,есть. Если смотреть маршруты на bird,то они выглядят так: 194.1.198.0/24 unreachable [bgp1 2018-10-19 from X.X.X.X] * (100/-) [AS44263i]

Посмотрел на bird. Подскажите пожалуйста знающие - соседство поднимается, маршруты принимаются,в системную таблицу их отдаем. Но в системной таблице рутинга все маршруты получаемые через ibgp получаются с next-hop 127.0.0.1,а хотелось бы вместо 127.0.0.1 видеть адрес ibgp пира конечно )

Доброго дня. Бордер на FreeBSD 10.3, quagga 1.0 - несколько лет принимает 3 FV,все хорошо работает. Понадобилось на один из брасов слить FV по iBGP. Брас на freebsd 10.4, quagga 1.2.4. Соседство поднимается, квага принимает все маршруты (около 700к) , все нормально. Проблема в следующем - zebra начинает переносить эти 700к маршрутов в кернел и происходит факап в виде 100% загрузки зеброй проца и отсутствием этих маршрутов в кернеле. Зебра в цикле пытается их пихать в кернел,видимо обламывается по какой-то причине и начинает снова. Если смотреть кол-во маршрутов netstat -nr | wc -l , число растет, потом они все удаляются и начинается заново. Что не так?

Берем все эти точки на тест, какая вывезет в итоге - такую и поставим )

Спасибо всем за ответы!

Вагончики не фанерные.

Всем доброго дня! У нас ведь страна советов, посоветуйте пожалуйста оборудование под следующую задачу: Поле, площадь 300 на 300 метров, вагончики. Максимум одновременно работающих устройств - до 30. Все устройства - это смартфоны и ноутбуки. Нужно организовать для подключаемых устройств локалку, из которой будет также выход в инет до 10мбит максимум. 10мбит - это на всех. Оборудование нужно максимально надежное, так как обслуживать его там будет некому, максимум перезагрузить смогут. Спасибо заранее!

1. Точно выключены. На сервере только квага, bgp и ospf , ntpd, pf с 3 строчками ната. 2. Шедулер ULE на обоих системах 3. Потестим )

Не нравится что на FreeBSD 10.3 на этом же сервере и при той же загрузке прерываний в 3 раза меньше.

Видимо проблема здесь: 49.7% kernel sched_idletd fork_exit Кто-нибудь знает что это и с чем это есть?

pmcstat -TS instructions -w1 %SAMP IMAGE FUNCTION CALLERS 49.7 kernel sched_idletd fork_exit 2.6 kernel cpu_search_highest cpu_search_highest:1.6 sched_idletd:0.5 2.2 libc.so.7 bsearch 0x64db 2.0 pf.ko pf_test pf_check_in:1.1 pf_check_out:1.0 1.9 kernel lock_delay __mtx_lock_sleep:1.1 _mtx_lock_spin_cookie:0.8 1.7 kernel cpu_search_lowest cpu_search_lowest 1.7 kernel rn_match fib4_lookup_nh_basic 1.6 pf.ko pf_test_rule pf_test 1.4 kernel _rm_rlock pfil_run_hooks:0.5 in_localip:0.5 1.1 kernel bzero 1.1 kernel murmur3_32_hash32 pf_find_state 1.1 kernel ixgbe_rxeof ixgbe_msix_que 1.0 kernel sched_switch mi_switch 0.9 pf.ko pf_test_state_tcp pf_test 0.8 pf.ko pf_normalize_ip pf_test 0.7 kernel ip_tryforward ip_input 0.7 pf.ko pf_match_translation pf_get_translation 0.6 kernel bcopy 0.6 pf.ko pf_normalize_tcp pf_test 0.6 kernel critical_exit

Вытащили один проц. На 800 мбит загрузка 60%. uname -na FreeBSD GW_1 11.2-RC1 FreeBSD 11.2-RC1 #0 r334470: top -SCHIP 164 processes: 10 running, 122 sleeping, 32 waiting CPU 0: 0.0% user, 0.0% nice, 2.3% system, 39.5% interrupt, 58.1% idle CPU 1: 0.0% user, 0.0% nice, 2.3% system, 51.2% interrupt, 46.5% idle CPU 2: 0.0% user, 0.0% nice, 2.3% system, 62.8% interrupt, 34.9% idle CPU 3: 2.3% user, 0.0% nice, 4.7% system, 46.5% interrupt, 46.5% idle Mem: 438M Active, 303M Inact, 2113M Wired, 1159M Buf, 13G Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME CPU COMMAND 11 root 155 ki31 0K 64K RUN 1 660:00 53.04% idle{idle: cpu1} 11 root 155 ki31 0K 64K RUN 0 662:32 52.36% idle{idle: cpu0} 11 root 155 ki31 0K 64K RUN 3 663:58 49.69% idle{idle: cpu3} 11 root 155 ki31 0K 64K RUN 2 654:38 49.38% idle{idle: cpu2} 12 root -92 - 0K 560K WAIT 3 23:40 37.04% intr{irq259: ix0:q3} 12 root -92 - 0K 560K WAIT 2 24:00 32.73% intr{irq258: ix0:q2} 12 root -92 - 0K 560K CPU0 0 23:27 31.79% intr{irq256: ix0:q0} 12 root -92 - 0K 560K WAIT 1 24:50 23.33% intr{irq257: ix0:q1} 12 root -92 - 0K 560K CPU1 1 17:31 20.06% intr{irq262: ix1:q1} 12 root -92 - 0K 560K WAIT 2 15:20 15.48% intr{irq263: ix1:q2} 12 root -92 - 0K 560K RUN 0 13:50 13.74% intr{irq261: ix1:q0} 12 root -92 - 0K 560K WAIT 3 13:32 11.57% intr{irq264: ix1:q3} 4277 root 20 0 7916K 4328K CPU1 1 0:00 2.70% top 12 root -72 - 0K 560K WAIT 1 3:35 2.47% intr{swi1: pfsync} 663 root -16 - 0K 16K pftm 1 4:59 1.98% pf purge 12 root -92 - 0K 560K WAIT 0 12:22 1.32% intr{irq267: bce0} sysctl.conf net.inet.carp.preempt=1 net.inet.ip.redirect=0 hw.ix.enable_aim=1 kern.ipc.nmbclusters=5242880 kern.ipc.maxsockbuf=83886080 loader.conf carp_load="YES" net.isr.defaultqlimit=4096 # (default 256) hw.ix.max_interrupt_rate=16000 # (default 8000) hw.ix.rx_process_limit=-1 hw.ix.tx_process_limit=-1 hw.ix.num_queues=4 hw.ix.rxd=4096 hw.ix.txd=4096 net.isr.bindthreads=1 net.isr.maxthreads=4 net.isr.numthreads=4 vmstat -i interrupt total rate irq1: atkbd0 6 0 irq14: ata0 28447 1 irq20: hpet0 18878914 440 irq22: uhci4 1708 0 irq256: ix0:q0 82997235 1935 irq257: ix0:q1 84871725 1979 irq258: ix0:q2 88312220 2059 irq259: ix0:q3 82268600 1918 irq260: ix0:link 53 0 irq261: ix1:q0 57475063 1340 irq262: ix1:q1 60558888 1412 irq263: ix1:q2 54806017 1278 irq264: ix1:q3 51703498 1205 irq265: ix1:link 2 0 irq266: ciss0 92935 2 irq267: bce0 62646697 1460 Total 644642008 15028 sysctl -a kern.eventtimer kern.eventtimer.periodic: 0 kern.eventtimer.timer: HPET kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 2 kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) LAPIC(100) i8254(100) RTC(0) kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.HPET2.quality: 440 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET1.quality: 440 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET.quality: 450 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.HPET.flags: 3 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.LAPIC.quality: 100 kern.eventtimer.et.LAPIC.frequency: 0 kern.eventtimer.et.LAPIC.flags: 15 netstat -m 35400/11925/47325 mbufs in use (current/cache/total) 34861/8159/43020/5242880 mbuf clusters in use (current/cache/total/max) 34861/8149 mbuf+clusters out of packet secondary zone in use (current/cache) 0/12/12/509479 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/150956 9k jumbo clusters in use (current/cache/total/max) 0/0/0/84913 16k jumbo clusters in use (current/cache/total/max) 78572K/19347K/97919K bytes allocated to network (current/cache/total) harvest_mask - по умолчанию оставил.