Добрый деньЕсть два линка, траф делится на них ч/з ip load-sharing per-destination
Проблема - при падении одного из линков перестают ходить пакеты до половины абонентов
Вопрос - как сделать так что бы весь траффик направлялся через оставшийся рабочий линк???
>Добрый день
>
>Есть два линка, траф делится на них ч/з ip load-sharing per-destination
>
>Проблема - при падении одного из линков перестают ходить пакеты до половины
>абонентов
>
>Вопрос - как сделать так что бы весь траффик направлялся через оставшийся
>рабочий линк???это как он у вас так падает?
>это как он у вас так падает?Он у нас падает раз в неделю/месяц/год. Т.е. практически не падает.
НО так как мы живем в россии и фаза луны может легко войти в фазу сатурна то может например пропать питание на одном из линков.Хотелось бы сделать решение с системой защиты от сбоев и хотелось бы чтобы выпадение одного линка не вызывало 50% потерь.
Нужно что бы циска детектила выпадение одного из двух равноценных маршрутов (ибо с выпадением линка маршрут тоже должен потеряться) и не слала пакеты на него.
Вопрос - как это сделать
>[оверквотинг удален]
>из линков.
>
>Хотелось бы сделать решение с системой защиты от сбоев и хотелось бы
>чтобы выпадение одного линка не вызывало 50% потерь.
>
>Нужно что бы циска детектила выпадение одного из двух равноценных маршрутов (ибо
>с выпадением линка маршрут тоже должен потеряться) и не слала пакеты
>на него.
>
>Вопрос - как это сделатья другое имел в виду. физика падает или где-то что-то посередине рвётся, а циска не видит?
да и что за канал у вас тоже интересно - NxE1 или что ещё?
>Вопрос - как сделать так что бы весь траффик направлялся через оставшийся
>рабочий линк???В ниже приведённой ветке обсуждаются проблемы доступности узлов при нескольких подключениях к провайдерам, имеются куски конфигов и упоминаются используемые технологии:
http://www.opennet.me/openforum/vsluhforumID6/19757.html
>В ниже приведённой ветке обсуждаются проблемы доступности узлов при нескольких подключениях к
>провайдерам, имеются куски конфигов и упоминаются используемые технологии:
>http://www.opennet.me/openforum/vsluhforumID6/19757.htmlДанное обсуждение совершенно не касается моей проблемы.
У меня дела совершенно не касаются подключений к провайдерам и т.д.Нужно как-то докрутить балансинг per-destination что бы из двух равноценных маршрутов
ip route х.х.х.х 255.255.255.128 у.у.у.1
ip route х.х.х.х 255.255.255.128 у.у.у.2что бы при выпадении например у.у.у.1 ВЕСЬ траффик (а не половина) шла у.у.у.2
>Нужно как-то докрутить балансинг per-destination что бы из двух равноценных маршрутов
>ip route х.х.х.х 255.255.255.128 у.у.у.1
>ip route х.х.х.х 255.255.255.128 у.у.у.2
>
>что бы при выпадении например у.у.у.1 ВЕСЬ траффик (а не половина) шла
>у.у.у.2Тогда чтобы окружающим понять проблему Вам следует прислушаться к вопросу: shutdown now, 20:47 , 15-Окт-09
Кратко:
Статические маршруты, приложенные Вами остаются в таблице маршрутизации до тех пор пока доступна адресация назначения, осталось узнать "тип" адресации (connected|static|dynamic) и что происходит при пропадании одного из линковВозможно получить ответы на приведённые ниже вопросы?:
1. На каких интерфейсах находится адресация у.у.у.1, у.у.у.2;
2. Конфиги этих интерфейсов;
3. Возможно ли использование динамической маршрутизации на этих направлениях.
>Кратко:
>Статические маршруты, приложенные Вами остаются в таблице маршрутизации до тех пор пока
>доступна адресация назначения, осталось узнать "тип" адресации (connected|static|dynamic) и что происходит
>при пропадании одного из линков
>
>Возможно получить ответы на приведённые ниже вопросы?:
>1. На каких интерфейсах находится адресация у.у.у.1, у.у.у.2;
>2. Конфиги этих интерфейсов;
>3. Возможно ли использование динамической маршрутизации на этих направлениях.В конфигах ничего особенного. Вот как-то так:
ip cef
(т.к. по умолчанию в ip cef используется ip load-sharing per-destination тов конфиге он естессно не отображается)
...
interface GigabitEthernet0/2
ip address у.у.у.6 255.255.255.248
ip virtual-reassembly
ip route-cache same-interface
ip route-cache flow
duplex auto
speed auto
media-type rj45
negotiation auto
no cdp enable
...
ip route х.х.х.х 255.255.255.128 у.у.у.1
ip route х.х.х.х 255.255.255.128 у.у.у.2
Про ситуацию при падении линков черкану чуть позже
>Про ситуацию при падении линков черкану чуть позжеСамая распространённая ситуация - при нарушении канала ПД ethernet интерфейс функционирует нормально и статические маршруты через эти интерфейсы остаются в таблице маршрутизации.
Вылечить эту болячку можно применив на этих линках динамическую маршрутизацию или использовав знания полученные из ранее приведённой ссылки на внешний трэд.
НАсчет ip cef
Router#sh ip cef х.х.х.х
х.х.х.х/25, version 1898597, epoch 0, per-destination sharing
0 packets, 0 bytes
via у.у.у.2, 0 dependencies, recursive
traffic share 1, current path
next hop у.у.у.2, GigabitEthernet0/1 via у.у.у.6/32
valid adjacency
via у.у.у.1, 0 dependencies, recursive
traffic share 1
next hop у.у.у.1, GigabitEthernet0/1 via у.у.у.0/29
valid glean adjacency
0 packets, 0 bytes switched through the prefix
tmstats: external 0 packets, 0 bytes
internal 0 packets, 0 bytes
Меня удивила мессага via у.у.у.0/29
Как такое может быть?
Если не получится через ip cef balancing то придется юзать мониторинг и сла, а ой как не хочется. Неужто ip cef balancing так ограничен???
вот еще кусочек информацииRouter#sh ip route х.х.х.х
Routing entry for х.х.х.х/25
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
у.у.у.2
Route metric is 0, traffic share count is 1
* у.у.у.1
Route metric is 0, traffic share count is 1
Router#sh ip route у.у.у.1
Routing entry for у.у.у.0/29
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via GigabitEthernet0/1
Route metric is 0, traffic share count is 1Router#sh ip cef exact-route a.a.a.a х.х.х.205
a.a.a.a -> х.х.х.205 : GigabitEthernet0/1 (next hop у.у.у.1)
Вобщем я сделал вывод что ip load-sharing per-destination ч/з ip cef рулит лишь тогда когда у.у.у.1 и у.у.у.2 были бы заведены непосредственно на циску каджый в отдельный порт. Тогда упавший у.у.у.1 гасил бы порт а следовательно на циске терялся маршрут.
В силу российских реалий это невозможно.Итого - зарядил шедулер и сла. Все гуд.
Кстати может кому пригодитсяip sla 1
icmp-echo у.у.у.1
timeout 2000
frequency 3
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo у.у.у.2
timeout 2000
frequency 3
ip sla schedule 2 life forever start-time now
...
ip route х.х.х.х 255.255.255.128 у.у.у.1 track 1
ip route х.х.х.х 255.255.255.128 у.у.у.2 track 2
>Вобщем я сделал вывод что ip load-sharing per-destination ч/з ip cef рулит
>лишь тогда когда у.у.у.1 и у.у.у.2 были бы заведены непосредственно на
>циску каджый в отдельный порт. Тогда упавший у.у.у.1 гасил бы порт
>а следовательно на циске терялся маршрут.Ethernet порт маршрутизатора конечно может "упасть", но только если будет нарушена среда передачи данных подключенная к этому порту, упадёт портообразующее оборудование с другой стороны этой среды передачи данных, или это самое портообразующее оборудование(например SHDSL модем или медиа-конвертер) сумеет "потушить" свой ethernet порт при падении соединительной линии и/или других нарушениях связи. ip cef в Вашем случае работал корректно и вполне даже "рулил" :) ибо ему никто не поведал о недоступности connected сетей в которые в свою очередь и смотрят static. Варианты решения были предложены, что выбрать необходимо решать исходя из условий конкретной ситуации, что Вы и сделали.