[c-nsp] BGP Route Reflectors

[Alex Foster]

Okay, so separating the physical topology - provided I'm running IGP - I can create iBGP peering between the loopbacks of routers that are not directly connected ??  Throughout any diagrams I looked at I always assumed that a full-mesh iBGP network inferred that a physical connection existed between each and every router (now that I consider that statement - it would seem ludicrous to expect that).

So in my scenario we don't need RRs just iBGP full-mesh as such:

Router A - iBGP to Loopback of Routers B,C,D
Router B - iBGP to Loopback of Routers A,C,D
Router C - iBGP to Loopback of Routers A,B,D
Router D - iBGP to Loopback of Routers A,B,C

Hopefully its as simple as that.

Regards

Alex




-----Original Message-----
From: Peter Salanki [mailto:peter.salanki at bahnhof.net] 
Sent: 11 July 2006 12:26
To: Alex Foster
Cc: Arnold Nipper; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] BGP Route Reflectors

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You have to separate physical topology from BGP topology. My  
suggestion is that you run an IGP (OSPF/IS-IS), and do full-mesh iBGP  
between loopbacks.

11 jul 2006 kl. 13.15 skrev Alex Foster:

> It will not be possible for me to implement a full mesh (at the  
> physical
> level), due to restrictions on ports/connectivity between sites -  
> hence
> my desire to run partial-mesh with route-reflectors.  The # of ISPs is
> really to allow us to maintain complete diversity across both sites  
> - so
> that if we loose site A all traffic would use the alternative links
> through site B (and still have upstream resilience).  The nature of
> traffic is VOIP so high-availability is important to us in all
> scenarios.
>
> Now that you understand my network options - I have had feedback from
> another list member who has advised me to steer clear of clustering  
> and
> to configure each router as a RR with the corresponding iBGP peers as
> clients:
>
> Router A is RR to clients B and C
> Router B is RR to clients D and A
> Router C is RR to clients A and D
> Router D is RR to clients B and C
>
> This would seem to make sense to me - but then Im no expert - so if  
> you
> have any additional ideas or feedback, feel free to comment.
>
> Regards
>
> Alex
>
>
>
> -----Original Message-----
> From: Arnold Nipper [mailto:arnold at nipper.de]
> Sent: 11 July 2006 11:43
> To: Alex Foster
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] BGP Route Reflectors
>
> On 11.07.2006 11:49 Alex Foster wrote
>
>> I am in the process of changing our current BGP architecture from
> single
>> site to dual site with some additional upstream peers.  Currently our
>> architecture is fairly simple and common:
>>
>> 	ISP 'A'			ISP 'B'
>> 	   |			    |
>> 	   |			    |
>> 	   |			    |
>> 	Router- A  -----iBGP------- Router B
>>
>> Were now looking to change it to this:
>>
>>
>> ISP 'A'			ISP 'B'
>> Site A			 Site A
>> 	   |			    |
>> 	   |			    |	
>> 	   |			    |
>> 	Router A  -----iBGP------- Router B
>>                |			    |
>>  	   |			    |
>> 	 iBGP			  iBGP	
>> 	   |			    |
>> 	   |			    |
>> 	Router C  ------iBGP------ Router D
>> 	   |			    |
>> 	   |			    |	
>> 	   |			    |
>> 	ISP 'C'			ISP 'D'
>> 	Site B			Site B
>>
>> Im aware that the four core routers are not fully meshed - and that I
>> need to implement some route reflection.  My understanding of this is
>> grainy at best so here is my stab at what I think needs to be done:
>>
>> Router C and Router B are RR in the same cluster with router A and D
> as
>> clients.
>> Router A and Router D are RR in the same cluster with router B and C
> as
>> clients.
>>
>> Would this provide me with the correct RR resilience whilst avoiding
> any
>> potential routing loops ??  Is this the best way to implement this or
> is
>> there a better way ??
>>
>
> I would run full mesh. RR with only 4 routers does not buy you much.
> Regarding # of ISP I would suggest to cut this down to two or at most
> three. From my experience more than two upstreams do not really buy  
> you
> something but headaches ...
>
>
> -- 
> Arnold Nipper, AN45
>
>
> This message has been scanned for viruses by MailController -
> www.MailController.altohiway.com
>
>
> The information in this e-mail and any attachments is confidential  
> and may be subject to legal professional privilege. It is intended  
> solely for the attention and use of the named addressee(s). If you  
> are not the intended recipient, or person responsible for  
> delivering this information to the intended recipient, please  
> notify the sender immediately. Unless you are the intended  
> recipient or his/her representative you are prohibited from, and  
> therefore must not, read, copy, distribute, use or retain this  
> message or any part of it. The views expressed in this e-mail may  
> not represent those of Gamma Telecom.
>
> This message has been scanned for viruses by MailController
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

Med vänliga hälsningar

Peter Salanki
Nätansvarig
Bahnhof AB (AS8473)
www.bahnhof.se
Kontor: +46855577132
Mobil: +46709174932



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFEs4rQiQKhdiFGiogRAkapAKCFrAa7Jqe+yF8dbSUVCDZSoAjZjQCggyRZ
7VONENPc+gXmC65YFfS+nPE=
=DH3J
-----END PGP SIGNATURE-----