|
ru.cisco
- RU.CISCO ---------------------------------------------------------------------
From : Andrew Nikulin 2:5020/400 20 May 2005 15:10:44
To : All
Subject : Странности с service-policy и NetFlow
--------------------------------------------------------------------------------
Здравствуйте, уважаемые коллеги!
Помогите, пожалуйста, осознать этиологию проблемы.
Есть вот такая платформа:
#sh ver
Cisco IOS Software, 7200 Software (C7200-PK9U2-M), Version 12.3(11)T5,
RELEASE SOFTWARE (fc1)
[skip]
Cisco 7206VXR (NPE400) processor (revision A) with 491520K/32768K bytes
of memory.
Processor board ID 21275902
R7000 CPU at 350MHz, Implementation 39, Rev 3.3, 256KB L2 Cache
6 slot VXR midplane, Version 2.1
[skip]
2 FastEthernet interfaces
125K bytes of NVRAM.
[skip]
#sh diag
Slot 0:
Dual FastEthernet (RJ-45) I/O Card Port adapter, 2 ports
Port adapter is analyzed
Port adapter insertion time 21:55:37 ago
EEPROM contents at hardware discovery:
Hardware Revision : 1.2
Top Assy. Part Number : 800-07114-04
Part Number : 73-5003-04
Board Revision : B0
PCB Serial Number : 23976293
RMA History : 00
Fab Version : 02
Fab Part Number : 28-3455-02
Product (FRU) Number : C7200-I/O-2FE/E
Board Revision :
[skip]
Для BGP сконфигурирована table-map, при помощи которой, в зависимости
от принятых community, префиксам назначаються разные qos-group,
выглядит это так:
router bgp XXXX
table-map RM_BGP_TABLE_MAP
[skip]
!
route-map RM_BGP_TABLE_MAP permit 10
match community 2
set ip qos-group 1
!
route-map RM_BGP_TABLE_MAP permit 20
match community 3
set ip qos-group 2
!
route-map RM_BGP_TABLE_MAP permit 30
match community 4
set ip qos-group 3
!
route-map RM_BGP_TABLE_MAP permit 40
match community 5
set ip qos-group 4
!
route-map RM_BGP_TABLE_MAP permit 1000
set ip qos-group 63
Интерфейс F0/1 смотрит на аплинка, с которым поднята BGP сессия.
Hа F0/1 установлен режим bgp-policy source ip-qos-map
и прописан service-policy для входящего трафика, который копирует
значение qos-group в поле DSCP заголовка IP пакета. Вот как это
выглядит.
interface FastEthernet0/1
ip address XXX.XXX.XXX.XXX 255.255.255.248
no ip redirects
no ip proxy-arp
service-policy input PM_IN
bgp-policy source ip-qos-map
ip route-cache flow
duplex full
speed 100
snmp ifindex persist
policy-map PM_IN
class class-default
set dscp qos-group
Hу и соответсвенно настроен экспорт NetFlow:
ip flow-export source Loopback0
ip flow-export version 5
ip flow-export destination XXX.XXX.XXX.XXX XXXX
Целью всего изложенного выше, является классификация входящего
трафика от вышестоящего провайдера по префиксу источника
(провайдер анонсирует префиксы с разными community) и маркировка
экспортируемых потоков NetFlow путем установки поля TOS.
Вроде все работает как ожидалось.
Через sh ip cef det убеждаемся что qos-group для префиксов
нормально выставляются (цитировать вывод не буду из-за
большого обьема).
#sh policy-map interface F0/1
FastEthernet0/1
Service-policy input: PM_IN
Class-map: class-default (match-any)
38136127 packets, 16645009047 bytes
5 minute offered rate 3400000 bps, drop rate 0 bps
Match: any
QoS Set
dscp qos-group
Packets marked 37835571
Запускаем несколько раз подряд последнюю команду, убеждаемся что
счетчик маркированных пакетов исправно тикает. Вроде все OK.
Смотрим чтоже мы получили на коллекторе NetFlow...
А там мы получили фигу, т.е. немодифицированное поле TOS для всех
потоков. Складываеться впечатление, что информация
о потоке NetFlow сбрасываеться на коллектор ДО того как
service-policy модифицирует поле DSCP.
Внимание вопроc: Почему после добавления на интерфейсе route-map,
устанавливающего output interface, все мгновенно начинает работать как
надо?
interface FastEthernet0/1
ip policy route-map RM_SETIF_LOOPBACK0
route-map RM_SETIF_LOOPBACK0 permit 10
set interface Loopback0
После этого все действительно становится OK! В экспорте NetFlow
четко видны правильно выставленные поля TOS.
Интуитивно я понимаю, что проблема связана с очередностью этапов
обработки IP-пакета, но хотелось бы точной информации.
Документ "NAT Order of Operation"
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a
0080133ddd.shtml
я читал, но это не то. Про NetFlow там нет ни слова :(
Да, еще одна маленькая деталь, наводящая на рызмышления.
Включен TCP Intercept:
ip tcp intercept list ACL_TCP_INTERCEPT
так вот, те пакеты, которые проходят через этот механизм
(соответствуют ACL_TCP_INTERCEPT) в NetFlow экспорт попадают
правильно промаркированными в ЛЮБОМ случае, даже при выключенном
route-map на интерфейсе.
В общем помогите осознать причину проблемы и по возможности избавится
от route-map. А то неаккуратненько как то :)
- ---
С уважением, Hикулин Андрей (AVN4-RIPE).
ЗАО "Элкател", системный администратор.
--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5.3
* Origin: Talk.ru (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
