Павел Rel1cto

Алиса может все 4 раза написать «Боб». Они ведь не будут напряжённо расшифровывать все остальные строчки, чтобы это исключить.
А чтобы получились разные шифрованные тексты, немного варьировать написание. «Боб», «Бобби», «Роберт», «Конечно, Боб!»

Напомнило, как на мамах Dead Space 2 тестировали.

Меня удивила фраза «про bandwidth-percent для control plane траффика»
Что именно там говорится? Я могу понять политики CoPP для ограничения ICMP, например. Но bandwidth-percent?

Как bandwidth-percent связан с control plane? Это ж процент он линка, который разрешено использовать EIGRP для своего трафика.

Хочу заметить, что часто значение 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 выбирается…
Да всем лень тестить, и авторам в том числе. Зачем тестить то, что использоваться точно не будет? :)

• Load (K2) – Cumulative load of all outgoing interfaces in the path, given as a fraction of 255

Источник: www.routeralley.com/ra/docs/eigrp.pdf

Почему выкинуть? Ведь максимума достигла не композитная метрика, а всего лишь одно из её слагаемых.

Reliability is the worst reliability for any interface in the path. Load is cumulative.
Что, в принципе, логично, поскольку 100% надёжность — уже 255, больше некуда суммировать. С загрузкой — наоборот.

Если мне не изменяет память, EIGRP передаёт векторную метрику при изменении BW или delay. При добавлении в расчёт reliability и load это поведение не меняется.
То есть EIGRP будет использовать те reliability и load, которые получил когда-то давно, они могут сто раз измениться где-то там в сети, но никто об этом не узнает и метрика не изменится.
То есть никаких «штормов» метрики не будет. Будет просто её расчёт исходя из ранее запомненных, неактуальных, уже не нужных никому значений.

Расскажите, пожалуйста, об основных преимуществах оборудования Extreme Networks в сравнении с конкурентами.

Они это мотивировали тем, что для Wasteland весь сюжет, мир и т.д. уже написаны и проработаны, осталось реализовать. Так что теперь либо разгонять штат писателей, либо дать им новую работу. Вот как раз Торментом и займутся.

Нет ли при таком раскладе мотивации у инженера затягивать работу? Чем больше часов займёт — тем больше за неё заплатят.

Ну и другие аутсорсеры имеют мало опыта с продуктами знаменитого софтверного гиганта.

Неужели в городе N превалируют *nix-администраторы? о_О
Мне казалось, обычно бывает наоборот.

Если бы мы кто-то хотел прочитать маркетинговый материал Хуавея, он бы легко это сделал и в другом месте.
Здесь нужны интересные статьи. Например, «мы внедряли, выбрали такое-то железо по такой-то причине, с такими-то технологиями, столкнулись с такими-то проблемами и выкрутились вот так».
А «покупайте наших слонов» на хабре ни к чему.

Интересно, рассказывайте.

Цитата с форума Джунипера:

...per default router would load balance per prefix. So if you have 10 prefixes learned over two equal-cost pathes then traffic destined to 5 out of 10 prefixes would be forwarded over one path and another 5 would go over other path.

Now if you define «per-packet» it will load-balance per flow. L4 information is taken in account in this case. The name «per-packet» is highly misleading but it has historical reasons. No reordering will ever take place!

Я этот кусок понял так:

