networking-forum.com
Community Blog • Community Wiki * Register  * Search  * Login
View unanswered posts • View active topics

Board index » Cisco Networking » Cisco Routing and Switching

All times are UTC - 6 hours [ DST ]


Post new topic Reply to topic  Page 1 of 2
  [ 35 posts ]  Go to page 1, 2  Next
  Print view Previous topic | Next topic 
Author Message
d_estin_y
PostPosted: Sun Jun 10, 2012 4:56 am 
Offline
Junior Member
Junior Member

Joined: Sat Mar 07, 2009 1:36 pm
Posts: 81
In a topology with 3 routers attached to a multi-access segment. The router with the highest priority will be the DR, with the default setting the one with highest RID will win the election. Once the DR is elected, then another router cannot override this election even if it has a higher priority.

R1 11.11.11.11 Prio 1
R2 22.22.22.22 Prio 1
R3 33.33.33.33 Prio 1

With this configuration R3 will be the DR if all routers are booted up at the same time. R2 will be the BDR.

Is it possible without reseting the OSPF process on any routers to elect R1 as the DR?
Top
 Profile  
 
mellowd
PostPosted: Sun Jun 10, 2012 5:00 am 
Offline
CCIE #38070
CCIE #38070
User avatar

Joined: Wed Jun 18, 2008 7:49 am
Posts: 12475
Location: London, UK
Certs: CCIE ,CC-NP/IP, JNCIP-SP, JNCIS-ENT, BC-/SPNE/NP
No

_________________
www.mellowd.co.uk/ccie/
Top
 Profile  
 
d_estin_y
PostPosted: Mon Jun 11, 2012 4:19 am 
Offline
Junior Member
Junior Member

Joined: Sat Mar 07, 2009 1:36 pm
Posts: 81
OKAY I accept the answer, but what about in a stable topology someone claiming to be a DR. Will that cause an interface state change?
Top
 Profile  
 
mellowd
PostPosted: Mon Jun 11, 2012 4:32 am 
Offline
CCIE #38070
CCIE #38070
User avatar

Joined: Wed Jun 18, 2008 7:49 am
Posts: 12475
Location: London, UK
Certs: CCIE ,CC-NP/IP, JNCIP-SP, JNCIS-ENT, BC-/SPNE/NP
I don't understand exactly. An interface state change is caused by an interface's state being changed. The DR is non-preemptive and hence any router claiming to be the DR on a segment which already has a DR will be ignored

_________________
www.mellowd.co.uk/ccie/
Top
 Profile  
 
d_estin_y
PostPosted: Mon Jun 11, 2012 5:44 am 
Offline
Junior Member
Junior Member

Joined: Sat Mar 07, 2009 1:36 pm
Posts: 81
mellowd wrote:
any router claiming to be the DR on a segment which already has a DR will be ignored


I would like to hear comments from others on this :roll:
Top
 Profile  
 
mellowd
PostPosted: Mon Jun 11, 2012 6:01 am 
Offline
CCIE #38070
CCIE #38070
User avatar

Joined: Wed Jun 18, 2008 7:49 am
Posts: 12475
Location: London, UK
Certs: CCIE ,CC-NP/IP, JNCIP-SP, JNCIS-ENT, BC-/SPNE/NP
Why are you rolling your eyes? Just read the RFC.

Section 7.3
Quote:
The Designated Router is elected by the Hello Protocol. A
router's Hello Packet contains its Router Priority, which is
configurable on a per-interface basis. 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. (This makes it harder to
predict the identity of the Designated Router, but ensures that
the Designated Router changes less often. See below.)
Otherwise, the router itself becomes Designated Router if it has
the highest Router Priority on the network. A more detailed
(and more accurate) description of Designated Router election is
presented in Section 9.4.


Go and read 9.4 yourself and you'll see exactly what happens.

http://www.ietf.org/rfc/rfc2328.txt

_________________
www.mellowd.co.uk/ccie/
Top
 Profile  
 
Project2501
PostPosted: Mon Jun 11, 2012 6:06 am 
Offline
Post Whore
Post Whore
User avatar

Joined: Thu Apr 17, 2008 6:44 pm
Posts: 6071
Location: Perth, WA
Certs: CCNA
You can lead a horse to water.

_________________
- Pete
Top
 Profile  
 
d_estin_y
PostPosted: Mon Jun 11, 2012 6:09 am 
Offline
Junior Member
Junior Member

Joined: Sat Mar 07, 2009 1:36 pm
Posts: 81
mellowd wrote:
Why are you rolling your eyes? Just read the RFC.

Section 7.3
Quote:
The Designated Router is elected by the Hello Protocol. A
router's Hello Packet contains its Router Priority, which is
configurable on a per-interface basis. 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. (This makes it harder to
predict the identity of the Designated Router, but ensures that
the Designated Router changes less often. See below.)
Otherwise, the router itself becomes Designated Router if it has
the highest Router Priority on the network. A more detailed
(and more accurate) description of Designated Router election is
presented in Section 9.4.


Go and read 9.4 yourself and you'll see exactly what happens.

