Da_Uff

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

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

Добрый день, коллеги! Прошу совета. Такая ситуация: имеется 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?

Expect-ом через ssh скрипты открывают/закрывают доступ и нарезают шейпинг абонентам по комманде от ЛанБиллинга. Не без минусов способ, разумеется, но работает вполне.