отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
Объявления
Добро пожаловать в Сообщество Технической поддержки Cisco. Мы рады получить обратную связь .
New Member

qos pre-classify

Здравствуйте!

Коллеги, я что то не понимаю ....:-)

Есть туннель:

interface Tunnel0

qos pre-classify

tunnel source x.x.x.x

есть QoS на исходящий трафик:

interface GigabitEthernet0/0.100

ip address x.x.x.x

service-policy output INTERNET

По  идее, изменение policy-map INTERNET должно влиять только на трафик  исходящий с туннеля (qos pre-classify) , а на деле влияет на оба  направления - и на исходящий и на ВХОДЯЩИЙ трафик в туннель.

Как такое может быть?

1 УТВЕРЖДЕННОЕ РЕШЕНИЕ

Утвержденные решения

qos pre-classify

Ну для детального разбора надо смотреть весь полиси-мап\класс-мапы\ACL.

А что за трафи идёт через туннель?

Он может быть симметричным, и если вы режете тот трафик, который уходит от вас, то также просядет скорость и обратного трафика. Может дело просто в этом?

Вопрос в том, какая часть трафика просядает при применение политики.

Можно посмотреть распределение трафика по классам командой:

sh policy-map int gi0/0.100

Но удобнее так:

sh policy-map int gi0/0.100 | in Class|drop

Там в выоде можно увидеть значение offered rate  в  bps.

Только как показывает практика не на всех платформах и версиях софта эта команда отрабатвает адекватно - иногда упорно показывает нули, хотя трфик есть и политика к нему явно применяется.

12 ОТВЕТ.

qos pre-classify

Добрый день!

А почему вы считаете, что на входящий трафик влияет ваша service-policy ?

А трафик пришедший внутри туннеля через саб gi0/0.100 потом куда уходит ?

Точнее через какой интерфейс - не через этот же случаем ?

Направление, в котором трафик обрабатывается определяется в команде service-policy  на интерфейсе - OUTPUT\INPUT.

Команда  qos pre-classify  определяет CLASS пакета до того, как он будет инкапсулирован, таким образом, когда пакет выходит через физический интерфейс к нему применяется политика, соответствующая ранее определённому CLASS, вот и всё, на направления qos pre-classify не влияет.

New Member

qos pre-classify

Спасибо за ответ !

Трафик дальше идёт через другой интерфейс.

Я снимаю service-policy output INTERNET с interface GigabitEthernet0/0.100 и вижу на графике (в реалтайме) snmp рост трафика (там есть шэйперы) в туннеле на входяжем направлении, хотя эта операция и не должна давать этот прирост трафика.

qos pre-classify

Ну для детального разбора надо смотреть весь полиси-мап\класс-мапы\ACL.

А что за трафи идёт через туннель?

Он может быть симметричным, и если вы режете тот трафик, который уходит от вас, то также просядет скорость и обратного трафика. Может дело просто в этом?

Вопрос в том, какая часть трафика просядает при применение политики.

Можно посмотреть распределение трафика по классам командой:

sh policy-map int gi0/0.100

Но удобнее так:

sh policy-map int gi0/0.100 | in Class|drop

Там в выоде можно увидеть значение offered rate  в  bps.

Только как показывает практика не на всех платформах и версиях софта эта команда отрабатвает адекватно - иногда упорно показывает нули, хотя трфик есть и политика к нему явно применяется.

New Member

qos pre-classify

Спасибо! посмотрю повнимательней.

Нагружаю ftp трафиком. При снятии политики рост входящего трафика ~ 50%

New Member

qos pre-classify

ftp попадает в класс KSPD. До снятия в около 1Мбит, после снятия около 2.5Мбит