http://www.ietf.org/rfc/rfc2328.txt



BTW thanks for the RFC ... but there are also some hidden things in rfc's ;)

anyway let someone else have a chance to help my eyes from not rolling ;)
Top
 Profile  
 
d_estin_y
PostPosted: Mon Jun 11, 2012 6:11 am 
Offline
Junior Member
Junior Member

Joined: Sat Mar 07, 2009 1:36 pm
Posts: 81
Project2501 wrote:
You can lead a horse to water.



what do u mean with this?

im not an English speaker :(
Top
 Profile  
 
Project2501
PostPosted: Mon Jun 11, 2012 6:20 am 
Offline
Post Whore
Post Whore
User avatar

Joined: Thu Apr 17, 2008 6:44 pm
Posts: 6071
Location: Perth, WA
Certs: CCNA
If you lead a horse to water for a drink it doesn't mean it'll drink.

By the same token, mellowd's been studying OSPF for the CCIE lab so much lately he probably poops hello messages.

Edit: Also if you don't agree with what mellowd's suggested then it would be polite to post why you don't think it's true. People on this forum and really patient so English not being a primary language isn't going to be a problem/barrier. Post away!

_________________
- Pete
Top
 Profile  
 
d_estin_y
PostPosted: Mon Jun 11, 2012 7:30 am 
Offline
Junior Member
Junior Member

Joined: Sat Mar 07, 2009 1:36 pm
Posts: 81
THANKS ... first for being polite :)

I agree that OSPF DR election is not pre-emptive ... to certain extent.

actually i came to the idea of posting this thread from the following thread.
viewtopic.php?f=33&t=31444

I now for the moment tell that R1 could be made a DR without clearing OSPF process on any routers.
sec 9.2 of 2328 also states this.
Code:
NeighborChange
There has been a change in the set of bidirectional
neighbors associated with the interface. The (Backup)
Designated Router needs to be recalculated.

One of the bidirectional neighbors is newly declaring
itself as either Designated Router or Backup Designated
Router.


any more comments now?
Top
 Profile  
 
ristau5741
PostPosted: Mon Jun 11, 2012 7:56 am 
Offline
Post Whore
Post Whore
User avatar

Joined: Tue Aug 21, 2007 2:15 pm
Posts: 8457
Location: Frederick MD
Certs: Instanity
Project2501 wrote:
By the same token, mellowd's been studying OSPF for the CCIE lab so much lately he probably poops hello messages.


lol.


rebooting router 2 and 3 will make router 1 the DR without resetting the OSPF process.

_________________
"If you're good at anticipating the human mind. It leaves nothing to chance."
-Jigsaw
Top
 Profile  
 
d_estin_y
PostPosted: Mon Jun 11, 2012 8:06 am 
Offline
Junior Member
Junior Member

Joined: Sat Mar 07, 2009 1:36 pm
Posts: 81
restarting the router will also restart OSPF process (clear ospf process) ;)
Top
 Profile  
 
ristau5741
PostPosted: Mon Jun 11, 2012 8:08 am 
Offline
Post Whore
Post Whore
User avatar

Joined: Tue Aug 21, 2007 2:15 pm
Posts: 8457
Location: Frederick MD
Certs: Instanity
d_estin_y wrote:
restarting the router will also restart OSPF process (clear ospf process) ;)


the same OSPF process would still be running on router 1.

_________________
"If you're good at anticipating the human mind. It leaves nothing to chance."
-Jigsaw
Top
 Profile  
 
Project2501
PostPosted: Mon Jun 11, 2012 8:55 am 
Offline
Post Whore
Post Whore
User avatar

Joined: Thu Apr 17, 2008 6:44 pm
Posts: 6071
Location: Perth, WA
Certs: CCNA
d_estin_y wrote:
any more comments now?


I actually read about this a while ago when I was studying more often.

That part of the RFC is describing a situation that has already occured and so a new BDR needs to be elected.

Code:
 One of the bidirectional neighbors is newly declaring
 itself as either Designated Router or Backup Designated
 Router.  This is detected through examination of that
 neighbor's Hello Packets.


An OSPF process would be doing this because another router has already defined its self as the DR during the exchange of Database Description packets and is now declaring its self as the BDR. Not because a router has recently been added after the DR/BDR election process has been performed.

I honestly can't even think of a time when a router running OSPF would attempt to elect a new DR/BDR when one already exists unless there was a change state to trigger it like a reboot or interface flap.

_________________
- Pete
Top
 Profile  
 
Steven King
PostPosted: Mon Jun 11, 2012 7:01 pm 
Offline
Post Whore
Post Whore
User avatar

Joined: Mon Nov 16, 2009 8:10 pm
Posts: 2629
Location: San Diego, CA
Certs: CCNP, BCNE, Network+, Security+
I'll vouch for Mellow. A new router added to an established OSPF process will not become DR.

Yeah, if you reboot every router so you effectively break the OSPF process, then of course a re-election will occur. That wasn't Mellow's point.

