dex

ePMP-2000 не использует AC, она о ней не знает (AC wave 2 обещают в epmp-3000 вроде как). Все дело в полинговой технологии как я понимаю (может и не совсем верно), у cambium среда передачи делится по времени, у ubnt она делится по количеству переданных данных. Из за этого дальние/медленные клиенты у ubnt тормозят всех ... А есть ли тут на форуме графики загрузки 5АС ubnt? Дайте ссылку пожалуйста. Про ширину полосы, с месяц назад у epmp была 20МГц, потом сделали 40МГц, как раз эксперименту ради, сильного отличия замечено не было, все равно под потолок грузится, и этот потолок все равно 60-70Мбит/с (с тарифами погорячились, раздали слишком быстрые, но на обоих базах они одинаковые). у epmp в одну картинку все не влезли:

Всем привет. Добавлю свои пять копеек. Искал вот на форуме варианты как разогнать rocket m5 titanium, без покупки нового железа, но не нашел, а жаль. В данный момент стоят базы на ubnt (Rocket M5 Tit) и cambium (ePMP-2000). Разница по скорости на секртор - почти в два раза в пользу cambium. Ubnt - 35Мбит при 32 клиентах и 30МГц. Cambium - 60Мбит при 63 клиентах и 40МГц. На обоих базах стоят omny антенны от ubnt (AMO-5G13). Если выбираете между этими вендорами, выводы делайте сами (скрины графиков для cambium из интерфейса самой базы, для ubnt из dude): Cambium: Ubnt:

Приветствую! С цисками я не работал совсем. Подскажите пожалуйста модели Layer 2 и 3, что бы на борту было от 16 до 24 оптических портов. А то с наскока и не разобраться )). Если можно с ссылками где почитать.

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

У меня похожая ситуация (CCR1016-12S-1S+, ROS-6.37.5), два провайдера и небольшая подсеть белых адресов. Часть клиентов идет через NAT, а другой нужно выдать белые. Вот экспериментирую: - подсети как вы и писали, с маской /24 - прописал маркированный дефолтный маршрут - включил proxy-arp на внешнем интерфейсе нужного провайдера, и одном из локальных (эксперимент пока без valn, на физическом порту) - промаркировал трафик И все работает, пока белые адреса попадают под общий nat, но как только выше прописываю правило scrnat с указанием src адреса, выходного интерфейса и action - accept, трафик ходить перестает. От сюда вопрос, как правильно сделать обходной путь мимо общего NAT-a для нужных адресов или интерфейсов?

Неужели не существует готовых, упрощенных способов поднять сеть, без применения направленных антенн? Повторюсь, народ живет очень тесно, расстояние между точками будет всего 200м! Сеть поднимается не для раздачи интернета (хотя не без него), а скорее для игр и перекачки файлов. Именно по этому хотим mikrotik, что бы настроить приоритеты, и зарубить не нужный трафик. Кто нибудь уже делал что то похожее? Если никто не знает как это сделать на микротиках, то может подскажите про ubnt?

20-30 Мбит/с для wifi c MIMO 2x2, это много?

Скорости должны быть хотя бы 20-30 Мбит/с. Поднять над домом на высоту пары - тройки метров это не проблема. OmniTIK U-5HnD будет столько, сколько будет человек в сети. Народ живет довольно плотно, и не в линию, а скорее в шахматном порядке, поэтому использовать SXT не представляется целесообразным. Каждая точка будет видеть как минимум две других, т.к. расстояния до соседних будет в пределах 200м. Поэтому нужны точки, встроенные в антенну с круговой диаграммой. Нет. Хотим без SXT. Компьютеры клиентов будут подключатся кабелем непосредственно к OmniTIK U-5HnD. Просто у каждого будет стоять свой OmniTIK U-5HnD, и по замыслу, они должны будут цепляться друг за друга по технологии WDS. В том и суть, что бы для близко расположенных точек исключить SXT. такая схема не актуальна, из за близких расстояний. Неужели mikrotik это только для линков свыше километра? Знаю, что WiFi железо других фирм (к примеру dlink) имеет в настройках режим WDS. На dlink-ах даже есть опыт использования этой технологии. Но в них и близко нет тех возможностей по настройкам, как в Mikrotik. Вот насчет Ubiquiti не знаю, возможно у них есть что то сравнимое с RouterOS? Хочется и шейпер, и фаервол, и снифер ... Возможно мы уперлись в эту аббревиатуру WDS, может у mikrotik это называется по другому?

