відповідність класу за замовчуванням керує трафіком?

Я бачу проблему з BFD за посиланням, яке здійснює поліцейський вихід, коли воно з’являється під час, коли поліцейський розміщує пакети BFD, не потрапляючи на іншу сторону. Мені цікаво, чи привітання BFD підлягають поліцейському чи вони потрапляють поза поліцейських. Якщо вони підпорядковуються поліцейським, чи це так просто, як додати відповідність за DSCP CS6 та надати йому пріоритет? Нижче наведено конфігурацію:

interface GigabitEthernet1/1
 service-policy output 500meg
end

Router-1#sh policy-map 500meg
  Policy Map 500meg
    Class class-default
     police cir 500000000 bc 31250000 be 31250000
       conform-action transmit
       exceed-action drop
       violate-action drop

@Муд, ти майже отримав відповідь на своє запитання на кілька коментарів, тому я просто консолідував це тут в одній відповіді.

На 7600s / 6500s ви можете фільтрувати BFD (трафік в контрольній площині) на рівні інтерфейсу, як і будь-який інший трафік (транзитний трафік, що проходить через пристрій).

Якщо ви застосуєте ACL до порту на лінійній карті, він застосовується до всього трафіку на цьому інтерфейсі. Трафік, який потрібно обробляти за допомогою RSP або DFC, якщо ви їх використовуєте, повинен бути покараний там, що відбувається після обробки ACL.

Як правило, я в останній час включаю трафік на контрольній площині в політику QoS, наприклад, наступний, коли "клас NC" відповідає лише CS6 та CS7:

policy-map QoS-Example
 class NC
  bandwidth percent 2
 !
 class REALTIME
  police rate percent 10
   conform-action transmit
   exceed-action drop
  !
  priority level 1
 !
 class 1
  bandwidth percent 22
 !
 class 2
  bandwidth percent 24
 !
 class 3
  bandwidth percent 12
 ....... and so on

Якщо ви пишете політику CoPP для своїх 7600s / 6500s, вам потрібно написати ACL, які відповідають усім вашим відповідним типам трафіку в контрольній площині. Таким чином, ви також можете зіставити трафік BFD, зіставивши трафік до / з порту UDP 3784 (і заблокуйте його далі до IP вашого інтерфейсу, якщо можливо).

Як @ytti сказав, що вам потрібно бути обережними щодо таймерів BFD у вашому налаштуванні, якщо у вас немає DFC, ваш BFD працює на RSP / CPU. У цьому випадку ви також можете подивитися на налаштування глобальної команди "time-max-time" та на графік процесу "планувальник виділити xxx xxx".

Рекомендований Cisco мінімум є, bfd interval 100 min_rx 100 multiplier 3але на деяких виробничих коробках без DFC я фактично працюю, bfd interval 500 min_rx 500 multiplier 3що було нормально, я думаю, що на коробках з DFC, до яких я зараз не маю доступу, я запускаю те саме.

Ви можете ознайомитись з цими посиланнями для отримання додаткової інформації, яка охоплює настройку BFD та ACL для трафіку на контрольній площині (як CoPP, так і інтерфейс ACL), а також деяку настройку площини управління, що, як правило, є хорошою практикою, а також поведінку QoS з трафіком в площині управління:

http://www.cisco.com/c/en/us/td/docs/routers/7600/troubleshoot/guide/7600_Trouble_Shooting.pdf

http://www.cisco.com/c/en/us/td/docs/routers/7600/ios/12-2SR/configuration/guide/swcg/dos.html

http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html

http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-congestion-management-queueing/18664-rtgupdates.html

Через критичний характер керуючого пакету BFD, він не проходить мапу політики QoS виходу на виході, а безпосередньо розміщується у черзі виходу. Підтверджено TAC.

Згідно з цим документом cisco "Користувачі не можуть, наприклад, фільтрувати або застосовувати якість обслуговування (QoS) до переданого пакету BFD". Тому я думаю, що ці пакети отримують прапор PAK_PRIORITY .