Если есть несколько маршрутов до цели, берётся набор next-hop`ов, хешируется и выбирается 1. Таким образом, балансировки нет.
Если включить load-balance per-packet, то:
1. На Internet Processor ASIC включается именно per packet балансировка.
2. На Internet Processor II ASIC включается балансировка per flow.

О, классная pdfка, не натыкался на неё там.
Спасибо!

Разумеется, как и в 100500 других источников, которые можно нагуглить. Только вот почему — не написано.

А, кстати, почему зона 0 должна быть непрерывной? В RFC про это не сказано.
Рискну предположить, что ABR отбрасывает LSA 3 типа и выше, если не имеет LSA 1 про Advertising Router.

Насчёт условия считания себя ABR в RFC написано, что просто должен принадлежать нескольким зонам. Хотя в Cisco надпись «It is an area border router» не появится, пока не дашь ему ещё и интерфейс в 0 зоне.

Про Микротик — подозрительно похоже на proxy arp.

Damn, опередили)

Реквестируем полезную статью на тему.

А этого типа распознает?

Это не статья нужна, а целая книга. Причём по каждому пункту. :)
Если вкратце, EIGRP, OSPF и BGP — протоколы динамической маршрутизации. Первый — Cisco-проприетарный, частичному открытию его спецификаций и посвящён данный пост.
SDN — технология вынесения всей логики работы сети в отдельное контролирующее устройство, эдакий супермозг. Все о ней говорят, очень модная, но рабочих реализаций пока не видно. Особенно учитывая, что каждый вендор вкладывает в слова «SDN» какой-то свой смысл.
MPLS — технология коммутации пакетов c помощью меток. Используется, в основном, у провайдеров.

Первое — не правда.
У OSPF апдейты тоже по событиям. Периодический LSA flood раз в полчаса можно отключить.

Warhammer: Dark Omen

Ответ не пришёл. В диалогах пусто.

Полагаю, под контролем как раз подразумевались политики per-tunnel QoS, ACLы и т.д.
В итоге, они просто сделали VTI IPSec с хабом и всё бегает через него.

Года полтора назад на, скажем, собеседовании мне был задан вопрос: «У нас сеть с более 50 филиалов. Как ты думаешь, почему мы отказались от использования DMVPN».
Поскольку ни тогда (ни сейчас) с технологией я близко знаком не был, ответа, конечно, не дал. Но поинтересовался правильным ответом.
«Потому что с DMVPN я никак не могу контролировать/ограничивать трафик между споками.»

Прокомментируйте, пожалуйста.

Во-первых, эта статья была про High Level Design сетей кампуса, а не о построении ЦОД, Это уже другая ветка и Вы предлагаете мне вместо автора написать Вам ответ на эти вопросы?

А было бы очень интересно почитать, честное слово. Больше статей по сетям, хороших и разных!

… они не думали о том, что нужно объяснить Вам разницу решений Cisco, Juniper & HP. Не думаю, что это было бы корректно в статье любого вендора вообще.

А можно ли где-нибудь найти подобное сравнение? Или единственный способ — самому штудировать вендорские проспекты? Так там ведь сплошной маркетинг и bullshit bingo, фиг разберёт, кто лучше и чем.

/offtop: Ответьте, пожалуйста, на личное сообщение. :)

Причина уровня агрегации у звезды проста: на уровне агрегации цена за порт гораздо ниже, чем на уровне ядра у звезды,, а также для более гибкого применения различных политик.

Мне всегда казалось, что причина — разные задачи двух уровней. На аггрегации у нас применение политик, QoS, фильтрация. В ядре — никаких политик, просто высокоскоростная молотилка трафика (перегрузка недопустима).
Не ясно, чем кольцо тут лучше. Тем, что всё сразу в ядро втыкается? А оно выдержит? Да и в звезде тогда можно так же точно воткнуть.

Про сходимость выше JDima уже написал.
Если у вас L2 в доступе, то мне ещё интересно, как броадкасты со всех VLANов у вас по всему кольцу туда-сюда бегают, и какую долю в трафике (фактически, отъём полосы пропускания) они составляют.

Но у железных дорог Франции просто не было выбора после того как TR «умер».

Отличный аргумент. Поставили «костыль», чтобы использовать уже имеющуюся инфраструктуру, и теперь это преподносится как best practices.

а работать по топологии кольца на коммутаторах с распределением виртуальных сетей по всему кампусу без использования сложных и дорогостоящих технологий типа MPLS/VPLS могут только ограниченное число производителей – HP, Huawei, Extreme.

Это за счёт поддержки каких технологий, подскажите. Что не умеют C/J?

Он уже сделал.

beaglenetworks.net/post/42879624799/ipv6-version

Да, мысль про ASBR тоже пришла в голову. :)

А почему не может быть в разных зонах роутеров с одинаковыми router-id?
Если зоны не смежные, то, мне кажется, проблем не будет. Главное — чтобы никто не получал одновременно LSA с обоих.

Операция «Буря в пустыне» 1991 года показала всему миру, как мгновенно через активизацию закладок перестали работать все без исключения средства ПВО Ирака, только что закупленные во Франции.

Вы всё ещё думаете, что опасность надумана?

Про фейловер в течение пары минут не понял, если честно. Что имелось ввиду?

А что это даст? Где гарантия, что маршрут к клиенту во 2 случае будет лучше через ISP2, чем через ISP1?
Самый простой вариант — 2 ip-адреса на сервере. Один интерфейс шлюза (к ISP1) натит на первый адрес веб-сервера, а второй интерфейс (к ISP2) — на второй адрес. И policy-based routing направляет траффик с source 2 адресом веб-сервера на интерфейс к ISP2.
Про full view и его необходимость (вернее, как раз отсутствие необходимости) отлично расписано тут

Не понял, а как обратный пакет от веб-сервера будет отправлен в интерфейс ISP2? На основании чего?
Шлюзу прилетает пакет от веб-сервера. Веб-сервер находится в дефолтном VRF. Почему он вдруг отправит его в другой VRF?

Спасибо за статью, с нетерпением жду продолжения.

Скажите, а если бы мы настраивали не firewall, а роутер, что бы изменилось в настройке?