cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5119
Views
38
Helpful
28
Replies

Multiple OSPF Processes & Router-ID Election from Loopbacks

dmarekatc
Level 1
Level 1

Having difficulty in finding a firm answer on this detailed scenario, so here goes...

Scenario: One(1) router with two(2) OSPF processes running on it, and two(2) loopback interfaces & IP addresses have been defined.

The root question: Which OSPF process will get which Router-ID/IP address from which interface?

In conjunction with the question above, there are two possibilities but there is also an important implied question of consistency.

In other words, will OSPF processX ALWAYS get the same Router-ID and OSPF processY ALWAYS gets its same Router-ID, both based on looking to available (and not already in use) loopback interfaces - So essentially, what is Cisco's mechanism & is it consistent across IOS versions? There seems to again be two philosophies - Either "Cisco says" the process with the lower (or higher) process number goes first which would provide consistent results; or it says whichever one comes first in the config goes first which will most likely always remain the same, but at least in theory, could be altered & thus effect the resulting Router-ID assigned.

To Illustrate/Mock Things Up:

interface Loopback0

ip address 1.1.1.1 255.255.255.255

interface Loopback1

ip address 2.2.2.2 255.255.255.255

router ospf 100

network x x area x

router ospf 200

network y y area y

Here ospf 100 should have Router-ID 1.1.1.1 and ospf 200 Router-ID 2.2.2.2, but is that because it came first or because it has the lower process number? Would the results be the same if the IOS version changed or the config looked like this from top-down?:

interface Loopback0

ip address 1.1.1.1

interface Loopback1

ip address 2.2.2.2

router ospf 200

network y y area y

router ospf 100

network x x area x

i.e. What do you think ospf 200's Router-ID is?

Please Note (to nip some things in the bud): The typical selection process for determining the Router-ID is known (you don't need to post it just for the sake of posting it). Also, Yes - I'm aware that by explicitly specifying the Router-ID in each process resolves the consistency matter... but then there would have been no need/point in asking the question(s), and the questions are more about the mechanism (and resulting consistency) used by Cisco in a multi-process environment than actually having a "how do I get the end result" answer.

(I've also done testing in lab, so I can essentially answer the question, but a few small tests don't necessarily make things definitive nor would it prompt discussion.)

Thanks.

28 Replies 28

Richard Burts
Hall of Fame
Hall of Fame

Dan

It is good to see you active in the forum.

I have some experience with this, but not enough to be definitive. But enough to contribute to the discussion. In my experience the first process to initialize will get the higher of the loopback interface addresses. In general I would expect the process listed first in the config to be the one to initialize first. And as far as I remember the IOS has been fairly consistent in listing the processes in numeric order.

So I would expect some consistency that the lower numbered process should generally get the higher loopback address as its RID. But as you comment it is not something that we can really count on - who knows what would cause a process to take longer to initialize.

My recommendation is that consistency is a very good thing and to assure real consistency you should configure the RID in each process.

HTH

Rick

HTH

Rick

marikakis
Level 7
Level 7

Hello,

First of all, I am not posting for the sake of posting. I get the picture that you have done your homework. I am posting because I find this interesting and although I have never done this test myself, I would really like to know the answer you already have. :-)

I will try to put myself in the router's shoes or rather in the poor guys' shoes that write the software for it. When the administrator does not specify things by force, I have to make a decision of my own. When you start the first process, I cannot generally know if you will start a second process later or when you do start one whether the second process will have a higher ospf process number than the first one (only in the case where you chose process number 1 for the first process could I know that the second process will have a higher process number). So, I follow the same logic every time you start a process. I only like up/up interfaces, I like loopbacks more than any other interface, I try to grab the loopback with the highest id not already in use. If you have 100 loopbacks I will begin my search from the highest and when I find the first available, I stop my search. If you have no loopbacks or are all already in use, I will try using highest IP address from up/up interfaces. If administrator does not like what I do, I give him a hook to router-id the process by force.

Kind Regards,

M.

Maria

You are right that it is an interesting question and we welcome you as part of the discussion.

One small point: both you and Dan seem to believe that the OSPF process will prefer to take the loopback with the lowest interface number. In my experience OSPF prefers to take the address that is numerically higher. So it matters less whether it is loopback0 or loopback1 and matters more whether it is network 1.1.1.1 or 2.2.2.2. If Dan has test results that indicate that the behavior has changed since I did my testing with this (which has been a while) please jump in. Other than that I think that your summary of the router logic is right on the mark.

