Subject: [OSPF] nexthop question.

From: Joakim Tjernlund <[email-masked]>
Date: Tue, 20 Jan 2009 19:27:52 +0100

OSPF RCF 2328, chap 16.1.1, last para reads:
            In the second case, the parent vertex is a network that
            directly connects the calculating router to the destination
            router.  The list of next hops is then determined by
            examining the destination's router-LSA.  For each link in
            the router-LSA that points back to the parent network, the
            link's Link Data field provides the IP address of a next hop
            router.  The outgoing interface to use can then be derived
            from the next hop IP address (or it can be inherited from
            the parent network).

I am having trouble telling which parts of the router LSA one should
consider. There are four types:
                   Link type   Description       Link ID
                   __________________________________________________
                   1           Point-to-point    Neighbor Router ID
                               link
                   2           Link to transit   Interface address of
                               network           Designated Router
                   3           Link to stub      IP network number
                               network
                   4           Virtual link      Neighbor Router ID

Type 3 and 4 isn't used here but what about type 1, should one look in 
those
for a matching IP address?
To me only type 2 makes sense though.

 Jocke

_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: "Sean Andersen" <[email-masked]>
Date: Tue, 20 Jan 2009 10:51:49 -0800

Jocke,

I am not sure what you are asking here. The next hop is the described in the
destination's router LSA depending on the network type. And the outgoing
interface to use is the one that is on the network of the next hop's IP
address, or the inherited network.

Sean

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Joakim Tjernlund
Sent: Tuesday, January 20, 2009 10:28 AM
To: [email-masked]
Subject: [OSPF] nexthop question.

 Jocke

---

From: Dave Katz <[email-masked]>
Date: Tue, 20 Jan 2009 11:59:35 -0700

I think you're confusing Link ID and Link Data.

But for what it's worth, for most implementations, point-to-point  
links have no next-hop address, so the issue is moot.  This avoids the  
issue of having to know or care whether the far end is numbered or  
unnumbered.

---

From: Joakim Tjernlund <[email-masked]>
Date: Tue, 20 Jan 2009 20:04:44 +0100

> address, or the inherited network.

You scan the router LSA to find potential matches. You should be able to 
disregard
some entries in the router LSA based on link type only. To me it feels 
like
you should only look at the link type 2 entries for an nexthop IP 
addresses.

---

From: Joakim Tjernlund <[email-masked]>
Date: Tue, 20 Jan 2009 20:12:09 +0100

> I think you're confusing Link ID and Link Data.

Possibly, but I am looking at an existing impl. here and I am
trying to make sense of it :)

> issue of having to know or care whether the far end is numbered or 

But PtoP links can have an IP address and if they do, should link type
1 be considered?

---

From: Dave Katz <[email-masked]>
Date: Tue, 20 Jan 2009 12:42:09 -0700

> But PtoP links can have an IP address and if they do, should link type

If you're only installing an interface nexthop, why would you care?

If you want to come up with a next hop address, you have the side  
issue you touched on earlier, which is trying to discern whether the  
far end is numbered (in which case the link data would be the next hop  
address) or unnumbered (in which case the link data would be an  
interface index that means nothing to you.)  Other than attempting to  
apply heuristics to the data to find out if it is an interface index  
or not (I don't remember whether SNMP defined indices as something  
less than 32 bits;  if not, there is no heuristic that can work) the  
only choice is to look at your own numbered/unnumbered configuration  
and hope the other guy is set up the same way.

It all gets tricky when there are multiple links between pairs of  
systems as well, as you need to correlate the LSAs to interfaces...

--Dave

---

From: Joakim Tjernlund <[email-masked]>
Date: Wed, 21 Jan 2009 10:42:18 +0100

> 
> On Jan 20, 2009, at 12:12 PM, Joakim Tjernlund wrote:
> 

OK, I understand. No need to supply a next hop address for PtoP links.
I still got a problem though :(

The text "for each link in the router-LSA that points back
to the parent network" is where I still got a problem.
How do I find the correct ones? Since router ID and Interface address
may have the same value, I cant just match Network vertex ID against
every entry in the Router LSA.
Since the parent vertex is a network, I figured that the only thing I
can match is the Network vertex ID against is link ID in link type 2
(Link to transit network) and use the link data is nexthop address.
The text says that each link should "point back to the parent network"
and that implies to me that you should only consider links that is 
attached
to a network and to me PtoP links never points to a network so one should 
exclude
PtoP links as possible nexthops.

I am probably very confused so if you could give me a clue or two,
I would be very grateful.

 Jocke

---

From: John Smith <[email-masked]>
Date: Wed, 21 Jan 2009 13:57:42 +0000 (GMT)

I want to understand what data link layer technology is referred to when we talk of p2p and nbma networks in OSPF? I believe nbma alludes to ATM and Frame Relay networks. If so, then we will see the # of nbma networks going down as more and more ethernet networks are replacing atm and FR.

Can a MPLS tunnel be a p2p network in OSPF? What is a p2p network - a serial interface?

Thanks, John

---

From: "Juergen Arlt" <[email-masked]>
Date: Thu, 22 Jan 2009 15:07:10 -0000

talking OSPF over that link. The interface uses unnumbered IP (0.0.0.0)
and is therefore using an associated IP - which is in fact the IP of
another interface on the same box. 
This associated IP interface has NO OSPF configured. So this interface
should it should not appear in the LSDB.

In the LSDB however I can see them because the router assumes the
associate address on the point to point link and on that link there is
OPSF.

Is this correct? How should OSPF announce an unnumbered point to point
link? Should this network be announced at all? Which address shall be
used to announce?

Thanks
Juergen Arlt

---

From: Acee Lindem <[email-masked]>
Date: Thu, 22 Jan 2009 14:19:41 -0500

> I have a router that is connected over the WAN to another one. It is

An unnumbered link without a full adjacency will not result in any  
links in the router LSA.

Thanks,
Acee

---

From: "Juergen Arlt" <[email-masked]>
Date: Fri, 23 Jan 2009 08:16:22 -0000

mean without a full adjacency. Aren't the two devices on that point to
point link always adjacent?

Thanks

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]] 
Sent: Donnerstag, 22. Januar 2009 20:20
To: Arlt, Juergen (GERST:476S)
Cc: [email-masked]
Subject: Re: [OSPF] How to announce an unnumbered PtP link in the LSDB

Thanks,
Acee

---

From: "Sean Andersen" <[email-masked]>
Date: Fri, 23 Jan 2009 00:23:15 -0800

Their state is full (as oppose to two way, etc.). That's what Acee is
saying.

Sean

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Arlt
Sent: Friday, January 23, 2009 12:16 AM
To: Acee Lindem
Cc: [email-masked]
Subject: Re: [OSPF] How to announce an unnumbered PtP link in the LSDB

Thanks for the answer - is that documented somewhere? And how do you
mean without a full adjacency. Aren't the two devices on that point to
point link always adjacent?

Thanks

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]] 
Sent: Donnerstag, 22. Januar 2009 20:20
To: Arlt, Juergen (GERST:476S)
Cc: [email-masked]
Subject: Re: [OSPF] How to announce an unnumbered PtP link in the LSDB

Thanks,
Acee

---

From: "Juergen Arlt" <[email-masked]>
Date: Fri, 23 Jan 2009 08:36:59 -0000

The routers on the unnumbered links are in full state. As the link is a
PtP link it would under normal circumstances (with numbered IP
addressing) appear in the router LSA.
But in my case the PtP link is unnumbered. What would be the
representation in the LSDB of that PtP link?
Will there be the address of the associated IP in the LSDB for that PtP
link even though the associated IP has no OSPF configured on its real
interface?

Hope that is clearer.
Thanks

Juergen

-----Original Message-----
From: Sean Andersen [mailto:[email-masked]] 
Sent: Freitag, 23. Januar 2009 09:23
To: Arlt, Juergen (GERST:476S); 'Acee Lindem'
Cc: [email-masked]
Subject: RE: [OSPF] How to announce an unnumbered PtP link in the LSDB

Juergen,

Sean

-----Original Message-----

Thanks

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]] 
Sent: Donnerstag, 22. Januar 2009 20:20
To: Arlt, Juergen (GERST:476S)
Cc: [email-masked]
Subject: Re: [OSPF] How to announce an unnumbered PtP link in the LSDB

Thanks,
Acee

---

