Ответ к задаче №6.2
0
21293
32
Задача 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.
Примечание: При изменении стоимости или пропускной способности, надо обратить внимание на то, что менять надо стоимость или пропускную способность исходящего интерфейса по пути к получателю.
0
21293
32
Ещё статьи
32 коментария
Получилось изменить маршут изменив приоритет
ip ospf priority 0-255
во Владивостоке тоже в таком случае нужно вносить изменения в стоимость линков, иначе со стороны Москвы асимметрия получится.
Делаю в GNS. Увеличение стоимости не сработало вообще.
Уменьшать не пробовал, просто использовал ip ospf cost 100 на маршруте в сторону Владика.
А почему не сработало увеличение пропускной способности в сторону Красноярска?
Какой вариант предпочтительнее?
Поясните немного поподробнее по пункту (а).
Как распределяются стоимости интерфейсов? На xgu написано, что стоимость находится по формуле:
cost = reference bandwidth / link bandwidth
Но ничего не говорится, откуда берётся reference bandwidth. Это какая-то глобальная величина для всех маршрутизаторов?
И можно ли заранее узнать, какую стоимость выставить, чтобы один маршрут наверняка стал хуже, чем другой? То есть можно как-то посмотреть стоимость текущего и альтернативного маршрутов?
Привет, Александр из Украины. Пишет тебе Марат из заснеженной Сибири.
На эту тему Дима недавно написал отличную статью: habrahabr.ru/post/174167/
В комментах в том числе раскрыта тема.
Именно этой командой в режиме конфигурации интерфейса настраивается приоритет маршрутизатора для выбора DR/BDR.
(config-if)#ip ospf priority <1-255>
Взято из xgu.ru:
«Для того чтобы выбрать для сети DR и BDR, маршрутизаторы просматривают значение приоритета в hello-сообщениях и следуют таким условиям для того чтобы определить какой маршрутизатор выбрать:
Маршрутизатор с наивысшим значением приоритета становится DR.
Маршрутизатор со вторым наивысшим значением приоритета становится BDR.»
Посмотреть приоритет порта можно командой sh ip ospf int fa1/0 (№ порта взят из моей лабы)
Насколько я понимаю этим способом неправильно устанавливать приоритет маршрута, но работает?
Хотелось бы увидеть комментарий админов про этот способ.
Да, Илья говорит совершенно верно. Нужно назначать одинаковую стоимость интерфейса на обоих связанных между собой маршрутизаторах. Иначе по одну сторону от линка в маршрутизаторах будут дефолтовая метрика (сумма стоимости интерфейсов), а по другую сторону назначенная (сумма стоимости дефолтовых интерфейсов без последнего + назначенная стоимость последнего). И в результате может возникнуть «ассиметрия», когда пакеты будут ходить по разным маршрутам в одну и в другую сторону. Из Москвы — через Владивосток до Хабаровска, а из Хабаровска через Красноярск в Москву. У меня в лабе именно так и получилось.
Спасибо за ответ
Этот параметр только для протоколов маршрутизации. На реальную скорость интерфейса это не влияет.
Такой вопрос, а при уменьшении Вandwidth разве не уменьшится скорость канала?
Т.е. выставляя bandwidth 50000 — мы не получим канал 50мб вместо 100?
P.S. Уменьшение полосы пропускания сработало.
Что значит стоимость или приоритет? 🙂 полосу пропускания, возможно, имели ввиду? Обычно меняют стоимость.
Да, в PT. Попробую повторить в GNS3.
Скажите, а какой способ лучше (стоимость или приоритет менять)?
В РТ делете лабу? Там, насколько мне известно бывает с этим косяк.
P.S. странно, но уменьшение тоже как то не сработало, во всяком случае — сразу. А увеличение стоимости — моментально…
По умолчанию для OSPF reference badwidth 100Mb. Его можно изменить при желании.
При show ip route вы можете видеть такую запись: [110/2]. Первая — это административная дистанция, вторая — как раз метрика.
Ну собственно, да, я с имо и сижу. Перешёл на него, когда meebo продался.
354151335
Смотри как тебе удобнее.
Чем обычно пользуешься.
Лично я все рабочее время в аське/скайпе.
Кстати для скайпа (особенно для текста) хорошо сервис imo.im подходит, не нужно ставить тяжелый и сомнительный клиент от майкрософта.
Сегодня продолжилась эпопея с киевскими провайдерами)
Основной канал традиционно залег на несколько часов, это уже как-то в норму входить начало.
После того как поднялся я поставил промежуточный управляемый длинк, как и ожидалось ничего интересного кроме широковещательного трафика провайдера я так и не увидел.
Чисто по приколу поменял ip на увиденный в arp запросах и попал в чью-то сеть. Трафик Active Directory вроде даже промелькнул.
Глубже копать не стал, а то еще отключат за взлом)
Вот как-то так.
Может, нам перейти уже в более быстрые сообщения? Аська, например.
Надо будет почитать, что за команды)
За окном подозрительно густой туман, а я возвращаюсь к теме траблшутинга)
Есть такая «замечательная» команда IOS
Применение которой гарантированно приводит к частичной неработоспособности маршрутизатора.
Это даже не команда, а скорее некий скрипт который в режиме визарда задает несколько вопросов, а потом применяет изменения.
Но несколько интересных вещей вроде
я оттуда почерпнул и применил на всех маршрутизаторах.
Да, ладно. Это у тебя неплохая практика)
Я с цисками только год работаю.
А до этого 5 лет только с юниксами.
Был еще случай когда только после замены медиаконвертера стало устанавливаться обычное openvpn соединение.
Хотя я подозреваю, что провайдер чего-то не договаривает, как устройство работающее только на физическом уровне может что-то знать о размерах кадров эзернета.
Наши суровые монтажники даже в сильный снег муфты разваривают)
У вас там наверное еще более экстримальные условия.
Флюк — это охеренный набор для всего, что связано с витухой. Обжимники, ножи, ножницы, тестер)) Если бы я был монтажником, я бы себе его купил)
От 200$ и выше.
Но вещь конечно хорошая.
Фирма покупать не станет)
Так что глюки ловим дальше на канальном и сетевом уровнях.
Да, было дело немного. Выискивали кабели среди сотни других, находили места обрыва. Флюк нетворкс. Слышал, наверно, такое? 🙂
Ну и пару раз искали где оптика плохо сварена.
Вообщем, в последнее время больше всего не хватает каких-нибудь анализаторов физической среды (как меди так и оптоволокна).
Вот у NOC они есть, или хотя бы должны быть)
Ты чем то подобным не пользовался?
А я смотрю, у тебя неплохая практика в траблшутинге)
Эти MTU/MSS/MFL — вечная головная боль, особенно когда добавляются всякие L2TP, MPLS, L2VPN.
тогда интересно зачем вообще такая возможность.
Хотя однажды следуя «best practice» и отключив ip unreachables я получил несколько часов траблшутинга.
Почти все работало, но одна программа не устанавливала соединение.
Только после просмотра трафика tcpdump стало понятно, что установлен флаг DF и path mtu discovery не работает.
Но это уже другая история…
Угу. Верно.
Плюс он не убирается из таблицы маршрутизации в случае падения линка.
Плюс рекурсивные запросы и так не делаются — есть же FIB/CEF.
IOS линейки 15.2M дело хорошее, но пока не попадалось.
Пока все только 12.
Выходит что явное указание интерфейса приводит к тому что не нужно выполнять рекурсивные запросы к таблице маршрутизации.
Но и в этом случае будут apr запросы, что не совсем хорошо.
Так же еще некоторые нюансы возникают.
Значит лучше интерфейс не указывать вовсе.