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 <marelines(_at_)yahoo(_dot_)com>
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 |
| jstracke(_at_)incentivesystems(_dot_)com |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
ietf_censored(_at_)carmen(_dot_)ipv6(_dot_)cselt(_dot_)it, which
is a sublist of ietf(_at_)ietf(_dot_)org(_dot_) Not all messages are passed.
Decisions on what to pass are made solely by Raffaele D'Albenzio.