applicare QoS su un collegamento di velocità "variabile" in cui la negoziazione viene effettuata dai vettori NTE

In sostanza acquistiamo una linea 80/20 dal corriere che fornisce il trasporto tra i locali del cliente e lo scambio locale in cui il corriere termina nel nostro PE.

(Juniper PE) <--> [Interconnessione operatore in Exchange <---> NTE nella proprietà del cliente] <---> (Cisco CPE - 881,1921,1941,2921))

Il circuito tra la proprietà del cliente e l'armadio della strada locale è ancora in rame e quindi all'aumentare del rumore / distanza la velocità diminuisce.

la negoziazione della velocità effettiva della linea è in corso sui corrieri NTE e non sul nostro CPE.

come posso garantire che, quando il collegamento è saturo, i pacchetti prioritari non vengono eliminati, senza sapere a che cosa è stata autenticata la velocità della linea? si può fare qualcosa con ipsla?

qos cisco-ios-15

— DrBru
fonte

Stai parlando della configurazione QoS sul CPE, per la direzione del caricamento?

— jwbensley,

@javano davvero bidirezionale, attualmente l'unica opzione disponibile per me è quella di modellare il traffico su entrambi i lati verso un avg proprio come mi raccomandi nella tua risposta, sto cercando di stabilire se esiste un altro modo per farlo in modo più accurato .

— DrBru,

Non puoi davvero risolverlo senza fare un'ipotesi eccessivamente conservativa di quale tasso sarà sempre soddisfatto. Cerca di terminare la connessione direttamente nel tuo CPE Cisco rimuovendo l'NTE. Quindi l'interfaccia Cisco CPE conoscerà il linerate.

— Sì, il

@ytti Grazie, attualmente i suoi dati finanziari ci spingono a utilizzare il corriere come intermedio e fttc è ancora MOLTO nuovo qui.

— DrBru,

@IanK sì, ma se è DSL o qualcosa del genere, non puoi semplicemente sostituire completamente il modem e utilizzare solo il tuo CPE? Quindi è possibile applicare QoS all'interfaccia che è a conoscenza della velocità.

— Sì, il

Una possibilità è se si desidera che il traffico QoS a monte verso il gateway del CPE sia quello di modellare il traffico in uscita e quindi dare priorità al traffico importante all'interno di quella larghezza di banda che modella.

Se si tratta di una linea 80/20 e sai che la velocità media in aumento è di 15 Mbps, puoi modellare il traffico in uscita a 15 Mbps e dare priorità alla voce all'interno di quei 15 Mbps. Se la velocità di sincronizzazione scende di un paio di Mbps, non farà molta differenza. Se la velocità di sincronizzazione sale fino a 17 Mbps, saranno a corto di un paio di Mbps di larghezza di banda di upload.

Uso una configurazione come il colpo su alcune linee EFM. La velocità EFM può variare a causa delle condizioni della linea, una volta installata sebbene sembri essere molto coerente. Quindi, in questo esempio, questo CPE è collegato alla linea EFM 20/20 che si sincronizza in modo affidabile a 10/10, il caricamento è modellato su 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 che qui non modifichiamo il limite di velocità o la polizia, in modo che il traffico non venga eliminato, ma "modellato" in base alla larghezza di banda disponibile. Leggi questa pagina di Cisco per ulteriori informazioni.

— jwbensley
fonte

Non penso che funzioni, il problema di OP è che non sa dove stabilire la connessione. Se lo modifichi a 10 Mbps DEVI essere in grado di passare 10 Mbps per mantenere il contratto 'CM-VOICE-TRAFFIC'.

— Sì, il