[Areskr]

Доброго времени суток!

 

Имеется связка 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 на устройствах не наблюдалось.

 

Сталкивались Вы с подобными проблемами?

Edited September 19, 2014 by Areskr

[mightyscv]

Не сталкивался.

Зачем вам BFD на directly connected линках? Есть основания бояться смерти коробки со светящимися интерфейсами?

Что значит "запихан в control-plane"? Это речь про высокоприоритетную очередь, или что-то другое?

Таймеры BFD попробуйте увеличить.

[Areskr]

Не сталкивался.

Зачем вам BFD на directly connected линках? Есть основания бояться смерти коробки со светящимися интерфейсами?

Что значит "запихан в control-plane"? Это речь про высокоприоритетную очередь, или что-то другое?

Таймеры BFD попробуйте увеличить.

 

1) Имеется и вторая сессия bfg + bgp со вторым Nexus 7k. Catalyst выполняет роль агрегации и установлена в удаленном от Nexus месте. Получается: ложиться основной линк, BFD сообщает о разрыве и трафик идет по резерному маршруту

 

2) Да, речь идет про высокоприоритетную очередь:

 

access-list 120 permit tcp any any eq bgp

access-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 сек). Особого эфекта не вижу.

[mightyscv]

Имеется и вторая сессия 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 может развалиться только при потере контрольного трафика. Это либо потери на интерфейсе, либо внутри железки(баг, софтовая реализация + перегрузка процессора, итд).

[s.lobanov]

Зачем вам BFD на directly connected линках?

 

dc это вовсе не значит, то оно по физике "dc", там могут быть dwdm-узлы и прочая фигня, из-за которой падение разрыв оптики где-нибудь может не привести к падению/иям линка/ов

 

bfd внутри AS нужен, но только если он обрабатывается на лайнкартах, а не на цпу мгмт-карты

[pfexec]

bfd внутри AS нужен, но только если он обрабатывается на лайнкартах, а не на цпу мгмт-карты

это всё предрассудки. конечно, подрочить на "бфд в железе" хорошая затея, но оно вовсе не обязательно. гораздо важнее на контрол-плейне иметь нормальный процессор и распил приоритетов его времени между службами ОС, чем калькулятор, зато с бфд в железе. :) а то оно по прихоти бфд не будет успевать высчитывать новый бест и инсталить/удалять актуальные маршруты из fib'а. :D

 

а по теме, я бы обратился к TAC :)

Edited September 1, 2014 by pfexec

[s.lobanov]

я работал с разным железом - и с high-end'ом и со всяким дешёвым шлаком. и мой опыт подсказывает, что лучше бы, чтобы bfd было на линейных картах, что вовсе не эквивалентно "реализовано в железе". ну и ещё я сторонник того, чтобы линейные карты под аплинки/транзит и в сторону кастомеров были разные, но это не всегда экономически целесобразно

[applx]

3) Первочначально высталяли заначение на 150 мсек. и 10 паетов (1.5 сек), сейчас увеличили до 300 мсек и 35 пакетов (10.5 сек). Особого эфекта не вижу.

 

ваше понятие значения "multiplier" какое-то не правильное

 

bfd interval 300 min_rx 300 multiplier {35} <<<<это не пакеты...

 

п.с multiplier советую поставить "3"

Edited September 1, 2014 by applx

[DVM-Avgoor]

я работал с разным железом - и с high-end'ом и со всяким дешёвым шлаком. и мой опыт подсказывает, что лучше бы, чтобы bfd было на линейных картах, что вовсе не эквивалентно "реализовано в железе". ну и ещё я сторонник того, чтобы линейные карты под аплинки/транзит и в сторону кастомеров были разные, но это не всегда экономически целесобразно

 

 

BFD всегда в софте. Процессоры на LC по-вашему лучше процессора на RP? Да там еще больший шлак. К тому же, официально, если ничего не путаю, BFD на LC начинается от 7600 ES+ до 12000.

