NiTr0

любой инженер знает, что вполне можно (и даже нужно) составить математическую модель, хотя бы идеальных условий, по которой уже делать какие-то выводы. а джамшут - тот да, методом тыка, по недоразумению называемого "сакральными знаниями", что-то там "разрабатывает". и как только один из параметров меняется (ну, там, любимый кабель перестали выпускать, а у нового кабеля сопротивление отличается) - тут у джамшута случается паника... судя по тому, что вы не можете ответить на вопрос - вы относитесь ко вторым. не нужно - все данные, необходимые для ваших "сложных расчетов", есть в моем посте. с большим избытком. вот только печаль в том, что у вас нет не то что расчетов - а даже понимания процессов. ладно, еще больше значит упрощу вопрос: способна ли какая-либо камера с широким диапазоном питающих напряжений (ну допустим 12-60В) работать на линии с падением напряжения 30 вольт при питании 52 вольта? нет. камеры с DC-DC на входе (ну т.е. все камеры, и не только камеры), в т.ч. питающиеся по PoE, имеют одну отличительную, я бы сказал - фундаментальную особенность. но вы о ней, похоже, даже не догадываетесь...

все понятно - согласно "сккральных знаний" расчеты делаются "на глаз, с поправкой на направление струи мочи"... возьмите произвольную камеру с диапазоном 12-48В например, если вам будет легче от того дать ответ. да не нужно там ничего решать. в самом вопросе даже избыток исходных данных есть. и ответ простой на самом-то деле. но владелец "сакральных знаний" его не знает :) нет, элементарное моделиование дает однозначный ответ. но - это надо голову включать, модель правильную составлять же. проще по рабоче-крестьянскому - кабло размотать, покромсать, а потом - развести руками "не работает, нащальникэ, пачиму незнаманама"

ок, есть кусок кабеля, например 70м, где напряжение при включении моторчика камеры проседает до 27 вольт при 52 на входе. камеры пускай даже с широким диапазоном питающих напряжений (12-48, да хоть и 5-48 - не принципиально) и пое мощное. вопрос вам как владельцу "сакральных знаний": какой же на самом деле запас по напряжению будет в данном случае, и на сколько будет допустимо удлиннить кабель при необходимости?

дада)))) писал как-то насчет того что в 6.45 дхцп при работе с радиусом И пулами стал тупо игнорить пулы, принимая от клиентов предложенные ними лизы (хоть 192.168.0.100). выглядело это так: "вышлите supout.rif... ой, вышлите его снова, прошлый криво сгенерился... ой, а почему у вас сейчас нет клиента, получившего 192.168.0.100? вышлите supout.rif с этим клиентом... ой, а вышлите журнал радиуса... а, ну да - радиус не задает ип, потому клиенту назначается ип который он запросил, все правильно, так и должно быть. что, в 6.44 было иначе? ну тогда вышлите supout.rif и лог радиуса для 6.44..."

решил попробовать таки заапдейтить роутерось на одной ццр вундервафле с 6.44 на 6.46.7 (bugfix-only типа ветка, типа вылизана должна быть). итог: после ребута исчезли нахрен все dhcp сервера из конфига, при попытке скопипастить в терминал старый конфиг - ругалось ошибкой. повторны ребут волшебным образом вернул все сервера на место. но я совсем не уверен, что после очередного ребута у него опять не отсохнет dhcp опять, и с концами. волшебный загадочный некротик...

мож того... vmalloc заюзать? вроде как физически непрерывный кусок памяти же не нужен.

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

поюзай ssh на интертелекоме. если не лезть в конфиги с кипалайвами - минут через 5-10 (на глаз) сессия без активности в ней отсыхает. отвлекся на гугол, вернулся в ssh - а сессия померла. заморачиваться с настройками кипалайва ради резервного линка, юзаемого от силы раз в несколько месяцев - смысла не вижу (больше времени потрачу на настройку с экспериментами, чем сэкономлю на реконнекте за лет 5). цифры-то откуда? "мусорная запись" может взяться только в случае, если у клиента с активной сессией оборвалась связь. всё. экзотические tcp ddos - в теории конечно возможны, но на практике - я их не видел, да и малополезны они (пушо раскрывают ip отправителя пакетов).