[edit] when I re-read your post I see that I misinterpreted your discussion about the search for the loopback. My first read thought that you were saying that it stopped when it found the first available (which I thought meant first numerically available interface). Now that I read again you did specify that it starts from the highest and searches for an available address. My apologies.

HTH

Rick

HTH

Rick

Yes, you are right, I got a bit confused on this. I have edited my response when I saw my own note about non-loopbacks, but I am still confused. The process for other types of interfaces is clear to me, I think I got it right in the first place, but the loopback part still confuses me.

I think I have read about "first configured loopback" somewhere else, but I am not absolutely sure. I will keep searching all night (it is 21:00 in Greece now) unless we have the answer :-)

I want to add one thing however. When router initializes, it does not matter if configuration of OSPF processes is "sorted". This because the configuration is passed to the parser and from the parser's point of view this procedure is no different than the procedure the administrator follows to conf t during normal router operation.

Kind Regards,

M.

p.s. Keep editing (wrote 'interfaces' instead of 'processes'), I'd better go to sleep!

You were right in the first place, you read correctly, I am the one that keeps making mistakes (spelling and non-spelling). You are quick, I should edit faster :-)

I got my library down on the carpet, and the Cisco IP Routing super-book from Alex Zinin says that the command "router-id " was introduced in IOS 12.1. Before that, the router-id was selected automatically by using "highest IP address" logic, first tried loopbacks and then other interfaces.

Kind Regards,

M.

p.s. Still not gone to sleep, but I can handle copying the book. :-)

Maria

I am glad that I did not mis-read the post the first time around. And I believe that you are correct in the revised way that you describe it. The general logic is:

- only consider addresses that are not already used as router ID.

- only consider addresses that are up/up.

- prefer loopback interfaces and then physical interfaces.

- prefer numerically higher addresses to numerically lower addresses.

So IOS searches among available loopback interfaces for the numerically highest available loopback and if it finds no available loopback then it searches among available physical interfaces for the numerically highest available physical interface. And if it can not find any available loopback or physical interface to serve as RID then the process does not initialize.

HTH

Rick

HTH

Rick

Rick, I am giving you 5 for helping me clear this point with "highest IP address" logic.

Have fun in NetPro!

Edit: Good summarization man! I will give you another 5, so others (and me:-) can find this information right away when needed.

Maria

Thank you for the compliment and for the rating.

Now it is time for you to get some sleep.

HTH

Rick

HTH

Rick

Hello Rick (& All),

Nice to see you're active as ever here.

Yeah, it was an interesting pondering as I looked into router-id behavior under multiple processes and thought it might make for some discussion and/or debate.

For any that are curious, we have monitoring that gathers quite a bit of information for dissemination / alerting of problems, and the potential of differing values can give it confusion, so bringing consistency while allowing for things to be "semi-dynamic" (use of loopbacks versus an explicit router-id) led me down this road...

