application de la QoS sur une liaison à vitesse "variable" où la négociation est effectuée par les opérateurs NTE

Essentiellement, nous achetons une ligne 80/20 auprès du transporteur qui assure le transport entre les locaux du client et le central local où le transporteur se termine dans notre PE.

(Juniper PE) <--> [Interconnexion de l'opérateur dans Exchange <---> NTE dans la propriété du client] <---> (Cisco CPE - 881,1921,1941,2921))

Le circuit entre la propriété du client et l'armoire de rue locale est toujours en cuivre et donc à mesure que le bruit / la distance augmente, la vitesse diminue.

la négociation de la vitesse de ligne réelle a lieu sur les opérateurs NTE et non sur notre CPE.

comment puis-je m'assurer que lorsque le lien est saturé, les paquets prioritaires ne sont pas perdus, sans savoir à quoi la vitesse de la ligne s'est authentifiée? peut-on faire quelque chose avec ipsla?

qos cisco-ios-15

— DrBru
source

Parlez-vous de la configuration QoS sur le CPE, pour la direction de téléchargement?

— jwbensley

@javano bidirectionnel vraiment, actuellement la seule option à ma disposition est de façonner le trafic des deux côtés à une moyenne comme vous le recommandez dans votre réponse, j'essaie de déterminer s'il existe un autre moyen de le faire avec plus de précision .

— DrBru

Vous ne pouvez pas vraiment résoudre ce problème sans faire une estimation trop conservatrice du taux qui sera toujours atteint. Recherchez la fin de la connexion directement dans votre Cisco CPE en supprimant le NTE. L'interface Cisco CPE connaîtra alors le linerate.

— ytti

@ytti Merci, actuellement ses données financières nous poussent à utiliser le transporteur comme intermédiaire et fttc est encore TRÈS nouveau ici.

— DrBru

@IanK oui mais si c'est DSL ou quelque chose comme ça, ne pouvez-vous pas simplement remplacer le modem entièrement et utiliser uniquement votre propre CPE? Ensuite, vous pouvez appliquer la QoS à l'interface qui connaît le débit.

— ytti

Une possibilité consiste à façonner le trafic sortant, puis à hiérarchiser le trafic important dans cette bande passante de mise en forme, si vous souhaitez que le trafic QoS en amont vers la passerelle du CPE.

S'il s'agit d'une ligne 80/20 et que vous savez que la vitesse de montée moyenne est de 15 Mbits / s, vous pouvez définir le trafic sortant à 15 Mbits / s et prioriser la voix à l'intérieur de ces 15 Mbits / s. Si la vitesse de synchronisation chute de quelques Mbps, cela ne fera pas une énorme différence. Si la vitesse de synchronisation augmente jusqu'à 17 Mbps, ils manqueront de quelques Mbps de bande passante de téléchargement.

J'utilise une config comme le coup sur certaines lignes EFM. La vitesse de l'EFM peut varier en raison des conditions de la ligne, une fois installées, bien qu'elles semblent très cohérentes. Donc, dans cet exemple, ce CPE est connecté à une ligne EFM 20/20 qui se synchronise de manière fiable à 10/10, le téléchargement est mis en forme à 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

Il est important que nous ne modifions pas ici la limite de débit ou la police, afin que le trafic ne soit pas abandonné, il soit "façonné" en fonction de la bande passante disponible. Lisez cette page Cisco pour plus d'informations.

— jwbensley
source

Je ne pense pas que cela fonctionne, le problème d'OP est qu'il ne sait pas où façonner la connexion. Si vous le modifiez à 10 Mbps, vous DEVEZ pouvoir passer à 10 Mbps pour conserver le contrat 'CM-VOICE-TRAFFIC'.

— ytti