застосування QoS на "змінній" швидкості зв'язку, коли узгодження здійснюються перевізниками NTE

По суті, ми купуємо лінію 80/20 у перевізника, який забезпечує транспорт між приміщеннями клієнта та місцевою біржею, де перевізник переходить на наше ПЕ.

(Juniper PE) <--> [Взаємозв'язок несучої в Exchange <---> NTE у власності клієнта] <---> (Cisco CPE - 881,1921,1941,2921))

Схема між власністю замовника та місцевим вуличним шафою все ще мідна, а тому у міру збільшення шуму / відстані швидкість зменшується.

фактичне узгодження швидкості лінії відбувається на перевізниках NTE, а не нашому CPE.

як я можу гарантувати, що коли посилання насичене пріоритетними пакетами не випадає, не знаючи насправді, на яку швидкість лінії встановлено автентифікацію? можна щось зробити з ipsla?

qos cisco-ios-15

— ДрБру
джерело

Ви говорите про конфігурацію QoS на CPE для напрямку завантаження?

— jwbensley

@javano двосторонній дійсно, на даний момент єдиний доступний для мене варіант - це формувати трафік з обох сторін до середнього рівня так само, як ти рекомендуєш у відповідь, я намагаюся встановити, чи є інший спосіб, як це можна зробити більш точно .

— ДрБру

Ви не можете реально вирішити це, не надто консервативно здогадуючись, яку ставку завжди буде дотримано. Досліджуйте припинення з'єднання безпосередньо у вашій Cisco CPE, видаляючи NTE. Тоді інтерфейс Cisco CPE дізнається лінійну передачу.

— ytti

@ytti Спасибі, на сьогоднішній день його фінанси спонукають нас використовувати перевізника як проміжний & fttc - це все ще ДУЖЕ нове.

— DrBru

@IanK так, але якщо це DSL чи щось подібне, ви не можете просто замінити модем повністю і використовувати лише свій власний CPE? Тоді ви можете застосувати QoS до інтерфейсу, який знає швидкість.

— ytti

Однією з можливостей є те, що якщо ви хочете, щоб QoS-трафік вгору до шлюзу CPE - це формувати вихідний трафік, а потім визначати пріоритет важливого трафіку в межах цієї пропускної здатності.

Якщо це лінія 80/20, і ви знаєте, що середня швидкість збільшення дорівнює 15 Мбіт / с, ви можете сформувати вихідний трафік до 15 Мбіт / с і визначити пріоритет голосу в межах 15 Мбіт / с. Якщо швидкість синхронізації знизиться на пару Мбіт / с, це не змінить великої кількості. Якщо швидкість синхронізації зросте до 17 Мбіт / с, вони не матимуть декількох Мбіт / с пропускної здатності завантаження.

Я використовую конфігурацію, як удар по деяких лініях EFM. Швидкість EFM може змінюватись в залежності від лінійних умов, щойно встановлені, хоча вони здаються дуже стійкими. Отже, у цьому прикладі ця CPE підключена до лінії 20/20 EFM, яка фактично надійно синхронізується на 10/10, завантаження має форму 10Mbps.

class-map match-any CM-VOICE-TRAFFIC
 match access-group 100
!
policy-map PM-PRIORITISE-VOICE
 class CM-VOICE-TRAFFIC
   set ip dscp ef
   priority 1000
 class class-default
   fair-queue
!
policy-map PM-SHAPE-10M
 class class-default
  shape average 10000000
  service-policy PM-PRIORITISE-VOICE
!
interface FastEthernet0/1
 Description WAN Interface
 bandwidth 10000
 service-policy output PM-SHAPE-10M
!
access-list 100 remark Priority IP Destinations
access-list 100 permit ip 1.2.3.0 0.0.0.255 any

Важливо, щоб ми формували тут не ліміт тарифів чи поліцейських, щоб трафік не падав, він "формувався" до наявної пропускної здатності. Прочитайте цю сторінку Cisco, щоб отримати додаткову інформацію.

— jwbensley
джерело

Я не думаю, що це працює, проблема ОП у тому, що він не знає, де формувати зв'язок. Якщо ви сформулюєте його в 10 Мбіт / с, ви ОБОВ'ЯЗКОВО зможете пройти 10 Мбіт / с, щоб зберегти договір "CM-VOICE-TRAFFIC".

— ytti