Skip to content
  • Категории
  • Последние
  • Метки
  • Популярные
  • Пользователи
  • Группы
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • По умолчанию (Нет скина)
  • Нет скина
Collapse

Networks Engineering

  1. Главная
  2. Сети (Routing & Switching)
  3. Маршрутизация
  4. QOS

QOS

Запланировано Прикреплена Закрыта Перенесена Маршрутизация
15 Сообщения 0 Posters 0 Просмотры
  • Сначала старые
  • Сначала новые
  • По количеству голосов
Ответить
  • Ответить, создав новую тему
Авторизуйтесь, чтобы ответить
Эта тема была удалена. Только пользователи с правом управления темами могут её видеть.
  • M Не в сети
    M Не в сети
    Mlex1
    написал в отредактировано
    #4

    Здравствуйте Например, если у вас есть пакеты VOIP и класс видеопотока, оба с LLQ, и вы хотите обеспечить предпочтительное обращение с пакетами VOIP, вы связываете их класс-карту с наилучшим уровнем приоритета (вероятно, 1), а класс видео — с менее предпочтительным уровнем приоритета (вероятно, 2). Я прочитал в Интернете то, что вы написали. У меня немного другой вопрос: я имею в виду, что при настройке
    приоритета 1 процент 30 и приоритета 30 процент
    результат будет одинаковым? Желаю всего наилучшего.

    1 ответ Последний ответ
    0
    • G Не в сети
      G Не в сети
      Giuseppe Larosa
      написал в отредактировано
      #5

      Здравствуйте,
      @Mlex1
      , если у вас только один класс трафика LLQ, результат будет таким же. Надеюсь, это поможет Джузеппе

      1 ответ Последний ответ
      0
      • M Не в сети
        M Не в сети
        Mlex1
        написал в отредактировано
        #6

        Хорошо, для примера я выбрал этот вариант, как это работает на практике? policy-map TEST
        class FOR_TEST
        priority percent 30 трафик с приоритетом всегда будет контролироваться до 30% пропускной способности интерфейса, приоритетный трафик никогда не может использовать более 30% пропускной способности интерфейса.
        Я прав? Желаю всего наилучшего

        1 ответ Последний ответ
        0
        • J Не в сети
          J Не в сети
          Joseph W. Doherty
          написал в отредактировано
          #7

          приоритетный трафик всегда будет контролироваться до 30% пропускной способности интерфейса, «Всегда», нет. (Для постоянного контроля необходимо добавить явный контролер.) приоритетный трафик никогда не может использовать более 30% пропускной способности интерфейса. «Никогда», нет; может использовать до 100%. (По крайней мере,
          удивительно
          , но раньше так и было.)

          1 ответ Последний ответ
          0
          • M Не в сети
            M Не в сети
            Mlex1
            написал в отредактировано
            #8

            Если у вас есть ссылка, поделитесь ею, пожалуйста, или любой другой документацией. Желаю всего наилучшего

            1 ответ Последний ответ
            0
            • J Не в сети
              J Не в сети
              Joseph W. Doherty
              написал в отредактировано
              #9

              Кроме того, что уже ответил
              @balaji.bandi
              ? Поскольку на ваши первоначальные вопросы уже даны ответы, есть ли у вас другие вопросы, или ответы неясны, или вы ищете подтверждение в документации? Поскольку QoS — это обширная тема, постарайтесь быть как можно более конкретными в своих последующих вопросах.

              1 ответ Последний ответ
              0
              • M Не в сети
                M Не в сети
                Mlex1
                написал в отредактировано
                #10

                В условиях перегрузки приоритетный класс не может использовать избыточную пропускную способность. Я правильно понимаю, что если нет перегрузки интерфейса, приоритетный класс может использовать более 30 или 40% и так далее? Желаю всего наилучшего.

                1 ответ Последний ответ
                0
                • J Не в сети
                  J Не в сети
                  Joseph W. Doherty
                  написал в отредактировано
                  #11

                  Я правильно понимаю, что если нет перегрузки интерфейса, приоритет может использовать более 30 или 40% и так далее? Верно. Кстати, это не только мое мнение, это также утверждает Cisco в своей документации, на которую ссылается
                  @balaji.bandi
                  и которую я привел в предыдущем ответе. Я полагаю, что причина такого поведения заключается в том, что неявный полисер гарантирует трафику, не относящемуся к LLQ, определенный процент пропускной способности, но, как и в случае с другими классами, если есть доступная пропускная способность, трафик класса LLQ может ее использовать. Если вы хотите всегда ограничивать пропускную способность класса LLQ, вы можете настроить явный полисер.

                  1 ответ Последний ответ
                  0
                  • J Не в сети
                    J Не в сети
                    Joseph W. Doherty
                    написал в отредактировано
                    #12

                    Кстати, техническая записка по ATM, на которую я ссылался:
                    https://www.cisco.com/c/en/us/support/docs/asynchronous-transfer-mode-atm/ip-to-atm-class-of-service/6142-txringlimit-6142.html Как я уже писал ранее, настройка tx-ring-limit может иметь решающее значение для правильной работы политики CBWFQ, и не только для интерфейсов ATM или поддержки голосовой связи. По сути, она контролирует настройку глубины аппаратной
                    FIFO
                    -очереди интерфейса. Перефразируя фразу из
                    «Дюны»
                    «Страх убивает разум»,
                    можно
                    сказать,
                    что FIFO убивает QoS
                    . Кроме того, «вещи» очереди CBWFQ вступают в игру только при переполнении очереди tx-ring. Я упоминаю об этом, потому что любой, кому нужно использовать LLQ, скорее всего, пытается обеспечить эффективное QoS.

                    1 ответ Последний ответ
                    0
                    • B Не в сети
                      B Не в сети
                      balaji.bandi
                      написал в отредактировано
                      #13

                      Добавляю предложение и пояснение
                      @Giuseppe Larosa
                      . Какая модель устройства и код IOS используется на устройстве? Ознакомьтесь с приведенным ниже справочным руководством: https://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-packet-marking/10100-priorityvsbw.html BB
                      =====Preenayamo Vasudevam=====
                      ***** Оцените все полезные ответы *****
                      Как обратиться за помощью к сообществу Cisco

                      1 ответ Последний ответ
                      0
                      • M Не в сети
                        M Не в сети
                        Mlex1
                        написал в отредактировано
                        #14

                        Привет Полагаю, вы также неправильно поняли, что в ссылке речь идет именно о проценте оставшейся пропускной способности Желаю всего наилучшего

                        1 ответ Последний ответ
                        0
                        • J Не в сети
                          J Не в сети
                          Joseph W. Doherty
                          написал в отредактировано
                          #15

                          Эти настройки отличаются или совпадают, и как они работают в реальных условиях? policy-map TEST класс FOR_TEST priority lavel 1 percent 30 ! policy-map TEST класс FOR_TEST приоритет процент 30 Как показано, они одинаковы (и как уже описано другими). Также, как и: policy-map TEST класс FOR_TEST уровень приоритета 2 процент 30 Что касается того, как они будут работать, все они будут обеспечивать один физический LLQ, а трафик
                          только
                          в классе FOR_TEST будет контролироваться на уровне 30%, но
                          только
                          в случае перегрузки (в отличие от явного контролера).

                          1 ответ Последний ответ
                          0

                          Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.

                          Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.

                          С вашими комментариями этот пост может стать ещё лучше 💗

                          Зарегистрироваться Войти
                          Ответить
                          • Ответить, создав новую тему
                          Авторизуйтесь, чтобы ответить
                          • Сначала старые
                          • Сначала новые
                          • По количеству голосов


                          • Войти

                          • Нет учётной записи? Зарегистрироваться

                          • Login or register to search.
                          • Первое сообщение
                            Последнее сообщение
                          0
                          • Категории
                          • Последние
                          • Метки
                          • Популярные
                          • Пользователи
                          • Группы