BGP - konfederacja i problemy

[Michal Szczesny]

On Mon, Aug 27, 2001 at 07:59:54PM +0200, repcio w repe.k.pl wrote:

(...)

> Hmm z manuali Cisco to w ten sposób zrozumiałem kondeferację ;/

czyli ?
ogolnie, zarowno konfederacje jak i route reflektory sluza glownie do
wyeliminowania full mesh iBGP, przy 100 routerach bedzie to 4950 polaczen
(n(n-1)/2), znacznie elastyczniejsze i szybsze w implementacji (jak juz
mamy te 100 routerow) jest rozwiazanie bazujace na route reflektorach,
konfederacje maja ta przewage, ze sa to odrebne systemy autonomiczne, czyli
np. idealnie nadaja sie do wszelkich redystrybucji. 
np. majac taka siec:

AS1<-eBGP->AS5(a)<-iBGP->AS5(b)<-iBGP->AS5(c)<-eBGP->AS2

jesli nie bedzie polaczenia miedzy AS5(a) a AS5(c) to trasy oglaszane przez
te routery nie beda nawzajem widziane - mozna to szybko rozwiazac robiac z 
AS5(b) route reflektor, a z AS5(a) i AS5(c) jego klientow. w przypadku 
konfederacji mozemy np. przyjac, ze AS5(a) i AS5(b) beda tworzyly konfederacje 
AS65500, a AS5(c) bedzie konfederacja AS65505

> Jest jeden problem... często mimo iż ping na druga stronę jest sesja BGP 
> nie wstaje i wtedy iBGP mi się nie sprawdzało.. sprowadzało się to że w 
> sytuacji..
> 
>                     8664 (ICM)
>                      |
>      +------------ 65202 --------------+
>      |                                 |
>      |                                 |
>    65203                             65220 
>      |                                 
>      |                                 
>      +------------ 65205     
>                     
> na AS65205 (przy iBGP) mialem tylko własne prefixy po sieci...

poniewaz AS65205 musi miec polaczenie z AS65202 (tzn. ten rysunek to
oczywiscie eBGP, ale chodzi mi o AS65205, ktory na rysunku jest AS65202;))

ps. przy powyzszej topologii mozna zrobic 2 konfederacje: AS65203+AS65205 i
AS65202+AS65220 
-- 
michal szczesny