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

Вопросы по LLQ

Добрый вечер коллеги.

 

 

Требуется настроить LLQ для трафика идущего через DMVPN Cloud (Phase1) + к нескольким public ip в Internet.

Оборудование 3925E/881/819.

 

1) в направлении branch -> dmvpn_cloud-> HQ

 VOICE - 512 kbit/s (тут voice signaling + RTP/данный трафик идёт и через dmvpn и к public ip в Internet)

Business critical data - 512 kbit/s (тут трафик идёт только к Public ip в Internet)

VIDEO - 512 kbit/s (трафик идёт только через DMVPN)

Routing - 16 kbit/s (тут только eigrp в DMVPN)

VPN 16 kbit/s (IPSec через Internet)

Net-MGMT - 32 kbit/s (тут и через dmvpn + internet)

Scavenger - DROP

Best-Effort - всё остальное (WRED)

 

Классы трафика VOICE/Business critical data - критичны к delay/jitter/loss, поэтому используем PQ.

Для всего остального используем CBWFQ.

Точной ширины каналов я не знаю, по договорам якобы 2 Mbit/s, по факту как получится.

(тут сразу вопрос, какое значение bandwidth ставить на интерфейсе или если я чётко выставляю bandwidth в kbit/s это не важно  ?)

 

настройка:

# Для классификации трафика использую acl + Nbar

# класс Business critical

#sh access-list discount
Extended IP access list discount
    10 permit tcp any host X.X.X.X eq XXXX (6564 matches)
    20 permit tcp host X.X.X.X eq XXXX any (6897 matches)

 

 

class-map match-any discount
 match access-group name discount

 

 


class-map match-any VPN
 match protocol gre
 match protocol ipsec
 match protocol isakmp


class-map match-any VIDEO
 match access-group name video-surveillance


class-map match-any VOICE
 match access-group name voip
 match protocol h323
 match protocol sip
 match protocol mgcp
 match protocol rtp
 match protocol rtcp


class-map match-any ROUTING
 match protocol ospf
 match protocol eigrp
 match protocol bgp


class-map match-any SCAVENGER
 match protocol gnutella
 match protocol fasttrack
 match protocol kazaa2
 match protocol bittorrent
 match protocol edonkey
 match protocol winmx
 match protocol directconnect
 match protocol bittorrent-networking
 match protocol encrypted-bittorrent
 match protocol encrypted-emule

 


class-map match-any NET-MGMT
 match protocol telnet
 match protocol ssh
 match protocol snmp
 match protocol icmp

 

 

policy-map NEW-1
 class discount
  priority 512
 class VOICE
  priority 512
 class VIDEO
  bandwidth 512
 class ROUTING
  bandwidth 16
 class NET-MGMT
  bandwidth 32
 class VPN
  bandwidth 16
 class SCAVENGER
  drop
 class class-default
  random-detect

 

Далее на туннельных интерфейсах указываю: qos pre-classify

После чего данную политику применяю к физическому интерфейсу fa4 (outside в интернет):

 

int fa4

 service-policy output NEW-1

 

Что-то ещё требуется ?

 

 

2 УТВЕРЖДЕН. РЕШЕН.

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

bandwidth на интерфейсе это

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

Для SPOKE будет выглядеть примерно так:

policy-map SHAPE_PMAP
 class A
  priority percent 20
 class B
  bandwidth percent 2
 class C
  bandwidth percent 5
 class class-default
  fair-queue
  random-detect
!
policy-map OUTSIDE_PMAP
 class class-default
  shape average [BANDWIDTH] [BANDWIDTH_Bc]
 service-policy SHAPE_PMAP

 

Для HUB:

 

ip access-list extednded SPOKE_A_ACL

permit ip any host <spoke_A>

ip access-list extednded SPOKE_B_ACL

permit ip any host <spoke_B>

 

class-map SPOKE_A_MAP
 match access-group name SPOKE_A_ACL

class-map SPOKE_B_MAP
 match access-group name SPOKE_B_ACL

 

policy-map OUTSIDE_PMAP
 class SPOKE_A_MAP
  shape average 2048000
  service-policy SHAPE_A_PMAP

 class SPOKE_B_MAP
  shape average 2048000
  service-policy SHAPE_B_PMAP

 

Также можно использовать per-tunnel qos, это более масштабируемо, чем классификация на основе внешних адресов spoke:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_dmvpn/configuration/15-mt/sec-conn-dmvpn-15-mt-book/sec-conn-dmvpn-per-tunnel-qos.html