sh policy-map interface gigabitEthernet 0/0.100
GigabitEthernet0/0.100

  Service-policy output: INTERNET

    Class-map: class-default (match-any) 
      833103 packets, 324725029 bytes
      5 minute offered rate 257000 bps, drop rate 0000 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/2801/0
      (pkts output/bytes output) 825830/321551943
      shape (average) cir 6000000, bc 24000, be 24000
      target shape rate 6000000

      Service-policy : INTERNET_SHAPE

        queue stats for all priority classes:
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 102155/14204434

        Class-map: VOICE (match-any) 
          102155 packets, 14204434 bytes
          5 minute offered rate 0000 bps, drop rate 0000 bps
          Match: ip precedence 5
            102155 packets, 14204434 bytes
            5 minute rate 0 bps
          Match: access-group name VOICE
            0 packets, 0 bytes
            5 minute rate 0 bps
          Priority: 2000 kbps, burst bytes 50000, b/w exceed drops: 0

        Class-map: DB (match-all) 
          30490 packets, 9520435 bytes
          5 minute offered rate 0000 bps, drop rate 0000 bps
          Match: access-group name DB
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 30489/9520377
          bandwidth 1500 kbps

        Class-map: LOW_SPEED (match-all) 
          0 packets, 0 bytes
          5 minute offered rate 0000 bps, drop rate 0000 bps
          Match: access-group name LOW_SPEED
          police:
              cir 1000000 bps, bc 31250 bytes
            conformed 0 packets, 0 bytes; actions:
              transmit
            exceeded 0 packets, 0 bytes; actions:
              drop
            conformed 0000 bps, exceeded 0000 bps

        Class-map: KSPD (match-all) 
          193784 packets, 190630218 bytes
          5 minute offered rate 0000 bps, drop rate 0000 bps
          Match: access-group name KSPD
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/2513/0
          (pkts output/bytes output) 191271/187989486
          bandwidth 1500 kbps
          shape (average) cir 2500000, bc 10000, be 10000
          target shape rate 2500000

        Class-map: class-default (match-any) 
          506676 packets, 110370202 bytes
          5 minute offered rate 257000 bps, drop rate 0000 bps
          Match: any
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops/flowdrops) 0/288/0/0
          (pkts output/bytes output) 501915/109837646
          Fair-queue: per-flow queue limit 16 packets
            Exp-weight-constant: 9 (1/512)
            Mean queue depth: 0 packets
            class       Transmitted      Random drop      Tail/Flow drop Minimum Maximum Mark
                        pkts/bytes       pkts/bytes      pkts/bytes   thresh  thresh  prob
           
            0          500129/109528930      73/74702        215/226469            20            40  1/10
            1               0/0               0/0              0/0                 22            40  1/10
            2               0/0               0/0              0/0                 24            40  1/10
            3             283/30018           0/0              0/0                 26            40  1/10
            4               0/0               0/0              0/0                 28            40  1/10
            5               0/0               0/0              0/0                 30            40  1/10
            6            1503/278698          0/0              0/0                 32            40  1/10
            7               0/0               0/0              0/0                 34            40  1/10

qos pre-classify

1) 5 minute rate  -    создаёт очень размытую картинку, сделайте на всех интерфейсах (и туннельном тоже):

load-interval 30

Тогда статистика будет считаться за 30 сек, а не за 5 минут.

2) Вы сделали иерархический QoS (Service-policy  INTERNET_SHAPE  применена к  Default-class  Service-policy output: INTERNET, видимо ради   shape (average) cir 6000000).

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

Я бы вам посоветовал сначала отладить это не стенде - подключить ПК вместо провайдера, в качестве матчей в классах использовать что-то однозначное, например SRC_IP и с помощь ipperf запущенном на разных SRC_IP  погонять трафик и посмотреть на влияние полисера.

При работе через интернт сложно понять, что там на самом деле происходит.

