Cisco Support Community
отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 

Настройка QoS на маршрутизаторах 800 серии

Предисловие

В данной статье будет рассмотрена конфигурация QoS на маршртизаторах 800 серии при подключении офисов непосредственно к интернет, без VPN. Конфигурация выполнена для маршрутизатора C881W как самого распространенного на сегодняшний день. Несмотря на то, что данный маршрутизатор позиционируется для небольших офисов на 5-10 пользователей, зачастую требуется выполнить настройку интегрированных сервисов, включая исходящий и входящий QoS.

Введение

При подключении удаленного офиса к корпоративным хабам по MPLS или через Интернет по технологии DMVPN есть возможность настройки входящего QoS на стороне хаба. Но даже в таком случае при балансировке трафика между хабами или датацентрами, а также при использовании Spoke-to-Spoke режима в DMVPN входящий QoS нужно переносить на сторону удаленного сайта.

Поскольку QoS срабатывает в исходящем направлении, применять его нужно в направлении LAN. Подробно этот метод, названный Remote Ingress Shaping (RIS) описан в презентации brkrst-3500 “Designing Multipoint WAN QoS” с конференции CiscoLive.

Особенностями 800 серии с точки зрения функционала и настройки QoS являются:

- отсутствие единой точки агрегации LAN трафика. Наличие встроенного Ethernet модуля и Wireless AP не дают возможности применить policy-map для входящего QoS на какой-то один интерфейс.

- отсутствие поддержки практически всех функций QoS, кроме policing и marking на LAN интерфейсах (SVI)

http://www.cisco.com/c/en/us/products/collateral/routers/1800-series-integrated-services-routers-isr/prod_white_paper0900aecd8064c9f4.html

 

Исходные данные

- маршрутизатор C881W с universal IOS 15.5.3М

- отдельные VLAN-ы для пользователей LAN, WLAN и серверов

- подключение через интернет, 2 провайдера для резервирования

- внутренние сети в диапазоне 10.0.0.0/8

- static routing, NAT

- интерфейсы: Vlan1 – резервный ISP, Vlan2 – пользователи LAN, WLAN, Vlan3 – сервера

- емкость основного канала 50Мбит, резервного - 30Мбит

- используем NBAR для классификации трафика

Примечание:

Выбор данной версии IOS обусловлен его совместимостью с последней версией protocol pack-а NBAR-а:

C881W#sh ip nbar protocol-pack active

Active Protocol Pack:

Name:                            Advanced Protocol Pack
Version:                         23.0
Publisher:                       Cisco Systems Inc.
NBAR Engine Version:             23
Creation time:                   Tue Aug  2 09:04:20 UTC 2016
File:                            flash:pp-adv-isrg2-155-3.M2-23-23.0.0.pack
State:                           Active

Если вы будете обновлять IOS на universal, обратите внимание на требование к памяти в 512Mb.

Стоит отметить, что при наличие физической памяти 512Mb (это можно увидеть только при загрузке маршрутизатора), в выводе команды sh ver доступно будет только 384Mb DRAM:

C881W#sh ver
Cisco C881W-E-K9 (revision 1.0) with 363596K/29619K bytes of memory.
Processor board ID XXXXXXXXXXX
5 FastEthernet interfaces
1 Gigabit Ethernet interface
1 terminal line
1 Virtual Private Network (VPN) Module
1 cisco Embedded AP (s)
DRAM configuration is 32 bits wide
255K bytes of non-volatile configuration memory.
250880K bytes of ATA System CompactFlash (Read/Write)

То же относится и к Flash памяти: размер flash 256Mb, однако доступно только 192Mb:

C881W#dir
Directory of flash:/

    1  -rw-    55871496  Feb 27 2014 00:01:00 +00:00  c800-universalk9-mz.SPA.152-2.T.bin
    2  drw-           0  Jul 25 2016 20:09:56 +00:00  call-home
    3  -rw-         720  Jun 27 2015 09:48:48 +00:00  vlan.dat
    4  drw-           0  Jul 25 2014 20:29:46 +00:00  ccpexp
  243  -rw-        2464  Jul 26 2015 20:31:46 +00:00  home.shtml
  254  -rw-    89343796   Jul 30 2016 18:56:14 +00:00  c800-universalk9-mz.SPA.155-3.M3.bin
  255  -rw-     2522331   Jul 30 2016 19:07:54 +00:00  pp-adv-isrg2-155-3.M2-23-23.0.0.pack

200986624 bytes total (53245817 bytes free)

