Существуют технологии объединения нескольких каналов Е1 для увеличения суммарной пропускной способности. Задача заключается в создании логического интерфейса на который можно было бы "повесить" QoS политику с классами для приоритезации трафика.
В ходе испытаний выяснились следующие факты:
- логические интерфейсы Multilink (MLPPP) и
MFR используют в качестве собственного параметра пропускной способности сумму активных каналов.
router#sh ppp multilink
Multilink1
Bundle name: x
Remote Endpoint Discriminator: [1] x
Local Endpoint Discriminator: [1] x
Bundle up for 06:52:27, total bandwidth 3968, load 123/255
Receive buffer limit 24000 bytes, frag timeout 1000 ms
[skip]
Member links: 2 active, 0 inactive (max not set, min not set)
Se6/0.1/2/7/1:0, since 06:52:28
Se6/0.1/2/7/3:0, since 06:52:28
No inactive multilink interfaces
router#sh frame-relay multilink
Bundle: MFR1, State = up, class = A, fragmentation disabled
BID = MFR1
Bundle links:
Serial3/0:0, HW state = up, link state = Up, LID = Serial3/0:0
router#sh int mu1
Multilink1 is up, line protocol is up
...
MTU 1500 bytes, BW 3968 Kbit/sec, DLY 100000 usec,
reliability 255/255, txload 198/255, rxload 55/255
Encapsulation PPP, LCP Open, multilink Open
Open: IPCP, CDPCP, OSICP, loopback not set
Keepalive set (10 sec)
DTR is pulsed for 2 seconds on reset
Last input 00:00:00, output never, output hang never
Last clearing of "show interface" counters 05:38:05
Input queue: 0/75/186/0 (size/max/drops/flushes); Total output drops: 3861
Queueing strategy: Class-based queueing
Output queue: 0/1000/0 (size/max total/drops)
30 second input rate 863000 bits/sec, 1386 packets/sec
30 second output rate 3083000 bits/sec, 1540 packets/sec
23915860 packets input, 2731244914 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
24033895 packets output, 307154118 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
router#sh int mfr1
MFR1 is up, line protocol is up
Hardware is Multilink Frame Relay bundle interface
MTU 1546 bytes, BW 1984 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation FRAME-RELAY, loopback not set
Keepalive set (10 sec)
DTR is pulsed for 2 seconds on reset
LMI enq sent 5, LMI stat recvd 0, LMI upd recvd 0
LMI enq recvd 1649, LMI stat sent 1639, LMI upd sent 0, DCE LMI up
LMI DLCI 1023 LMI type is CISCO frame relay DCE
FR SVC disabled, LAPF state down
Broadcast queue 0/64, broadcasts sent/dropped 265/0, interface broadcasts 0
Last input 00:00:09, output never, output hang never
Last clearing of "show interface" counters 04:34:24
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/120 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
25694 packets input, 5677592 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
21339 packets output, 25506922 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
router#sh int mfr1.100
MFR1.100 is up, line protocol is up
Hardware is Multilink Frame Relay bundle interface
...
MTU 1546 bytes, BW 1984 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation FRAME-RELAY
- политика, применяемая к интерфейсу Multilink, должна содержать %%, а не фиксированную полосу. В противном случае, максимальная полоса для применения политики, кроме класса по-умолчанию, где полоса не задается, будет ограничена одним потоком, т.е. 1984кбит/с в данном случае. Пример политики:
router#sh policy-map E1-MLPPP
Policy Map E1-MLPPP
Class VOICE
priority 25 (%)
Class SIGNALING
priority 2 (%)
Class TRANSACTION
bandwidth 30 (%)
Class ROUTING
bandwidth 1 (%)
Class VIDEO
bandwidth 31 (%)
Class class-default
fair-queue
packet-based wred, exponential weight 9
dscp min-threshold max-threshold mark-probablity
----------------------------------------------------------
default (0) - - 1/10
router#sh run int mu1
Building configuration...
Current configuration : 292 bytes
!
interface Multilink1
...
ppp multilink
ppp multilink group 1
ppp multilink fragment disable
service-policy output E1-MLPPP
end
- политика, применяемая в классе для MFR, основывается только на той полосе, которая указана как CIR. Поэтому можно задать полосы для классов как будто имеется два рабочих Е1, вместо реально работающего одного.
router#sh policy-map E1-MFR
Policy Map Serial
Class VOICE
priority 900 (kbps)
Class SIGNALING
bandwidth 80 (kbps)
Class TRANSACTION
bandwidth 100 (kbps)
Class ROUTING
bandwidth 50 (kbps)
Class VIDEO
priority 1300 (kbps)
Class class-default
fair-queue
packet-based wred, exponential weight 9
dscp min-threshold max-threshold mark-probablity
----------------------------------------------------------
default (0) - - 1/10
router#sh run int mfr1
Building configuration...
Current configuration : 103 bytes
!
interface MFR1
mtu 1546
no ip address
frame-relay traffic-shaping
frame-relay intf-type dce
end
router#sh run int mfr1.100
Building configuration...
Current configuration : 143 bytes
!
interface MFR1.100 point-to-point
ip address ...
ip mtu 1500
frame-relay interface-dlci 100
class TEST
end
router#sh run | beg ^map-cl
map-class frame-relay TEST
frame-relay cir 3960000
frame-relay bc 39600
frame-relay be 0
frame-relay mincir 3960000
service-policy output E1-MFR
- MFR спокойно "пережил" изменение MTU на физическом и собственном интерфейсах. MLPPP отказался работать при одинаковой конфигурации с обоих сторон при увеличенном MTU, пока настройки не откатил и не произвел административное выключение/включение интерфейса mu1 на одной из сторон.
- При отсутствии ошибок на каналах, на контроллерах E1, на Serial'ах c обоих сторон появляются с одной стороны на интерфейсе Multilink входящие ошибки, чему объяснения я не нашел. При переводе на MFR ничего подобного не наблюдалось.
router2#sh int mu1
Multilink1 is up, line protocol is up
Hardware is multilink group interface
...
1794 input errors, 0 CRC, 0 frame, 0 overrun, 1794 ignored, 0 abort
- Никакого смысла применять interleaving на каналах Е1 и выше нет. Так как вносимая интерфейсом задержка на таких скоростях
пренебрежимо мала.
- задержки существенно меньше на MFR, чем на MLPPP. 40-60мс против 70-100мс
Есть у меня мнение, что ничто не мешает сделать
Frame-Relay Switch в итоге. А то как-то попадалось, что некто пытался слепить bridge-группу из ppp и еще какого-то интерфейса.