les correspondances par défaut de classe contrôlent le trafic?

16

Je vois un problème avec BFD sur un lien qui est évacué par la police où il apparaît pendant les moments où le policier est au maximum. Les paquets BFD n'atteignent pas l'autre côté. Je me demande si les hellos BFD sont soumis au policier ou s'ils ne relèvent pas du policier. S'ils sont soumis à un policier, est-ce aussi simple que d'ajouter une correspondance pour DSCP CS6 et de lui donner la priorité? Voici la configuration:

interface GigabitEthernet1/1
 service-policy output 500meg
end

Router-1#sh policy-map 500meg
  Policy Map 500meg
    Class class-default
     police cir 500000000 bc 31250000 be 31250000
       conform-action transmit
       exceed-action drop
       violate-action drop

— Boue
source

1

Quel modèle de Cisco utilisez-vous?

— Mike Pennington

@MikePennington 7606 w / WS-X6724-SFP

— Mud

3

Votre justification est correcte (pour cette plateforme, pas pour toutes les plateformes). Je ne donnerais une capacité dédiée à CS6 que si je garantissais ce qui est dans CS6 et ce qui ne l'est pas. Si je ne le garantis pas, alors vous préférez utiliser ACL pour correspondre à BFD spécifiquement. Cela dit, le 7600 n'est pas une très bonne plate-forme pour les temporisateurs BFD agressifs. Je préfèrerais éviter un intervalle plus agressif que 1 s, multiplicateur 3.

— ytti

Une réponse vous a-t-elle aidé? si c'est le cas, vous devez accepter la réponse afin que la question ne s'affiche pas indéfiniment, à la recherche d'une réponse. Alternativement, vous pouvez fournir et accepter votre propre réponse.

— Ron Maupin

2

@Mud, vous avez à peu près la réponse à votre question répartie sur plusieurs commentaires, je ne fais que la consolider ici en une seule réponse.

Sur les 7600/6500, vous pouvez filtrer le BFD (trafic du plan de contrôle) au niveau de l'interface comme tout autre trafic (trafic de transit passant par l'appareil).

Lorsque vous appliquez une ACL à un port de la carte de ligne, elle est appliquée à tout le trafic sur cette interface. Le trafic qui doit être traité par le RSP ou les DFC si vous les utilisez doit y être lancé, c'est-à-dire après le traitement de l'ACL.

En règle générale, j'ai récemment inclus le trafic des avions de contrôle dans les politiques de QoS, comme celles-ci où la "classe NC" correspond uniquement à CS6 et CS7:

policy-map QoS-Example
 class NC
  bandwidth percent 2
 !
 class REALTIME
  police rate percent 10
   conform-action transmit
   exceed-action drop
  !
  priority level 1
 !
 class 1
  bandwidth percent 22
 !
 class 2
  bandwidth percent 24
 !
 class 3
  bandwidth percent 12
 ....... and so on

Si vous écrivez une stratégie CoPP pour vos 7600/6500, vous devez écrire des listes de contrôle d'accès qui correspondent à tous vos types de trafic de plan de contrôle. Ainsi, vous pouvez également faire correspondre le trafic BFD en faisant correspondre le trafic vers / depuis le port UDP 3784 (et le verrouiller plus loin sur votre IP d'interface si possible).

Comme @ytti l'a dit, vous devez vous méfier des temporisateurs BFD sur votre configuration, si vous n'avez pas de DFC, votre BFD en cours d'exécution sur la puissance RSP / CPU. Dans ce cas, vous souhaiterez peut-être également peaufiner votre commande globale "process-max-time" et la planification de processus "scheduler allocate xxx xxx".

Le minimum recommandé par Cisco est bfd interval 100 min_rx 100 multiplier 3mais sur certaines boîtes de production sans DFC que j'exécute réellement, bfd interval 500 min_rx 500 multiplier 3ce qui était bien, je pense que sur les boîtes avec DFC auxquelles je n'ai pas accès en ce moment, j'exécute la même chose.

Vous pouvez voir ces références pour plus d'informations, qui couvrent le réglage BFD et les listes de contrôle d'accès pour le trafic du plan de contrôle (à la fois CoPP et ACL d'interface), ainsi que certains réglages du plan de contrôle qui sont généralement de bonnes pratiques, ainsi que le comportement QoS avec le trafic du plan de contrôle:

http://www.cisco.com/c/en/us/td/docs/routers/7600/troubleshoot/guide/7600_Trouble_Shooting.pdf

http://www.cisco.com/c/en/us/td/docs/routers/7600/ios/12-2SR/configuration/guide/swcg/dos.html

http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html

http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-congestion-management-queueing/18664-rtgupdates.html

— jwbensley
source

1

En raison de la nature critique du paquet de contrôle BFD, il ne passe pas par la carte de stratégie de Qo de sortie à la sortie et est placé directement dans la file d'attente de sortie. Confirmé avec TAC.

— Subeh
source

-1

Selon ce document de Cisco "les utilisateurs ne peuvent pas, par exemple, filtrer ou appliquer la qualité de service (QoS) au paquet BFD transmis". Je suppose donc que ces paquets obtiennent l' indicateur PAK_PRIORITY .

— Marco Marzetti
source

2

PAK_PRIORITY est utilisé pour un transfert accéléré à l'intérieur du routeur / châssis. Ce n'est pas un marquage extérieur. Le BFD est un plan de données et doit être marqué / mis en file d'attente manuellement pour lui donner un meilleur traitement.

— Daniel Dib

@Daniel a raison. J'ai oublié de mentionner que PAK_PRIORITY est un indicateur interne et son comportement dépend du système. Sur C7600, ces paquets marqués sont automatiquement marqués avec CoS6 et protégés par tout type de baisse de QoS. Donc, même si vous pouvez parier que les paquets seront livrés, si vous voulez un comportement de transfert accéléré, vous devez définir une file d'attente dédiée.

— Marco Marzetti

@MarcoMarzetti Donc pour ma propre clarification: le doc cisco fait référence aux paquets BFD d'entrée ne pouvant pas être QoS'd, et sont toujours soumis à un régulateur de sortie?

— Mud

@Mud PAK_PRIORITY est une chose interne (c'est-à-dire non marquée). "Le logiciel Cisco IOS dispose également d'un mécanisme interne pour accorder une priorité interne aux datagrammes de contrôle importants lors de leur traitement au sein du routeur. Ce mécanisme est appelé PAK_PRIORITY."

— Ryan Foley