[Da_Uff]

Добрый день, коллеги! Прошу совета.

Такая ситуация: имеется IPoE сетка, в ядре на агрегации, а так же бордером - Cat6509E(Sup2T, IOS 15.1(2)SY4 IPBASEK9-NPE). В силу версии софта, вынуждены использовать Flexible Netflow(Данный IOS уже не поддерживает обычный). Настройка монитора/экспортера netflow:

 

flow exporter EXPORT1

destination <адрес агрегатора>

source Vlan 4

transport udp 9996

export-protocol netflow-v5

 

flow monitor MONITOR1

record platform-original ipv4 full (использует предустановленную в IOS flow-запись в нужном для netflow-v5 формате)

exporter EXPORT1

 

 

На каталисте терминируются клиентские VLANы(как правило - vlan на дом). Настройка ip на vlan-интерфейсах следующая:

 

interface vlan xxxx

ip unnumbered Loopback2

ip helper-address xx.xx.xx.xx

....

 

interface Loopback2

ip address X.X.X.1 255.255.255.0

....

Как можно видеть, клиенты получают адрес(белый, X.X.X.0/24) от хелпера и маршрутизируются через IP loopback-a(соответственно, X.X.X.1 из той же белой подсети). Инет доступен через промежуточную сетку Y.Y.Y.1 вышестоящего провайдера на native vlan-e Ethernet свитчпорта GigabitEthernet 5/1, к этому же свитчпорту так же прицеплен rate-limiting на базе microflow policing. Конфигурация vlan-a, транспортной подсети и аплинк-свитчпорта:

 

interface Vlan4

ip address Y.Y.Y.214 255.255.255.252 (cеть вышестоящего провайдера)

...

 

ip default-gateway Y.Y.Y.213

 

interface GigabitEthernet5/1

description uplink

switchport

switchport trunk native vlan 4

switchport mode trunk

service-policy input UBRL

 

Проблема в следующем: на какой бы интерфейс я не прицеплял флоу-монитор (ip flow monitor MONITOR1 input(Либо вместе с такой же второй строкой, но output)) ни на клиентских вланах, ни на лупбеке, ни на Vlan 4 нетфлоу не видит никакого трафика белой клиентской сети X.X.X.0/24. Более того, debug ip packet, натравленный акцесс-листом permit ip any X.X.X.1 0.0.0.255 на клиентскую сеть, показывает хождение пакетов только между клиентскими адресами X.X.X.0/24 и их основным шлюзом X.X.X.1. На Vlan4 имеется так же NAT для офисной локалки и серверов, его трафик Netflow замечательно кэширует и показывает(кстати, думал, что NAT может мешаться, отключал. Погоды не сделало). Может у кого-то есть успешный опыт взаимодействия всех трех виновников торжества: UBRL, ip unnumbered и netflow?

[Da_Uff]

апдейт: между тем, в выводе debug ip cef packet vlan 4 input трафик интернет<->клиент присутствует

[Tosha]

Когда я спрашивал TAC почему не могу поднять UBRL на cisco 7606 (аппаратный брат 65xx) TAC мне ответил что UBRL и NDE (netflow data export) несовместимы и не могут быть включены одновременно ввиду конфликта на уровне программирования железа (если не путаю - требуют разных flowmask). Мне даже сказали номер зарегистрированного бага особенности. Ну то есть оно так работает и иначе принципиально не может. И это не лечится. Как минимум вплоть до фабрики rsp720 3CXL

Письмо потеряно за давностью лет. Если что не правильно вспомнил через 8 лет - извините.

 

Впрочем я не пробовал отключить сбор Netflow статистики с пары интерфейсов (в новом софте это управлялось на уровне интерфейсов) и поднять на них UBRL.

Попробуйте физически разделить места ограничения скорости и учета трафика. "Петель" понакрутите.

[Da_Uff]

Когда я спрашивал TAC почему не могу поднять UBRL на cisco 7606 (аппаратный брат 65xx) TAC мне ответил что UBRL и NDE (netflow data export) несовместимы и не могут быть включены одновременно ввиду конфликта на уровне программирования железа (если не путаю - требуют разных flowmask). Мне даже сказали номер зарегистрированного бага особенности. Ну то есть оно так работает и иначе принципиально не может. И это не лечится. Как минимум вплоть до фабрики rsp720 3CXL

Письмо потеряно за давностью лет. Если что не правильно вспомнил через 8 лет - извините.

 

Впрочем я не пробовал отключить сбор Netflow статистики с пары интерфейсов (в новом софте это управлялось на уровне интерфейсов) и поднять на них UBRL.

Попробуйте физически разделить места ограничения скорости и учета трафика. "Петель" понакрутите.

 

Спасибо за ответ! Да, я видел таковые жалобы в сети, вроде и вашу тоже, на sysadmins.ru. Для SUP2T и 15.1 IOS-а уже не актуально. Более того, у меня UBRL на одном интерфейсе, а netflow я пытаюсь сконфигурировать на другом. sh platform hardware capaqcity показывает, что из 32 flowmask 22 свободны(на 720ых супервизорах их вроде было всего 4), так что тут тоже косяка нет, правда не покидает подозрение, что тем не менее именно UBRL и мешает.

p.s.: Да, есть мысль завернуть через route-map клиентский трафик на отдельный Loopback, и уже с него снимать статистику. Однако, в этом случае смущает то, что обработка пакетов свалится на CPU. Но, видимо, придется все равно пробовать.

[Tosha]

мы все петли всегда делали не на лупбеках а на реальных железных портах. Как раз из-за боязни перехода в CPU