return

Ответ к задаче №6.2

29 октября 2012, 20:09

Задача 6.2
Варианты решения:
На маршрутизаторе в Хабаровске:
а) увеличить стоимость интерфейса, который ведет к Владивостоку, для OSPF (ухудшается маршрут, за счет большей суммарной стоимости пути):

khbr-amur-gw1(config)# int f1/1
khbr-amur-gw1(config-if)# ip ospf cost 5

По умолчанию значение стоимости было 1.
или
б) уменьшить величину пропускной способности канала (стоимость интерфейса для OSPF автоматически увеличится) на интерфейсе, который ведет к Владивостоку:

khbr-amur-gw1(config)# int f1/1
khbr-amur-gw1(config-if)# bandwidth 50000

По умолчанию пропускная способность была 100000Kbit.
Примечание: При изменении стоимости или пропускной способности, надо обратить внимание на то, что менять надо стоимость или пропускную способность исходящего интерфейса по пути к получателю.

like 0 views 16533 message 32

32 коментария

  • Получилось изменить маршут изменив приоритет
    ip ospf priority 0-255

    2 августа 2017, 19:20
  • во Владивостоке тоже в таком случае нужно вносить изменения в стоимость линков, иначе со стороны Москвы асимметрия получится.

    16 февраля 2016, 16:17
  • Делаю в GNS. Увеличение стоимости не сработало вообще.
    Уменьшать не пробовал, просто использовал ip ospf cost 100 на маршруте в сторону Владика.

    5 мая 2014, 09:58
  • А почему не сработало увеличение пропускной способности в сторону Красноярска?
    Какой вариант предпочтительнее?

    2 августа 2013, 15:57
  • Поясните немного поподробнее по пункту (а).

    Как распределяются стоимости интерфейсов? На xgu написано, что стоимость находится по формуле:
    cost = reference bandwidth / link bandwidth
    Но ничего не говорится, откуда берётся reference bandwidth. Это какая-то глобальная величина для всех маршрутизаторов?

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

    30 июня 2013, 11:55
  • Привет, Александр из Украины. Пишет тебе Марат из заснеженной Сибири.

    На эту тему Дима недавно написал отличную статью: habrahabr.ru/post/174167/
    В комментах в том числе раскрыта тема.

    3 апреля 2013, 18:48
  • Именно этой командой в режиме конфигурации интерфейса настраивается приоритет маршрутизатора для выбора DR/BDR.
    (config-if)#ip ospf priority <1-255>

    14 сентября 2017, 04:37
  • Взято из xgu.ru:
    «Для того чтобы выбрать для сети DR и BDR, маршрутизаторы просматривают значение приоритета в hello-сообщениях и следуют таким условиям для того чтобы определить какой маршрутизатор выбрать:
    Маршрутизатор с наивысшим значением приоритета становится DR.
    Маршрутизатор со вторым наивысшим значением приоритета становится BDR.»
    Посмотреть приоритет порта можно командой sh ip ospf int fa1/0 (№ порта взят из моей лабы)
    Насколько я понимаю этим способом неправильно устанавливать приоритет маршрута, но работает?
    Хотелось бы увидеть комментарий админов про этот способ.

    13 сентября 2017, 15:20
  • Александр Барашкин

    Да, Илья говорит совершенно верно. Нужно назначать одинаковую стоимость интерфейса на обоих связанных между собой маршрутизаторах. Иначе по одну сторону от линка в маршрутизаторах будут дефолтовая метрика (сумма стоимости интерфейсов), а по другую сторону назначенная (сумма стоимости дефолтовых интерфейсов без последнего + назначенная стоимость последнего). И в результате может возникнуть «ассиметрия», когда пакеты будут ходить по разным маршрутам в одну и в другую сторону. Из Москвы — через Владивосток до Хабаровска, а из Хабаровска через Красноярск в Москву. У меня в лабе именно так и получилось.

    22 сентября 2016, 21:07
  • Спасибо за ответ

    15 мая 2016, 00:19
  • Этот параметр только для протоколов маршрутизации. На реальную скорость интерфейса это не влияет.

    13 мая 2016, 18:42
  • Такой вопрос, а при уменьшении Вandwidth разве не уменьшится скорость канала?
    Т.е. выставляя bandwidth 50000 — мы не получим канал 50мб вместо 100?

    13 мая 2016, 14:06
  • P.S. Уменьшение полосы пропускания сработало.

    5 мая 2014, 10:02
  • Что значит стоимость или приоритет? 🙂 полосу пропускания, возможно, имели ввиду? Обычно меняют стоимость.

    4 августа 2013, 04:40
  • Да, в PT. Попробую повторить в GNS3.
    Скажите, а какой способ лучше (стоимость или приоритет менять)?

    3 августа 2013, 20:00
  • В РТ делете лабу? Там, насколько мне известно бывает с этим косяк.

    3 августа 2013, 13:29
  • P.S. странно, но уменьшение тоже как то не сработало, во всяком случае — сразу. А увеличение стоимости — моментально…

    2 августа 2013, 16:00
  • По умолчанию для OSPF reference badwidth 100Mb. Его можно изменить при желании.
    При show ip route вы можете видеть такую запись: [110/2]. Первая — это административная дистанция, вторая — как раз метрика.

    30 июня 2013, 18:37
  • Ну собственно, да, я с имо и сижу. Перешёл на него, когда meebo продался.

    354151335

    5 апреля 2013, 17:13
  • Смотри как тебе удобнее.
    Чем обычно пользуешься.
    Лично я все рабочее время в аське/скайпе.
    Кстати для скайпа (особенно для текста) хорошо сервис imo.im подходит, не нужно ставить тяжелый и сомнительный клиент от майкрософта.

    Сегодня продолжилась эпопея с киевскими провайдерами)
    Основной канал традиционно залег на несколько часов, это уже как-то в норму входить начало.
    После того как поднялся я поставил промежуточный управляемый длинк, как и ожидалось ничего интересного кроме широковещательного трафика провайдера я так и не увидел.
    Чисто по приколу поменял ip на увиденный в arp запросах и попал в чью-то сеть. Трафик Active Directory вроде даже промелькнул.
    Глубже копать не стал, а то еще отключат за взлом)
    Вот как-то так.

    5 апреля 2013, 17:10
  • Может, нам перейти уже в более быстрые сообщения? Аська, например.
    Надо будет почитать, что за команды)

    5 апреля 2013, 16:58
  • За окном подозрительно густой туман, а я возвращаюсь к теме траблшутинга)

    Есть такая «замечательная» команда IOS

    auto secure

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

    Но несколько интересных вещей вроде

    service tcp-keepalives-in
    service tcp-keepalives-out

    я оттуда почерпнул и применил на всех маршрутизаторах.

    5 апреля 2013, 10:22
  • Да, ладно. Это у тебя неплохая практика)
    Я с цисками только год работаю.
    А до этого 5 лет только с юниксами.

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

    4 апреля 2013, 10:24
  • Наши суровые монтажники даже в сильный снег муфты разваривают)
    У вас там наверное еще более экстримальные условия.

    4 апреля 2013, 19:46
  • Флюк — это охеренный набор для всего, что связано с витухой. Обжимники, ножи, ножницы, тестер)) Если бы я был монтажником, я бы себе его купил)

    4 апреля 2013, 19:40
  • От 200$ и выше.
    Но вещь конечно хорошая.
    Фирма покупать не станет)

    Так что глюки ловим дальше на канальном и сетевом уровнях.

    4 апреля 2013, 19:38
  • Да, было дело немного. Выискивали кабели среди сотни других, находили места обрыва. Флюк нетворкс. Слышал, наверно, такое? 🙂

    Ну и пару раз искали где оптика плохо сварена.

    4 апреля 2013, 15:58
  • Вообщем, в последнее время больше всего не хватает каких-нибудь анализаторов физической среды (как меди так и оптоволокна).

    Вот у NOC они есть, или хотя бы должны быть)
    Ты чем то подобным не пользовался?

    4 апреля 2013, 11:32
  • А я смотрю, у тебя неплохая практика в траблшутинге)

    Эти MTU/MSS/MFL — вечная головная боль, особенно когда добавляются всякие L2TP, MPLS, L2VPN.

    4 апреля 2013, 05:20
  • тогда интересно зачем вообще такая возможность.

    Хотя однажды следуя «best practice» и отключив ip unreachables я получил несколько часов траблшутинга.
    Почти все работало, но одна программа не устанавливала соединение.
    Только после просмотра трафика tcpdump стало понятно, что установлен флаг DF и path mtu discovery не работает.
    Но это уже другая история…

    3 апреля 2013, 22:37
  • Угу. Верно.
    Плюс он не убирается из таблицы маршрутизации в случае падения линка.
    Плюс рекурсивные запросы и так не делаются — есть же FIB/CEF.

    3 апреля 2013, 19:26
  • IOS линейки 15.2M дело хорошее, но пока не попадалось.
    Пока все только 12.

    Выходит что явное указание интерфейса приводит к тому что не нужно выполнять рекурсивные запросы к таблице маршрутизации.
    Но и в этом случае будут apr запросы, что не совсем хорошо.
    Так же еще некоторые нюансы возникают.
    Значит лучше интерфейс не указывать вовсе.

    3 апреля 2013, 19:22

Ещё статьи

Анонс подкаста. Выпуск 28
22-го июня — это будет понедельник — в 19:00 по МСК мы будем транслировать 28-й выпуск подкаста. В гостях Владислав Канайкин — мой коллега, инженер Хуавэй. Основная тема — STP ...
like 0 4686 12
14 июня 2015
Анонс подкаста. Выпуск 26
Друзья, в силу колоссальной загруженности ведущих и гостей подкаста, в этот раз мы делаем эфир прямо сегодня, 25 числа. В 26 выпуске мы продолжаем тему SDN и на этот раз ...
like 0 3154 0
25 апреля 2015
Сети для самых маленьких. Микровыпуск №2. Обзор эмуляторов/симуляторов Cisco
Друзья, мы рады сообщить о том, что мы начинаем публиковать статьи наших читателей. Сегодня материал от гостя нашего подкаста Александра aka Sinister.============================Специально для проекта linkmeup Существует достаточно большое количество симуляторов ...
like 91 119758 21
7 октября 2013