I just confirmed this. I got on GNS3 and hooked 3 routers up to eachother with serial interfaces, and then put a switch between them and connected them all to it with fast ethernet. I setup OSPF on R1 and R2 and verified the neighborship and that R2 configured with router-id 2.2.2.2 became the DR. After configuring R3 for OSPF with router-id 3.3.3.3, it did not take over as DR once the neighborships were established; R2 remained the DR.

_________________
Regards,

Steven King
San Diego Cisco User Group - http://www.sdcug.com
"The only time something is impossible is when you think it is." - Kevin Corbin, CCIE #11577
Top
 Profile  
 
d_estin_y
PostPosted: Tue Jun 12, 2012 12:09 am 
Offline
Junior Member
Junior Member

Joined: Sat Mar 07, 2009 1:36 pm
Posts: 81
Project2501 wrote:

I honestly can't even think of a time when a router running OSPF would attempt to elect a new DR/BDR when one already exists unless there was a change state to trigger it like a reboot or interface flap.


My point was to prove if an existing DR could be made NOT a DR. Such a scenario could arise in the CCIE Lab.

I again say ... an existing DR could be made not a DR if some other says that he is a DR. Technically, if someone says that he or someone else is a DR, a new election takes place. At this point we could configure the router we want to.. to be the DR.

Steven King wrote:
I setup OSPF on R1 and R2 and verified the neighborship and that R2 configured with router-id 2.2.2.2 became the DR. After configuring R3 for OSPF with router-id 3.3.3.3, it did not take over as DR once the neighborships were established; R2 remained the DR.


When R3 joined the broadcast domain, the election was already done. Thus he accepted the DR told to him.

I think that I used the word "preemption" which is wrong.... But what I wanted is just to achieve a new router from being a DR without clearing the ospf process in any way.
Top
 Profile  
 
Project2501
PostPosted: Tue Jun 12, 2012 12:28 am 
Offline
Post Whore
Post Whore
User avatar

Joined: Thu Apr 17, 2008 6:44 pm
Posts: 6071
Location: Perth, WA
Certs: CCNA
d_estin_y wrote:
without clearing the ospf process in any way.


What do you mean by clearing the OSFP process?

Based on the RFC which state or trigger is closest to what you're trying to achieve? I only ask because I don't see which change state would exist where a new DR is elected without a neighbour losing connectivity or a configuration error occurs causing the OSPF process to start afresh.

Code:
                                   +----+
                                   |Down|
                                   +----+
                                     |\
                                     | \Start
                                     |  \      +-------+
                             Hello   |   +---->|Attempt|
                            Received |         +-------+
                                     |             |
                             +----+<-+             |HelloReceived
                             |Init|<---------------+
                             +----+<--------+
                                |           |
                                |2-Way      |1-Way
                                |Received   |Received
                                |           |
              +-------+         |        +-----+
              |ExStart|<--------+------->|2-Way|
              +-------+                  +-----+

              Figure 12: Neighbor state changes (Hello Protocol)

                  In addition to the state transitions pictured,
                  Event KillNbr always forces Down State,
                  Event InactivityTimer always forces Down State,
                  Event LLDown always forces Down State



Code:
                                  +-------+
                                  |ExStart|
                                  +-------+
                                    |
                     NegotiationDone|
                                    +->+--------+
                                       |Exchange|
                                    +--+--------+
                                    |
                            Exchange|
                              Done  |
                    +----+          |      +-------+
                    |Full|<---------+----->|Loading|
                    +----+<-+              +-------+
                            |  LoadingDone     |
                            +------------------+

            Figure 13: Neighbor state changes (Database Exchange)

                In addition to the state transitions pictured,
                Event SeqNumberMismatch forces ExStart state,
                Event BadLSReq forces ExStart state,
                Event 1-Way forces Init state,
                Event KillNbr always forces Down State,
                Event InactivityTimer always forces Down State,
                Event LLDown always forces Down State,
                Event AdjOK? leads to adjacency forming/breaking

_________________
- Pete
Top
 Profile  
 
d_estin_y
PostPosted: Tue Jun 12, 2012 12:35 am 
Offline
Junior Member
Junior Member

Joined: Sat Mar 07, 2009 1:36 pm
Posts: 81
clear ip ospf process or reload will restart the ospf process.

even if a neighbor ship is lost, it must not all the time cause a re election.
Top
 Profile  
 
mellowd
PostPosted: Tue Jun 12, 2012 2:28 am 
Offline
CCIE #38070
CCIE #38070
User avatar

Joined: Wed Jun 18, 2008 7:49 am
Posts: 12475
Location: London, UK
Certs: CCIE ,CC-NP/IP, JNCIP-SP, JNCIS-ENT, BC-/SPNE/NP
Whenever you have this type of question, lab it, read the RFC and see what really happens.

I say both because a lot of the time vendors don't follow the RFC 100%

A bit of wireshark and RFC reading on this will answer all your questions :)

_________________
www.mellowd.co.uk/ccie/
Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 1 of 2
  [ 35 posts ]  Go to page 1, 2  Next

Board index » Cisco Networking » Cisco Routing and Switching

All times are UTC - 6 hours [ DST ]

Who is online

Users browsing this forum: jambo+22 and 33 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group