Такие “фокусы” с памятью связаны со встроенным модулем Wireless AP. На слатформе C881 установлен двухядерный процессор и память делится между двумя ядрами, на которых работают IOS и AP. Подробнее об этом делении можно посмотреть в этом документе:

http://www.cisco.com/c/dam/en/us/td/docs/routers/access/800/860-880-890/software/configuration/guide/SCG_880_series.pdf

 

Конфигурация RIS

WAN интерфейс на платформе – это FastEthernet4, именно к нему должен быть подключен линк на основного провайдера.

interface FastEthernet4
 description ISP1
 ip address x.x.x.x 255.255.255.252

! static route to ISP1 gateway
ip route 0.0.0.0 0.0.0.0 x.x.x.y

Поскольку единой точки агрегации входящего трафика у нас нет, мы создадим такую точку с помощью переноса LAN интерфейсов в VRF и создания туннеля между VRF и GRT (Global Routing Table).

В нашем случае оставляем внешние интерфейсы в GRT, а внутренние “прячем” в VRF. Такой выбор позволит сделать изменение удаленно, подключившсь по ssh через интернет:

ip vrf inside
 rd 1:1
 
int Loopback0
 ip address 10.1.1.1 255.255.255.255
int Loopback1
 ip address 10.1.1.2 255.255.255.255

interface Tunnel0
ip address 10.2.1.1 255.255.255.252
tunnel source Loopback0
tunnel destination 10.1.1.2
! moving NAT from LAN interface to Tunnel0 in GRT
ip nat inside

interface Tunnel1
ip vrf forwarding inside
ip address 10.2.1.2 255.255.255.252
tunnel source Loopback1
tunnel destination 10.1.1.1

int Vlan2
!LAN interface for users
 ip vrf forwarding inside
 ip address 10.0.0.1 255.255.255.0
!removing NAT from VRF
 no ip nat inside

int Vlan3
! LAN interface for servers
 ip vrf forwarding inside
 ip address 10.10.0.1 255.255.255.0
! removing NAT from VRF
 no ip nat inside
 
interface Virtual-Template1
! interface for remote access
 ip vrf forwarding inside
 ip unnumbered Vlan2
! removing NAT from VRF
 no ip nat inside

! adding routes to VRF
ip route vrf inside 10.0.0.0 255.0.0.0 Null0
ip route vrf inside 0.0.0.0 0.0.0.0 Tunnel1

! adding route for LAN networks to GRT
ip route 10.0.0.0 255.0.0.0 Tunnel0

Задачу маршрутизации между GRT и VRF можно также решить с помошью EIGRP:

router eigrp 1
 network 10.0.0.0
 no auto-summary

address-family ipv4 vrf inside
 network 10.0.0.0
 no auto-summary
 autonomous-system 1
 exit-address-family

Замечания:

Создавая точку агрегации трафика для реализации входящего QoS вы жертвуете итоговой производительностью, т.к. фактически маршрутизатор выполняет роутинг трафика дважды, сокращая производительность на 30-40%. При отсутствии шифрования трафика такая схема должна обеспечить полосу в 40-50Мбит.

Поскольку теперь трафик проходит через туннель, нужно обеспечить соответствие размера пакетов уменьшенному MTU с помощью механизма tcp adjust-mss. В данном случае мы не используем функции checksum и tunnel key на GRE туннеле:

C881W#sh int Tun0
Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 10.2.1.1/30
  MTU 17916 bytes, BW 50000 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel linestate evaluation up
  Tunnel source 10.1.1.1 (Loopback0), destination 10.1.1.2
   Tunnel Subblocks:
      src-track:
         Tunnel0 source tracking subblock associated with Loopback0
          Set of tunnels with source Loopback0, 1 member (includes iterators), on interface <OK>
  Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled

Поэтому GRE tunnel overhead будет 4 байта, а максимально возможный MSS – 1456 (1500 байт – 20 байт IP – 20 байт TCP – 4 байта GRE):

int Tun0
  ip tcp adjust-mss 1456

int Tun1
  ip tcp adjust-mss 1456

Настройка QoS

int FastEthernet4
! we will use NBAR for QoS classification
 ip nbar protocol-discovery

int Tunnel0
! we will use NBAR for QoS classification
 ip nbar protocol-discovery
 
class-map match-any media
 match protocol rtp
 match protocol skype

class-map match-any network
 match protocol ssh
 match protocol dns
 match protocol ntp

class-map match-any control
 match protocol sip

class-map match-any business
 match protocol ms-wbt
 match access-group name RDP
 match access-group name SRV
 