3) Мне не очень понятна политика, применённая к KSPD.  Там указанны одновременно и bandwidth и shape:

        Class-map: KSPD (match-all) 

          193784 packets, 190630218 bytes

          5 minute offered rate 0000 bps, drop rate 0000 bps

          Match: access-group name KSPD

          Queueing

          queue limit 64 packets

          (queue depth/total drops/no-buffer drops) 0/2513/0

          (pkts output/bytes output) 191271/187989486

          bandwidth 1500 kbps

          shape (average) cir 2500000, bc 10000, be 10000

          target shape rate 2500000

Вы дествительно применили и то и другое?

4) На счёт bandwith скажу отдельно - я видел единичные случаи комбинаций  железо+софт, когда bandwith работал именно так, как ожидаешь.

Но на 15-той версии софта при испоьзовании иерархического QoS, как раз как в вашем случае, я обнаружил такой нюанс - вложенный shape работает фактически как bandwith.

Я поясню на примере.

Допустим мы в родительском классе сделали shape 6Mbit.

Далее во вложенной политике сделали три класса:

класс_1 = shape 4Mbit

класс_2 = shape 4Mbit

класс_дефаулт = shape 6Mbit

Реально работает такая конструкция так - если есть трафик в классе описанном раньше, то он съедает столько, сколько ему нужно, но остаётся в рамках своего shape, при этом остальным классам достаётся то, что осталось.

Т.е. если по всем классам будет загрузка на полную, то первый получит 4М, второй 2М, а дефаeлту почти ничего не останется. Но если трафика в классах 1 и 2 нету, то дефаулт съест все 6М.

New Member

qos pre-classify

2. Service-policy  INTERNET_SHAPE без него  на саб интерфейсе никак  :-(

3. Да именно так. Гарантировать 1.5, но при этом чтоб не забрал больше 2.5

4. :-(..........

Я тестировал когда трафик был только KSPD, причём в исходящем направлении он занимал максимально выделенную для него полосу - 2.5Мбит, в этом случае входящий в туннель трафик прыгает в районе чють больше 1 Мбит

Как только я убираю исходящий трафик, трафик входящий в туннель набирает свои положенные 2.5 Мбит.

чёткая зависимость входящего от исходящего трафика....

qos pre-classify

1) Тестировать лучше всего ipperf'ом и симметричным трафиком, имхо.

2) Если вы тестируете FTP, то там трафик по определению асимметриный - вы качете только в  одну сторону.

Зависимости входящего от исходящего быть не должно при НЕ симметричном трафике.

Что бы понять почему так надо более целостно представлять ситуацию, скорее всего вы просто что-то не учитываете.

New Member

qos pre-classify

Я внимательно ещё раз прочитал переписку

Sergey Goffert написал(а):

А трафик пришедший внутри туннеля через саб gi0/0.100 потом куда уходит ?

Точнее через какой интерфейс - не через этот же случаем ?


Я видимо Вас не понял.  Трафик потом уходит через другой саб на том же физическом интерфейсе.

qos pre-classify

А вот это нюанс, да.

Даже не могу сказать, как он может повлиять - надо проверять на стенде, возмжно это как раз оно.

New Member

qos pre-classify

Возможно дело вообще и не в QoS

Я отключил все полиси и нагрузил в обе стороны iperf
Есть чёткая зависимость исходящего от входящего трафика.
входящий  всегда получает существующую полосу пропускания, а вот исходящий ровно в  2 раза меньше (при наличии входящего). Если убрать входящий - исходящий  получает необходимую полосу пропускания.

Весь трафик ходит через саб интерфейсы на ОДНОМ физическом гигабит эзернете.

New Member

qos pre-classify

кстати по п.4, так вроде и всегда было, циска шэйпит  первый клас и не смотрит сколько всего...

а вот bandwith смотрит и не даёт указать больше в сумме чем пропускная способность интерфейса

Например если у меня

interface GigabitEthernet0/0.100

bandwidth 6000

то в политике циска не даст указать несколько

bandwidth, в сумме превышающих 6000 (там сколько то процентов)

455
Просмотры
0
Полезный материал
12
Ответы