Ответ на вопрос по bandwidth

Ответ на вопрос по bandwidth - да. Это информационный параметр. Перегрузка происходит из-за ограничения полосы у провайдера, до провайдера у вас физический линк на заданной скорости физики.

Если Вы хотите для классификации внутреннего туннельного трафика использовать NBAR, то, безусловно, нужно использовать политику на туннеле для туннельного трафика. Но Вас никто не ограничивает, Вы можете также использовать поликику и на внешнем интерфейсе для классификации трафика Интернет, не забывайте при этом учитывать, конечно, ваш туннельный ESP-трафик.

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

Пожалуйста, не забывайте отмечать мои ответы как полезные, если они Вам помогли.

22 ОТВЕТ.

bandwidth на интерфейсе это

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

Для SPOKE будет выглядеть примерно так:

policy-map SHAPE_PMAP
 class A
  priority percent 20
 class B
  bandwidth percent 2
 class C
  bandwidth percent 5
 class class-default
  fair-queue
  random-detect
!
policy-map OUTSIDE_PMAP
 class class-default
  shape average [BANDWIDTH] [BANDWIDTH_Bc]
 service-policy SHAPE_PMAP

 

Для HUB:

 

ip access-list extednded SPOKE_A_ACL

permit ip any host <spoke_A>

ip access-list extednded SPOKE_B_ACL

permit ip any host <spoke_B>

 

class-map SPOKE_A_MAP
 match access-group name SPOKE_A_ACL

class-map SPOKE_B_MAP
 match access-group name SPOKE_B_ACL

 

policy-map OUTSIDE_PMAP
 class SPOKE_A_MAP
  shape average 2048000
  service-policy SHAPE_A_PMAP

 class SPOKE_B_MAP
  shape average 2048000
  service-policy SHAPE_B_PMAP

 

Также можно использовать per-tunnel qos, это более масштабируемо, чем классификация на основе внешних адресов spoke:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_dmvpn/configuration/15-mt/sec-conn-dmvpn-15-mt-book/sec-conn-dmvpn-per-tunnel-qos.html

New Member

А применять политику лучше на

 

А применять политику лучше на физ. интерфейс или логические туннели ?

Получается на основе значения bandwidth на интерфейсе и его текущей утилизации оборудование не поймёт, что появилась congestion?

просто если я смотрю средствами nbar на туннельных интерфейсах и на физических в сторону провайдера, я вижу разные цифры по трафику/протоколам + через туннельные ходит трафик только к HQ , а там только часть ресурсов к которым мне требуется применить политику LLQ.

В итоге мне потребуется применить политику и на внешний интерфейс, и на туннельных.

Ответ на вопрос по bandwidth

Ответ на вопрос по bandwidth - да. Это информационный параметр. Перегрузка происходит из-за ограничения полосы у провайдера, до провайдера у вас физический линк на заданной скорости физики.

Если Вы хотите для классификации внутреннего туннельного трафика использовать NBAR, то, безусловно, нужно использовать политику на туннеле для туннельного трафика. Но Вас никто не ограничивает, Вы можете также использовать поликику и на внешнем интерфейсе для классификации трафика Интернет, не забывайте при этом учитывать, конечно, ваш туннельный ESP-трафик.

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

Пожалуйста, не забывайте отмечать мои ответы как полезные, если они Вам помогли.

New Member

А если я не буду использовать

А если я не буду использовать вложенную политику вида с шейпингом:

 

policy-map BRANCH-WAN-EDGE
 class class-default
  shape average 20000000
   service-policy NEW-1

 

У меня PQ отработает, а распределение BW между остальными классами нет ?

 

Нет, не отработает. Политики

Нет, не отработает. Политики QoS работают только при перегрузке, в т.ч. LLQ., т.е. с помощью шейпера, грубо говоря, маршрутизатор поймет что у него не хватает пропускной способности для исходящего трафика.

New Member

А как быть, если есть 3G/LTE

А как быть, если есть 3G/LTE интерфейс где вообще не ясно какая там BW? Тоже самое и с проводными интернет каналами, в договоре цифра 2 Mbit/s, а по факту как получится. В shaping ставить что?) Или сидеть мерить каждый канал и методом перебора крутить политику ?

Если провайдер в договоре

Если провайдер в договоре указывает пропускную способность 2 Мбит/с, то от него и нужно требовать соответствующую пропускную, не вижу здесь других вариантов. С 3G/LTE все сложнее, не могу что-либо советовать с уверенностью.

