Поиск по этому блогу

07.12.2010

Компрессия, netflow и bandwidth для политик

Недавно экспериментировали с компрессией на WAN-линках. Поскольку данные обрабатываются процессором перед отправкой, получился неожиданный результат, а именно:
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
ip flow ingress
load-interval 30
compress stac
serial restart-delay 0
service-policy output CDM-v35.ext
end
Входящие пакеты не обрабатываются netflow, как будто ip flow ingress вообще отсутствует. В кэше (show ip cache flow ) DstIf Serial2/0 отсутствует. Есть записи с DstIf Null вместо этого. В общем, караул. В операторских сетях с подсчетом трафика по netflow такую компрессию использовать нельзя. Благо к нашей работе это не относится, но мониторинг страдает и ip flow top-talkers использовать нельзя, а это неудобно.



Теперь что касается экономии полосы. Поэкспериментировав с Serial-интерфейсами и политиками получилось следующее. Сделал тестовую политику:
Router-01#sh policy-map testtest
Policy Map testtest
Class RTP
priority 50 (%)
Проверка на неиспользуемом интерфейсе настройками по-умолчанию:
Router-01(config))#interface Serial2/1
Router-01(config-if)#service-policy output testtest
Router-01(config-if)#^Z
Router-01#sh policy-map interface Serial2/1
Serial2/1

Service-policy output: testtest

queue stats for all priority classes:

queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0

Class-map: RTP (match-all)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: protocol rtp
Priority: 50% (772 kbps), burst bytes 19300, b/w exceed drops: 0


