le partite predefinite per classe controllano il traffico?

16

Sto riscontrando un problema con BFD su un collegamento in uscita di sicurezza in cui appare durante i periodi in cui il poliziotto è al massimo I pacchetti BFD non arrivano dall'altra parte. Mi chiedo se gli Hellos BFD siano soggetti al poliziotto o se cadano fuori dal poliziotto. Se sono soggetti a un poliziotto è semplice come aggiungere una corrispondenza per DSCP CS6 e dargli priorità? Di seguito è la configurazione:

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

— Fango
fonte

1

Quale modello di Cisco stai usando?

— Mike Pennington,

@MikePennington 7606 w / WS-X6724-SFP

— Fango

3

La tua logica è corretta (per questa piattaforma, non per ogni piattaforma). Darei la capacità dedicata a CS6 solo se garantissi cosa c'è in CS6 e cosa no. Se non lo garantisco, preferiresti utilizzare ACL per abbinarlo specificamente a BFD. Detto questo, 7600 non è un'ottima piattaforma per timer BFD aggressivi. Vorrei evitare un intervallo più aggressivo di 1 secondo, 3 moltiplicatore.

— ytti,

Qualche risposta ti è stata d'aiuto? in tal caso, dovresti accettare la risposta in modo che la domanda non continui a comparire per sempre, alla ricerca di una risposta. In alternativa, potresti fornire e accettare la tua risposta.

— Ron Maupin

2

@Mud, hai praticamente ottenuto la risposta alla tua domanda su più commenti, quindi la sto semplicemente consolidando qui in un'unica risposta.

Su 7600s / 6500s puoi filtrare BFD (traffico sul piano di controllo) a livello di interfaccia proprio come qualsiasi altro traffico (traffico di transito che passa attraverso il dispositivo).

Quando si applica un ACL a una porta sulla scheda di linea, viene applicato a tutto il traffico su quell'interfaccia. Il traffico che deve essere elaborato dall'RSP o dai DFC se li si utilizza deve essere puntato lì che è dopo l'elaborazione dell'ACL.

Come regola generale ho incluso il traffico del piano di controllo nelle politiche di QoS negli ultimi tempi, come quello che segue in cui "classe NC" corrisponde solo a CS6 e 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

Se scrivi una politica CoPP per i tuoi 7600s / 6500s devi scrivere ACL che corrispondano a tutti i tuoi tipi rilevanti di traffico sul piano di controllo. Quindi puoi anche abbinare il traffico BFD abbinando il traffico da / verso la porta UDP 3784 (e bloccalo ulteriormente all'IP della tua interfaccia, se possibile).

Come ha detto @ytti, devi stare attento ai timer BFD sulla tua configurazione, se non hai DFC il tuo BFD in esecuzione con la potenza RSP / CPU. In tal caso, potresti anche voler modificare il comando globale "process-max-time" e la pianificazione del processo "scheduler allocate xxx xxx".

Il minimo consigliato da Cisco è bfd interval 100 min_rx 100 multiplier 3ma su alcune scatole di produzione senza DFC che sto effettivamente eseguendo, il bfd interval 500 min_rx 500 multiplier 3che è andato bene, penso sulle scatole con DFC a cui non ho accesso in questo momento sto eseguendo lo stesso.

Puoi vedere questi riferimenti per maggiori informazioni, che coprono l'ottimizzazione BFD e gli ACL per il traffico del piano di controllo (sia ACP di interfaccia sia CoPP) e anche alcune ottimizzazioni del piano di controllo che sono generalmente buone pratiche, anche il comportamento QoS con il traffico del piano di controllo:

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
fonte

1

A causa della natura critica del pacchetto di controllo BFD, non passa attraverso la mappa delle politiche QoS in uscita all'uscita e viene inserito direttamente nella coda di uscita. Confermato con TAC.

— Subeh
fonte

-1

Secondo questo documento Cisco "Gli utenti non possono, ad esempio, filtrare o applicare la qualità del servizio (QoS) al pacchetto BFD trasmesso". Quindi suppongo che quei pacchetti ottengano il flag PAK_PRIORITY .

— Marco Marzetti
fonte

2

PAK_PRIORITY viene utilizzato per l'inoltro accelerato all'interno del router / telaio. Non è un marchio esterno. BFD è un piano dati e deve essere contrassegnato / messo in coda manualmente per fornire un trattamento migliore.

— Daniel Dib,

@Daniel ha ragione. Ho dimenticato di menzionare che PAK_PRIORITY è un flag interno e il suo comportamento dipende dal sistema. Su C7600 tali pacchetti contrassegnati vengono automaticamente contrassegnati con CoS6 e protetti da qualsiasi tipo di drop QoS. Quindi, anche se puoi scommettere che i pacchetti verranno consegnati, se vuoi un comportamento di spedizione accelerato devi definire una coda dedicata.

— Marco Marzetti,

@MarcoMarzetti Quindi per il mio chiarimento: il documento Cisco fa riferimento a pacchetti BFD in ingresso che non possono essere QoS'd e sono ancora soggetti a un poliziotto in uscita?

— Fango

@Mud PAK_PRIORITY è una cosa interna (cioè non contrassegnata). "Il software Cisco IOS ha anche un meccanismo interno per garantire la priorità interna a importanti datagrammi di controllo mentre vengono elaborati all'interno del router. Questo meccanismo è chiamato PAK_PRIORITY."

— Ryan Foley,