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

telefan

Активный участник
  • Content Count

    379
  • Joined

  • Last visited

About telefan

  • Rank
    Студент

Контакты

  • ICQ
    176210276

Город

  • Город
    украина
  1. Имеется такая конфигурация 6509: --- ----- -------------------------------------- ------------------ ----------- 1 2 Catalyst 6000 supervisor 2 (Active) WS-X6K-SUP2-2GE SAL0822947F 2 16 16 port 1000mb GBIC ethernet WS-X6416-GBIC SAD05030A43 4 16 SFM-capable 16 port 10/100/1000mb RJ45 WS-X6516-GE-TX SAL0803SQA2 Mod MAC addresses Hw Fw Sw Status --- ---------------------------------- ------ ------------ ------------ ------- 1 000f.90ac.ef50 to 000f.90ac.ef51 5.2 7.1(1) 12.2(18)SXF3 Ok 2 0003.32b9.f60a to 0003.32b9.f619 1.2 5.4(2) 8.5(0.46)RFW Ok 4 000e.d77e.a1c8 to 000e.d77e.a1d7 2.5 6.3(1) 8.5(0.46)RFW Ok Mod Sub-Module Model Serial Hw Status ---- --------------------------- ------------------ ----------- ------- ------- 1 Policy Feature Card 2 WS-F6K-PFC2 SAL0819707U 3.4 Ok 1 Cat6k MSFC 2 daughterboard WS-F6K-MSFC2 SAL06190L6M 2.9 Ok необходимо произвести апгрейд с заменой sup2 на sup720-3bxl как мне лучше поступить? Можно ли вставить 720 на лету и скопировать в него конфиг? Или лучше сохранить конфиг с sup2 - выключить, а после замены на 720 залить в него текущий конфиг откорректировав его? Апгрейд делается в ядре работающей сети и даунтайм должен быть минимальным. БП 2500 ватт и блок вентиляторов будет заменен на FAN2.
  2. "У них вообще-то длина волны разная. ;-) Так что широкополосность очень даже при чем" есть такое дело LR - 1310 нм, остальные на 1550 работают, но на входе детектора фильтров нет :) реагирует на фотоны, разница в энергии не большая. Не поленился посмотрел пдф на sfp+ : " Receiver λC Center Wavelength 1260 1565 nm"
  3. поставьте два dell-6024 или 6224 и пусть роутят на уровне района, зачем гнать в центр местный трафик по 10G ? У меня агрегация районов сделана на 6024F и аплинк в ядро хватает 1 гига с головой, в районе сидит 2000 юзеров, аплинк максимум грузят на 500-600 мбит.
  4. LR/ER/ZR - а причем здесь широкополосность приемника, это обозначение длины линка LR - короткая дистанция(10 км), ER - средняя (40 км) и ZR - длинная (80 км). XENPAK, X2, XFP, SFP+ - это разные формфакторы реализации, а стандарт один - 10G так что они обязаны быть совместимы. ( правда были случаи несовместимости модулей китайских производителей, но это уже из другой оперы :) )
  5. зачем самим себе создавать проблемы? мы ставим оборудование в подъезде там всегда более-менее приемлемая температура, зимой не холодно, а летом не жарко и обслуживать намного проще. только что глянул как поживает свитч оптический, температура внутри свитча +35, на улице -4, свитч в подъезде.
  6. счастья не будет - порвет волокно, у меня постепенно тянуло до гильзы, потом обрыв и переварка :)
  7. если на украине и не дорого могу предложить Dell Powerconnect 6024F 24sfp+8комбо L3 у меня такие стоят, работают второй год без проблем. вот здесь посмотри, там] и контакты мои есть. Есть 3 штуки в наличие, новые в упаковке.
  8. общий низкий уровень жизни населения в купе с тупым демпингом обвалили ARPU на Украине ниже плинтуса, в таком раскладе я бы сейчас сильно задумался об инвестициях в этот бизнес, тем более на фоне общего негатива в экономике, который приведет к еще большему сокращению доходов ваших потенциальных клиентов с одной стороны и росту затрат связанных с девальвацией местной валюты с другой. Jab когда-то правильно писал, что обслуживание клиентов с ARPU меньше 20 баксов - сродни садомазохизму, ну или подвижничеству :). Все сказанное ИМХО, но основанное на личном опыте строительства и эксплуатации сети в течении 6 лет и с количеством клиентов более 2000 именно на украине.
  9. то что уходит в пдвал проще будет вывести через пол просверлив отверстие, а вверх - в трубу. Но сам подход конечно...
  10. пятый день работает пока NAS, нагрузка правда поболее чем здесь писали, сейчас около 360 чел онлайн. last pid: 83921; load averages: 1.17, 0.66, 0.54 up 5+00:11:51 19:03:05 71 processes: 4 running, 50 sleeping, 16 waiting, 1 lock CPU states: 2.6% user, 0.0% nice, 25.8% system, 20.5% interrupt, 51.1% idle Mem: 15M Active, 226M Inact, 182M Wired, 332K Cache, 111M Buf, 572M Free Swap: 1758M Total, 1758M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root 1 171 ki31 0K 8K RUN 0 84.1H 66.16% idle: cpu0 15 root 1 -44 - 0K 8K CPU1 0 31.5H 39.16% swi1: net 11 root 1 171 ki31 0K 8K CPU1 1 78.8H 38.92% idle: cpu1 45 root 1 -68 - 0K 8K - 0 19.5H 22.51% dummynet 32 root 1 -68 - 0K 8K - 1 663:38 11.47% em0 taskq 39 root 1 -68 - 0K 8K - 1 563:40 9.96% em1 taskq 558 root 1 121 0 20608K 10152K select 0 143:38 2.00% mpd4 23 root 1 -68 - 0K 8K *Giant 0 75:00 0.98% irq18: em1 uh 13 root 1 -32 - 0K 8K WAIT 1 66:22 0.00% swi4: clock s и netstat -bdh -w1 input (Total) output packets errs bytes packets errs bytes colls drops 21K 0 12M 22K 0 16M 0 0 20K 0 11M 21K 0 15M 0 0 21K 0 11M 21K 0 15M 0 0 22K 0 12M 22K 0 16M 0 0 21K 0 12M 22K 0 16M 0 0 периодически пишет dmesg вот такое: ipfw: ouch!, skip past end of rules, denying packet ipfw: ouch!, skip past end of rules, denying packet Limiting icmp unreach response from 227 to 200 packets/sec Limiting icmp unreach response from 232 to 200 packets/sec
  11. После перехода на новый nas наблюдался странный глюк: после 30 часов работы пропал из сети сервер, причем его оба интерфейса один с реальным адресом, а второй с серым смотрящим в сеть. Отсутствовал пинг на оба, при этом на управляемом коммутаторе оба порта показывали активное состояние. При подключение клавы и монитора, обнаружилось что система не висит! А нормально логиниться в консоле, но при попытке пропинговать другие сервера проскочил только один случайный пинг! К сожалению перезагрузку проводил не я лично, поэтому провести диагностику системы не удалось. Может у кого возникали подобные ситуации, было бы неплохо предупредить заранее такие приколы системы. Конфигурация системы: 7.0-RELEASE FreeBSD 7.0-RELEASE #4: Mon Dec 29 17:39:11 EET 2008 ***********:/usr/obj/usr/src/sys/VPNGATE i386 конфиг ядра стандартный, добавлено вот что: # netgraph options NETGRAPH options NETGRAPH_IPFW options NETGRAPH_PPP options NETGRAPH_PPTPGRE options NETGRAPH_L2TP options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options DUMMYNET ну и выкинуты лишние девайсы из железа которого нет. Железо такое: CPU: Intel® Core2 CPU E8500 @ 3.16GHz (3165.08-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLU SH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x309<SSE3,MON,TM2,SSSE3> AMD Features=0x20100000<NX,LM> AMD Features2=0x1<LAHF> Cores per package: 2 real memory = 1071620096 (1021 MB) avail memory = 1038602240 (990 MB) ACPI APIC Table: <INTEL S3200SHV> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 сетевые PCI-E INTEL 1000/ буквы не помню, дрова родные фряки em На системе кроме mpd4 который термирует PPTP еще крутиться ng_nat и шейпер средствами ipfw, больше ничего.
  12. dell 3324 и 3348 работают как часы, проблем 0, уже 6 месяцев полет нормальный. Весь доступ на них перевел. 3048 действительно проблемны, по-моему траблы в них из-за того что невозможно изолировать интерфейс управления от сети, это приводит к блокированию работы управления иногда даже слетает прошивка. В 33хх - с этим проблем нет, там управление изолировано и процессор помощнее, что видно по вебинтерфейсу - шустро работает.
  13. Linksys 3102 эксплуатирую больше года именно для проброса домашнего телефона, в последнее время стал очень часто зависать: или вешает телефонную линию ( постоянно идет сигнал занято) или на приемной стороне бывают подвисания которые вызывают односторонную слышимость. Напрягает честно говоря уже, сейчас задумался о другой железке.
  14. Регулировать процесс в мировом масштабе кто будет ? Правильно, регулятор(ы). Обслуживать это все кто будет ? Правильно, оператор(ы). Что меняется то принципиально ? Так нафиг вам регуляторы нужны, вообще не понятно? Предлагается же решение с глобальной базой идентифкаторов и открытым протоколом взаимодействия базы и любого оператора! Пользователь ставиться во главу угла как владелец идентификатора, а оператор тоже ставиться на место которое ему положено, как обеспечивающий пользователю наиболее качественное обслуживание, при этом владелец идентификатора сам решает кто его качественней обслужит и дешевле, а не регуляторы или операторы! А транспорт может быть вообще любой, хоть ip хоть сотовая сеть не все ли равно пользователю-владельцу идентификатора как операторы изголяться будут. Я еще в прошлом году пытался эту мысль продвинуть и демо-проект запустили для этого http://globalnum.net/ .
  15. наверное надо и на компе прописать шлюзом 10.77.77.1