На дорогих каналах передачи данных интересно использовать компрессию. У Cisco их два типа:
1. Протоколонезависимая
2. Компрессия TCP/IP заголовков.
Почитать сравнение методов одним CCIE.
Если со второй ранее приходилось сталкиваться довольно часто, особенно применяя компрессию rtp, то с первой - нет. Можно сделать вывод, что ее целесообразно применять на каналах, где не преобладает voip.
Итак, есть serial интерфейс с включенной компрессией и с наличием политики приоритезации трафика на основе классов:
Использование политик в случае такой компрессии невыгодно. Казалось бы, экономится ресурс, но сэкономленное нельзя потратить из-за работы шейпера. Есть мнение, что сначала отрабатывает политика, а только потом - сжатие. Увеличение полосы в политике возможно только после глубокого анализа статистики по сжатию.
Мониторить загрузку можно двумя способами. Либо показывать загрузку интерфейса на основе snmp-счетчиков, либо показывать bitrate в выбранном классе, который будет немного больше. Про мониторинг CBQOS тоже как-нибудь напишу.
1. Протоколонезависимая
2. Компрессия TCP/IP заголовков.
Почитать сравнение методов одним CCIE.
Если со второй ранее приходилось сталкиваться довольно часто, особенно применяя компрессию rtp, то с первой - нет. Можно сделать вывод, что ее целесообразно применять на каналах, где не преобладает voip.
Итак, есть serial интерфейс с включенной компрессией и с наличием политики приоритезации трафика на основе классов:
ROUTER-01#show run interface se1/0Смотрим загрузку на интерфейсе:
Building configuration...
Current configuration : 304 bytes
!
interface Serial2/0
ip address 10.0.1.1 255.255.255.252
load-interval 30
compress stac
serial restart-delay 0
service-policy output CDM-v35.ext
end
ROUTER-01#show inteface se1/0 | in rateи то, что показывает политика:
Queueing strategy: Class-based queueing
30 second input rate 1153000 bits/sec, 946 packets/sec
30 second output rate 3072000 bits/sec, 936 packets/sec
PE-01#show policy-map interface se1/0Получилось немного больше. Что же покажет статистика по сжатию?
Serial1/0
Service-policy output: CDM-v35.ext
Class-map: class-default (match-any)
1120960 packets, 586507162 bytes
30 second offered rate 3762000 bps, drop rate 271000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 146/51598/0
(pkts output/bytes output) 1069362/551094507
shape (average) cir 4000000, bc 16000, be 16000
target shape rate 4000000
ROUTER-01#show compress details
Serial1/0
Software compression enabled
uncompressed bytes xmt/rcv 156842655/79460467
compressed bytes xmt/rcv 89359994/53100344
Compressed bytes sent: 89359994 bytes 517 Kbits/sec ratio: 1.755
Compressed bytes recv: 53100344 bytes 307 Kbits/sec ratio: 1.496
1 min avg ratio xmt/rcv 0.143/0.515
5 min avg ratio xmt/rcv 0.018/0.049
10 min avg ratio xmt/rcv 0.000/0.013
no bufs xmt 0 no bufs rcv 0
resyncs 0
Additional Stac Stats:
Transmit bytes: Uncompressed = 457676599 Compressed = 89359994
Received bytes: Compressed = 53655118 Uncompressed = 0
Использование политик в случае такой компрессии невыгодно. Казалось бы, экономится ресурс, но сэкономленное нельзя потратить из-за работы шейпера. Есть мнение, что сначала отрабатывает политика, а только потом - сжатие. Увеличение полосы в политике возможно только после глубокого анализа статистики по сжатию.
Мониторить загрузку можно двумя способами. Либо показывать загрузку интерфейса на основе snmp-счетчиков, либо показывать bitrate в выбранном классе, который будет немного больше. Про мониторинг CBQOS тоже как-нибудь напишу.