(BTW there were comments/then edits in the posts above, so I'm not sure where things stood but I'm not under the impression interface number matters [it doesn't], but rather it's the highest IP on any available loopback that is not already a router-id... However, since re-edits seem to be fashionable I do see in my first example I also flipped the router-id mistakenly *kudos to you if you caught it* / sorry if it brought confusion)

*Let me repost the examples correctly*

To Illustrate/Mock Things Up:

interface Loopback0

ip address 1.1.1.1 255.255.255.255

interface Loopback1

ip address 2.2.2.2 255.255.255.255

router ospf 100

network x x area x

router ospf 200

network y y area y

Here ospf 100 should have Router-ID 2.2.2.2 and ospf 200 Router-ID 1.1.1.1, but is that because it came first or because it has the lower process number? Would the results be the same if the IOS version changed or the config looked like this from top-down?:

interface Loopback0

ip address 1.1.1.1

interface Loopback1

ip address 2.2.2.2

router ospf 200

network y y area y

router ospf 100

network x x area x

i.e. What do you think ospf 200's Router-ID is?

*The Results*

As for actual behavior, it's somewhat disappointing... It appears the order in the config determines which process goes first and not the process number upon reload - Nor does the CLI rearrange things for you. (That means, in the 2nd example - ospf 200 gets 2.2.2.2) So be mindful of how you order things (as with ACLs), to get the desired results.

Also note, a clearing of the ospf processes does not necessarily reset everything - And it is possible to retain what would be an existing "wrong" router-id (if you went by normal election rules) until the router is actually reloaded. Think of a case where you delete a process with a higher loopback router-id - The remaining process will retain it's original value until a reload, unless it too is deleted and re-added (thereby triggering the election of a router-id).

Regards.

Hello,

I will repeat something I have already said, because it might have been lost in the postings above.

When you start the first process, router cannot generally know if you will start a second process later or when you do start the second process whether the second process will have a higher ospf process number than the first one (only in the case where you chose process number 1 for the first process could router know that the second process will have a higher process number). So, the router follows the same logic every time you start a process. Cannot wait for you to enter following process configuration, to see what you mean. Commands take effect as they are entered, not in the future.

Now, when router initializes, the configuration is passed to the parser and from the parser's point of view this procedure is no different than the procedure the administrator follows to conf t during normal router operation. So, it follows same procedure, only in this case the ospf process id's are passed to the parser sorted (lowest first). The parser still does not care at initialization that configuration is sorted. The configuration file contains all the commands you had entered, but not in the order in which you entered them, so some information is inevitably lost during initialization.

This does not seem that disappointing to me, especially if I have done nothing to make things work my way. Whenever a process starts, the same procedure is followed. The process number is never used as a factor in the algorithm, because it can't. It requires knowledge from the future for something like this to work. This future knowledge can only be taken advantage of at initialization, but not during normal operation, so even if something like this had been implemented, it would still not be consistent with normal operation.

Kind Regards,

M.

Hehe - Fair enough on your point regarding consistent startup behavior in your last paragraph, since (from the router's perspective) by taking whatever process comes listed first, is being consistent.

So perhaps I should rephrase: There is consistency in the manner in which the router initializes the config, so I can't be disappointed there, it's "disappointing" (least in my case) that the parser doesn't look at all entries at the time of initialization and then orders by process number. (I completely understand of course not taking into account additional processes that get added afterwards - I'm only referring to startup).

In other words, you're saying the router parses the ospf processes top-down (first come, first serve), where as what I was hoping for would more like route selection per se (where the more specific route is selected even if it's not listed first), but of course in this case it would be that the process number acted more like a priority in determining which goes first.

Outside of that - I appreciate you input & comments. Thanks!

The parser is a simple, stupid program that reads commands one line at a time. Having stupid programs in embedded systems is good. Simple and neat, fewer bugs. Bugs are still out there, of course, but could be more. :-)

This is a fascinating discussion, and I cannot resist the temptation to throw a spanner in the works. I just want to take a sideways look at this question for a moment.

As I understand it, the RID intrinsically has nothing to do with any IP address. It is just a 32-bit number that identifies the router. It does not need to be a routeable IP address. But for its purpose, it is pretty essential to ensure that it is unique within the OSPF domain. So the algorithm the router uses, for want of any hard-coded value, a number equal to one of its IP addresses, in the hope that it will be unique.

Having said that, what happens when you have two OSPF processes? Why have the software writers chosen to ensure that the RID is different between the processes? What would happen if they are the same?

As far as I am aware, you cannot run the two OSPF processes on the same real interface - they would get their Hellos confused. So why do you need the RIDs to be different?

Kevin Dorrell

Luxembourg

Kevin

Welcome to the discussion. I believe that Dan as the original poster would agree that the more participants the better. I have some comments about a couple of your points.

I believe that you are correct that the RID is a 32 bit number that identifies the router. As part of the process of accurately drawing the topology map you want to uniquely identify each data source. As an identifier the RID does not need to be a routable address but should be unique within the OSPF domain.

Left to its own the OSPF process will pick an IP address from one of the interfaces on the router. This should assure that the RID will be unique because we assume that an IP address should appear at only 1 place in the network. (If the same address does appear in more than one place then your network has problems) You do not need to let the OSPF process pick the interface and you have the option to manually configure the RID. As Dan points out there are possibilities that over time the OSPF process might pick different addresses for its RID. So if you have some reason to want to have very stable choice of RID (as Dan does) then manual configuration is recommended.

If you manually configure the RID there is no requirement that the RID be matched in a network statement and no requirement that the RID be an address that is advertised to neighbors. In fact it is not a requirement that the RID actually be an address on that router (if manually configured).

You are certainly correct that you can not run 2 OSPF processes on the same physical interface. If you configure network statements in both processes to include the interface it will be active in only one of them. I assume that the RIDs must be unique in an attempt to assure that we can still accurately identify sources of information if information between the 2 processes were shared (redistributed).

HTH

Rick

HTH

Rick
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: