11. Configuration and Deployment Considerations (Considerazioni sulla Configurazione e Distribuzione)

The BGP protocol provides no way for a Client to identify itself dynamically as a Client of an RR. The simplest way to achieve this is by manual configuration.

Il protocollo BGP non fornisce alcun modo per un Client di identificarsi dinamicamente come un Client di un RR. Il modo più semplice per ottenere questo è attraverso la configurazione manuale.

One of the key component of the route reflection approach in addressing the scaling issue is that the RR summarizes routing information and only reflects its best path.

Uno dei componenti chiave dell'approccio route reflection nell'affrontare il problema di scalabilità è che l'RR riassume le informazioni di routing e riflette solo il suo percorso migliore.

Both Multi-Exit Discriminators (MEDs) and Interior Gateway Protocol (IGP) metrics may impact the BGP route selection. Because MEDs are not always comparable and the IGP metric may differ for each router, with certain route reflection topologies the route reflection approach may not yield the same route selection result as that of the full IBGP mesh approach. A way to make route selection the same as it would be with the full IBGP mesh approach is to make sure that route reflectors are never forced to perform the BGP route selection based on IGP metrics that are significantly different from the IGP metrics of their clients, or based on incomparable MEDs. The former can be achieved by configuring the intra-cluster IGP metrics to be better than the inter-cluster IGP metrics, and maintaining full mesh within the cluster. The latter can be achieved by

Sia i Multi-Exit Discriminators (MED) che le metriche del Protocollo Gateway Interno (IGP) possono impattare sulla selezione della rotta BGP. Poiché i MED non sono sempre comparabili e la metrica IGP può differire per ogni router, con certe topologie di route reflection l'approccio route reflection potrebbe non produrre lo stesso risultato di selezione della rotta di quello dell'approccio full IBGP mesh. Un modo per rendere la selezione della rotta uguale a come sarebbe con l'approccio full IBGP mesh è assicurarsi che i route reflector non siano mai forzati a eseguire la selezione della rotta BGP basata su metriche IGP che sono significativamente diverse dalle metriche IGP dei loro client, o basate su MED incomparabili. Il primo può essere ottenuto configurando le metriche IGP intra-cluster per essere migliori delle metriche IGP inter-cluster, e mantenendo il full mesh all'interno del cluster. Il secondo può essere ottenuto da

• setting the local preference of a route at the border router to reflect the MED values, or

  impostando la preferenza locale di una rotta sul router di confine per riflettere i valori MED, o

• making sure the AS-path lengths from different ASes are different when the AS-path length is used as a route selection criteria, or

  assicurandosi che le lunghezze del percorso AS da diversi AS siano diverse quando la lunghezza del percorso AS è usata come criterio di selezione della rotta, o

• configuring community-based policies to influence the route selection.

  configurando policy basate su community per influenzare la selezione della rotta.

One could argue though that the latter requirement is overly restrictive, and perhaps impractical in some cases. One could further argue that as long as there are no routing loops, there are no compelling reasons to force route selection with route reflectors to be the same as it would be with the full IBGP mesh approach.

Si potrebbe discutere tuttavia che quest'ultimo requisito sia eccessivamente restrittivo, e forse poco pratico in alcuni casi. Si potrebbe ulteriormente discutere che finché non ci sono loop di routing, non ci sono ragioni convincenti per forzare la selezione della rotta con i route reflector ad essere la stessa di come sarebbe con l'approccio full IBGP mesh.

To prevent routing loops and maintain consistent routing view, it is essential that the network topology be carefully considered in designing a route reflection topology. In general, the route reflection topology should be congruent with the network topology when there exist multiple paths for a prefix. One commonly used approach is the reflection based on Point of Presence (POP), in which each POP maintains its own route reflectors serving clients in the POP, and all route reflectors are fully meshed. In addition, clients of the reflectors in each POP are often fully meshed for the purpose of optimal intra-POP routing, and the intra-POP IGP metrics are configured to be better than the inter-POP IGP metrics.

Per prevenire loop di routing e mantenere una vista di routing coerente, è essenziale che la topologia di rete sia attentamente considerata nel progettare una topologia di route reflection. In generale, la topologia di route reflection dovrebbe essere congruente con la topologia di rete quando esistono percorsi multipli per un prefisso. Un approccio comunemente usato è la riflessione basata su Point of Presence (POP), in cui ogni POP mantiene i propri route reflector che servono i client nel POP, e tutti i route reflector sono fully meshed. Inoltre, i client dei riflettori in ogni POP sono spesso fully meshed allo scopo di un routing intra-POP ottimale, e le metriche IGP intra-POP sono configurate per essere migliori delle metriche IGP inter-POP.