Привет всем! Есть потребность поднять небольшую сеть в частном секторе. Множество одно этажных домов. Всего порядка двух десятков желающих подключится, но разбросаны они на площади примерно 0,5км х 1км, почти равномерно, с расстоянием по цепочке между друг другом 100-200м. Можно ли на OmniTIK U-5HnD поднять в этих условиях WDS сеть? Если нет, то какое железо от Mikrotik можете порекомендовать (именно для WDS)? Явных возвышенностей нет, высоких столбов или мачт тоже нет, поэтому с установкой центральной точки проблема, ну а как народ подтянется переделать все на кабель. И еще вопрос, насколько я понял, WDS настраивается программно на любом радиомаршрутизаторе mikrotik?

пришло наконец новое оборудование, сейчас пробую на DES-3200-18 и все работает! с теме же конфигами! значит проблема была в DES-3828, будем крутить его, хотя варианты с разными его настройками я перебрал еще тогда ...

на самом деле проблема в циклической выдаче и мгновенной отмене выданного адреса, это видно по логам: Jan 10 00:19:31 testd dhcpd: DHCPINFORM from 192.168.169.50 via 192.168.171.254 Jan 10 00:19:31 testd dhcpd: DHCPACK to 192.168.169.50 (00:17:31:81:23:19) via eth0 Jan 10 00:19:43 testd dhcpd: DHCPDISCOVER from 00:1f:16:37:84:03 via eth0: network test: no free leases Jan 10 00:19:43 testd dhcpd: *** Jan 10 00:19:43 testd dhcpd: *Leased 192.168.168.244 (with opt82) Jan 10 00:19:43 testd dhcpd: *Remote-ID: 0:1c:f0:23:51:0 Jan 10 00:19:43 testd dhcpd: *Port: 4 Jan 10 00:19:43 testd dhcpd: ### Jan 10 00:19:43 testd dhcpd: DHCPDISCOVER from 00:1f:16:37:84:03 via 192.168.171.254 Jan 10 00:19:44 testd dhcpd: DHCPOFFER on 192.168.168.244 to 00:1f:16:37:84:03 (pc) via 192.168.171.254 Jan 10 00:19:44 testd dhcpd: DHCPREQUEST for 192.168.168.244 (192.168.168.6) from 00:1f:16:37:84:03 via eth0: lease 192.168.168.244 unavailable. Jan 10 00:19:44 testd dhcpd: DHCPNAK on 192.168.168.244 to 00:1f:16:37:84:03 via eth0 Jan 10 00:19:44 testd dhcpd: *** Jan 10 00:19:44 testd dhcpd: *Leased 192.168.168.244 (with opt82) Jan 10 00:19:44 testd dhcpd: *Remote-ID: 0:1c:f0:23:51:0 Jan 10 00:19:44 testd dhcpd: *Port: 4 Jan 10 00:19:44 testd dhcpd: ### Jan 10 00:19:44 testd dhcpd: DHCPREQUEST for 192.168.168.244 (192.168.168.6) from 00:1f:16:37:84:03 (pc) via 192.168.171.254 Jan 10 00:19:44 testd dhcpd: DHCPACK on 192.168.168.244 to 00:1f:16:37:84:03 (pc) via 192.168.171.254 Jan 10 00:19:44 testd dhcpd: DHCPDISCOVER from 00:1f:16:37:84:03 via eth0: network test: no free leases Jan 10 00:19:44 testd dhcpd: *** Jan 10 00:19:44 testd dhcpd: *Leased 192.168.168.244 (with opt82) Jan 10 00:19:44 testd dhcpd: *Remote-ID: 0:1c:f0:23:51:0 Jan 10 00:19:44 testd dhcpd: *Port: 4 Jan 10 00:19:44 testd dhcpd: ### Jan 10 00:19:44 testd dhcpd: DHCPDISCOVER from 00:1f:16:37:84:03 via 192.168.171.254 Jan 10 00:19:44 testd dhcpd: DHCPOFFER on 192.168.168.244 to 00:1f:16:37:84:03 (pc) via 192.168.171.254 Jan 10 00:19:44 testd dhcpd: DHCPREQUEST for 192.168.168.244 (192.168.168.6) from 00:1f:16:37:84:03 via eth0: lease 192.168.168.244 unavailable. Jan 10 00:19:44 testd dhcpd: DHCPNAK on 192.168.168.244 to 00:1f:16:37:84:03 via eth0 Jan 10 00:19:44 testd dhcpd: *** Jan 10 00:19:44 testd dhcpd: *Leased 192.168.168.244 (with opt82) Jan 10 00:19:44 testd dhcpd: *Remote-ID: 0:1c:f0:23:51:0 Jan 10 00:19:44 testd dhcpd: *Port: 4 и до windows машины ответы эти долетают, только адрес никакой не присваивается, и syslog заполняется с ужосающей скоростью. вот еще выдежка из dhcpd.leases: lease 192.168.168.244 { starts 1 2012/01/09 12:19:52; ends 2 2012/01/10 00:19:52; cltt 1 2012/01/09 12:19:52; binding state active; next binding state free; hardware ethernet 00:1f:16:37:84:03; uid "\001\000\037\0267\204\003"; option agent.circuit-id 0:4:0:1:0:4; option agent.remote-id 0:6:0:1c:f0:23:51:0; client-hostname "pc"; } lease 192.168.168.244 { starts 1 2012/01/09 12:19:52; ends 1 2012/01/09 12:19:52; tstp 1 2012/01/09 12:19:52; cltt 1 2012/01/09 12:19:52; binding state free; hardware ethernet 00:1f:16:37:84:03; uid "\001\000\037\0267\204\003"; } lease 192.168.168.244 { starts 1 2012/01/09 12:19:53; ends 2 2012/01/10 00:19:53; cltt 1 2012/01/09 12:19:53; binding state active; next binding state free; hardware ethernet 00:1f:16:37:84:03; uid "\001\000\037\0267\204\003"; option agent.circuit-id 0:4:0:1:0:4; option agent.remote-id 0:6:0:1c:f0:23:51:0; client-hostname "pc"; } lease 192.168.168.244 { starts 1 2012/01/09 12:19:53; ends 1 2012/01/09 12:19:53; tstp 1 2012/01/09 12:19:53; cltt 1 2012/01/09 12:19:53; binding state free; hardware ethernet 00:1f:16:37:84:03; uid "\001\000\037\0267\204\003"; и так до бесконечности ... перепробовал включать и отключать стандартные опции в dhcpd.conf, не помогает (( хоть бы идею какую-никакую в какую сторону копать ...

