Возникла необходимость прикрутить QoS для ip-телефонии на граничном маршрутизаторе для предотвращения забивания канала пользовательскими торрентами. Инфраструктура следующая: граничный маршрутизатор с NAT раздает инет нескольким организациям, на маршрутизаторе несколько виртуальных интерфейсов с разными VLAN, через один заходит инет от прова, остальные клиентские, каждая организация в своем VLAN. У двух клиентов стоят сервера Asterisk, если кто-нибудь начинает что-то зверски качать начинаются проблемы со связью.
Реализовать пробовал таким образом (25.5 и 5.10 - asterisk'и):
class-map match-any voip
match ip dscp af11
class-map match-all match_org1_sip
match access-group 30
class-map match-all match_org4_net
match access-group 51
class-map match-all match_org1_net
match access-group 50
match access-group 54
class-map match-all match_org3_net
match access-group 52
class-map match-all match_org2_net
match access-group 53
match access-group 55
class-map match-all match_org2_sip
match access-group 40
class-map match-any network
match ip dscp af13
!
!
policy-map org2_in
class match_org2_net
set ip dscp af13
class match_org2_sip
set ip dscp af11
policy-map org1_in
class match_org1_net
set ip dscp af13
class match_org1_sip
set ip dscp af11
policy-map qos
class voip
shape average 4000000
class network
shape average 6000000
policy-map org3_net_mark
class match_org3_net
set ip dscp af13
policy-map org4_net_mark
class match_org4_net
set ip dscp af13
interface FastEthernet0/1.100
description org4
encapsulation dot1Q 100
ip address 192.168.35.1 255.255.255.0
no ip redirects
ip nat inside
ip virtual-reassembly
service-policy input org4_net_mark
!
interface FastEthernet0/1.101
description org1
encapsulation dot1Q 101
ip address 192.168.5.1 255.255.255.0
no ip redirects
ip nat inside
ip virtual-reassembly
service-policy input org1_in
!
interface FastEthernet0/1.102
description org2
encapsulation dot1Q 102
ip address 192.168.25.1 255.255.255.0
no ip redirects
ip nat inside
ip virtual-reassembly
service-policy input org2_in
!
interface FastEthernet0/1.103
description internets
encapsulation dot1Q 103
ip address XXXXXXXXXXXXX 255.255.255.248 secondary
ip address XXXXXXXXXXXXX 255.255.255.248
no ip redirects
ip nat outside
ip virtual-reassembly
service-policy output qos
!
interface FastEthernet0/1.104
description org3
encapsulation dot1Q 104
ip address 192.168.0.1 255.255.255.0
ip access-group org3 in
no ip redirects
ip nat inside
ip virtual-reassembly
service-policy input org3_net_markaccess-list 30 permit 192.168.5.10
access-list 40 permit 192.168.25.5
access-list 50 permit 192.168.5.0 0.0.0.255
access-list 51 permit 192.168.35.0 0.0.0.255
access-list 52 permit 192.168.0.0 0.0.0.255
access-list 53 permit 192.168.25.0 0.0.0.255
access-list 54 deny 192.168.5.10
access-list 55 deny 192.168.25.5Короче говоря, маркирую трафик dscp согласно ACLям, политика шейпит согласно dscp. Это в теории, на практике не шейпится.
С Cisco не очень давно работаю, может подскажет кто что-нибудь дельное, может методы диагностики какие-нибудь. Заранее благодарен.
> Возникла необходимость прикрутить QoS для ip-телефонии на граничном маршрутизаторе для
> предотвращения забивания канала пользовательскими торрентами. Инфраструктура следующая:
> граничный маршрутизатор с NAT раздает инет нескольким организациям, на маршрутизаторе
> несколько виртуальных интерфейсов с разными VLAN, через один заходит инет от
> прова, остальные клиентские, каждая организация в своем VLAN. У двух клиентов
> стоят сервера Asterisk, если кто-нибудь начинает что-то зверски качать начинаются проблемы
>
... конфиг поскипан
> Короче говоря, маркирую трафик dscp согласно ACLям, политика шейпит согласно dscp. Это
> в теории, на практике не шейпится.
> С Cisco не очень давно работаю, может подскажет кто что-нибудь дельное, может
> методы диагностики какие-нибудь. Заранее благодарен.
Судя по всему, забивается внешний канал на вход, но со своей стороны вы на это можете повлиять можете только ограничив скорость в сторону клиентов.
> Судя по всему, забивается внешний канал на вход, но со своей стороны вы на это можете повлиять можете только ограничив скорость в сторону клиентов.Если я все правильно понял, то политика с шейперами висит как раз на интерфейсе, смотрящем в WAN. А по поводу конфига, он действительно поскипан, привел только те фрагменты, которые касаются QoS, если что-то ещё интересует - могу запостить.
>> Судя по всему, забивается внешний канал на вход, но со своей стороны вы на это можете повлиять можете только ограничив скорость в сторону клиентов.
> Если я все правильно понял, то политика с шейперами висит как раз
> на интерфейсе, смотрящем в WAN. А по поводу конфига, он действительноОна у вас для исходящего трафика, и толку от этого нет. Повлиять на входящий трафик напрямую вы не можете. Поэтому надо ограничивать исходящий трафик на интерфейсе к клиенту.
> поскипан, привел только те фрагменты, которые касаются QoS, если что-то ещё
> интересует - могу запостить.
Спасибо, попробую, по результатам отпишусь.
Спасибо, разобрался. Ну надо же мне было так затупить...