From: Joakim Tjernlund <[email-masked]>
Date: Fri, 23 Jan 2009 09:53:02 +0100

> Thanks for the answer but let me clarify the situation:
> 

You will have ifIndex instead of address and no Option 1 nor Option 2

 Jocke

---

From: Abhijit Chaudhary <[email-masked]>
Date: Fri, 23 Jan 2009 14:37:15 +0530

According to RFC 2328, if a new router with higher priority is added to the 
broadcast/NBMA network, it cannot become DR if DR and BDR already exists for 
the network. This is done to avoid route-calculation, advertisement of new 
LSA and temporary loss of data traffic.
But in some scenario, it may be desirable to make the new router as DR 
because the new router has an upgraded software, has higher horse-power 
(more memory, ...) and the existing DR is unable to take any more load of 
the network.
In such scenario, is there any procedure to dynamically select the new 
router as the DR without manually changing the configuration of the existing 
DR and BDR? Does any other RFC define such a procedure?

Thanks,
- Abhijit
.

---

From: Richard Ogier <[email-masked]>
Date: Fri, 23 Jan 2009 07:55:16 -0800

The reason you give below is exactly why in the MANET extension called 
OSPF-MDR, router priority is given precedence over the existing DR (or 
MDR) status when a router decides whether it should be a DR (or MDR).

I think a simple backward compatible modification for OSPF is for a DR 
to simply change its interface state to DR Other or Backup if it has a 
neighbor with a larger router priority.  The neighbor will then select 
itself as a DR.  (If this results in two Backup DRs, one of them will 
change its state to DR Other.)  Similarly, a Backup DR can change its 
interface state to Other if it has two neighbors with a larger router 
priority.  Someone can correct me if I am wrong.

Richard

Abhijit Chaudhary wrote:

> Hi,
> According to RFC 2328, if a new router with higher priority is added 
> to the broadcast/NBMA network, it cannot become DR if DR and BDR 
> already exists for the network. This is done to avoid 
> route-calculation, advertisement of new LSA and temporary loss of data 
> traffic.
> because the new router has an upgraded software, has higher 
> horse-power (more memory, ...) and the existing DR is unable to take 
> any more load of the network.
> router as the DR without manually changing the configuration of the 
> existing DR and BDR? Does any other RFC define such a procedure?
>
> Thanks,
> - Abhijit
> .
>

---

From: Mitchell Erblich <[email-masked]>
Date: Fri, 23 Jan 2009 08:47:04 -0800

IF A DR were to be changed, the overhead of doing this change, can  
be more substantial than
		creating adjancies from scratch and during such a rollover AND  
during the change routing
		loops or DOS or eqivs are expected.

		THat said, the RFCs allow joining of areas where different DRs exist  
and re-electing a DR.

		THus in the simplest idea snoop  the advertised  priority and  
announce oneself as a DR with
		a higher priority.

		Mitchell Erblich
		===============

On Jan 23, 2009, at 1:07 AM, Abhijit Chaudhary wrote:

> already exists for the network. This is done to avoid route- 
> calculation, advertisement of new LSA and temporary loss of data  
> traffic.
> But in some scenario, it may be desirable to make the new router as  
> DR because the new router has an upgraded software, has higher horse- 
> power (more memory, ...) and the existing DR is unable to take any  
> more load of the network.
> In such scenario, is there any procedure to dynamically select the  
> new router as the DR without manually changing the configuration of  
> the existing DR and BDR? Does any other RFC define such a procedure?
>
> Thanks,
> - Abhijit
> .
>

---

From: Richard Ogier <[email-masked]>
Date: Fri, 23 Jan 2009 08:52:03 -0800

The problem is that in the DR election algorithm, an existing
BDR is preferred over an Other for becoming a DR, regardless
of router priority.  Therefore, both the DR and the BDR must
change their states to Other if they see an Other that has
higher router priority.  Hopefully, the following modification
works and is backward compatible.

If a DR has a neighbor with a larger router priority, then it
changes itself to an Other and runs the DR election algorithm.

If a BDR has a non-DR neighbor with a larger router priority, then it
changes itself to an Other and runs the DR election algorithm.
 
Richard

---

From: Acee Lindem <[email-masked]>
Date: Fri, 23 Jan 2009 13:07:32 -0500