policy-map PM-TRAFFIC
!defining child policy
 class media
  priority 2000
 class network
  bandwidth remaining percent 7
  random-detect dscp-based
 class control
  bandwidth remaining percent 7
  random-detect dscp-based
 class business
  bandwidth remaining percent 53
  random-detect dscp-based
 class class-default
  bandwidth remaining percent 33
  fair-queue
  random-detect dscp-based

policy-map WAN-OUT
! outgoing shaper is 95% of ISP contract bandwidth
class class-default
  shape average 49000000
   service-policy PM-TRAFFIC
 
policy-map LAN-OUT
! outgoing LAN shaper is 90% of ISP contract bandwidth
 class class-default
  shape average 45000000
   service-policy PM-TRAFFIC

int FastEthernet4
 service-policy output WAN-OUT

int Tunnel0
 service-policy output LAN-OUT

Замечания:

  • для примера взяты 4 класса + default
  • описания ACL для класса business пропущены
  • в опреденеии классов используем match-any, т.к. матчатся разные приложения
  • в определении политики используем конструкцию bandwidth remaining percent. Это позволяет не высчитывать проценты явно определенных классов (priority или bandwidth)  и не ошибиться с делением
  • в child policy можно явно указывать class-default и тогда можно определить тип очереди для него - fair-queue, но также нужно указать процент, выделенный этому классу. Либо явно не определять class-default и тогда алгоритм обслуживания очереди будет fifo и классу будет отдана оставшаяся нераспределенная полоса

Проверяем, что QoS применился и работает:

C881W#sh policy-map int fa4 output 
 FastEthernet4

  Service-policy output: WAN-OUT

    Class-map: class-default (match-any)  
      167 packets, 29864 bytes
      5 minute offered rate 6000 bps, drop rate 0000 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 167/29864
      shape (average) cir 49000000, bc 156000, be 156000
      target shape rate 49000000

      Service-policy : PM-TRAFFIC
[...remaining output skipped...]

C881W#sh policy-map int tun0 output
 Tunnel0

  Service-policy output: LAN-OUT

    Service policy LAN-OUT is in suspended mode

Как видим service policy не работает. Возможно проблема в том, что на интерфейсе Tunnel не указан bandwidth, который нужен для включения механизма QoS:

C881W(config)#int Tun0
C881W(config-if)#bandwidth 50000000

C881W#sh policy-map int tun0 output
 Tunnel0

  Service-policy output: LAN-OUT

    Service policy LAN-OUT is in suspended mode

Идея хорошая, правильная, но не помогла.

Включаем debug hcf all и применяем policy-map снова:

C881W#(config)int tun0
C881W(config-if)#service-policy out LAN-OUT
*Aug  2 19:48:20.944: hqf_target_dynamic_execute_pending_events: for Tunnel0 if_number 15

*Aug  2 19:48:20.944: hqf_tunnel_ret_forwarding_if: af 1 tableid 0 tabel 1970788
*Aug  2 19:48:20.944: hqf_tunnel_ppcp_event: No forwarding path, policy suspended (Tunnel0)
*Aug  2 19:48:20.944: hqf_target_dynamic_register_intf: Register FIB intf callback (Tunnel0) with tableid=0

Исследуя этот вопрос мы обнаружим, что для работы HQF QoS требуется наличие физического интерфейса L3, через который проходит трафик. В случае туннельного интерфейса tunnel source должен быть L3 интерфейсом и трафик должен выходить через L3 интерфейс. В таком случае будут использоваться cef структуры данных физического интерфейса и полиси будет применен.

Что же теперь делать с входящим QoS?

Единственной возможностью для маршрутизаторов серии 800 является конфигурация rate-limit.

Да, мы не сможем приоритезировать все классы трафика, но сможем ограничить class-default.

Для упрощения классификации нужного трафика воспользуемся QoS функцией marking для входящего трафика:

policy-map MARK-IN
 class media
  set dscp ef
 class network
  set dscp af41
 class control
  set dscp af31
 class business
  set dscp af21
 class class-default
  set dscp 0

int FastEthertnet4
 service-policy input MARK-IN
 
access-list 100 permit ip any any dscp default
 
int Tunnel0
 rate-limit output access-group 100 20000000 18000 30000 conform-action transmit exceed-action drop

Можно ли настроить несколько rate-limit для разных классов с exceed-action remark в dscp 0 для критичных классов - это вопрос, требующий отдельного исследования.

Настройка резервирования каналов

Настроим также автоматическое переключение на резервный канал в случае проблем с основным. В качестве трекинга используем доступность шлюза и  одного из адресов Google:

ip sla 1
 icmp-echo 8.8.8.8 source-interface FastEthernet4
   freq 10
