QoS - LLQ sem banda definida no priority queue

Pessoal,

Possuo o seguinte equipamento e IOS em produção:

Router 7300 (NSE100)
Cisco IOS Software, 7300 Software (C7300-IS-M), Version 12.2(33)SB3, RELEASE SOFTWARE (fc1)


Na interface WAN, tenho uma policy aplicada (QoS - LLQ).
Basicamente, o que me interessa, e é a minha dúvida, é o cálculo da banda mínima garantida para outras classes (que não priority), sendo que as mesmas usam "bandwidth remaining" e não foi definido explicitamente o valor da banda para a priority queue.

Nota-se que, para saber qual é a banda disponível para as outras classes, primeiramente, deve-se saber qual é a banda dedicada à priority queue.

Na config que possuo, a priority queue não tem explicitamente a banda definida, como pode ser visto no output logo abaixo.

Alterei a policy/classes para que ficasse mais simples e focada em minha dúvida.


class-map match-any VOICE
match ip dscp ef
class-map match-any DATA
match ip dscp af31

policy-map POLICY-TEST
class VOICE
priority
police 1048576 131072 131072 conform-action set-dscp-transmit ef exceed-action drop violate-action drop
class DATA
bandwidth remaining percent 50


Segundo o command reference guide, ele exibe como obrigatório informar a banda em kbps ou %.

{} significa obrigatoriedade.

priority {bandwidth-kbps | percent percentage} [burst]


Sei que existe police aplicado na priority queue, e que ele limitará o tráfego do priority queue, já que exceeded e violation está como drop em 1 Mega bits.

1048576 bits = 131072 bytes = 1 Mega bit


Imaginemos então, que o link de WAN seja de 2 megas e que estamos usando "max-reserved-bandwidth" em 100, para tornar simples nossos cálculos.


Agora vem a questão:

O police aplicado no priority queue (VOICE class) o limita a 1 Mb.
Num link de 2 Mb, sobraria 1 Mb livre para outras classes.

Como não foi definida explicitamente a banda utilizada pela priority queue, mesmo que se tenha a police limitando a 1 Mb, as outras classes dependem do valor definido no priority para calcular adequadamente sua banda, quando usando remaining.

Mesmo tendo 1 mb ainda livre, sem a definição da banda através do comando priority, não há como saber quanto tem de banda disponível, impossibilitando o cálculo correto de garantia mínima de banda das outras classes.


No meu entender, há duas possibilidades:

- O roteador fica aware da police aplicada na priority queue e utiliza o valor dele (em nosso caso, 1 mb). Isto é, link de 2 mbps, se está utilizando 1 mb, sobraria 1 mbps para as classes posteriores. Sendo 500 Kbps para a classe DATA.

- O roteador sabe que existe um priority queue, mas não há banda definida para ele, portanto, do ponto de vista do roteador, 100% da banda (2 mbps em nosso caso) está dedicada para o priority queue. Como existe a police, o tráfego fica limitado a 1 mbps, sobrando outro 1 mbps para as demais classes. Neste caso, com o comando remaining em 50% para a classe DATA não surtiria efeito, pois não há banda "sobrando". Sendo assim, em caso de utilização do link em 100%, a classe DATA concorreria com a classe default, sem garantir uma banda mínima para ela.

Pensando num caso de total utilização do link, para a segunda hipótese, isso seria um grande problema, pois a banda de cada classe estaria configurada diferente do projetado, não havendo garantia mínima para as classe DATA.


Tentei simular no Dynamips, mas não encontrei qualquer IOS que permitisse o comando priority sem definir a banda.

Eu penso que a primeira possibilidade é a correta, pois, quando configurando LLQ em outros casos, se você define uma banda para o priority queue e depois, para classes subsequentes, uma banda maior do que a banda disponível, o próprio IOS não permite que você o faça.
Mas como remaining é %, pode ser que ele permita a configuração, mesmo que não garanta banda mínima, já que ficaria em 0%.

exemplo: 10% de 0 de banda disponível = 0

Pelos meus testes, a primeira hipótese é a correta...


Definindo banda explicitamente (100% para priority e 10% para a classe data), não foi permitido, pois excedia a banda disponível:

Router(config)#policy-map test
Router(config-pmap-c)#class voz
Router(config-pmap-c)#prio percent 100
Router(config-pmap-c)#class data
Router(config-pmap-c)#band per 100
Sum total of class bandwidths exceeds 100 percent



No caso, se a policy já está aplicada na interface, e você tenta alterar a banda, ele não permite, exibindo a seguinte mensagem:

I/f FastEthernet0/0 class data requested bandwidth 10%, available only 0%

interface FastEthernet0/0
no ip address
shutdown
duplex auto
speed auto
max-reserved-bandwidth 100
service-policy output test


class-map match-all data
match dscp 21
class-map match-all voz
match dscp ef
!
policy-map test
class voz
priority percent 100
class data


Quando tentei aplicar remaining 10% na classe data, não me foi permitido.

Router(config-pmap-c)#bandwidth remaining per 10
I/f FastEthernet0/0 class data requested bandwidth 10%, available only 0%



Quando não aplicada na interface, me foi permitido configurar remaining bandwidth na classe data, mesmo que já havia definido 100% para o priority queue:

interface FastEthernet0/0
no ip address
shutdown
duplex auto
speed auto
max-reserved-bandwidth 10

Porém, na hora de aplicar na interface, recebo o mesmo erro:

Router(config-if)#service-policy output test
I/f FastEthernet0/0 class data requested bandwidth 10%, available only 0%



Portanto, apesar de não ter certeza definitiva ainda, já que não utilizei o priority sem banda, acredito que, dado os outputs de meu lab, o IOS não permite que seja configurada banda a mais, mesmo que seja através do comando remaining, que por definição, seria uma proporção (10% de 0 = 0) que deve ficar num valor positivo (maior que 0).

consequentemente, acredito que o equipamento, mesmo que não tenha priority bandwidth definido, mas tendo police, ele adota o valor do police como o total de banda definido para a priority queue.

A única forma que vejo para provar se, sem banda explicita no priority queue e sem police ele toma 100% da banda e com police, ele toma o valor do police, seria aplicando o comando num equipamento que permitisse isso e verificando com "show interfaces"

Por definição, no "sh interfaces", é exibido o quanto tem de banda ainda disponível... para tanto, ele subtrai o valor do max-reserved-bandwidth mais priority queue.

Neste caso, como max-reserved-bandwidth é igual a 100 (não possuindo banda reservada) e apliquei 50% de banda para priority queue, ele exibe como disponível, 50 mbps.


FastEthernet0/0 is administratively down, line protocol is down
Hardware is AmdFE, address is cc00.15a0.0000 (bia cc00.15a0.0000)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: Class-based queueing
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/0/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 50000 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog
0 input packets with dribble condition detected
0 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out


Se tivesse a possibilidade de configurar um equipamento com IOS que permitisse priority sem definir banda, faria o seguinte:

- Aplicaria, numa interface, o policy-map sem banda definida no priority queue e daria um show interface, e observaria o quanto de banda tem disponível. Neste caso, ao meu entender, seria 0 de banda disponível.

Depois,

- Adicionaria uma police na priority queue e, com show interfaces, verificaria se a banda disponível seria o resultado da diferença entre a banda total menos o valor do police.


Bom, é isso!!!

Já postei no forum da Cisco e nada até agora!!!

Se ninguém tiver um equipamento para testar (o meu está em produção é é um sonet, na verdade hehe, se derrubar, perco emprego), ou mesmo se ninguém souber a resposta, acho que abriei um TAC na Cisco, dando uma de "João sem braço" dizendo que existe algum problema, tentando validar a configuração.

Talvez no forum do INE também! Vou postar lá também e ver o que rola

Abralhos

Legal Ronaldo.

Sua primeira tese de que o router adota o valor do police como o total de banda definido para a fila priority.
estes equipamentos sao geralmente equipamentos com IOS obsoletas por isso nao conseguiu aplicar no dinamips.
Utilizamos esta configuracao com muita frequencia na empresa em determinados equipamentos que nao da a opcao de bandwith no priority e funciona perfeitamente a police fazendo a mesma funcao.

Funciona parecido em casos onde temos um ambiente com interface fastethernet e varias subinterfaces nesta interface.
na hora de configurar o qos temos um problema de a % da banda ser sempre sobre o link fisico que seria 100MB, sendo assim criamos uma police onde dentro da classe default configuramos um shape average para limitar a banda na velocidade que desejamos que funcione aquela interface e em seguida aplicamos a police original dentro desta police do shape, assim todos os calculos percentuais da police serao calculados em cima da banda do shape average.
todas as reservas em percentagem sao levadas em consideracao os priority, shape average ou o mais comum o bandwith e todos funcionam perfeitamente.
Porem como somos teimosos e gostamos de ver o negocio funcionando vou ver se no nosso lab tem um equipamento com estas caracteristicas para deixar vc com certeza absoluta..rsrsrs


Wellington mota

Legal sua resposta... talvez seja mesmo por causa do IOS.

Tentei baixar um IOS antigo do 7200, mas não rolou. Todos tinham o comando com, ao menos, obrigatoriedade da definição da banda com kbps.


12.0(7)T
This command was introduced.
12.0(5)XE5
This command was introduced for the Versatile Interface Processor (VIP) as part of the Distributed Low Latency Queueing (Low Latency Queueing for the VIP) feature.
12.0(9)S
This command was introduced for the VIP as part of the Distributed Low Latency Queueing (Low Latency Queueing for the VIP) feature.
12.1(2)E
The burst argument was added.
12.1(3)T
The burst argument was added.
12.1(5)T
This command was introduced for the VIP as part of the Distributed Low Latency Queueing (Low Latency Queueing for the VIP) feature.

Ou aparece:

Router(config-pmap-c)#priority ?
<8-2000000> Kilo Bits per second

Ou:

Router(config-pmap-c)#priority ?
<8-2000000> Kilo Bits per second
percent % of total bandwidth

Router(config-pmap-c)#priority
% Incomplete command.


Se puder ver se existe algum devide para o teste, seria legal.
Vou tentar achar no lab de minha empresa também.

Não consegui baixar nenhum 12.0. Baixei apenas 12.1,mesmo assim, acima do 12.1(5)T, que seria a última atualização em relação ao comando priority.

Isso é um tanto quanto estranho, pois olha em qual equipamento e qual versão eu tenho o priority aplicado sem bandwidth definido:

Router 7300 (NSE100)
Cisco IOS Software, 7300 Software (C7300-IS-M), Version 12.2(33)SB3, RELEASE SOFTWARE (fc1)

Abraços e obrigado

O problema é que o dynamips não roda o 7300

Vou tentar achar algum outro router que tenha a mesma função e ver se nele existe a mesma estrutura de config do priority queue. Caso sim, baixarei o IOS do site da Cisco, ou,se não existir mais disponível, farei um tftp da flash para meu note...

Aí, posto aqui o resultado.

Nesse meio tempo, se conseguir algo, ficaria grato.

Abraços,