Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Manral, Vishwas (VishwasMNETPLANE.COM)
Date: Thu Jan 17 2002 - 06:01:23 CST
Though I would start by saying that the approach is implementation specific,
let me hazard an attempt to answer ur question. The idea, as I see it, is
that we have a broadcast link with all the routers in the cluster connected.
The DR of the network is what is visible to the external world. If you want
to use OSPF within the cluster, we necessarily need to have different
router-ids for the entire thing to work, not just DR election(even DB
exchange will not happen).
Also any internal info to the cluster should not be visible to external
routers, this can be done by using filters. However what is the router-id to
be used in hellos to routers outside the domain, I guess its that of the DR.
In that case you need to have a mechanism to tell the routers to use the
router-id of DR in Hellos to routers outside the cluster(this will require a
proprietry mechanism or a twist in the code). Also all information
originated for internal links should not be distributed to other routers
i.e. the router LSA for the cluster would have to be the union of
information in all individual router LSA's of routers(minus the links
internal to the cluster), and have the router ID of the DR. There would be a
lot of other issues, I guess, router-Id would be just a small one.
A routing table computaion in an approach which can be used in your kind of
environment has been described in the paper, "Parallel Routing Table
Computation for Scalable IP Routers" by Xipeng Xiao and Lionel Ni.
It may be of help.
From: Manav Bhatia [mailto:mnvbhatiaYAHOO.COM]
Sent: Thursday, January 17, 2002 4:38 PM
Subject: Re: Router ID in Distributed Architecture
Thanks for such a detailed reply.
I have some doubts though.
The approach which seems most optimal and best suited to my designs seems
to be your last implementation wherein there are separate OSPF daemons
running which appear as one fully functional OSPF daemon to the external
world. There are a lot of complications involved in keeping the processes
Suppose i have multiple routers configured inside a single area. From the
outside it appears that this mega router has some interfaces which are
connected to the external world. But within this box, we know that those
interfaces are spread across multiple routing engines.
I assign each one of the router a common Router ID. My problem starts when
i have to choose one router from this whole lot to act as a designated
router for my BIG Box. This way i can reduce the traffic generated inside
my BOX and keep the number of adjacencies each router has to maintain
But for the DR selection we need to have different Router IDs .. Here in
this case we assign a single common Router ID to all the routers. How do we
then run the election process ?
----- Original Message -----
From: "Anton Smirnov" <asmirnovCISCO.COM>
Sent: Thursday, January 17, 2002 4:24 PM
Subject: Re: Router ID in Distributed Architecture
| it is solely implementation matter. You can do it either way.
| Obviously, way of keeping completely separate running OSPF processes
| each blade is easiest to code and troubleshoot. On the other hand, it
| represent each box as ~~dozen of OSPF vertexes in each area. It impacts
| scalability very much, and so decreases value of the overall product. I
| never heard of any product taking this approach.
| Next easiest would be keeping separate running processes; one of them
| fully active and rest is in hot standby state, ready to start
| resynchronization in microseconds. Death of primary process results in
| restart of the OSPF (i.e. adjacencies must be reestablished), but new
| process starts very quickly. In the past this approach provided
| robustness and some implementations following it are on the market since
| Next approach is keeping processes separate but provide special
| out-of-box signaling to make backup process gracefully take over full
| responsibilities of failed process with the help of neighboring devices.
| Check wg drafts for possible methods of a such 'non-stop forwarding
| restart'. Benefits and drawbacks of the approach discussed there as well.
| The ultimate approach would be to make separate processes fully
| synchronized yet visible from outside of the box as one standard-based
| Obviously, it poses some requirements both on hardware and underlying OS
| software and it complicates implementation significantly. How this
| can be implemented depends on many factors. For example, if processors on
| boards have access to shared memory large enough to keep LSDB and related
| structures, then switchover between processes may be painless and almost
| automatic from OSPF process point of view (all the job will be done by
| In the case of more common hardware I personally think that the most
| solution would be modifying flooding procedure to ensure synchronization
| databases on boards before ack-ing anything to outside neighbors, but it
| not the only possibility.
| Three of these four approaches result in same RID for the whole box.
| ----- Original Message -----
| From: "Manav Bhatia" <mnvbhatiaYAHOO.COM>
| To: <OSPFDISCUSS.MICROSOFT.COM>
| Sent: Thursday, January 17, 2002 04:29
| Subject: [OSPF] Router ID in Distributed Architecture
| > Hi,
| > In a distributed architecture the implementation of OSPF will be
| > from the current OSPF implementations as in a traditional router.
| > Traditional router implements the routing protocols on a centralized
| > processor, which has visibility to all the interfaces associated with
| > router. In the distributed architecture it differs from a traditional
| > router in the sense that both control and data processing are
| > across different processors introducing new challenges in implementing
| > traditional routing protocols wherein each processor must have all of
| > routing tables synchronized.
| > Essentially each of the processors is a router by itself - compliant to
| > 1812.
| > Now in such a scenario, will each of the individual routers be given a
| > unique router ID or will my whole box aggregating each of these routers
| > have one unique router ID in the domain?
| > I feel that the whole box should be given one router ID independent of
| > number of routers it aggregates inside for to the external world this
| > box is one unit - one router.
| > Regards,
| > Manav Bhatia