>----Messaggio originale---- >Da: [email protected] >Data: 14/09/2009 0.34 >A: "AreaNetworking Cisco Users Group"<[email protected]. it> >Ogg: Re: [Cug] BGP: next-hop-self VS redistribute connected > >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 > Io andrei di next-hop self, la red della statica mi sembra troppo macchinoso, credo anche che bisogna dare un occhio a cio che si red. Magari a livello di isp non succede (non ho esp in campo isp), ma pensa se il tuo ebgp ti annunciasse 2 net differenti, esempio stupido la 151.1.1.1/32 e la 152.1.1.1/32 con il nex-hop self ti basterebbe un solo cmd, con la red delle statiche dovresti add 2 statiche (che puntano lo stesso gw), poi agg la red nel proc bgp.... credo che il vantaggio che ti l utilizzo della statica e' "l evidenza del percorso" mentre cambiando il well-know att, la cosa diventa magari un attimino meno evvidente. Daniele
_______________________________________________ http://cug.areanetworking.it [email protected] http://ml.areanetworking.it/mailman/listinfo/cug