New Member

При попытке повесить политику

При попытке повесить политику на логические интерфейсы Tunnel возникает ошибка:

 

(config-if)#service-policy output BRANCH-WAN-EDGE

Insufficient bandwidth 448 kbps for bandwidth guarantee

 

при этом:

sh int tun1 | i BW
  MTU 17870 bytes, BW 4096 Kbit/sec, DLY 50000 usec,

 

 

а в политике я указываю только :

 class discount - 512 kbit/s
 class VOICE - 512 kbit/s
 class VIDEO - 512 kbit/s
 class ROUTING - 16 kbit/s
 class NET-MGMT - 32 kbit/s
 class VPN - 16 kbit/s
 class-default - остальное

в сумме: 1600 kbit/s

Раньше по умолчанию можно было выделять 75%, сейчас с HQF - 100%.

Почему ошибка тогда ?
 

 

 

Покажите sh run | sec class

Покажите sh run | sec class-map|policy-map и вывод show int t1 полностью, все станет ясно. Что там с class-default, не забыли ли выделить ему пропускной способности?

New Member

class-map match-any discount

class-map match-any discount
 match access-group name discount
class-map match-any VPN
 match protocol gre
 match protocol ipsec
 match protocol isakmp
class-map match-any VIDEO
 match access-group name video-surveillance
class-map match-any VOICE
 match access-group name voip
 match protocol h323
 match protocol sip
 match protocol mgcp
 match protocol rtp
 match protocol rtcp
class-map match-any ROUTING
 match protocol ospf
 match protocol eigrp
 match protocol bgp
class-map match-any SCAVENGER
 match protocol gnutella
 match protocol fasttrack
 match protocol kazaa2
 match protocol bittorrent
 match protocol edonkey
 match protocol winmx
 match protocol directconnect
 match protocol bittorrent-networking
 match protocol encrypted-bittorrent
class-map match-any NET-MGMT
 match protocol telnet
 match protocol ssh
 match protocol snmp
 match protocol icmp
policy-map NEW-CELLULAR
 class discount
  priority 512
 class VOICE
  priority 512
 class VIDEO
  drop
 class ROUTING
  bandwidth 16
 class NET-MGMT
  bandwidth 32
 class VPN
  bandwidth 16
 class SCAVENGER
  drop
 class class-default
  random-detect
policy-map BRANCH-WAN-EDGE-CELLULAR
 class class-default
  shape average 2048000
   service-policy NEW-CELLULAR
policy-map NEW-1
 class discount
  priority 512
 class VOICE
  priority 512
 class VIDEO
  bandwidth 512
 class ROUTING
  bandwidth 16
 class NET-MGMT
  bandwidth 32
 class VPN
  bandwidth 16
 class SCAVENGER
  drop
 class class-default
  random-detect
policy-map BRANCH-WAN-EDGE
 class class-default
  shape average 2048000
   service-policy NEW-1

###

Tunnel1 is up, line protocol is up
  Hardware is Tunnel
  Description: ## DMVPN - MAIN
  Internet address is 192.168.0.166/23
  MTU 17870 bytes, BW 4096 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 82.147.107.154 (GigabitEthernet0), destination 141.101.243.16
   Tunnel Subblocks:
      src-track:
         Tunnel1 source tracking subblock associated with GigabitEthernet0
          Set of tunnels with source GigabitEthernet0, 2 members (includes iterators), on interface <OK>
  Tunnel protocol/transport GRE/IP
    Key 0x900BEFBA, sequencing disabled
    Checksumming of packets disabled
  Tunnel TTL 255, Fast tunneling enabled
  Path MTU Discovery, ager 10 mins, min MTU 92
  Tunnel transport MTU 1430 bytes
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Tunnel protection via IPSec (profile "VPN-DMVPN")
  Last input 00:00:00, output never, output hang never
  Last clearing of "show interface" counters 08:04:15
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 168
  Queueing strategy: fifo (QOS pre-classification)
  Output queue: 0/0 (size/max)
  30 second input rate 2000 bits/sec, 1 packets/sec
  30 second output rate 0 bits/sec, 0 packets/sec
     58571 packets input, 6237861 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     52484 packets output, 17163745 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out

Мне кажется что такое

Мне кажется что такое поведение зависит от версии IOS, попробуйте задать bandwidth для class-default в policy-map NEW-1 явно в размере оставшейся пропускной от 2 Мбит/с