> I need to update the modification I suggested earlier.

I believe a router supporting the proposed "DR preemption" would  
simply need to advertise itself as backup-DR to force a  
NeighborChange event on in other OSPF routers on the network.

Thanks,
Acee

>> According to RFC 2328, if a new router with higher priority is  
>> added to the broadcast/NBMA network, it cannot become DR if DR and  
>> BDR already exists for the network. This is done to avoid route- 
>> But in some scenario, it may be desirable to make the new router  
>> as DR because the new router has an upgraded software, has higher  
>> horse-power (more memory, ...) and the existing DR is unable to  
>> take any more load of the network.
>> new router as the DR without manually changing the configuration  
>> of the existing DR and BDR? Does any other RFC define such a  
>> procedure?
>>
>> Thanks,
>> - Abhijit
>> .
>>

---

From: Richard Ogier <[email-masked]>
Date: Fri, 23 Jan 2009 11:06:21 -0800

>
> On Jan 23, 2009, at 11:52 AM, Richard Ogier wrote:
>

But this is not enough if there is an Other that has the largest router 
priority.  The Other would still not promote itself to BDR or DR since 
it has a BDR neighbor (the one you refer to above).  Also, when the new 
BDR runs the DR election algorithm again, it will promote itself back to 
a DR.

That is why I am suggesting the following rules:

If a DR has a neighbor with a larger router priority, then it  changes 
itself to an Other (and advertises itself as such).

If a BDR has a non-DR neighbor with a larger router priority, then it  
changes itself to an Other (and advertises itself as such).

Otherwise, the DR election algorithm is run as usual.

Richard

>>> DR because the new router has an upgraded software, has higher

---

From: Joakim Tjernlund <[email-masked]>
Date: Fri, 23 Jan 2009 20:45:50 +0100

> Dave Katz <[email-masked]> wrote on 20/01/2009 20:42:09:
> > 

> I would be very grateful.

Ping, any clues to my ranting above?

 Jocke

---

From: Dave Katz <[email-masked]>
Date: Fri, 23 Jan 2009 17:27:22 -0700

>> PtoP links as possible nexthops.

I'm pretty confused about your confusion, though one of them seems to  
be mixing up "network" and "network LSA" which are not the same  
thing.  The paragraph applies to either type 1 or type 2 links.

The interface IP address of the next-hop router will never be the same  
for multiple links, as it would imply the same subnet assigned to two  
networks, so this disambiguates parallel numbered links.

In the case of numbered point-to-point links, it's trivial.  Find  
every link in the neighbor's LSA with your own router ID and grab the  
next-hop address out of the associated link data.  Sort out which  
interface each address belongs to, and you've got your next hop (you  
don't actually need the address.)

For the LAN/NBMA case you find the link that matches the network LSA  
you're looking through to see the router LSA, which tells you the  
interface, and the link data specifies the next hop address.

For unnumbered links you cannot actually disambiguate parallel links,  
but it doesn't really matter.  The next hop interface(s) are those  
matching the interface index in the local router LSA, with no next hop  
addresses.

--Dave

---

From: Richard Ogier <[email-masked]>
Date: Fri, 23 Jan 2009 17:59:45 -0800

> NeighborChange event on in other OSPF routers on the network.

As you suggest, it would be better to have the DR change
to a BDR, rather than a DR Other, when possible.  It may be
possible to do this if the router with larger router priority
is not a DR Other.  The following rules might achieve this.

1. If the router is DR or BDR and has a DR Other neighbor with
   a larger router priority, then it changes itself to DR Other.

2. Otherwise, if the router is DR and has a BDR neighbor with
   a larger router priority, then it changes itself to BDR.

If step 2 is executed, then the neighboring BDR with larger
router priority will soon change its state to DR.
Hopefully, this will happen before the the next time the
router itself runs the DR election algorithm.  If not, then
the router will change its state to DR Other temporarily, and then
back to BDR.  To avoid this, I think the DR election algorithm
can be modified so that a BDR can remain a BDR if there is no
DR and only one BDR neighbor has a lexicographically larger
value of (RtrPri, RID).

Obviously, some details need to be worked out.

Richard

---