Class-map: class-default (match-any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any

queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
Router-01#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-01(config)#interface Serial2/1
Router-01(config-if)#bandwidth 4000
Router-01(config-if)#^Z
Router-01#sh policy-map interface Serial2/1
Serial2/1

Service-policy output: testtest

queue stats for all priority classes:

queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0

Class-map: RTP (match-all)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: protocol rtp
Priority: 50% (2000 kbps), burst bytes 50000, b/w exceed drops: 0


Class-map: class-default (match-any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any

queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0

Вот ведь что получается. Полосу для политики на WAN-интерфейсах можно регулировать через bandwidth и использовать всю доступную пропускную способность канала с применением компрессии и политик для обеспечения качества обслуживания. На подинтерфейсах применял только иерархические политики, которые в случае компрессии применять невыгодно, о чем писал ранее.

06.12.2010

TTCP - "iperf" в устройствах Cisco

Коллега приехал с курса TSHOOT. Рассказал про недокументированную команду ttcp, которая позволяет протестировать канал аналогично iperf. Возможности немного ограничены и подробнее я с ней не разбирался.
Запускается на одном маршрутизаторе в режиме получения пакетов:
Router-01#ttcp
transmit or receive [receive]:
Router-01#ttcp
transmit or receive [receive]:
perform tcp half close [n]:
receive buflen [8192]:
bufalign [16384]:
bufoffset [0]:
port [5001]:
sinkmode [y]:
rcvwndsize [4128]:
delayed ACK [y]:
show tcp information at end [n]:
Второй - в режиме отправки:
Router-02#ttcp
transmit or receive [receive]: transmit
Target IP address: 10.0.0.1
perform tcp half close [n]:
send buflen [8192]:
send nbuf [2048]:
bufalign [16384]:
bufoffset [0]:
port [5001]:
sinkmode [y]:
buffering on writes [y]:
show tcp information at end [n]:

ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp -> 10.0.0.1
ttcp-t: connect
ttcp-t: 16777216 bytes in 2480 ms (2.480 real seconds) (~6606 kB/s) +++
ttcp-t: 2048 I/O calls
ttcp-t: 0 sleeps (0 ms total) (0 ms average)

Актуально для тестирования низкоскоростных каналов связи.

Зеркалирование портов

При необходимости мониторинга трафика на коммутаторах есть возможность организовать отправку входящих и исходящих фреймов из одного или нескольких портов в порт, куда подключено устройство наблюдения/мониторинга. В примере данные снимаются с оптических интерфейсов и отправляются в Gi2/0/24
monitor session 1 source interface Gi1/0/25 - 28
monitor session 1 source interface Gi2/0/25 - 28
monitor session 1 destination interface Gi2/0/24
При этом статус интерфейса определен как monitoring
Switch#sh int Gi2/0/24
GigabitEthernet2/0/24 is up, line protocol is down (monitoring)
Hardware is Gigabit Ethernet, address is 001a.e3b7.0000 (bia 001a.e3b7.0000)
Description: Monitoring
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 46/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 2d17h, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 163960752
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 180921000 bits/sec, 32691 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts (0 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
30689513448 packets output, 18682312723003 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out

02.12.2010

Meetme конференции

CUCME позволяет реализовать что-то наподобие сервера конференций. Функционал называется Meetme, когда можно позвонить на определенный номер и попасть в конференцию, в отличии от Ad-hoc конференций, когда до каждого участника вручную необходимо дозвониться.



Настройки маршрутизатора остаются прежними. Добавляется только ephone-dn:
ephone-dn  111  dual-line
number 2222
conference meetme
preference 2
no huntstop
!
!
ephone-dn 112 dual-line
number 2222
conference meetme
preference 3
no huntstop
!
!
ephone-dn 113 dual-line
number 2222
conference meetme
preference 4
no huntstop
!
!
ephone-dn 114 dual-line
number 2222
conference meetme
preference 5
no huntstop
!
!
ephone-dn 115 dual-line
number 2222
conference meetme
preference 6
no huntstop
!
!
ephone-dn 116 dual-line
number 2222
conference meetme
preference 7
no huntstop
!
!
ephone-dn 117 dual-line
number 2222
conference meetme
preference 8
no huntstop
!
!
ephone-dn 118 dual-line
number 2222
conference meetme
preference 9
no huntstop
!
!
ephone-dn 119 dual-line
number 2222
conference meetme
preference 10
no huntstop
!
!
ephone-dn 120 dual-line
number 2222
conference meetme
preference 10
no huntstop
!
!
ephone-dn 121 dual-line
number 2222
conference meetme
preference 10
no huntstop
!
!
ephone-dn 122 dual-line
number 2222
conference meetme
preference 10
no huntstop
!
!
ephone-dn 123 dual-line
number 2222
conference meetme
preference 10
no huntstop
!
!
ephone-dn 124 dual-line
number 2222
conference meetme
preference 10
Количество dn определяет число участников, как и в Ad-hoc конференциях. Понятно, используются ресурсы DSP.
Конференция создается только при наличии строки conference meetme хотя бы в одной DN. И только с телефона или ip-коммуникатора Cisco имеющего программные клавиши. Их необходимо создать и применить к телефону, который будет создавать конференцию. В примере ниже такое проделано для ip-коммуникатора:
ephone-template  1
softkeys hold Newcall Resume Select Join
softkeys idle Cfwdall ConfList Dnd Gpickup HLog Join Login Newcall Pickup Redial RmLstC
softkeys seized Redial Pickup Gpickup HLog Meetme Endcall
softkeys connected Acct ConfList Confrn Endcall Flash HLog Hold Join Park RmLstC Select Trnsfer
ephone  89
device-security-mode none
mac-address 0025.B311.E0D0
ephone-template 1
type CIPC
button 1:10

Последовательность создания конференции:
- снимаем "трубку" на телефоне.
- выбираем программную клавишу Meetme (для русифицированных это Конф№). Она активна, если есть DN c conference meetme. Услышите тоновый сигнал по нажатию.
- набираем номер конференции 2222.

Все остальные могут звонить на 2222 без ограничений как на обычный телефонный номер. Подключение и отключение участников будет сопровождаться join и leave тоновыми сигналами.

К недостатку можно отнести невозможность управления участниками конференции из-за ошибок русификации. Все меню с участниками в кракозябрах.
К ограничениям можно отнести возможность создания конференции только с аппаратов, использующих sccp сигнализацию. Cisco IP-Phone с прошивками SIP, а так же телефонные шлюзы ATA не могут создавать конференции Meetme.