New Member

Попытался сделать так: 

Попытался сделать так: 

 

создал 2 Service policy для туннельных интерфейсов

и два для физических (wired/LTE).

 

1) повесил политику на туннельные - ок

2) при попытке повесить на физические - ошибка:

 

Service policy with queueing features on this interface is not allowed
if tunnel based queuing policy is already installed.

 

получается, что я могу повесить политики или на физические только или на туннельные только.

 

 

My bad, sorry. http://www

My bad, sorry. http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_hrhqf/configuration/12-4t/qos-hrhqf-12-4t-book/qos-hrhqf.html

Service policies with queueing features cannot simultaneously coexist on child and parent interfaces, such as tunnel and physical interfaces, or subinterface and physical interfaces.

В таком случае Вам нужно выбирать, где применить полиси.

Cisco Employee

Ну, нет. Эта дискуссия

Ну, нет. Эта дискуссия состоит из сплошных заблуждений. Евгений, Вы ссылаетесь на документ по 12.4(20)T, но в 12.4(22)T уже все переделали.

Во-первых нужно разделить вопрос классификации трафика (classification) и очередизации/диспетчеризации (queuing/scheduling).

Использовать NBAR, во-первых, это искать себе на голову high CPU (не знаю уж, что там сейчас с NBAR2). Во-вторых, действительно вопрос, будет ли работать классификация NBAR, если policy-map применена на int tunnel или тем более на физику, а трафик уже инкапсулирован (будет ли работать qos pre-classify?). Когда-то давно у меня не работало, а чуть позднее - работало вроде. Но, в любом сл., если будут проблемы, то они легко решаются переносом классификации на LAN-интерфейс и маркированием там же DSCP (или qos-group, но это в каких-то версиях тоже не работало). Тогда на WAN-интерфейсе или на int tunnel можно при повторной классификации просто опираться на это DSCP или qos-group.

С queuing/scheduling все вообще запутано. Применять политики на физику и int tunnel можно:

http://www.cisco.com/c/en/us/td/docs/ios/qos/configuration/guide/qos_hqf_mply_support.html

но только сначала на физику, а потом - на tunnel. Только вопрос: а зачем? Не нужно этого делать для одного и того же трафика. Поскольку со статистикой будет беспорядок (см. ниже) и вообще это сложно. Если нужно просто раздать какие-то приоритеты туннелируемому трафику, то проще всего повесить иерархическую policy-map на физику, где в class-default настроить shaping до скорости, гарантируемой провайдером, для создания backpressure, и вложить в нее дочернюю policy раздав bandwidth/priority туннелируемому трафику. Если есть "более важные" и "менее важные" туннели, то можно действовать двумя путями: либо class-default заменить на много "class tunnelX", классифицировав туннели по комбинации "tunnel source" + "tunnel destination", и в каждом задать свое уникальное значение "shape", либо вешать иерархические политики на int tunnel, оставив на физике только class-default с "shape". В конечном счете - что в лоб, что по лбу, поскольку иерархия queuing все-равно конструируется на физическом интерфейсе. При желании можно даже на физическом интерфейсе выделить какой-то clear-text трафик, чтобы его приоритезировать, тогда туннели со своими policy-map будут связаны с class-default физического интерфейса. Все это будет работать для всех видов туннелей, чтобы там документация не писала. Для DMVPN альтернативно можно применять per-tunnel QoS for DMVPN применяя политику per-Spoke динамически, когда он подключается (в этом сл. м.б. разные зн. shape на каждый туннель до спока, хотя на хабе int tunnel один общий). Тогда на физике опять-таки д.б. class-default с shape для создания backpressure до скорости, обеспечиваемой провайдером.

Важно, что если на туннеле для какого-то класса сказано "priority ...", то этот трафик будет приоритетным и на физике тоже и не будет стоять в shaping queue class-default. По кр. мере так должно быть. Это т.н. "priority propagation".

Дальше скопипастю по-английски.

- The tunnel PQ traffic gets low latency through priority propagation.
- The tunnel bandwidth classes are also protected when either the
- tunnel shaper is active or when the physical interface is congested.
- Per-tunnel shaping and fairness is also enforced.
- Non-tunnel PQ and bandwidth classes get their latency and bandwidth
guarantee regardless of the amount of tunnel traffic.
- Non-tunnel default traffic is scheduled at the tunnel default queue.
- The tunnel default queue gets a fair share of the parent class-default
bandwidth from all tunnel traffic.