ip sla schedule 1 life forever start-time now
ip sla 2
 icmp-echo x.x.x.y source-interface FastEthernet4
   freq 10
ip sla schedule 2 life forever start-time now
track 1 ip sla 1 reachability
track 2 ip sla 2 reachability

! tracking both events
track 10 list boolean and
object 1
object 2
!delay 30 seconds for stability
 delay down 30 up 30

! primary ISP route
ip route 0.0.0.0 0.0.0.0 x.x.x.y track 10
! backup ISP route
ip route 0.0.0.0 0.0.0.0 z.z.z.z 10

Также нам потребуется EEM скрипт для очистки таблицы трансляций NAT при переключении каналов:

event manager applet clear_nat
event track 10 state any
action 0.0 cli command "enable"
action 1.0 cli command "clear ip nat trans *"
action 3.0 syslog msg "WAN Link failover or failback, cleared NAT entries"

Настройка QoS на резервном канале

Если требуется настроить QoS также и на резервном канале, то нужно учеть 2 момента:
- поскольку в большинстве случаев емкость резервного канала меньше, то использовать текущую пару туннелей не получится, т.к. полоса для rate-limit рассчитана исходя из емкости основного канала, поэтому нужно настроить допонительную пару туннелей
- если резервный канал подключен к одному из интерфейсов Fa0 - Fa3 (как в данном примере), то настроить исходящую QoS политику c shaper-ом не получится из-за ограничения платформы (см. выше).

Настраиваем туннели. В качестве Tunnel source можно взять текущие  интерфейсы Loopback0 и Loopback1, но тогда придется использовать Tunnel Key, что приведет в уменьшению эффективного MTU. Мы добавим отдельную пару Loopback интерфейсов

int Loopback2
 ip address 10.1.1.3 255.255.255.255
int Loopback3
 ip address 10.1.1.4 255.255.255.255

interface Tunnel2
 ip address 10.2.1.5 255.255.255.252
 tunnel source Loopback2
 tunnel destination 10.1.1.4
 ip nat inside
 ip tcp adjust-mss 1456

interface Tunnel3
 ip vrf forwarding inside
 ip address 10.2.1.6 255.255.255.252
 tunnel source Loopback3
 tunnel destination 10.1.1.3
 ip tcp adjust-mss 1456

Для маршрутизации трафика в новую пару туннелей в случае проблем с основным каналом поправим статические маршруты. В качестве track object используем существующий объект 10.

ip route vrf inside 0.0.0.0 0.0.0.0 Tunnel1 track 10
ip route vrf inside 0.0.0.0 0.0.0.0 Tunnel3 10

ip route 10.0.0.0 255.0.0.0 Tunnel0 track 10
ip route 10.0.0.0 255.0.0.0 Tunnel2 10

Для упрощения классификации трафика применим маркировку входящего (со стороны WAN и со стороны LAN) трафика на базе DSCP как это делалось для входящего QoS на основном интерфейсе и назначим rate-limit для class-default трафика.
ACL 100 матчит пакеты с DSCP 0.

policy-map MARK-IN
 class media
  set dscp ef
 class network
  set dscp af41
 class control
  set dscp af31
 class business
  set dscp af21
 class class-default
  set dscp 0

access-list 100 permit ip any any dscp default

int Tunnel3
 bandwidth 30000
 service-policy input MARK-IN
 rate-limit output access-group 100 10000000 17916 24000 conform-action transmit exceed-action drop

int Vlan1
 description Backup ISP
 bandwidth 30000
 service-policy input MARK-IN
 rate-limit output access-group 100 10000000 17916 24000 conform-action transmit exceed-action drop

На этом конфигурация закончена. Дальше нужно внимательно сделать за дропами в классах HQF и на полисере и сделать необходимые поправки в распределении трафика классов.

Комментарии
New Member

Добрый день!

Статья интересная, о том как можно работать с QoS и VRF, но получается, что output shaper в сторону LAN (т.е. для входящего снаружи трафика ) так и не удалось поднять. Тогда в чем все же преимущество данного метода перед входящим policer на внешнем интерфейсе с разбивкой по классам так же? На первый взгляд видно только в том, что если трафик расшифровывается именно на этой железке, то можно его классифицировать, в отличие от варианта с incoming policer на внешнем интерфейсе. Или есть еще какие-то плюсы данной реализации?

Cisco Employee

Добрый день Николай,

Совершенно верно, данный метод дает возможность классифицировать трафик уже после decryption.

770
Просмотры
5
Полезный материал
2
Комментарии