В своё время задавался этим вопросом (на 5 курсе), спросил у преподавателя одного из учебных центров Нерезиновой по Linux`у.
Он сказал, брось эти мысли, никому эта учёная степень в IT нафиг не нужна. Что к нему на собеседования часто приходят кандидаты и доктора наук, которые, как выясняется при беглом опросе, обладают настолько устаревшими знаниями, что брать их на желаемые ими должности — самоубийство.
Лучше самообразовываться и получать признание (сертификаты) вендоров в области, которая интересна.
Microsoft, Red Hat, Cisco, всех не перечесть. И знания будут как минимум актуальны (а, следовательно, и полезны).
Почитайте требования к IT-шникам на каком-нибудь hh. Ни разу не видел там «к.т.н. или д.т.н.», а вот «не ниже CCIE» сплошь и рядом.
Думаю, надо сделать уточнение для первого архива, что пароль — с большой буквы и с точкой в конце.
В документе предложение написано с маленькой буквы, так не прокатывает.
Ни Backup interface, ни bridge group не дадут эффекта MLAG, работу обоих портов одновременно.
Первый способ отключает backup интерфейс, пока жив primary, автоматически.
Второй способ включает на обоих портах STP, так что один порт заблокируется этим протоколом.
Прочитал сначала «Так говорил Геббельс», а потом «Манипуляцию сознанием» Кара-Мурзы (или вторую часть, не помню). Разницы не нашёл.
Кара-Мурза точно так же сыпет фразами, не поддающимися проверке, и уничижительными эпитетами. Типа «вот тут бы и спросить о том-то, но ангажированный жидомасон Познер, хитро прищурившись, мастерски уходит от темы».
Под весами подразумевалась длина префиксов? Тогда пардон, не понял. У меня вес как-то проассоциировался с параметром weight.
И уточните, пожалуйста, что за параметр у Juniper при меньше 20 секунд считается фладом? Время, которое проходит между потерей маршрута и анонсом этой потери соседу по BGP, или что?
А зачем, имея /23, заморачиваться с EXIST_MAP?
Ведь можно с каждой площадки отдавать /23 и свою /24. Тогда если вторая площадка отвалится, пропадёт её /24 и клиенты потекут на первую через /23 маршрут.
Алиса может все 4 раза написать «Боб». Они ведь не будут напряжённо расшифровывать все остальные строчки, чтобы это исключить.
А чтобы получились разные шифрованные тексты, немного варьировать написание. «Боб», «Бобби», «Роберт», «Конечно, Боб!»
Меня удивила фраза «про bandwidth-percent для control plane траффика»
Что именно там говорится? Я могу понять политики CoPP для ограничения ICMP, например. Но bandwidth-percent?
Хочу заметить, что часто значение MED фильтруется, поэтому метод с его изменением не является надёжным.
Лучшим вариантом в данном случае было бы добавление AS (as-prepend) к параметру AS_PATH, тогда будет точно выбран путь с более коротким значением.
Заменяем set metric 30 на set as-path prepend 65500 65500 65500 на роутере, канал к которому хотим сделать резервным для входящих подключений.
На основном можно ничего не настраивать.
Хей-хо, товарищи.
Я тут наткнулся на решение схожей задачи на Cisco (выпустить людей, находящихся в VRF, в интернет), и, думаю, оно нам может немного помочь.
На Cisco это решается так:
1. Создаём маршрут по умолчанию для VRFа, который будет брать next-hop из глобальной таблицы адресов. Это указывается словом global в конце команды ip route…
2. Включаем NAT обычным образом, указав в конце команды ip nat inside… ключевые слова VRF xxx. Тогда (ход конём!) внутренние адреса (inside local) берутся из VRF xxx, а интерфейс, куда будет натиться (inside global) берётся из глобальной таблицы.
Когда трафик возвращается назад, NAT отрабатывает раньше роутинга и помещает пакеты в нужный интерфейс (и VRF соответственно).
Так что рискну предположить, для полного понимания работы системы, описанной в посте, не хватает конфигурации NAT.
Пепельняк в своей книге тоже говорит, что худший load выбирается…
Да всем лень тестить, и авторам в том числе. Зачем тестить то, что использоваться точно не будет? :)
Он сказал, брось эти мысли, никому эта учёная степень в IT нафиг не нужна. Что к нему на собеседования часто приходят кандидаты и доктора наук, которые, как выясняется при беглом опросе, обладают настолько устаревшими знаниями, что брать их на желаемые ими должности — самоубийство.
Лучше самообразовываться и получать признание (сертификаты) вендоров в области, которая интересна.
Microsoft, Red Hat, Cisco, всех не перечесть. И знания будут как минимум актуальны (а, следовательно, и полезны).
Почитайте требования к IT-шникам на каком-нибудь hh. Ни разу не видел там «к.т.н. или д.т.н.», а вот «не ниже CCIE» сплошь и рядом.
В документе предложение написано с маленькой буквы, так не прокатывает.
Можно сделать bpdufilter с двух сторон и поиметь в результате петлю.
Первый способ отключает backup интерфейс, пока жив primary, автоматически.
Второй способ включает на обоих портах STP, так что один порт заблокируется этим протоколом.
Кара-Мурза точно так же сыпет фразами, не поддающимися проверке, и уничижительными эпитетами. Типа «вот тут бы и спросить о том-то, но ангажированный жидомасон Познер, хитро прищурившись, мастерски уходит от темы».
Тоже неплохо.
И уточните, пожалуйста, что за параметр у Juniper при меньше 20 секунд считается фладом? Время, которое проходит между потерей маршрута и анонсом этой потери соседу по BGP, или что?
Ведь можно с каждой площадки отдавать /23 и свою /24. Тогда если вторая площадка отвалится, пропадёт её /24 и клиенты потекут на первую через /23 маршрут.
А чтобы получились разные шифрованные тексты, немного варьировать написание. «Боб», «Бобби», «Роберт», «Конечно, Боб!»
Что именно там говорится? Я могу понять политики CoPP для ограничения ICMP, например. Но bandwidth-percent?
Лучшим вариантом в данном случае было бы добавление AS (as-prepend) к параметру AS_PATH, тогда будет точно выбран путь с более коротким значением.
Заменяем set metric 30 на set as-path prepend 65500 65500 65500 на роутере, канал к которому хотим сделать резервным для входящих подключений.
На основном можно ничего не настраивать.
Я тут наткнулся на решение схожей задачи на Cisco (выпустить людей, находящихся в VRF, в интернет), и, думаю, оно нам может немного помочь.
На Cisco это решается так:
1. Создаём маршрут по умолчанию для VRFа, который будет брать next-hop из глобальной таблицы адресов. Это указывается словом global в конце команды ip route…
2. Включаем NAT обычным образом, указав в конце команды ip nat inside… ключевые слова VRF xxx. Тогда (ход конём!) внутренние адреса (inside local) берутся из VRF xxx, а интерфейс, куда будет натиться (inside global) берётся из глобальной таблицы.
Когда трафик возвращается назад, NAT отрабатывает раньше роутинга и помещает пакеты в нужный интерфейс (и VRF соответственно).
Так что рискну предположить, для полного понимания работы системы, описанной в посте, не хватает конфигурации NAT.
Да всем лень тестить, и авторам в том числе. Зачем тестить то, что использоваться точно не будет? :)