CIDR — предполагает что маска сети может отличаться от классовой и предлагает форму записи таких масок в виде длины префикса. Да, RIPv2 передаёт в пакете маску подсети и она может отличаться от стандартных масок классовых сетей.
VLSM — предполагает дробление одной классовой сети на множество подсетей более узких (речь идёт именно про подсети — SUBNET MASK), но с переменной длинной префикса (собственно в этом и заключается VARIBLE LENGTH). Да, RIPv2 может передать информацию о нескольких подсетях входящих в одну сеть с маской более узкой, чем классовая и даже c разной длиной префикса.
Но! В RIP (независимо от версии) вы не можете указать в команде network маску, а выполнение комнады «network 10.10.10.0», например, в конфиге превратится в 10.0.0.0 фактически с маской /8. RIP умеет охватывать только всю классовую сеть целиком. Конечно можно использовать passive-interface и distribute list'ы, но это уже костыли.
В случае если у вас на роутере все интерфейсы из диапазона 10.0.0.0/8, и вам нужно через один из них поднять RIP с соседом, но не сообщать ему о своих остальных сетях, а только принимать маршруты от него, то эта задача решается только с помощью distribute-list'ов. В OSPF, EIGRP или BGP этот вопрос закрывается командой network c узкой маской (как правило /30 на транзитных сетях).
Я наверное погорячился на счёт того что RIPv2 совсем не умеет VLSM. С точки зрения передачи информации о сетях — конечно умеет, но вот с точки зрения настроек самого протокола маршрутизации — нет.
Classfull — RIPv1 и IGRP — С этим согласен.
Но! Classless, (он же CIDR) это только RIPv2.
А вот BGP, OSPF, EIGRP и IS-IS это уже не просто CIDR, а ещё и VLSM.
Принципиальная разница в том, что RIPv2 не умеет VLSM, поэтому некорректно ставить его в один ряд с OSPF и прочими.
Сделать обзор подобных систем за неделю — нереально.
Я сам когда выбирал — неделю ковырял популярные сервисы на предмет основных возможностей, а потом почти месяц пользовался тремя сразу. Некоторые нюансы выявил ещё спустя год использования.
Cам остановился на easyfinance.ru
Уже почти два года ей пользуюсь — мои задачи решает полностью.
Так что не проходите мимо.
ИМХО — НЕТ. Если и достаточная, то уж точно НЕ эффективная. При такой «мотивации» сотрудники будут делать только то что велено и фактически станут просто дополнительными руками управленца, который все решения принимает сам, всё сам контролирует и продумывает, а исполнителям только говорит на какие кнопки нажимать. Но управленец не может шарить одновременно и в цисках, и в серверах и серверных ОС, и виртуализации и в АД и в чёрт-знает в чём ещё. Админы-то тогда ему на кой? Тогда надо эни-кейщиков нанимать, а не админов.
Кончено можно сказать, что тех.дир должен задавать только вектор, а конкретные технические реализации — дело рук админов… но! откуда бы ему тогда узнать этот вектор? Он же, например, не сопровождает ЦОД и понятия не имеет как там обстоят дела с дисковой производительностью, а админы при «пинково-векторном» подходе управления сами ему о надвигающихся проблемах не скажут, потому что в ответ получат только пинок вида «с производительностью дисков надо что-то делать. Не знаю что, но идите делайте».
Одним из лучших способов управления квалифицированной группой людей является «самоуправление». Тех.дир не может всё знать и за всех всё решать да ещё ходить контролировать каждого, что бы он это выполнял.
Должна присутствовать здоровая самоорганизация и инициативность исполнителей, которые сами на поле боя хорошо видят какие задачи требуют решения и подходят к тех.диру с конкретными предложениями, предварительно их проработав по своей инициативе, а не ждут раздачи пинков от руководства что бы начать что-то делать.
Вот что бы к этому прийти нужна мотивация, и уж явно не кнутом, а пряником.
ИМХО.
Клиентов всё больше с каждым днём, производительности текущей дисковой системы в ЦОДе ещё хватает, но уже на грани, система мониторинга недоразвита, сбор статистики по доступности сервисов вообще не ведётся, и так далее… и вот именно в таких условиях и стоит задача мотивации ИТ-отдела.
Пост интересный, но то, что там описано я бы отнёс либо к внутренней, либо к нематериальной мотивации, да и направленность там именно на девелоперов. У меня гораздо больше возникает вопросов именно в ключе материальной мотивации ИТ-отдела.
Будем считать что с нематериальной мотивацией всё в порядке и к ИТ-отделу в компании не относятся как к транжирам, которые только тратят деньги и ничего не зарабатывают.
Но при этом возникает другая проблема — у админов нет никакого стимула работать с огоньком — а зачем, если кроме них и их прямого руководства никто не в состоянии оценить новый отказоустойчивый кластер или работу SAN-сети, зато если в процессе внедрения этих новшеств они пару раз роняли сетку или ЦОД, то матом их не крыл только ленивый?
За отсутствием внешних стимулов развитие ИТ-инфраструктуры становится обыкновенной рутиной, за которую ещё и по голове можно получить. И когда начальный щенячий драйв со временем проходит и возникает чёткое жизненное понимание того, что «если где-то почесать -то там и упадёт», «не трогай то, что работает» и «не ошибается только тот кто ничего не делает» то желание что-то делать, кроме текучки, отсыхает напрочь. Вот тут и встаёт вопрос — как в такой среде стимулировать дальнейшее развитие?
И при этом придерживаться золотого врачебного правила «не навреди» и не вводить штрафы за каждый сбой — это точно отобьёт желание что-то делать, но и не премировать ввод в эксплуатацию всяких бессмысленных свистелок-перделок, от которых реальному бизнесу ни жарко ни холодно.
Проблема мотивации ИТ-отдела на мой взгляд кроется в вопросе — «Как завязать обеспечение реальных показателей отказоустойчивости сервиса и желание развивать собственный сервис (при некотором округлении вещи друг-друга взаимоисключающее, имхо) с денежной премией исполнителей?».
Из того что хотелось бы услышать в Вашем исполнении — «Система мотивации админов», ну или «Система мотивации для внутреннего отдела ИТ».
Работа админов она как и ТП в софтверной компании — обладает большим значением неопределённости, а поэтому всё регламентировать и предопределить сроки зачастую невозможно, отсюда и проблема мотивации.
В целом текст этой статьи даёт полезные советы и в рамках озвученных мной тем тоже, но вдруг Вы сможете предложить более развёрнутый ответ.
link-based работает как само-собой разумеется… казалось бы, да.
Но я имел опыт с Solaris x86, который НЕ реагировал на физическое падение линка и фактически работал только в probe-mode.
Т.е. Соляра в упор не видела, что у неё упал интерфейс, при этом если ей было кого пинговать, то методом PROBE она могла обнаружить падения интерфейса.
Так что режим probe-mode (без link) в природе тоже встречается!
Хотя это скорее глюк, чем фича.
=)
с 10-той Солярой ещё не ковырялся, но в 9-той вникал в этот вопрос глубоко.
Во первых на счёт того, кому верить.
Курил много инфы по сабжу, и форумы и книжки для подготовки на SCNA, но самым информативным и близким к истине оказался «man mpath.d».
(Истину проверял снятием снифов посредством Wireshark и snoop)
А ещё очень полезной оказалась эта статья
Во вторых на счёт двух режимов я с вами не очень-то согласен. Вы указываете на обоих интерфейсах группу, а дальше есть варианты и их далеко не два!
Вы задаёте параметр -failover и соответственно интерфейсы работают в режиме ACTIVE-STANDBY. Но если этот параметр не задавать, то все интерфейсы группы будут работать в режиме ACTIVE-ACTIVE, о чём вы вообще не упоминаете (а оно работает — проверено!).
Вы задаёте параметр DEPRICATED — на самом деле этот параметр означает, что IP адрес данного интерфейса будет использоваться для сбора проб в данной группе. Это даёт много вариантов настройки для всевозможных ситуаций. Например для выявления отказа коммутатора можно использовать один интерфейс, а для передачи трафика другой. Или например можно включить интерфейс в группу, но не задавать ему DEPRICATED адрес, тогда он будет участвовать в группе, но пробы с него делаться не будут, ну и т.д.
В файле /etc/default/mpathd тоже есть чего поправить, а вы его даже не упомянули.
Например там можно указать время FAILURE_DETECTION. Там же можно указать FAILBACK — т.е. делать ли его вообще. Время FAILBACK'a равно двойному значению FAILURE_DETECTION.
А ещё там можно включить сбор проб для ВСЕХ интерфейсов, а не только для тех, которые участвуют в группах, а трафиком управлять уже за счёт таблицы маршрутизации.
Вообщем, назвался груздем — полезай в кузов. Взялись писать «статью на хабр», можно было бы уж уделить внимание теории и написать человеческий обзор IPMP, а не пионэрский очерк в две строчки «самого интересного» (и нихрена непонятного).
Чуть выше речь шла про «участие проца в формировании PS».
Соответственно перечислять все возможные варианты причин, по которым может не стартовать MB я вообщем-то и не пытался.
А вообще это топик полугодичной давности (сентябрь 2011) — писать сюда это уже некрофилизм, ИМХО. Более того я думал, что топики которым более 3-х дней и комментировать-то нельзя!
Классический Domain Based NAT несколько ограничен в своих возможностях и требует однозначного указания inside\outside, а вот более современная реализация NVI (NAT Virtual Interface) даёт возможность лучше понять этот алгоритм.
При использовании NVI мы просто указываем на интерфейсе «ip nat enable» — т.е. просто включаем на этом интерфейсе проверку NAT. Все пакеты проходящие через этот интерфейс будут проверяться на наличие каких-либо NAT-трансляций.
Т.е. пакет идёт через 3 стадии:
1.входящий интерфейс
2.маршрутизация
3.исходящий интерфейс
В 1 и 3 пунктах ВОЗМОЖНА проверка правил NAT. Соответственно при классическом NAT проверка делается на обоих интерфейсах, но подмена происходит только на outside интерфейсе, т.е. только один раз.
Поэтому для пакета идущего из inside в outside подмена осуществляется ПОСЛЕ маршрутизации.
А для пакета идущего из outside в inside подмена осуществляется ДО маршрутизации.
Для входящего в роутер пакета NAT обрабатывается раньше, чем маршрутизация, а для исходящего наоборот — сначала маршрутизится, потом уже NATируется.
Тут дело в том, что когда на WAN-интерфейс приходит пакет адресованный в LAN, а не на IP-адрес WAN-интерфейса, то так как такой записи нет в таблице трансляций NAT, то он маршрутизируется в соответствии с таблицей маршрутизации.
0)Трафик снимал SPAN-сессией между cisco2950 и cisco2821.
1)Факт не реклама. Понятия не имею почему, но часто сталкивался с тем, что широковещательные пакеты шлются именно с выставленным 8-мым битом, а не на FF:FF:FF:FF:FF:FF.
Собственно поэтому и имел заблуждение на счёт того, что это и есть броадкаст.
Чистый броадкаст как-то редко встречается в природе =)
Ну разве что ARP.
2)Тем не менее с конфигом по умолчанию коммутатор шлёт BPDU на все порты без разбору кто там подключен и это правильно, ибо коммутатор не может знать, что будет подключено к порту(хост или другой свитч), а петли обнаруживать надо в любом случае.
Ну wikimedia первый раз вижу, так что за достоверный источник не приму.
Тогда уж велкам ту CiscoWiki
Ну чтож, прийдётся согласиться.
Если стоит 8-ой бит первого октета — то это MULTICAST
Если стоят все F — то это BROADCAST
НО!
С точки зрения коммутатора — в чём разница?
И то и другое получат все в данном L2-cегменте.
Я частенько ковыряюсь в дампах сети и просто держу в голове утверждение — «если у пакета есть 8-ой бит — значит это BROADCAST».
В сущности при разборе дампов главное понимать как раз то, кто этот пакет получит. А получат его как раз все участники текущего L2-домена, так что нельзя сказать, что моё утверждение ложно.
Хотя если коммутатор поддерживает igmp, то тогда пакет получат только участники рассылки.
Впрочем в большинстве случаев если вы получили пакет с 8-мым битом, то скорее всего его получили также все в этой сети.
Таким образом рассылается например STP BPDU(только что проверил — DMAC=01:80...), который явно должен рассылаться броадкастом и всем, а не мультикастом и выборочно.
VLSM — предполагает дробление одной классовой сети на множество подсетей более узких (речь идёт именно про подсети — SUBNET MASK), но с переменной длинной префикса (собственно в этом и заключается VARIBLE LENGTH). Да, RIPv2 может передать информацию о нескольких подсетях входящих в одну сеть с маской более узкой, чем классовая и даже c разной длиной префикса.
Но! В RIP (независимо от версии) вы не можете указать в команде network маску, а выполнение комнады «network 10.10.10.0», например, в конфиге превратится в 10.0.0.0 фактически с маской /8. RIP умеет охватывать только всю классовую сеть целиком. Конечно можно использовать passive-interface и distribute list'ы, но это уже костыли.
В случае если у вас на роутере все интерфейсы из диапазона 10.0.0.0/8, и вам нужно через один из них поднять RIP с соседом, но не сообщать ему о своих остальных сетях, а только принимать маршруты от него, то эта задача решается только с помощью distribute-list'ов. В OSPF, EIGRP или BGP этот вопрос закрывается командой network c узкой маской (как правило /30 на транзитных сетях).
Я наверное погорячился на счёт того что RIPv2 совсем не умеет VLSM. С точки зрения передачи информации о сетях — конечно умеет, но вот с точки зрения настроек самого протокола маршрутизации — нет.
Не совсем верно указано.
Classfull — RIPv1 и IGRP — С этим согласен.
Но! Classless, (он же CIDR) это только RIPv2.
А вот BGP, OSPF, EIGRP и IS-IS это уже не просто CIDR, а ещё и VLSM.
Принципиальная разница в том, что RIPv2 не умеет VLSM, поэтому некорректно ставить его в один ряд с OSPF и прочими.
А вообще 30 Мбит/c днём и 100 Мбит/c ночью за 290р. большинству хватает.
Я сам когда выбирал — неделю ковырял популярные сервисы на предмет основных возможностей, а потом почти месяц пользовался тремя сразу. Некоторые нюансы выявил ещё спустя год использования.
Cам остановился на easyfinance.ru
Уже почти два года ей пользуюсь — мои задачи решает полностью.
Так что не проходите мимо.
Кончено можно сказать, что тех.дир должен задавать только вектор, а конкретные технические реализации — дело рук админов… но! откуда бы ему тогда узнать этот вектор? Он же, например, не сопровождает ЦОД и понятия не имеет как там обстоят дела с дисковой производительностью, а админы при «пинково-векторном» подходе управления сами ему о надвигающихся проблемах не скажут, потому что в ответ получат только пинок вида «с производительностью дисков надо что-то делать. Не знаю что, но идите делайте».
Одним из лучших способов управления квалифицированной группой людей является «самоуправление». Тех.дир не может всё знать и за всех всё решать да ещё ходить контролировать каждого, что бы он это выполнял.
Должна присутствовать здоровая самоорганизация и инициативность исполнителей, которые сами на поле боя хорошо видят какие задачи требуют решения и подходят к тех.диру с конкретными предложениями, предварительно их проработав по своей инициативе, а не ждут раздачи пинков от руководства что бы начать что-то делать.
Вот что бы к этому прийти нужна мотивация, и уж явно не кнутом, а пряником.
ИМХО.
Готового рецепта конечно нет, ну я на это и не рассчитывал, зато есть над чем подумать.
Спасибо!
Будем считать что с нематериальной мотивацией всё в порядке и к ИТ-отделу в компании не относятся как к транжирам, которые только тратят деньги и ничего не зарабатывают.
Но при этом возникает другая проблема — у админов нет никакого стимула работать с огоньком — а зачем, если кроме них и их прямого руководства никто не в состоянии оценить новый отказоустойчивый кластер или работу SAN-сети, зато если в процессе внедрения этих новшеств они пару раз роняли сетку или ЦОД, то матом их не крыл только ленивый?
За отсутствием внешних стимулов развитие ИТ-инфраструктуры становится обыкновенной рутиной, за которую ещё и по голове можно получить. И когда начальный щенячий драйв со временем проходит и возникает чёткое жизненное понимание того, что «если где-то почесать -то там и упадёт», «не трогай то, что работает» и «не ошибается только тот кто ничего не делает» то желание что-то делать, кроме текучки, отсыхает напрочь. Вот тут и встаёт вопрос — как в такой среде стимулировать дальнейшее развитие?
И при этом придерживаться золотого врачебного правила «не навреди» и не вводить штрафы за каждый сбой — это точно отобьёт желание что-то делать, но и не премировать ввод в эксплуатацию всяких бессмысленных свистелок-перделок, от которых реальному бизнесу ни жарко ни холодно.
Проблема мотивации ИТ-отдела на мой взгляд кроется в вопросе — «Как завязать обеспечение реальных показателей отказоустойчивости сервиса и желание развивать собственный сервис (при некотором округлении вещи друг-друга взаимоисключающее, имхо) с денежной премией исполнителей?».
Из того что хотелось бы услышать в Вашем исполнении — «Система мотивации админов», ну или «Система мотивации для внутреннего отдела ИТ».
Работа админов она как и ТП в софтверной компании — обладает большим значением неопределённости, а поэтому всё регламентировать и предопределить сроки зачастую невозможно, отсюда и проблема мотивации.
В целом текст этой статьи даёт полезные советы и в рамках озвученных мной тем тоже, но вдруг Вы сможете предложить более развёрнутый ответ.
Но я имел опыт с Solaris x86, который НЕ реагировал на физическое падение линка и фактически работал только в probe-mode.
Т.е. Соляра в упор не видела, что у неё упал интерфейс, при этом если ей было кого пинговать, то методом PROBE она могла обнаружить падения интерфейса.
Так что режим probe-mode (без link) в природе тоже встречается!
Хотя это скорее глюк, чем фича.
=)
Во первых на счёт того, кому верить.
Курил много инфы по сабжу, и форумы и книжки для подготовки на SCNA, но самым информативным и близким к истине оказался «man mpath.d».
(Истину проверял снятием снифов посредством Wireshark и snoop)
А ещё очень полезной оказалась эта статья
Во вторых на счёт двух режимов я с вами не очень-то согласен. Вы указываете на обоих интерфейсах группу, а дальше есть варианты и их далеко не два!
Вы задаёте параметр -failover и соответственно интерфейсы работают в режиме ACTIVE-STANDBY. Но если этот параметр не задавать, то все интерфейсы группы будут работать в режиме ACTIVE-ACTIVE, о чём вы вообще не упоминаете (а оно работает — проверено!).
Вы задаёте параметр DEPRICATED — на самом деле этот параметр означает, что IP адрес данного интерфейса будет использоваться для сбора проб в данной группе. Это даёт много вариантов настройки для всевозможных ситуаций. Например для выявления отказа коммутатора можно использовать один интерфейс, а для передачи трафика другой. Или например можно включить интерфейс в группу, но не задавать ему DEPRICATED адрес, тогда он будет участвовать в группе, но пробы с него делаться не будут, ну и т.д.
В файле /etc/default/mpathd тоже есть чего поправить, а вы его даже не упомянули.
Например там можно указать время FAILURE_DETECTION. Там же можно указать FAILBACK — т.е. делать ли его вообще. Время FAILBACK'a равно двойному значению FAILURE_DETECTION.
А ещё там можно включить сбор проб для ВСЕХ интерфейсов, а не только для тех, которые участвуют в группах, а трафиком управлять уже за счёт таблицы маршрутизации.
Вообщем, назвался груздем — полезай в кузов. Взялись писать «статью на хабр», можно было бы уж уделить внимание теории и написать человеческий обзор IPMP, а не пионэрский очерк в две строчки «самого интересного» (и нихрена непонятного).
Велкоме ту хабр!
=)
Чуть выше речь шла про «участие проца в формировании PS».
Соответственно перечислять все возможные варианты причин, по которым может не стартовать MB я вообщем-то и не пытался.
А вообще это топик полугодичной давности (сентябрь 2011) — писать сюда это уже некрофилизм, ИМХО. Более того я думал, что топики которым более 3-х дней и комментировать-то нельзя!
а как же dst port в случае NAT overload?
;)
Классический Domain Based NAT несколько ограничен в своих возможностях и требует однозначного указания inside\outside, а вот более современная реализация NVI (NAT Virtual Interface) даёт возможность лучше понять этот алгоритм.
При использовании NVI мы просто указываем на интерфейсе «ip nat enable» — т.е. просто включаем на этом интерфейсе проверку NAT. Все пакеты проходящие через этот интерфейс будут проверяться на наличие каких-либо NAT-трансляций.
Т.е. пакет идёт через 3 стадии:
1.входящий интерфейс
2.маршрутизация
3.исходящий интерфейс
В 1 и 3 пунктах ВОЗМОЖНА проверка правил NAT. Соответственно при классическом NAT проверка делается на обоих интерфейсах, но подмена происходит только на outside интерфейсе, т.е. только один раз.
Поэтому для пакета идущего из inside в outside подмена осуществляется ПОСЛЕ маршрутизации.
А для пакета идущего из outside в inside подмена осуществляется ДО маршрутизации.
Прочитайте ещё раз мой коммент выше внимательно.
Для входящего пакета — сначала NAT, потом маршрутизация.
Для исходящего пакета — сначала маршрутизация, потом NAT
см. — NAT order operation
Для входящего в роутер пакета NAT обрабатывается раньше, чем маршрутизация, а для исходящего наоборот — сначала маршрутизится, потом уже NATируется.
Тут дело в том, что когда на WAN-интерфейс приходит пакет адресованный в LAN, а не на IP-адрес WAN-интерфейса, то так как такой записи нет в таблице трансляций NAT, то он маршрутизируется в соответствии с таблицей маршрутизации.
1)Факт не реклама. Понятия не имею почему, но часто сталкивался с тем, что широковещательные пакеты шлются именно с выставленным 8-мым битом, а не на FF:FF:FF:FF:FF:FF.
Собственно поэтому и имел заблуждение на счёт того, что это и есть броадкаст.
Чистый броадкаст как-то редко встречается в природе =)
Ну разве что ARP.
2)Тем не менее с конфигом по умолчанию коммутатор шлёт BPDU на все порты без разбору кто там подключен и это правильно, ибо коммутатор не может знать, что будет подключено к порту(хост или другой свитч), а петли обнаруживать надо в любом случае.
Тогда уж велкам ту CiscoWiki
Ну чтож, прийдётся согласиться.
Если стоит 8-ой бит первого октета — то это MULTICAST
Если стоят все F — то это BROADCAST
НО!
С точки зрения коммутатора — в чём разница?
И то и другое получат все в данном L2-cегменте.
Я частенько ковыряюсь в дампах сети и просто держу в голове утверждение — «если у пакета есть 8-ой бит — значит это BROADCAST».
В сущности при разборе дампов главное понимать как раз то, кто этот пакет получит. А получат его как раз все участники текущего L2-домена, так что нельзя сказать, что моё утверждение ложно.
Хотя если коммутатор поддерживает igmp, то тогда пакет получат только участники рассылки.
Впрочем в большинстве случаев если вы получили пакет с 8-мым битом, то скорее всего его получили также все в этой сети.
Таким образом рассылается например STP BPDU(только что проверил — DMAC=01:80...), который явно должен рассылаться броадкастом и всем, а не мультикастом и выборочно.
MAC-адреса работают на втором уровне. Установка 8-го бита в первом октете MAC-адреса в поле DMAC — это BROADCAST.
В противном случае приведите мне пример отличия broadcast от multicast выраженные на втором уровне в MAC-адресе.