Come gestire il degrado delle prestazioni in profondità nella rete del provider?

9

Quali sono alcuni modi possibili per rilevare la perdita di pacchetti in profondità nella rete di un provider che si trova a diversi hop di distanza? Con più provider scrutati su BGP sui nostri router perimetrali Internet, devo essere in grado di rilevare automaticamente la perdita di pacchetti (principalmente) e la latenza (in secondo luogo), fare una traccia dell'interfaccia o qualcosa di simile e spegnerli in modo che tutto il traffico utilizzi i nostri altri provider .

Ho riscontrato due problemi con l'utilizzo degli SLA IP. In primo luogo, ciò che deve essere misurato sono almeno diversi hop di distanza (ben oltre il loro peer BGP), quindi il monitoraggio di qualsiasi cosa in profondità nella rete del provider non è una proposta statica come il monitoraggio dei nostri collegamenti con loro (che sono stati stabili); se i collegamenti di quel provider vengono chiusi, gli SLA avrebbero comunque la possibilità di raggiungere il percorso di un altro provider. In secondo luogo, l'utilizzo di un monitor di tipo ICMP non rileva il livello di perdita di pacchetti che si osserva in genere con pacchetti molto più grandi e la latenza non sembra cambiare in modo significativo.

Is Performance Routing (PdR) la migliore opzione qui e influenzare localpref di BGP? Sembra che il Master Controller sia un SPoF (Single Point of Failure), quindi se PfR è la strada da percorrere, come possono i router di frontiera non dipendere da un singolo Master Controller? Quali sono altre due o tre opzioni praticabili?

La maggior parte e il più critico del nostro traffico proviene dalle nostre risposte HTTP in uscita.

cisco bgp performance

— generalnetworkerror
fonte

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

— Ron Maupin

6

PfR è davvero un'opzione.

Opzione in cui non ho esperienza personale, ma so che le persone che li usano sono ottimizzatori BGP, che sono indipendenti dal fornitore in quanto guardano solo BGP, misurano la rete e iniettano percorsi per modificare il routing.

Opzioni di coppia

— ytti
fonte

Grazie per l'opzione InterNAP FCP e promemoria. Abbiamo INAP sbirciato su questi router, quindi abbiamo già una relazione con loro.

— generalnetworkerror

7

Se si utilizza Cisco ai margini, PfR sarebbe effettivamente l'opzione migliore qui per i motivi specificati. È possibile impostare la ridondanza del controller principale e Cisco mostra come su questo link: http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/Transport_diversity/PfR_Master_Controller_Redundancy.html

— mellowd
fonte

Basta leggere quel link: non è possibile avere un controller di standby in un'altra posizione o è l'unica topologia con HSRP tra i controller? E questo sembra contrario a ciò che PfR sta cercando di realizzare se il tuo percorso dal confine al controller è degradato: "Nel caso in cui il router di confine PfR perde il contatto con il controller principale, il router di confine smette di gestire prefissi o applicazioni. In altre parole, il la modalità fail-safe di PfR è quella di rimuovere qualsiasi route immessa nella tabella di routing IP o nella tabella BGP e di interrompere il routing dei criteri delle applicazioni se il controller principale non è disponibile. "

— generalnetworkerror

Sembra che HSRP sia l'unico modo. È un po 'sciocco nei miei libri poiché Cisco dovrebbe essere in grado di progettare PfR per supportare due controller master in due sottoreti separate. È possibile ottenere un VLL / VPLS in un'altra posizione ed eseguire HSRP su quello. Non ideale, ma funziona. Qualsiasi "L2 allungato" funzionerebbe qui. Ancora una volta non è l'ideale, ma funzionerebbe fino a quando Cisco non riuscirà a mettere insieme i suoi due controller.

— Mellowd,