Вот, как задумывался дизайн QoS:

 

1)   Both policies as non-queuing

     Both policies do behave independent policies. There is no
     relation. Packets classified at tunnel will also be classified
     again at main interface.

2)   Tunnel as queuing and main interface as non-queuing

     Both policies do behave independent policies. There is no
     relation. Packets classified at tunnel will also be classified
     again at main interface. Since there is no queuing at main
     interface, tunnel packets will be queued as per tunnel policy.

3)   Main interface policy as queuing and tunnel as non-queuing

     Both policies do behave as independent policies. There is no
     relation. Packets classified at tunnel will also be classified
     again at main interface. Since there is no queuing at tunnel
     interface policy, tunnel packets will be queued as per main
     interface policy classification.

4)   Both tunnel and main interface as queuing policies

     Tunnel policy will be considered as child policy to class
     default of main interface policy from queuing perspective.

     Reclassification of tunnel traffic will happen at main interface.
     So any packet classifying class video at tunnel will also get
     classified in class video at main interface policy.

     And it will also get policed as configured in class video at
     main interface. But this tunnel packet will be queued in class
     default of main interface policy though any main interface
     packet classified in class video will be queued in class video
     only.

     Since queuing hierarchy is constructed in a way that all tunnel
     traffic has to be queued in class default of main policy. So in
     this case classification counters for tunnel packets of class
     video will be shown in class video of main interface policy but
     actually queued in class default of main interface policy.

     So there is mismatch in counters from queuing perspective.
     That's why it is recommended not to have same class on main
     interface as on tunnel interface. It is recommended that on
     main interface user defined classes should have classification
     criterion exclusively for main interface traffic and should not
     get tunnel packets classified.

 

 

 

 


 

New Member

Олег:>>Использовать NBAR, во

Олег:

>>Использовать NBAR, во-первых, это искать себе на голову high CPU (не знаю уж, что там сейчас с NBAR2).

Да грузит, но это удобней чем создавать acl

 

>> Во-вторых, действительно вопрос, будет ли работать классификация NBAR, если policy-map применена на int tunnel 

 

Судя по моим счётчикам, как-то оно не полностью работает

 

>> если будут проблемы, то они легко решаются переносом классификации на LAN-интерфейс и маркированием там же DSCP

 

Да это лучшая практика, но мне банально не хочется раздувать конфиг ещё и маркировкой трафика на внут. интерфейсе

 

>> Применять политики на физику и int tunnel можно

 

Везде в рекомендациях вижу политику именно на физике + qos pre-classify на туннелях

 

>>  Если нужно просто раздать какие-то приоритеты туннелируемому трафику, то проще всего повесить иерархическую policy-map на физику, где в class-default настроить shaping до скорости, гарантируемой провайдером, для создания backpressure,

 

Тут основная проблема, по контракту нам дают 2Mbit/s в Branch, а вот по факту при тестировании этих цифр и в помине нет.

Получается, что канал в Branch перегружен, а дело до политики LLQ даже и не дошло, так как шейпер не отработал.

Как быть с 3G/LTE каналами, там вообще нет гарантий ?

 

Да почитываю документацию на предмет внедрения: per-tunnel QoS for DMVPN, но пока у меня на хабах общая политика висит без детализации по спокам

Cisco Employee

Сон в руку. Как раз сижу

Сон в руку. Как раз сижу тестирую адаптивный QoS для DMVPN, который появился в 15.5(1)T. Он сам меняет параметры shaping в зависимости от потерей в канале и может это делать, как на spoke, так и на hub. Первое ощущение: это атас - живет своей жизнью:

! Hub
policy-map SPOKE-OUTER
 class class-default
  shape adaptive upper-bound 256000 lower-bound 128000

interface Tunnel1
 nhrp group HUB
 nhrp map group SPOKE service-policy output SPOKE-OUTER

! Spoke
policy-map HUB-OUTER
 class class-default
  shape adaptive upper-bound 224000 lower-bound 128000   

interface Tunnel1
 nhrp group SPOKE
 nhrp map group HUB service-policy output HUB-OUTER

! Intermediate device Spoke -> Hub
policy-map TEST
 class class-default
  police 160000 conform-action transmit  exceed-action drop

 

Оптимальные параметры шейпера найти не может:

BSNS-3845-1#ping 172.16.1.1 size 1000 repeat 10000 timeout 1

