Manav,

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.

Thanks,
Vishwas

-----Original Message-----
From: Manav Bhatia [mailto:mnvbhatiaYAHOO.COM]
Sent: Thursday, January 17, 2002 4:38 PM
To: OSPFDISCUSS.MICROSOFT.COM
Subject: Re: Router ID in Distributed Architecture

Hi Anton,
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
in synch.

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
minimized.

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 ?

Regards,
Manav

----- Original Message -----
From: "Anton Smirnov" <asmirnovCISCO.COM>
To: <OSPFDISCUSS.MICROSOFT.COM>
Sent: Thursday, January 17, 2002 4:24 PM
Subject: Re: Router ID in Distributed Architecture

| Manav,
| it is solely implementation matter. You can do it either way.
| Obviously, way of keeping completely separate running OSPF processes
on
| each blade is easiest to code and troubleshoot. On the other hand, it
will
| 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
full
| restart of the OSPF (i.e. adjacencies must be reestablished), but new
| process starts very quickly. In the past this approach provided
sufficient
| robustness and some implementations following it are on the market since
mid
| 90-th.
| 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
OSPF.
| Obviously, it poses some requirements both on hardware and underlying OS
| software and it complicates implementation significantly. How this
approach
| 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
OS).
| In the case of more common hardware I personally think that the most
logical
| solution would be modifying flooding procedure to ensure synchronization
of
| databases on boards before ack-ing anything to outside neighbors, but it
is
| not the only possibility.
|
| Three of these four approaches result in same RID for the whole box.
|
| Anton
|
| ----- 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
different
| > 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
the
| > router. In the distributed architecture it differs from a traditional
| > router in the sense that both control and data processing are
distributed
| > across different processors introducing new challenges in implementing
| > traditional routing protocols wherein each processor must have all of
| their
| > routing tables synchronized.
| >
| > Essentially each of the processors is a router by itself - compliant to
| rfc
| > 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
| whole
| > box is one unit - one router.
| >
| > Regards,
| > Manav Bhatia

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]