The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"QoS + tunnel interface"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Маршрутизаторы CISCO и др. оборудование. (Cisco маршрутизаторы)
Изначальное сообщение [ Отслеживать ]

"QoS + tunnel interface"  +/
Сообщение от cisco (??) on 04-Фев-10, 16:25 
Добрый всем день!
Существует схема в которой есть распределенные филиалы с головным офисом в центре. В филиалах есть cisco 871, в центре cisco 1841. Есть необходимость настроить QoS учитывая, что в сети подняты тунели. Как изначально сделать все правильно?
Теоретически, думаю, что во всех филиалах необходимо класифицировать трафик и распределить полосу для каждого из них до того как трафик будет попадать в тунель. В головном офисе делать тоже самое...!?
И как связать VPN c QoS?
Просьбa, поделитесь идеями!
Высказать мнение | Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "QoS + tunnel interface"  +/
Сообщение от Aemon email on 04-Фев-10, 18:31 
>Добрый всем день!
>Существует схема в которой есть распределенные филиалы с головным офисом в центре.
>В филиалах есть cisco 871, в центре cisco 1841. Есть необходимость
>настроить QoS учитывая, что в сети подняты тунели. Как изначально сделать
>все правильно?
>Теоретически, думаю, что во всех филиалах необходимо класифицировать трафик и распределить полосу
>для каждого из них до того как трафик будет попадать в
>тунель. В головном офисе делать тоже самое...!?
>И как связать VPN c QoS?
>Просьбa, поделитесь идеями!

и вам день добрый!
Для вашего случая подходит архитектура DMVPN. О том как строить это можете почитать здесь: http://xgu.ru/wiki/DMVPN
Теперь об особенностях. В указанной мною статье не рассматривается использование QoS, потому вам нужно учесть следующее (после построения архитектуры DMVPN):

1) на туннельных интерфейсах прописать опции qos pre-classify (соотв. кусок конфига приведу в конце)
2) для использования качества обслуживания определитесь для чего вам нужны QoS'ы? Если для сервера видеоконференций, то просто выделите каждому филиалу исходящюю зарезервированную полосу, если задач поболее, то подумайте как именно делить хотите. При написании class-map'ов не забудьте опцию shape average percent 100, чтоб все "завелось"


Обещанные части конфигов:
class-map match-all INTERNAL
match access-group name INTERNAL
class-map match-all UDP
match access-group name UDP
class-map match-all VIDEO
match access-group name VIDEO
!
!
policy-map QoS
class VIDEO
  priority percent 50
class INTERNAL
  bandwidth percent 20
class UDP
  bandwidth percent 5
class class-default
  fair-queue
policy-map Shaper
class class-default
  shape average percent 100
  service-policy QoS

interface Tunnel0
ip address 10.1.1.1 255.255.255.0
no ip redirects
ip mtu 1416
no ip next-hop-self eigrp 1
ip nhrp map multicast dynamic
ip nhrp network-id 999
no ip split-horizon eigrp 1
qos pre-classify
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint
tunnel key 999
tunnel protection ipsec profile DMVPN

interface GigabitEthernet0/0
description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-GE 0/0$
ip address 192.168.100.1 255.255.255.0
ip pim sparse-mode
duplex auto
speed auto
media-type rj45
service-policy output Shaper
!

Если нужны полные конфиги говорите.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "QoS + tunnel interface"  +/
Сообщение от GolDi (??) on 05-Фев-10, 09:54 
>[оверквотинг удален]
> description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-GE 0/0$
> ip address 192.168.100.1 255.255.255.0
> ip pim sparse-mode
> duplex auto
> speed auto
> media-type rj45
> service-policy output Shaper
>!
>
>Если нужны полные конфиги говорите.

А что service-policy на  int tunnel0 нельзя повесить?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

3. "QoS + tunnel interface"  +/
Сообщение от Aemon email(ok) on 05-Фев-10, 10:07 
> А что service-policy на  int tunnel0 нельзя повесить?

Можно. Но тут дело в том, что используя архитектуру DMVPN нельзя быть уверенным, что QoS'ы будут использоваться в направлении к центральному узлу (когда передача будет вестись по интерфейсу tunnel0), ибо если идет связь между споками (spoke), то создается иной интерфейс, к примеру tunnel1, и тогда к нему не будут применяться правила описанные в service-policy. Потому было принято решение вешать на физический интерфейс.
Минусом DMVPN является невозможность задания правил для каждого виртуального туннельного интерфейса в отдельности, для отдельного указания необходимо использовать технологию с виртуальными интерфейсами.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