ubuntu 11.10, isc-dhcp-server-4.1.1-P1-17ubuntu10.1, настроен под option 82, конфиги один в один тестовый свич des-3828 с натсройками: DES-3800:admin#show dhcp_relay Command: show dhcp_relay DHCP/BOOTP Relay Status : Enabled DHCP/BOOTP Hops Count Limit : 4 DHCP/BOOTP Relay Time Threshold : 0 DHCP Relay Agent Information Option 82 State : Enabled DHCP Relay Agent Information Option 82 Check : Enabled DHCP Relay Agent Information Option 82 Policy : Replace Interface Server 1 Server 2 Server 3 Server 4 ------------ --------------- --------------- --------------- -------------- System 192.168.168.6 Те же грабли, адрес выдается, DHCPREQUEST возвращает unavailable, и тут же проходит dhcpnak с отбоем. И цикл повторяется с ***енной скоростью, в syslog сыпятся те же, что и выше сообщения. Как решилась задачка?

300м на витой паре ни какой Ethernet свич не возьмет (предел - 100м, ну может на считанные метры больше, но не 300!). Либо разбивайте этот линк на части, либо кидайте оптоволокно. Хотя есть еще xDSL ...

Скорее всего глюки создает пробитый порт на свиче и сам кабель здесь не причем. Заземлять экран нужно еще до подключения кабеля к оборудованию! Если этого не сделано, то грозозащита на 100% никогда не защитит! Статика пробьет и грозозащиту и порт на свиче, потому как заменить грозозащиту сразу после выхода ее из строя почти не реально. Заземляйте экран, а затем выясняйте какой порт успело пробить, меняйте свич, хотя возможно и старый еще будет работать, здесь зависит от оборудования ... А заземлять или занулять - это зависит от доступности каждого из методов. Если есть выбор то лучше заземлить, потому как зануление имеет свои нюансы (не в коем случае на зануляйте экран в обоих зданиях сразу, делайте это только с одного конца кабеля, а вот заземлять можно и с двух сторон).

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