On Sun, 2009-09-06 at 18:59 +0200, Gianluca Mazzei wrote: > > Guarda, ho finito di studiare BGP del BSCI proprio questa settimana. > > Fare il redistribute in ogni caso (BGP o connected) e' impensabile. > > Cisco raccomanda di effettuare sessioni IBGP full-meshed nell'AS di > > transito, in modo da avere un'immagine di rete e quindi una BGP > > forwarding database uguale su tutti i router del transit-path. > > > > > > > > Ciao, > > > > Gianremo > > > > ))))))))))))))))- > > Be credo che non hai ben compreso il senso della mia domanda , > probabilmente mi sono espresso male ma la visione che ti da BSCI del BGP è un > pò > limitata.... Cmq provo a spiegarmi meglio , all' interno di un AS di transito > avrai degli edge > routers con sessioni sia e-bgp che i-bgp ,le sessioni interne in full-mesh > riguardano un full-mesh > logico e non certamente fisico ,sia che si utilizzino dei router reflector > sia altre soluzioni . > Un router che riceve una rotta da un neighbor e-bgp ,riceve questa rotta con > settato > il next-hop (attiributo well-known mandatory ) del router che gli ha fornito > l' update > di conseguenza poi passa l' update verso gli i-bgp neighbor lasciando il > next-hop invariato , > quindi il next-hop resta l' ip del neighbor e-bgp da cui il nostro edge > router ha ricevuto > l' update appunto. > > > A questo punto scatta l' inghippo , gli i-bgp neighbor conoscono attraverso > un IGP ( nella > maggior parte dei casi OSPF o IS-IS che sono gli unici 2 protocolli con i > qualil si può > sviluppare MPLS Traffic Engineering ) le rotte verso i loro i-bgp neighbors ma > non sanno come raggiungere un next-hop con ip appartenente ad un e-bgp , > quindi per > aggirare questo problema l' edge router che riceve la rotta ha due opzioni la > prima è > sovrascrivere l' attributo next-hop con il proprio indirizzo conosciuto dal > IGP e fa ciò > attraverso il comando next-hop-self la seconda è ridistribuire le > connesse . Ti preciso > che quest' ultima cosa non è assolutamente da confondere con il ridistribuire > l' intera tabella BGP nell' IGP !!!!!!! > In realtà esiste anche una terza opzione che personalmente giudico sporca che > è quella di > pubblicizzare attraverso il comando ''network'' la subnet in cui si sta > svolgendo la sessione > ebgp e poi mettere le relative interfacce in passive per prevenire il > passaggio di informazioni > contenute nell IGP... > > > Ora alla luce di questo chiarimento ribadisco a quanti hanno esperienza > acquisita in merito > le 2 domande ovvero : > > > Quali sono secondo voi i vantaggi e gli svantaggi di una soluzione rispetto > all´ altra ? > E quali i casi guida nei quali una delle due soluzioni è più indicata dell´ > altra ? > > > > Porgo un saluto anche Pier Carlo che ha segnalato un testo che per alcune > parti > è molto bello e piacevole da leggere , offre spunti interessanti ma spesso > li butta lì senza approfondirli , per altri versi ha anche parecchie lacune > dovute in minima parte al fatto che è un po datato, > ma sporatutto al modo in cui è stato concepito... > >
Devo dire che, almeno per me, non mi è ancora chiaro il senso della tua domanda :-? Provo comunque a esprimere la mia opinione che propende per la prima soluzione. Partiamo dal presupposto che una network con il BGP trasporta già di suo una notevole quantità di prefix, lo scopo primario è quello di ridurre al minimo possibile le dimensioni della BGP Table eliminando l'annuncio delle prefix superflue. Il questo caso è utile il next-hop-self. Inoltre, in un ambiente di notevoli dimensioni, tipo ISP, ogni volta che attivo un nuovo link con un customer bisogna ricordarsi di annunciare all'interno dell'AS la subnet della DMZ, questo vuol dire altro overhead per gli administrators. Ti prego di dirci anche tu quali sono i vantaggi e gli svantaggi che trovi nelle due soluzioni. Ciao, Davide
_______________________________________________ http://cug.areanetworking.it [email protected] http://ml.areanetworking.it/mailman/listinfo/cug