4. "QoS + tunnel interface"  +/
Сообщение от cisco (??) on 05-Фев-10, 12:12 
Спасибо огромное за столь подробный ответ.

Хорошо, согласен на счет DMVPN, но при нынешней конфигурации (без DMVPN), будет ли работать корректо QoS при использовании тунельных интерфейсов?

Так правильно?

interface tunnel 1
description <<< LAN >>>
ip address 10.1.1.1 255.255.255.0
qos pre-classify
tunnel source GigabitEthernet0/0
tunnel destination 1.1.1.1
tunnel protection ipsec profile VTI
tunnel mode ipsec ipv4
service-policy output Shaper

У меня 3,4 вида трафика между филиалами и ц. офисом, которым хочется отдать особый приоритет. Мне еще посоветовали организовать очередь определив для каждого трафика один из четырех класов: high, medium, normal, low с помощью priority-list 1 protocol ip high list VIDEO-TRAFFIC-acl.
Но где-то прочитал что на тунельных интерфейсах это делать нельзя.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

5. "QoS + tunnel interface"  +/
Сообщение от Aemon email(ok) on 05-Фев-10, 12:56 
Пожалуйста!
Без использования DMVPN данные настройки QoS будут работать. Что касается классов, то вашего вопроса не особо понял. Рекомендуюь обычно устанавливать тип класса - золотой, серебрянный и простой, но я так не делал. Вместо этого я приоритезировал по типам качества обслуживания (priority - гарантированная пропсукная способность при любых условиях, bandwidth - "полоса не ниже чем" или же fair-queue - всем оставшимся справедливо между собой), для разных задач. думаю для ваших 3-4 видов вполне хватит.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

6. "QoS + tunnel interface"  +/
Сообщение от cisco (??) on 05-Фев-10, 16:04 
>Пожалуйста!
>Без использования DMVPN данные настройки QoS будут работать. Что касается классов, то
>вашего вопроса не особо понял. Рекомендуюь обычно устанавливать тип класса -
>золотой, серебрянный и простой, но я так не делал. Вместо этого
>я приоритезировал по типам качества обслуживания (priority - гарантированная пропсукная способность
>при любых условиях, bandwidth - "полоса не ниже чем" или же
>fair-queue - всем оставшимся справедливо между собой), для разных задач. думаю
>для ваших 3-4 видов вполне хватит.

Кстати, попробовал выделить для теста icmp трафик:
class-map match-all ICMP
match access-group name MATCH_ICMP
class-map match-all GRE
match access-group name MATCH_GRE

policy-map MyPolicy
class ICMP
class GRE

interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.252
service-policy output MyPolicy

Сделал:

R1# ping удаленный рутер repeat 10

При этом:
show policy-map interface f0/0
Service-policy output: MyPolicy

Class-map: ICMP (match-all)
  10 packets, 1240 bytes
  30 second offered rate 0 bps
  Match: protocol icmp

Class-map: GRE (match-all)
  0 packets, 0 bytes
  30 second offered rate 0 bps
  Match: protocol gre

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

Я не понял, как такое получилось, если на выходе fastethernet-a у меня уже инкапсулированный трафик? Qos какимто образом в инкапсулированном трафике увидел icmp заголовок...И какой тогда смысл в qos pre-clasify?
...

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

7. "QoS + tunnel interface"  +/
Сообщение от Valery12 (ok) on 06-Фев-10, 08:51 
>Пожалуйста!
>Без использования DMVPN данные настройки QoS будут работать.

а для DMVPN есть еще более красивое решение - QoS настраивается на хабе и по NHRP распространяется на споки вот ссылка
http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/...

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

8. "QoS + tunnel interface"  +/
Сообщение от weez on 08-Фев-10, 10:10 
Не, там про распространение на споки ничего не говорится. Это просто удобный способ применять QOS полиси на хабе на egress в зависимости от различных nhrp-group сконфигурированных на споках.

>а для DMVPN есть еще более красивое решение - QoS настраивается на
>хабе и по NHRP распространяется на споки вот ссылка
>http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/...

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

9. "QoS + tunnel interface"  +/
Сообщение от gvm email on 13-Июн-10, 21:04 
уважаемый Aemon, ваш пример очень помог (у меня такая точно задача). Однако есть одно но. Сделав все по вашему примеру, классы VIDEO,INTERNAl,UDP стали гарантировано получать полосу однако, если же вышеуказанные класы незанимают канал(нет соответсвуюющего трафика), они все равно продолжают резервировать канал "под себя" - получается нерациональное использование канала :( Как можно настроить выделение полосы "динамически" в зависимости т загрузки?? Спасибо!
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру