openospfd router-priority

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

openospfd router-priority

Tim Epkes
All,

I had implemented a network using openospf and initially left
router-priorities off.  Problem is I kept coming up FULL/OTHER and would
not get routes.  I changed the router priority values (not to match as when
I matched got the same).  I changed one side of a line to 10, while the
other was 5.  When I reloaded the side I changed, it stayed in FULL/OTHER
state when it came up again.  To get it to change to FULL/DR or FULL/BCKUP
I needed to reload both systems ospfd daemons.  Then it recalced fine.
 This leads me to believe that their isn't a full renegotiation if the
other side is still running.  That would be hard to do in an environment
where you have to bring down the entire network to make a change.  Is this
a bug or was this the intended deployment.  Also if priorities match,
shouldn't they then move to see who has the highest RID to determine DR and
Backup.  Cause coming up as OTHER by default was a real pain.  Thanks

P.S. once all reloaded it works fine.

Tim
Reply | Threaded
Open this post in threaded view
|

Re: openospfd router-priority

Florian Riehm-2
On 08/19/14 21:45, Tim Epkes wrote:

> All,
>
> I had implemented a network using openospf and initially left
> router-priorities off.  Problem is I kept coming up FULL/OTHER and would
> not get routes.  I changed the router priority values (not to match as when
> I matched got the same).  I changed one side of a line to 10, while the
> other was 5.  When I reloaded the side I changed, it stayed in FULL/OTHER
> state when it came up again.  To get it to change to FULL/DR or FULL/BCKUP
> I needed to reload both systems ospfd daemons.  Then it recalced fine.
>  This leads me to believe that their isn't a full renegotiation if the
> other side is still running.  That would be hard to do in an environment
> where you have to bring down the entire network to make a change.  Is this
> a bug or was this the intended deployment.  Also if priorities match,
> shouldn't they then move to see who has the highest RID to determine DR and
> Backup.  Cause coming up as OTHER by default was a real pain.  Thanks
>
> P.S. once all reloaded it works fine.
>
> Tim
>

Hi Tim,

If you start two ospfd without any special router priority, the default priority
of both routers is 1, one router becomes DR and the other one BDR.
That's how it supposed to work and if it doesn't something is wrong. I have
tried it with a very simple configuration and it works for me.

If your network is up alreade and their is a DR in it and another ospfd goes
up, the DR won't change regardless of it's priority.
See RFC 2328 section 7.3:
In general, when a router's interface to a network first becomes functional,
it checks to see whether there is currently a Designated Router for the
network. If there is, it accepts that Designated Router, regardless of its
Router Priority.

Why will you enforce a new DR if their is already one?

Florian

Reply | Threaded
Open this post in threaded view
|

Re: openospfd router-priority

Tim Epkes
Agree with once elected a DR he stays that way (eliminates a lot of
bouncing).  My issue was that both sides became FULL/OTHER.  I stopped all
and removed all router priorities and let them go default. When I brought
it all back up, most went FULL/OTHER on both sides so I got nothing.  I am
using a /31 on the interfaces, I don't know if that messes anything up.  In
the past Linux use to have an issue with /31 links.

Tim


On Tue, Aug 19, 2014 at 4:52 PM, Florian Riehm <[hidden email]> wrote:

> On 08/19/14 21:45, Tim Epkes wrote:
> > All,
> >
> > I had implemented a network using openospf and initially left
> > router-priorities off.  Problem is I kept coming up FULL/OTHER and would
> > not get routes.  I changed the router priority values (not to match as
> when
> > I matched got the same).  I changed one side of a line to 10, while the
> > other was 5.  When I reloaded the side I changed, it stayed in FULL/OTHER
> > state when it came up again.  To get it to change to FULL/DR or
> FULL/BCKUP
> > I needed to reload both systems ospfd daemons.  Then it recalced fine.
> >  This leads me to believe that their isn't a full renegotiation if the
> > other side is still running.  That would be hard to do in an environment
> > where you have to bring down the entire network to make a change.  Is
> this
> > a bug or was this the intended deployment.  Also if priorities match,
> > shouldn't they then move to see who has the highest RID to determine DR
> and
> > Backup.  Cause coming up as OTHER by default was a real pain.  Thanks
> >
> > P.S. once all reloaded it works fine.
> >
> > Tim
> >
>
> Hi Tim,
>
> If you start two ospfd without any special router priority, the default
> priority
> of both routers is 1, one router becomes DR and the other one BDR.
> That's how it supposed to work and if it doesn't something is wrong. I have
> tried it with a very simple configuration and it works for me.
>
> If your network is up alreade and their is a DR in it and another ospfd
> goes
> up, the DR won't change regardless of it's priority.
> See RFC 2328 section 7.3:
> In general, when a router's interface to a network first becomes
> functional,
> it checks to see whether there is currently a Designated Router for the
> network. If there is, it accepts that Designated Router, regardless of its
> Router Priority.
>
> Why will you enforce a new DR if their is already one?
>
> Florian
>
Reply | Threaded
Open this post in threaded view
|

Re: openospfd router-priority

Stuart Henderson-6
On 2014/08/19 18:32, Tim Epkes wrote:
> Agree with once elected a DR he stays that way (eliminates a lot of
> bouncing).  My issue was that both sides became FULL/OTHER.

I get this sometimes, usually after a link has gone away for a bit but
hasn't lost link, normally restarting ospfd on one router brings things back.
(I seem to have to restart ospfd quite a lot, vlan additions often need it
too.)