Areskr Опубликовано 1 сентября, 2014 (изменено) · Жалоба Доброго времени суток! Имеется связка Catalyst 4900M и Nexus 7009. Соеденены по физике между собой 10 G линком. Между ними настроенна BGP сессия, поверх нее бежит протокол BFD. Время от времени ложиться BFD сессия. В логах на Nexus выдает: 2014 Aug 31 22:40:01 core1 %BFD-5-SESSION_STATE_DOWN: BFD session 1090519206 to neighbor 94.73.*.* on interface Vlan70 has gone down. Reason: Echo Function Failed.2014 Aug 31 22:40:02 core1 %BFD-5-SESSION_REMOVED: BFD session to neighbor 94.73.*.* on interface Vlan70 has been removed 2014 Aug 31 22:40:29 core1 %BFD-5-SESSION_CREATED: BFD session to neighbor 94.73.*.* on interface Vlan70 has been created 2014 Aug 31 22:40:31 core1 %BFD-5-SESSION_STATE_UP: BFD session 1090519312 to neighbor 94.73.*.* on interface Vlan70 is up. Логи Catalyst: Aug 31 22:39:59: %BGP-5-NBR_RESET: Neighbor 94.*.*.31 reset (BFD adjacency down)Aug 31 22:39:59: %BGP-5-ADJCHANGE: neighbor 94.*.*.31 Down BFD adjacency down Aug 31 22:39:59: %BGP_SESSION-5-ADJCHANGE: neighbor 94.*.*.31 IPv4 Unicast topology base removed from session BFD adjacency down Aug 31 22:40:12: %BGP-5-ADJCHANGE: neighbor 94.*.*.31 Up Сессия после падения, почти сразу подымается. В линке между устройствами также бегут L2 вланы клиентов последней мили. Настройки интерфеса на Nexus: interface Vlan70 description core1-c27 no shutdown bfd interval 300 min_rx 300 multiplier 35 no ip redirects ip address 94.*.*.31/31 no ip ospf passive-interface ip pim sparse-mode ip arp timeout 60 ip policy route-map Uzels2 neighbor 94.*.*.30 bfd remote-as ***** description ---====c27====---- update-source Vlan70 address-family ipv4 unicast route-reflector-client prefix-list AllDefault out default-originate soft-reconfiguration inbound Настройки на Catalyst: interface Vlan70 description core1-c27 ip address 94.*.*.30 255.255.255.254 no ip redirects no ip unreachables ip pim sparse-mode ip igmp unidirectional-link bfd interval 300 min_rx 300 multiplier 35 arp timeout 60 end bgp neighbor 94.*.*.31 remote-as ***** neighbor 94.*.*.31 description === Core1 === neighbor 94.*.*.31 update-source Vlan70 neighbor 94.*.*.31 fall-over bfd neighbor 94.*.*.31 soft-reconfiguration inbound neighbor 94.*.*.31 route-map LocPrf_300 in neighbor 94.*.*.31 route-map LocPrf_300 out Плюс трафик BFD и BGP запихан в control-plane на обоих устройствах. Во время разрыва сессии скачка cpu на устройствах не наблюдалось. Сталкивались Вы с подобными проблемами? Изменено 19 сентября, 2014 пользователем Areskr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mightyscv Опубликовано 1 сентября, 2014 · Жалоба Не сталкивался. Зачем вам BFD на directly connected линках? Есть основания бояться смерти коробки со светящимися интерфейсами? Что значит "запихан в control-plane"? Это речь про высокоприоритетную очередь, или что-то другое? Таймеры BFD попробуйте увеличить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Areskr Опубликовано 1 сентября, 2014 · Жалоба Не сталкивался. Зачем вам BFD на directly connected линках? Есть основания бояться смерти коробки со светящимися интерфейсами? Что значит "запихан в control-plane"? Это речь про высокоприоритетную очередь, или что-то другое? Таймеры BFD попробуйте увеличить. 1) Имеется и вторая сессия bfg + bgp со вторым Nexus 7k. Catalyst выполняет роль агрегации и установлена в удаленном от Nexus месте. Получается: ложиться основной линк, BFD сообщает о разрыве и трафик идет по резерному маршруту 2) Да, речь идет про высокоприоритетную очередь: access-list 120 permit tcp any any eq bgpaccess-list 120 permit udp any any eq 3784 access-list 120 permit udp any any eq 3785 Штука вроде работает, счетчики бегают: C27#sh policy-map control-plane Control Plane Service-policy input: copp-control-plane Class-map: copp-bgp-bfd-ssh (match-all) 15357105 packets Match: access-group 120 Class-map: class-default (match-any) 29576183 packets Match: any 3) Первочначально высталяли заначение на 150 мсек. и 10 паетов (1.5 сек), сейчас увеличили до 300 мсек и 35 пакетов (10.5 сек). Особого эфекта не вижу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mightyscv Опубликовано 1 сентября, 2014 · Жалоба Имеется и вторая сессия bfg + bgp со вторым Nexus 7k. Catalyst выполняет роль агрегации и установлена в удаленном от Nexus месте. Получается: ложиться основной линк, BFD сообщает о разрыве и трафик идет по резерному маршруту Имеется связка Catalyst 4900M и Nexus 7009. Соеденены по физике между собой 10 G линком. Между ними настроенна BGP сессия Ещё раз - зачем вам BFD между физически подключенными устройствами? Вы вообще понимаете, что BFD делает? Если у вас железка/линк умрёт - это будет interface down, и BGP само ляжет сразу, даже быстрее чем BFD это просигнализирует. Единственный сценарий, в котором тут BFD может помочь, это если на железке умирает PFE, но при этом interface up. Такие сценарии сравнительно редки, поэтому я и уточнял про опасения. Хорошо, теперь получается, что у вас два нексуса и каталист. Между второй сессией каталист нексус BFD падает? Софт на нексусах одинаковый? Настройки сессии со вторым нексусом идентичны? Забыл ещё наводящие вопросы. Вы там по приоритезации показали только классификатор. Нет никакой уверенности, что у вас scheduler на интерфейсе правильно работает. Соответственно ещё надо проверить этот факт, ну и просто глянуть нет ли дропов на интерфейсах. Если дропов нет вообще то конфигурацию QoS можно не проверять. По сути BFD может развалиться только при потере контрольного трафика. Это либо потери на интерфейсе, либо внутри железки(баг, софтовая реализация + перегрузка процессора, итд). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 1 сентября, 2014 · Жалоба Зачем вам BFD на directly connected линках? dc это вовсе не значит, то оно по физике "dc", там могут быть dwdm-узлы и прочая фигня, из-за которой падение разрыв оптики где-нибудь может не привести к падению/иям линка/ов bfd внутри AS нужен, но только если он обрабатывается на лайнкартах, а не на цпу мгмт-карты Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pfexec Опубликовано 1 сентября, 2014 (изменено) · Жалоба bfd внутри AS нужен, но только если он обрабатывается на лайнкартах, а не на цпу мгмт-картыэто всё предрассудки. конечно, подрочить на "бфд в железе" хорошая затея, но оно вовсе не обязательно. гораздо важнее на контрол-плейне иметь нормальный процессор и распил приоритетов его времени между службами ОС, чем калькулятор, зато с бфд в железе. :) а то оно по прихоти бфд не будет успевать высчитывать новый бест и инсталить/удалять актуальные маршруты из fib'а. :D а по теме, я бы обратился к TAC :) Изменено 1 сентября, 2014 пользователем pfexec Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 1 сентября, 2014 · Жалоба я работал с разным железом - и с high-end'ом и со всяким дешёвым шлаком. и мой опыт подсказывает, что лучше бы, чтобы bfd было на линейных картах, что вовсе не эквивалентно "реализовано в железе". ну и ещё я сторонник того, чтобы линейные карты под аплинки/транзит и в сторону кастомеров были разные, но это не всегда экономически целесобразно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
applx Опубликовано 1 сентября, 2014 (изменено) · Жалоба 3) Первочначально высталяли заначение на 150 мсек. и 10 паетов (1.5 сек), сейчас увеличили до 300 мсек и 35 пакетов (10.5 сек). Особого эфекта не вижу. ваше понятие значения "multiplier" какое-то не правильное bfd interval 300 min_rx 300 multiplier {35} <<<<это не пакеты... п.с multiplier советую поставить "3" Изменено 1 сентября, 2014 пользователем applx Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 1 сентября, 2014 · Жалоба я работал с разным железом - и с high-end'ом и со всяким дешёвым шлаком. и мой опыт подсказывает, что лучше бы, чтобы bfd было на линейных картах, что вовсе не эквивалентно "реализовано в железе". ну и ещё я сторонник того, чтобы линейные карты под аплинки/транзит и в сторону кастомеров были разные, но это не всегда экономически целесобразно BFD всегда в софте. Процессоры на LC по-вашему лучше процессора на RP? Да там еще больший шлак. К тому же, официально, если ничего не путаю, BFD на LC начинается от 7600 ES+ до 12000. В любом случае не вижу проблемы в BFD на RP. Тайминги надо выставить адекватные. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 1 сентября, 2014 · Жалоба если выставлять "адекватные" тайминги, т.е. суммарно секунды, то получаем примерно те же тайминги, что и у самих протоколов, на которые эти самые bfd навешиваем. смысл bfd в том, что он уменьшает до малого значения стандартные таймауты, а не повторяет их Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 1 сентября, 2014 · Жалоба если выставлять "адекватные" тайминги, т.е. суммарно секунды, то получаем примерно те же тайминги, что и у самих протоколов, на которые эти самые bfd навешиваем. смысл bfd в том, что он уменьшает до малого значения стандартные таймауты, а не повторяет их ОСПФ прикрывать BFD смысла мало, согласен. А вот в BGP тайминги очень даже иные. Я не против BFD, очень даже за. Но если канал или CPU не позволяет делать оценку в микросекунды - надо задуматься о более реальных таймингах, вот и все. У него же в логах ясно видно Echo function failed. Echo не зависит от CPU второй стороны, поскольку использует простой механизм L3 роутинга. Значит или у него с каналом не все хорошо, или с настройками. В обоих случаях надо крутить таймеры. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Areskr Опубликовано 3 сентября, 2014 · Жалоба Хорошо, теперь получается, что у вас два нексуса и каталист. Между второй сессией каталист нексус BFD падает? Софт на нексусах одинаковый? Настройки сессии со вторым нексусом идентичны? Настройки одинаковы, Nexus с одинаковым NS-OX 6.2(6). Резерв от второго Nexus идет не напрямую, а через другой коммутатор. Ещё раз - зачем вам BFD между физически подключенными устройствами? Вы вообще понимаете, что BFD делает? Если у вас железка/линк умрёт - это будет interface down, и BGP само ляжет сразу, даже быстрее чем BFD это просигнализирует. Единственный сценарий, в котором тут BFD может помочь, это если на железке умирает PFE, но при этом interface up. Такие сценарии сравнительно редки, поэтому я и уточнял про опасения. Проблемы могут возникнуть с физикой, но такие что интерфейс будет поднят, а трафик по факту не проходить. Резервы не всегда идут напрямую к коммутатору. По этому требуется дополнительная сигнализация поверх BGP. 3) Первочначально высталяли заначение на 150 мсек. и 10 паетов (1.5 сек), сейчас увеличили до 300 мсек и 35 пакетов (10.5 сек). Особого эфекта не вижу. ваше понятие значения "multiplier" какое-то не правильное bfd interval 300 min_rx 300 multiplier {35} <<<<это не пакеты... п.с multiplier советую поставить "3" Возникает вопрос: multiplier за что отвечает? Не совсем понятно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ChargeSet Опубликовано 3 сентября, 2014 · Жалоба Возникает вопрос: multiplier за что отвечает? Не совсем понятно. это количество потерянных bfd пакетов, после которого интерфейс признается нерабочим Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Areskr Опубликовано 3 сентября, 2014 (изменено) · Жалоба Возникает вопрос: multiplier за что отвечает? Не совсем понятно. это количество потерянных bfd пакетов, после которого интерфейс признается нерабочим Пакет посылается каждый 300 мс. Считается, что не так если потерялось 35 пакетов, то соединение оборвалось. Возникают проблемы с не прохоят 35 пакетов подряд. 35*300мс= 10500 мс = 10,5 сек. При сборке стенда так и происходило. Тогда вопрос, как решается проблема частого разрыва BFD сессии сокращение данного показателя до 3-ех пакетов? Это только сделает ситуацию хуже. Изменено 3 сентября, 2014 пользователем Areskr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ChargeSet Опубликовано 3 сентября, 2014 · Жалоба Пакет посылается каждый 300 мс. Считается, что не так если потерялось 35 пакетов, то соединение оборвалось. Возникают проблемы с не прохоят 35 пакетов подряд. 35*300мс= 10500 мс = 10,5 сек. При сборке стенда так и происходило. Тогда вопрос, как решается проблема частого разрыва BFD сессии сокращение данного показателя до 3-ех пакетов? Это только сделает ситуацию хуже. 10,5 секунд на обнаружение отпавшего линка? Нет, увольте, это много. Нет, это дофигища, оно при таких таймингах вовсе не нужно. Сессия BFD на пустом месте не рвется, этот протокол простой как топор. Он даже на микротиках работает :) Либо пакеты искажаются\теряются по дороге, либо одно из двух. И вообще, в cisco BGP таймеры keepalive и holdtime по-моему имеют нижний порог в считанные секунды (1 и 3), зачем вам тогда BFD с 10,5 сек? спецов по cisco прошу ногами не пинать, я эти железки видел плохо и издалека, но крепко зауважал в свое время, но не помню за что:) Но зауважал:) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
applx Опубликовано 3 сентября, 2014 (изменено) · Жалоба советую Multiplier = HOLD DOWN timer 300x3 = 900 msec / у вас 35, что значит 10сек Изменено 3 сентября, 2014 пользователем applx Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Areskr Опубликовано 4 сентября, 2014 · Жалоба советую Multiplier = HOLD DOWN timer 300x3 = 900 msec / у вас 35, что значит 10сек Проблема в том, что при таких значениях - BFD сессия "летает". Происходит перестроение маршрутов - загружается процессор и т.д. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 4 сентября, 2014 · Жалоба Проблема в том, что при таких значениях - BFD сессия "летает". Происходит перестроение маршрутов - загружается процессор и т.д. А у вас с линком то всё в порядке? А то может не просто так BFD страдает? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Areskr Опубликовано 4 сентября, 2014 · Жалоба Проблема в том, что при таких значениях - BFD сессия "летает". Происходит перестроение маршрутов - загружается процессор и т.д. А у вас с линком то всё в порядке? А то может не просто так BFD страдает? С линком все впорядке: ведется мониторинг ошибок, уровня оптического сигнала - все четко. Проблема с BFD возникает, к примеру когда есть петля в соседнем влане проходящий через этот линк. Буду копать в сторону приоритезации трафика: фактически по всей ничего не настроенно. После создание политики и применение ее к сети будем смотреть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
applx Опубликовано 4 сентября, 2014 · Жалоба это cisco recommended values так сказать, так что CPU должен быть ок итд итп. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...