impor QoS em um link de velocidade "variável", em que a negociação é feita pelas operadoras NTE

Em essência, adquirimos uma linha 80/20 da transportadora que fornece o transporte entre as instalações do cliente e a central local onde a transportadora termina em nosso PE.

(Juniper PE) <--> [Interconexão de operadora no Exchange <---> NTE na propriedade do cliente] <---> (Cisco CPE - 881,1921,1941,2921))

O circuito entre a propriedade do cliente e o armário da rua local ainda é de cobre e, portanto, à medida que o ruído / distância aumenta, a velocidade diminui.

a negociação real da velocidade da linha está ocorrendo nas transportadoras NTE e não no nosso CPE.

como posso garantir que, quando o link estiver saturado, os pacotes prioritários não sejam descartados, sem realmente saber para que a velocidade da linha foi autenticada? algo pode ser feito com o ipsla?

qos cisco-ios-15

— DrBru
fonte

Você está falando sobre a configuração de QoS no CPE, para a direção do upload?

— jwbensley

@javano bidirecional realmente, atualmente a única opção disponível para mim é moldar o tráfego em ambos os lados para uma média como você recomenda na resposta, estou tentando estabelecer se existe alguma outra maneira de fazer isso com mais precisão .

— 22313 DrBru

Você realmente não pode resolver isso sem adivinhar excessivamente conservadoramente qual taxa sempre será alcançada. Pesquise terminar a conexão diretamente no seu Cisco CPE removendo o NTE. Em seguida, a interface do Cisco CPE saberá a linha.

— ytti 25/07/2013

@ytti Obrigado, atualmente suas finanças nos levam a usar a transportadora como intermediária e a fttc ainda é MUITO nova aqui.

— 22313 DrBru

@ Ian sim, mas se for DSL ou algo parecido, você não pode simplesmente substituir o modem completamente e usar apenas seu próprio CPE? Em seguida, você pode aplicar a QoS à interface que está ciente da taxa.

— ytti

Uma possibilidade é se você deseja que o tráfego de QoS upstream em direção ao gateway do CPE seja modelar a saída de tráfego e, em seguida, priorizar o tráfego importante dentro dessa largura de banda de modelagem.

Se esta é uma linha 80/20 e você sabe que a velocidade média média é de 15 Mbps, você pode moldar o tráfego de saída para 15 Mbps e priorizar a voz nesses 15 Mbps. Se a velocidade de sincronização cair alguns Mbps, não fará muita diferença. Se a velocidade de sincronização subir até 17 Mbps, eles terão poucos Mbps de largura de banda de upload.

Eu uso uma configuração como o golpe em algumas linhas EFM. A velocidade do EFM pode variar devido às condições da linha, uma vez instaladas, embora elas pareçam muito consistentes. Portanto, neste exemplo, esse CPE está conectado à linha 20/20 EFM que é sincronizada de maneira confiável em 10/10, o upload é modelado para 10 Mbps.

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

É importante que modelemos aqui, não o limite de taxa ou a polícia, para que o tráfego não caia, seja "moldado" para a largura de banda disponível. Leia esta página da Cisco para obter mais informações.

— jwbensley
fonte

Eu não acho que isso funcione, o problema do OP é que ele não sabe onde moldar a conexão. Se você configurá-lo para 10 Mbps, DEVE poder passar 10 Mbps para manter o contrato 'CM-VOICE-TRAFFIC'.

— ytti