From: Joakim Tjernlund <[email-masked]>
Date: Sat, 24 Jan 2009 21:22:25 +0100

> matching the interface index in the local router LSA, with no next hop 

Nice, this was useful info, but I still don't get why PtP links are
considered is this case. Here is why:

Input to this function is a parent vertex and a destination vertex. In 
this
case the parent vertex must be a Network vertex and the destination vertex
is a Router vertex. This Figure illustrates what I think this case is 
about: 
  CR -- N -- DR
 CR = Calculating Router
 N = Network in question
 DR = Destination Router

We are looking at N, a network vertex who is directly connected to the
calculating router, CR. The destination is DR is also connected to N.
No Ptp or PtMP is connected to a Network vertex, only LAN/NBMA are.
So the only link type that you should look for is type 2 that point back
to you and use its link_data as next hop.

Also, this paragraph mentions that you can inherit the outgoing interface 
from
the parent. I think this means that you don't have to look for it as you 
describe
above, just use the interface from the parent directly, or do I 
misunderstand?

I really need an example on how PtP links fits into this, I can't see it.

 Jocke

---

From: Richard Ogier <[email-masked]>
Date: Sat, 24 Jan 2009 16:08:28 -0800

Joakim Tjernlund wrote:

OK, I understand. No need to supply a next hop address for PtoP
links.
I still got a problem though :(

Since the parent vertex is a network, I figured that the only thing I
can match is the Network vertex ID against is link ID in link type 2
(Link to transit network) and use the link data is nexthop address.
The text says that each link should "point back to the parent
network"
and that implies to me that you should only consider links that is
attached
to a network and to me PtoP links never points to a network so one

should

exclude

Maybe I am missing something, but I am confused why you are requiring

the parent vertex to be a network. Just above the paragraph on page 168

that you quoted, you can find the following sentence:

"If the destination is a

directly connected network, or a router which connects to

the calculating router via a point-to-point interface, no

next hop IP address is required."

Therefore, for a point-to-point link, the next hop consists only

of the outgoing interface.  Does this answer your question or

am I missing something?

Richard

Jocke

---

From: Dave Katz <[email-masked]>
Date: Sun, 25 Jan 2009 01:44:01 -0700

When all else fails, just do what makes sense.  An SPF that didn't  
work with point-to-point would make for a pretty disjointed network...

--Dave

---

From: Joakim Tjernlund <[email-masked]>
Date: Sun, 25 Jan 2009 10:34:01 +0100

> of the outgoing interface.  Does this answer your question or

Ah, now we are getting closer I think. Chapter 16.1.1 is rather big 
describes
3 cases(the third being the one that doesn't match case 1 or 2 ):

            If there is at least one intervening router in the current
            shortest path between the destination and the root, the
            destination simply inherits the set of next hops from the
            parent.  Otherwise, there are two cases.  In the first case,
            the parent vertex is the root (the calculating router
            itself).
.....
            In the second case, the parent vertex is a network that
            directly connects the calculating router to the destination
            router.

The text you quoted is from the first case and I have no problem with that 
part and
it includes PtP links and both types of vertexes.
I have however only asked about the second case, I guess it got lost 
somewhere.

So looking only at the second case, does my theory make sense?

 Jocke

---

From: Richard Ogier <[email-masked]>
Date: Sun, 25 Jan 2009 10:22:39 -0800

Joakim Tjernlund wrote:

"If the destination is a

Richard

I think your point was that you don't see how point-to-point links fit

into the second case.  I think the answer is that they don't, since

for point-to-point links, the parent vertex is not a network, but is

the calculating router.  There is no transit network vertex associated

with a point-to-point link.  Thus, a point-to-point link always falls

into the first case, not the second case.  (This seems clear to me,

so I don't know why there was any confusion.)

Richard

Jocke

---

From: Joakim Tjernlund <[email-masked]>
Date: Sun, 25 Jan 2009 19:41:14 +0100

> so I don't know why there was any confusion.)

When I asked the question the first time I was not familiar with this
part of the spec. Since then I have been reading up and now things
are much clearer, thanks for the confirmation.

 Jocke

---

From: Abhijit Chaudhary <[email-masked]>
Date: Tue, 27 Jan 2009 10:56:01 +0530

> I believe a router supporting the proposed "DR preemption" would  simply 
> need to advertise itself as backup-DR to force a  NeighborChange event on 
> in other OSPF routers on the network.

----> As Mitchell Erblich suggested, I too believe to trigger "DR 
preemption", the new router that the administrator wants to be DR, can 
announce itself as DR with higher priority than the existing DR of the 
network. This will trigger a NeighbourChange event that makes the new router 
as DR, while previous BDR (before the DR election) still exists to be the 
new BDR.
I did not follow your suggestion to advertise the new router as backup-DR. 
As far as I understand, since a DR already exists for the network, 
announcing the new router as BDR will trigger neighbourchange event making 
the new router as BDR (not DR). Someone can please correct me if my 
understanding is wrong.
Thanks,
- Abhijit

>>> According to RFC 2328, if a new router with higher priority is  added to 
>>> the broadcast/NBMA network, it cannot become DR if DR and  BDR already 
>>> exists for the network. This is done to avoid route- calculation, 
>>> advertisement of new LSA and temporary loss of data  traffic.
>>> (more memory, ...) and the existing DR is unable to  take any more load 
>>> of the network.

---

From: Abhijit Chaudhary <[email-masked]>
Date: Tue, 27 Jan 2009 11:26:42 +0530

>   a larger router priority, then it changes itself to BDR.
---->
Hi Richard,
I actually meant DR pre-emption for a specific case (like software upgrade) 
when an administrator wants a router of his choice to become the DR.
Following Step 1 & Step 2 that you mentioned above as part of the generic 
DR-election algorithm will actually trigger new DR/BDR to be selected 
everytime a new router with higher priority is added. As the RFC suggests, 
it may not be desirable to change the DR and BDR of the network often.
Probably, the algorithm you mentioned can be kept as a separate 
DR-preemption algorithm, that gets triggered when a HELLO packet is received 
from a neighbour with a specific option bit set (DR-pre-emption bit).
Thanks,
- Abhijit

---

From: Dave Katz <[email-masked]>
Date: Tue, 27 Jan 2009 00:25:26 -0700

There's some confusion here.

Normally, simply raising the priority on a box will *not* make it DR.   
This is to avoid a new router showing up from seizing DR-ship to avoid  
a new DR election.  In this scenario, the new router will not be  
declaring *itself* to be DR, so the DR election algorithm will ignore  
it unless there is no other DR.

If, on the other hand, you wanted to make a router become DR  
preemptively, all it needs is to have the highest priority and to  
claim (in its Hello packets) that it is already the DR;  this is the  
fait accompli that will make it become DR.  This is a fine case of  
cheating the spec in a way that is useful and interoperable, *if  
you're careful.*  What would be a rather bad thing, however, is to  
claim that you're DR when you're not, and not going to be.  If you're  
trying to preempt like this, but the "real" DR has a higher priority  
(or the same priority but a higher router ID) then you're going to  
mess things up.  So any implementation that tries to pull this off  
needs a fail-safe mechanism of some sort to keep from totally screwing  
things up.

This sort of shenanigans runs the risk of tweaking bugs in other  
peoples' implementations, and while you might have the moral high  
ground in saying that it has to work unless the other guy is broken,  
this gains you little traction with customers, particularly when the  
other guy's broken implementation happens to have the highest market  
penetration (he says, speaking from experience.)

--Dave

On Jan 26, 2009, at 10:56 PM, Abhijit Chaudhary wrote:

> I actually meant DR pre-emption for a specific case (like software  
> upgrade) when an administrator wants a router of his choice to  
> become the DR.
> Following Step 1 & Step 2 that you mentioned above as part of the  
> generic DR-election algorithm will actually trigger new DR/BDR to be  
> selected everytime a new router with higher priority is added. As  
> the RFC suggests, it may not be desirable to change the DR and BDR  
> of the network often.
> Probably, the algorithm you mentioned can be kept as a separate DR- 
> preemption algorithm, that gets triggered when a HELLO packet is  
> received from a neighbour with a specific option bit set (DR-pre- 
> emption bit).
> Thanks,
> - Abhijit
>
>>>>> added to the broadcast/NBMA network, it cannot become DR if DR  
>>>>> and  BDR already exists for the network. This is done to avoid  
>>>>> route- calculation, advertisement of new LSA and temporary loss  
>>>>> of data traffic.
>>>>> But in some scenario, it may be desirable to make the new  
>>>>> router  as DR because the new router has an upgraded software,  
>>>>> has higher horse-power (more memory, ...) and the existing DR is  
>>>>> unable to  take any more load of the network.
>>>>> In such scenario, is there any procedure to dynamically select  
>>>>> the  new router as the DR without manually changing the  
>>>>> configuration  of the existing DR and BDR? Does any other RFC  
>>>>> define such a  procedure?
>>>>>
>>>>> Thanks,
>>>>> - Abhijit
>>>>> .
>>>>>

---

From: Mitchell Erblich <[email-masked]>
Date: Tue, 27 Jan 2009 00:08:04 -0800

Dave Katz, Et Al

		I partially agree..

		 ... DR re-election when a area JOINING results in two DRs is a  
required
		supported functionality via RFC AND SHOULD NOT tweak bugs..
		
		Identifing the RIGHT mechanics matching the arch and having a Fail- 
safe implementation
		that achieves without side-effects the desired result is almost a  
bit of an art, IMO.

		And ONE should NOT believe that all the expected pitfalls have been  
discussed in this
		thread.

		Mitchell Erblich
		=========================

On Jan 26, 2009, at 11:25 PM, Dave Katz wrote:

> Normally, simply raising the priority on a box will *not* make it  
> DR.  This is to avoid a new router showing up from seizing DR-ship  
> to avoid a new DR election.  In this scenario, the new router will  
> not be declaring *itself* to be DR, so the DR election algorithm  
> will ignore it unless there is no other DR.
>
> claim that you're DR when you're not, and not going to be.  If  
> you're trying to preempt like this, but the "real" DR has a higher  
> priority (or the same priority but a higher router ID) then you're  
> going to mess things up.  So any implementation that tries to pull  
> this off needs a fail-safe mechanism of some sort to keep from  
> totally screwing things up.
>
>> generic DR-election algorithm will actually trigger new DR/BDR to  
>> be selected everytime a new router with higher priority is added.  
>> As the RFC suggests, it may not be desirable to change the DR and  
>> BDR of the network often.
>>>>>> has higher horse-power (more memory, ...) and the existing DR  
>>>>>> is unable to  take any more load of the network.

---

From: Dave Katz <[email-masked]>
Date: Tue, 27 Jan 2009 01:17:49 -0700

> 		supported functionality via RFC AND SHOULD NOT tweak bugs..

"SHOULD NOT" is the key.  And refreshing your LSAs every 50 minutes  
instead of every 30 minutes SHOULD NOT cause problems.  But it did.   
In three different implementations from multiple companies.  I  
couldn't figure out for the life of me how it was even possible, and  
finally begged someone to explain it.  True evil genius.

> 		that achieves without side-effects the desired result is almost a  

It requires knowing the *whys* of the protocol mechanisms, which are  
not always obvious and are seldom documented.  And a really healthy  
sense of paranoia.

>
>
> 		And ONE should NOT believe that all the expected pitfalls have  
> been discussed in this
> 		thread.

Amen.

--Dave

---

From: Richard Ogier <[email-masked]>
Date: Tue, 27 Jan 2009 09:51:36 -0800

Abhijit Chaudhary wrote:

> upgrade) when an administrator wants a router of his choice to become 
> the DR.
> selected everytime a new router with higher priority is added. As the 
> RFC suggests, it may not be desirable to change the DR and BDR of the 
> network often.

Right.  But as you pointed out, some implementors might prefer that the 
DR should always be a router with the highest router priority, so the 
steps I suggested would provide this feature in a backward compatible 
way, if they are implemented on all routers attached to a given 
broadcast network.   I realize this is different from your objective.

> DR-preemption algorithm, that gets triggered when a HELLO packet is 
> received from a neighbour with a specific option bit set 
> (DR-pre-emption bit).

Right.  But you don't really need a new option bit, since it is backward 
compatible. A router that uses the new feature will only downgrade its 
DR status if there is a neighbor with higher router priority, and there 
is no need for that neighbor to select the DR-preemption option.

Richard

>>>>> route- calculation, advertisement of new LSA and temporary loss of 
>>>>> data traffic.