Type escape sequence to abort.
Sending 10000, 1000-byte ICMP Echos to 172.16.1.1, timeout is 1 seconds:
!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!.!!!
!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!
!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.
!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!
!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!
!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!
!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!
!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!
.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!.!!!
!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!
!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.
!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!
!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!
!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!
!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!
!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!
!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!
!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!
!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.
!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!
!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!
!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!
!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!
.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!.!!!
!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!
!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.
!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!
!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!
!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!.!
!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!
!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!
!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!
!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!
!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!
.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!
!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!
!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!
.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!
!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!
!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!
!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!
!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!
!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!
!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!
!!!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!
!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!
!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!
!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!
!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!
!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!
!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!
!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!
!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!
!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!
!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!!!
!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!.!!!!!
!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!
!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!
!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!
Success rate is 96 percent (9688/10000), round-trip min/avg/max = 1/53/332 ms

New Member

Ознакомился с документацией

Ознакомился с документацией Per-Tunnel QoS for DMVPN.

Есть несколько вопросов:

 

1) В примере пишут, что на хабе сделайте так:

 

This example shows a router with a 100-Mbps link on interface GigabitEthernet0/0/3.

policy-map WAN-INTERFACE-G0/0/3-SHAPE-ONLY
 class class-default
 shape average 100000000
!
interface GigabitEthernet0/0/3
 service-policy output WAN-INTERFACE-G0/0/3-SHAPE-ONLY

 

1) Сколько мне ставить в Shape average ? Интерфейсы - 1 Gbps, для выхода в Internet использую 3х апстримов -200/200/100 Mbps.

2) Для каждого спока не требуется создавать отдельную/уникальную nhrp-group если каналы везде 2 Mbps  ?

 

policy-map RS-GROUP-2Mb-POLICY
 class class-default
 shape average 2000000
 service-policy WAN

 

1) На каждом сабинтерфейсе

1) На каждом сабинтерфейсе сделать свой service-policy, указав shape average соответственно 20000000/200000000/100000000

2) Для всех spoke с одинаковой пропускной и характеристиками QoS nhrp-группа будет одна и та же

New Member

1) На Wan Edge роутере нет

1) На Wan Edge роутере нет сабов вообще, только 2 интерфейса 1Gbps (main/backup) в public internet и два (main/backup) к ядру 1 Gbps.

За интерфейсами в сторону Public internet идут два Internet Edge роутера куда и терминируются апстримы (200/200/100)

Схема:

WAN Edge router ---1 Gbps --> Internet edge router---3 апстрима 200/200/100

Ok, тогда я не понимаю в чем

Ok, тогда я не понимаю в чем у Вас состоит проблема сконфигурировать service-policy с требуемыми параметрами на Internet Edge сабинтерфейсах, а на Wan Edge делать per-tunnel QoS.

New Member

Хорошая мысль !Буду думать,

А разве не требуется на физ.интерфейсе WAN Edge роутера сделать как пишут ?

http://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Aug2014/CVD-VPNWANDesignGuide-AUG14.pdf

### for HUB

policy-map WAN-INTERFACE-G0/0/3-SHAPE-ONLY
 class class-default
 shape average 100000000
!
interface GigabitEthernet0/0/3
 service-policy output WAN-INTERFACE-G0/0/3-SHAPE-ONLY
 
А потом уже:
 
 
interface tunnel10
 ip nhrp map group RS-GROUP-50MBPS service-policy output RS-GROUP-50MBPS-POLICY
 ip nhrp map group RS-GROUP-25MBPS service-policy output RS-GROUP-25MBPS-POLICY
 ip nhrp map group RS-GROUP-10MBPS service-policy output RS-GROUP-10MBPS-POLICY

SRND (CVD) это рекомендации

SRND (CVD) это рекомендации как нужно делать, Example - это, очевидно, пример. Требования и ограничения нужно смотреть, например, тут:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_dmvpn/configuration/15-mt/sec-conn-dmvpn-15-mt-book/sec-conn-dmvpn-per-tunnel-qos.html#GUID-182BD32F-56D4-479C-BFEF-B9738291E046

в разделе "Restrictions for Per-Tunnel QoS for DMVPN" и "Prerequisites for Per-Tunnel QoS for DMVPN"

Если Вас смущает вот эта фраза "The class default shaper policy map on the main interface must be applied before the tunnel policy map is applied.", то ключевым словом тут является Before, а не Must.

205
Просмотры
4
Полезный материал
22
Ответы