thoughts....
1) one and only one of your boxes will send the TCP ACK on the
BGP session for incoming packets. this argues for keeping the
replication mechanism well away from the incoming BGP session.
2) if your boxes have much higher bandwidth between them than to
the external world, letting one compute the routing table and
the others snapshot it at intervals may be a better strategy than
running a distributed routing computation across the internal net.
3) same argument if the limiting factor is the CPU power
4) if internal comm is slow, and cpus fast, ibgp may be the
right approach. (but that would seem strange)
Lots of ideas, most of them irrelevant to the config you are running,
probably....
Harald
--On 5. desember 2001 09:17 +0530 Mareline Sheldon <[EMAIL PROTECTED]>
wrote:
> No the processors are not going to be exposed to the outside world. From
> outside it'll be one single router. You yourself acknowledge the problems
> in client-server architecture.
> My intention is to let all other routers on my private LAN (inside my
> router) know of all the routing updates each of my processor gets.
>
> This is my idea, i dont know feasible it actually is:
>
> As soon as one router recieves an update from the outside world it simply
> broadcasts it within the router. Mind you we are talking of the BGP
> packets (in effect TCP). Now my doubt is that each router will receive
> that broadcast packet. But how to get it up the TCP stack to port 179. TCP
> doesn't support broadcast/multicast so how do i do that !?!?
>
> What changes do i need to bring in to the BGP protocol so that it may
> accept broadcast packets also from its virtual interfaces i.e ones within
> the router.
>
> Can i do some sort of broadcasting/multicasting of TCP packets on an
> ethernet.
>
> regards,
> mareline s.
>
> John wrote:
>
> Well...fundamentally, I'm not sure you have much in the way of
> alternatives. You could use a different synchronization protocol; but the
> scaling issues are likely to be the same as with BGP. (I'm assuming here
> that you're not planning on exposing the N processors to the outside BGP
> world separately.) Either way, you're passing messages around which update
> the routing table.
>
> One option would be a client/server system, where the clients forward all
> incoming BGP updates to the server, and the server maintains the routing
> table. This could work if you can devise a server-to-client protocol that
> the clients can interpret more cheaply than they interpet BGP. (The
> simplest way to do that, of course, is if all the processors are in a
> single box, and the clients can read the routing table directly out of
> memory.) This has the disadvantage of introducing a single point of
> failure.
>
> /==============================================================\
>| John Stracke |Principal Engineer |
>| [EMAIL PROTECTED] |Incentive Systems, Inc. |
>| http://www.incentivesystems.com|My opinions are my own. |
>| ==============================================================|
>| "Simply vanished--like an old oak table." --Lord Percy, _Black|
>| Adder II_ |
> \==============================================================/
> ---
> The grass is high,
> The fields are ripe,
> It's the springtime of my life.
>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
> -
> This message was passed through [EMAIL PROTECTED], which
> is a sublist of [EMAIL PROTECTED] Not all messages are passed.
> Decisions on what to pass are made solely by Raffaele D'Albenzio.
>
>
