Фрагментация и LMI на Frame-Relay Печать
Cisco - QoS качество обслуживания
Автор: barabu   

Fragmentation and Interleaving with MLP over Frame-Relay - на FR сети можно достичь фрагментации с перемешиванием двумя способами: Средствами FRTS + FRF.12 Средствами MLP LFI over Frame-Relay Несколько слов об обычном MLP LFI.

heart problems or blood pressure levels pharmacy canadian If you are using the medication regularly, make missed dose as soon as you remember 10mg cialis. till looking for answers? Try looking for what we seek or daily cialis.
argaiv1499

Несколько слов об обычном MLP LFI.

  • Если MLP объединяет несколько ррр-линков, то фрагментация включается автоматически, причем каждый пакет делится на равные части по числу линков.
  • Если MLP состоит из одной линки, то по умолчанию фрагментация не выполняется до тех пор пока явно не введена команда “ppp multilink fragment delay X”. При наличии нескольких линков эта команда просто меняет размер фрагмента (фрагментация уже включена).
  • Наличие фрагментации не включает перемешивания. Его нужно включить явно.
  • По умолчанию на Multipoint интерфейсе включается WFQ. В этом случае перемешивание работает неэффективно, т.к. шедулер WFQ старается «справедливо» обслуживать очереди, в результате чего голос не имеет явного приоритета.
  • Для того чтобы MLP LFI эффективно перемешивал нужно, чтобы на Multilink интерфейсе работала не WFQ, а что-то с механизмом PQ (например, LLQ). Тогда на админа ложится обязанность правильно классифицировать траф, чтобы голос попал в low-latency буфер.
  • MLP Interleave, т.е. перемешивание, работает только на одной линке из bundlе. Дело в том, что маленькие голосовые пакеты не фрагментируются, а значит отправляются в оригинальном виде без дополнительный служебных заголовков, содержащих sequence number. А раз нет sequence number’а, то принимающая сторона не сможет упорядочить пакеты если они будут приходить по параллельным линкам.

NOTE: Вообще перемешиванием фактически занимается шедулер механизма очередей. Он работает по своему обычному алгоритму, а наша задача – позаботиться о том, чтобы в приоритетный буфер попадал голосовой траф. Тогда шедулер будет захватывать его раньше, чем фрагменты пакетов, помещенные в другие буферы.

Теперь о MLP LFI over Frame-Relay. Для работы этого механизма необходимы два условия:

  • FRTS должен быть включен.
  • На VC, входящем в MLP, должна быть очередь FIFO.

Далее дана конфига для настройки фичи. А также моя схема показывающая,  весь процесс.

map-class frame-relay frts-102 <--- We need FRTS and FIFO queue per VC

frame-relay cir 512000

frame-relay bc 5120 <--- Tc will be 10 ms

frame-relay be 0

-------------------------------------

class-map match-all cm-voice

match ip rtp 16384 16383

!

policy-map pm-llq <--- LLQ for Multipoint interface

class cm-voice

priority 128

class class-default

fair-queue

--------------------------

!

interface Virtual-Template1

no ip address

ppp multilink

ppp multilink group 10

!

interface Serial1/0 <--- Assume the clock rate is 512000

no ip address

encapsulation frame-relay

frame-relay traffic-shaping

!

interface Serial1/0.102 point-to-point

frame-relay interface-dlci 102 ppp Virtual-Template1

class frts-102 <--- Shape Class for PVC 102

--------------------------

interface Multilink10

bandwidth 512

ip address 131.1.88.1 255.255.255.0

ppp multilink

ppp multilink fragment delay 10

ppp multilink interleave

ppp multilink group 10

service-policy output pm-llq <--- LLQ for output packets

------------------------------

R1#sh int se1/0

Serial1/0 is up, line protocol is up

......

Queueing strategy: dual fifo <--- Dual FIFO even without FRF.12

Output queue: high size/max/dropped 0/256/0

Output queue: 0/128 (size/max)

......

R1#sh int mu10

Multilink10 is up, line protocol is up

......

Queueing strategy: Class-based queueing

......

R1#sh queueing interface se1/0

Interface Serial1/0 queueing strategy: priority

Output queue utilization (queue/count)

high/550 medium/0 normal/55 low/0

 
rss