угу, пока нет скринсейвера... когда у 99.9% операторов/провайдеров все гладко и шелковисто, а у 0.1%, которыми приходится изредка пользоваться (раз в несколько месяцев) - надо по мнению их собратьев ставить какие-то галочки где-то в openssh клиенте, который консольный, то тут таки вопросы к провайдеру...

обычно - идет udp флуд, причем - часто битые пакеты, с рандомным отправителем. халва, халва... расскажите тому, кто не пользовался ssh через недооператоров с зарезанными таймаутами коннтрака.

в том-то и дело что по неактивному ssh туннелю, который висит, пакеты не бегают. и, думается, rdp аналогично. ддосили tcp established коннектами?...

клиенты, юзающие ssh туннели или rdp, будут в диком восторге например, и быстро сменят такого недопровайдера на кого-то с более прямыми руками.

если поставит мак соседа и ип соседа (статикой или дхцп) - да, будет получать интернет.

dhcp, шейпер и нат. ну и мелочи типа бгп дефолта с днс сервером. никакого нетфлоу и т.п. торчит 3 sfp+ модуля (к слову, одна сфп+ дырка пару месяцев назад внезапно померла, причем частично - начали пакеты дропаться, где-то 1.5% потерь, торчала как раз на аплинк - потому диагностика была длительной и геморной). пинг скачет даже для адресов на которые не навешан шейпер (simple queues). если хочется натить на чем-то дешевом - уж лучше тазик на каких-то серверах с помойки или не совсем убогом десктопе собирать уж. и дешевле, и предсказуемее.

для некротикоадмина это слишком сложно. они по видосикам на ютупе в винбоксе мышкой клац-клац...

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

и куда его втыкать? ставить еще один некротик?)))

щито? в гугле забанили?))) например вот, ознакомьтесь:https://www.cisco.com/c/en/us/td/docs/ios/fundamentals/command/reference/cf_book.pdf в открытом доступе, да, на официальном сайте. комьюнити циски тоже на несколько порядков больше чем у всяких там производителей домашних мыльничек и прочих игрушек. ну а самое главное - оно просто работает. ну а если говорите что "все можно на некротике настроить" - откройте же секрет, как на longterm ветке в связке dhcp + radius авторизация заставить его таки выдавать по дхцп адреса строго из назначенного на радиус сервер пула, а не те которые клиент запросил сам? что, никак? пичаль-беда...

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

unknown unicast - 100% пойдет. или если вдруг какую-то фичу включите, которая аппаратно не поддерживается, все внезапно скукожится.

когда смешные несколько десятков мбит lbd-флуда укладывают свич с 10г (вплоть до прекращения форвардинга трафика) - это таки не особо приятно. повторюсь, подобное видел только у бдкомов. ну у нас 3120/3420 - такого не случалось. мож потому что всякие igmp snooping и т.п. не юзаем. а вот на бдкомах - то ли оно по дефолту включено, то ли отключение не помогает, но как только случается колечко даже 100мбит - бдком свичи умирают. некоторые - престают на пинги отвечать, s3740f - перестает даже трафик форвардить (хотя возможно то агрегация разваливается), причем - как-то прерывисто (то с дикими дропами форвардит пару минут, потом - пару минут не форвардит).

или выкидываете всю эту трахомудию и ставите одну-единственную циску. которая и обойдется дешевле, и проживет дольше, и будет ГОРАЗДО стабильнее работать.

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

сможет, но очень плохо и глюкаво. с перестройкой таблиц маршрутизации при флапе пиров до получаса, с пингами по 10-30-100-200 мс (изредка правда) при загрузке ядрышек более 30-40%, и прочими прелестями. не, если уже купили и поставили куда-то - то приходится с этим глюкалом жить, но покупать с нуля - выброшенные деньги имхо.

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