Как обрабытывается CEF-exception трафик внутри cppr-политики в Cisco IOS-XE?

Question

[John_Alban]

Написал cppr-политики для роутеров Cisco на IOS и IOS-XE.
И столкнулся со следующей проблемой: на IOS-XE железе нет control-plane cef-exception режима, весь трафик на коробку обрабатывается внутри единой политики. И в этой политике никак не удается поймать BFD-пакеты.. По счетчикам вижу, что вcе BFD-пакеты оседают на итоговом дискардном правиле. В стандартном IOS BFD по-идее не попадает в cef и обрабатывается внутри control-plane cef-exception; что делать в случае IOS-XE не пойму - странно, что трафик не попадает в нужный класс, но при этом внутри фильтра валится не в class-default, а именно в discard-all-UDP правило.
Железо: ASR1002
Версия IOS-XE ROMMON: 153-1r
Версия IOS-XE: 03.14.00.S
Версия IOS внутри: 15.5(1)S

Правило отбора для BFD (упрощенный конфиг):
ip access-list extended RE_bfd
permit udp object-group ext_hosts range 49152 65535 object-group int_hosts range 3784 3785
! далее класс, куда BFD входит:
class-map match-any RE_routing
match access-group name RE_bfd
! дискард правила
ip access-list extended RE_dis_tcp
permit tcp any any fragments
permit tcp any any
ip access-list extended RE_dis_udp
permit udp any any fragments
permit udp any any
ip access-list extended RE_dis_ip
permit icmp any any fragments
permit ip any any fragments
permit ip any any
! дискард класс
class-map match-any RE_dis_traffic
description RE_disable_traffic
match access-group name RE_dis_tcp
match access-group name RE_dis_udp
match access-group name RE_dis_ip
! и все это в cppr-политике:
policy-map RE_cppr
class RE_routing
class RE_dis_traffic
police rate 1 pps
! включаем
control-plane
service-policy input RE_cppr
!

UPD: С LDP трафиком аналогичная проблема, поэтому склонен считать, что она характерна для всех CEF-exception пакетов внутри коробки.

Answer 1

[John_Alban]

Итак, симтомы проблемы я устранил.
Изначально ACL для отбора было таким:
!
permit udp object-group ext_hosts range 49152 65535 object-group int_hosts range 3784 3785
!
Собственно, возникла идея поиграть с условиями и я убрал ограничение по адресам. ACL превратился в:
!
permit udp any range 49152 65535 any range 3784 3785
!
И все заработало! Но вопрос все равно открыт - устранился симптом, почему ASR не обрабатывает условие по ip-заголовкам - непонятно. Баг или особенность обработки host-inbound трафика на IOS-XE?

UPD: Весь сыр-бор возник из-за того, что внутри ACL для cef-exception трафика не работают object-groups. Для остального host-inbound трафика они работают.
Если вместо object-groups напрямую писать ip-адреса, то все работает как надо.

Comments

[Кирилл]

скорее всего в host-inbound ACL не нужно использовать object-group

[John_Alban]

у меня такое ощущение, что для cef-exeption трафика внутри cppr на IOS-XE в целом:
1. недоступен для анализа ip-заголовок (какой-то баг или недоработка софта)
2. некорректно отрабатывают object-groups
В пользу этих версий говорит еще то, что помимо BFD трафика, аналогичная проблема проявилась и на LDP трафике. В правилах под LDP так же использовались obect-groups и после их замены на "any" ldp-сессии поднялись.
Теперь почему я думаю, что проблема характерна для всего cef-exeption трафика. Разделы полисера, отвечающие за BGP, SSH, SNMP и пр. написаны так же с помощью object-groups и никаких вопросов не возникает - все работает корректно. Плюс, в политике есть раздел, написанный под tLDP трафик - все tldp сессии изначально были в up (tldp пакеты имеют ttl >1 и обрабатываются через cef. в остальном ничем от ldp-unicast пакетов не отличаются).

Завтра проверю гипотезы и отпишусь.

[John_Alban]

По всей видимости, object-groups действительно не работают внутри ACL для cef-exeption трафика внутри control-plane policing (copp) политик.
Здравствуй, еще один незадокументированный cisco-косяк

Answer 2

[Кирилл]

Скорее всего ответ в том, что на ХЕ-железе нет CEF. Там аналог QFP, через который все и идёт. На предыдущем железе не такая архитектура

Comments

[John_Alban]

Разве может не быть CEF у ASR роутеров? В доках он описан и на нем многое завязано:
www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipswitch...
Плюс CEF это фишка data plane, а QFP - это просто SPU-чип, часть PFE (packet forwarding engine) (PPE в доках ASR). Согласен, что через него все идет, он же чать фабрики, но с отсутствием CEF не согласен.
Или вы про архитектуру control-plane полисирования на ASR? Тогда согласен - на IOS фильтрция трехуровневая. Отдельный фильтр на CEF host-inbound трафик (host), отдельный на трафик host-inbound вне CEF (cef-exeption) и отдельный на транзитные пакеты, требующие для своей обработки ресурсы CPU (transit). Все вместе это и называлось cppr фильтрафией. На IOS-XE есть только единый агрегированный фильтр, позволяющий делать copp полисирование.
Но вопрос не о архитектурных различиях, он в том, почему пакеты не попадают под специально для них написанное условие (максимально специфичное) но попадают под условие "permit udp any any" в самом конце политики

[Кирилл]

John_Alban: а это может быть из-за компиляции правил на железе. Если другой action задать для class RE_routing - поведение не меняется?

[John_Alban]

небольшое изменение условий - в первой версией я написал упрощенный ACL. Сейчас попробовал его - он снял симптомы проблемы. Подробности ниже