В любом случае не вижу проблемы в BFD на RP. Тайминги надо выставить адекватные.

[s.lobanov]

если выставлять "адекватные" тайминги, т.е. суммарно секунды, то получаем примерно те же тайминги, что и у самих протоколов, на которые эти самые bfd навешиваем. смысл bfd в том, что он уменьшает до малого значения стандартные таймауты, а не повторяет их

[DVM-Avgoor]

если выставлять "адекватные" тайминги, т.е. суммарно секунды, то получаем примерно те же тайминги, что и у самих протоколов, на которые эти самые bfd навешиваем. смысл bfd в том, что он уменьшает до малого значения стандартные таймауты, а не повторяет их

 

ОСПФ прикрывать BFD смысла мало, согласен. А вот в BGP тайминги очень даже иные. Я не против BFD, очень даже за. Но если канал или CPU не позволяет делать оценку в микросекунды - надо задуматься о более реальных таймингах, вот и все. У него же в логах ясно видно Echo function failed. Echo не зависит от CPU второй стороны, поскольку использует простой механизм L3 роутинга. Значит или у него с каналом не все хорошо, или с настройками. В обоих случаях надо крутить таймеры.

[Areskr]

Хорошо, теперь получается, что у вас два нексуса и каталист. Между второй сессией каталист нексус 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 за что отвечает? Не совсем понятно.

[ChargeSet]

Возникает вопрос: multiplier за что отвечает? Не совсем понятно.

это количество потерянных bfd пакетов, после которого интерфейс признается нерабочим

[Areskr]

Возникает вопрос: multiplier за что отвечает? Не совсем понятно.

это количество потерянных bfd пакетов, после которого интерфейс признается нерабочим

Пакет посылается каждый 300 мс. Считается, что не так если потерялось 35 пакетов, то соединение оборвалось. Возникают проблемы с не прохоят 35 пакетов подряд. 35*300мс= 10500 мс = 10,5 сек. При сборке стенда так и происходило.

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

Edited September 3, 2014 by Areskr

[ChargeSet]

Пакет посылается каждый 300 мс. Считается, что не так если потерялось 35 пакетов, то соединение оборвалось. Возникают проблемы с не прохоят 35 пакетов подряд. 35*300мс= 10500 мс = 10,5 сек. При сборке стенда так и происходило.

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

10,5 секунд на обнаружение отпавшего линка? Нет, увольте, это много. Нет, это дофигища, оно при таких таймингах вовсе не нужно.

Сессия BFD на пустом месте не рвется, этот протокол простой как топор. Он даже на микротиках работает :)

Либо пакеты искажаются\теряются по дороге, либо одно из двух.

 

И вообще, в cisco BGP таймеры keepalive и holdtime по-моему имеют нижний порог в считанные секунды (1 и 3), зачем вам тогда BFD с 10,5 сек?

спецов по cisco прошу ногами не пинать, я эти железки видел плохо и издалека, но крепко зауважал в свое время, но не помню за что:) Но зауважал:)

[applx]

советую Multiplier = HOLD DOWN timer 300x3 = 900 msec / у вас 35, что значит 10сек

Edited September 3, 2014 by applx

[Areskr]

советую Multiplier = HOLD DOWN timer 300x3 = 900 msec / у вас 35, что значит 10сек

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

[DVM-Avgoor]

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

 

А у вас с линком то всё в порядке? А то может не просто так BFD страдает?

[Areskr]

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

 

А у вас с линком то всё в порядке? А то может не просто так BFD страдает?

С линком все впорядке: ведется мониторинг ошибок, уровня оптического сигнала - все четко.

Проблема с BFD возникает, к примеру когда есть петля в соседнем влане проходящий через этот линк.

Буду копать в сторону приоритезации трафика: фактически по всей ничего не настроенно. После создание политики и применение ее к сети будем смотреть.

[applx]

это cisco recommended values так сказать, так что CPU должен быть ок итд итп.