Multiple OSPF Processes & Router-ID Election from Loopbacks

[dmarekatc]

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.

[Kevin Dorrell]

Hi Rick,

Thanks for the comments. The business about having the same RID on two routers because they had the same IP address is a classic CCIE lab "gotcha". (Not from a real exam, I hasten to add, but from my training provider!)

You get candidate to configure OSPF, and it all works fine. Then in the very last section of the lab, multicast, you get him to configure an anycast scenario with MSDP. This, of course, involves loopbacks on two routers with the same IP address. Everything works fine until you reload the routers, at which point the OSPF stops working.

Can I take you to task on "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)" ? Sorry, but I am not convinced yet. Each OSPF process has its own database, and the local process id should be enough to identify the information. Sorry, but I am still looking for a valid reason why the two processes should use different RIDs.

Kevin Dorrell

Luxembourg

[marikakis]

Kevin,

I was thinking the same thing about the process id working as a differentiating factor for redistribution purposes (local process id's seem fine for a local redistribution procedure). Unless Rick has something particular in mind that we cannot think of. I still haven't got an answer to your painful question though. :-)

Kind Regards,

Maria

[marikakis]

Kevin,

I had a few thoughts, nothing conclusive, I will just list them here.

1. Specification requires some protocol data structures (in Section 5) that include the router-id, but specification does not say anything about second process, so perhaps a similar structure was created by implementors for the case of additional processes (with different RID's) as a simple extension of this concept. That is, instead of pluging things (areas, etc.) around the same router-id, create a new one and plug them there (software neat architecture considerations).

2. Specification says nothing about process-id's. The formal way to do things is according to specification, and not according to process-id hooks. Process-id is just an administrator-friendly parameter.

3. The different router-id for each ospf process approach has the advantage of simplicity. Non-overlapping graphs (nodes and links) can help you sleep peacefully. I was thinking of a possible issue with virtual links that do specify a remote router-id as a parameter, but I can't conclude and support sufficiently that there could be problems with this or that there won't. Sometimes when you implement something, you might choose a conservative strategy that will help you sleep well, instead of trying to consider all possible cases and prove that no issue will exist under any circumstances if you use the same RID in 2 different processes.

Kind Regards,

M.

Edit: The joke of the Specification in Section 5 (i.e. the word "smallest"):

"Router ID

A 32-bit number that uniquely identifies this router in the AS. One possible implementation strategy would be to use the smallest IP interface address belonging to the router."

[Kevin Dorrell]

Maria,

Thanks for those thoughts. I think you are right that it was an implementation decision rather than a architectural constraint that made them use different RIDs for the two processes. I suppose it was less of a risk as well, because that way they could be sure there were no "gotchas" - a minimal risk approach. I would probably have made the same decision.

It would be interesting to hear if Russ White has anything to say about it.

I am at work now, so I cannot check it out, but I seem to remember that if you configure OSPF with a static RID, and you then introduce ipv6 router ospf, then the IPv6 OSPF takes the same RID, and does not let you change it. I shall have to look at that a bit closer ... I usually use the same process ID for my IPv6 OSPF as for my IPv4 OSPF, so that may have something to do with it. I hadn't realised that they were so closely interdependant. So if you have two IPv4 OSPF processes and one IPv6, what RID does the IPv6 OSPF use?

As for "the smallest IP interface" ... what were they thinking of? I guess loopbacks do have the highest packing density, so it figures. You really have read that document from cover to cover! ;-)

Kevin Dorrell

Luxembourg

[Kevin Dorrell]

In answer to my question about whether there was some fundamental constraint that the two OSPF processes should have different RID: yes there is. The reason is to catch the case where you have two processes running OSPF out two interfaces, but those two OSPF domains are joined up eventually on another router. In that case, the two processes should have different RIDs, and effectively our router is treated as two different routers as far as the OSPF cloud is concerned.

Now I see the answer, it should have been obvious in the first place - it was just a matter of thinking "out of the box"!

Thanks to Marek Karasek, who presented the "New Developments in OSPF" session at Networkers, for pointing that out.

Kevin Dorrell

Luxembourg

(actually, Barcelona)

[Richard Burts]

Kevin

Thanks for posting the clarification. I had sort of thought along those lines when you asked the question in this discussion but had not gotten it clearly articulated. This presents it nicely.

HTH

Rick

[marikakis]

Addition:

The way the configuration file is crafted is very efficient (simple text, minimum information that does not include "time" information or cancelled configuration, which means minimum space to store in generally not large storage medium and fewer bugs, works same way across product lines) and is maintained in an order that guarantees that the commands entered at initialization will not fail for some stupid reason. All the loopbacks are entered before routing protocol configuration. Imagine that after you entered the config you posted as example, you had decided to put another loopback in the config. This loopback will be passed to the parser at initialization before the routing processes for good reasons, so you still have a problem, but router has to make sure some things go before others for a smooth startup.

Seems pretty neat to me. Wouldn't like it more any other way.

[dmarekatc]

To modify the discussion a little, and ultimately give some insight into what I'm considering making use of this all for, let me ask this in terms of which is functionally better (and it may be that there's no real discernable difference, more just a personal preference):

Say Loopback0 is used as the management interface and process 100 is the "main" process for routing (so there is more interest in the RID remaining consistent). Loopback1 is tied to dial-backup and the second process (200) is related to that.

Here's the Mockup:

interface Loopback0

ip address 1.1.1.1 255.255.255.255

interface Loopback1

ip address 2.2.2.2 255.255.255.255

interface Async1

ip unnumbered Loopback1

router ospf 100

* Will want 1.1.1.1 as the "mgt" RID

but would have 2.2.2.2 at the moment

router ospf 200

* Will want 2.2.2.2 as the "dial" RID

but would have 1.1.1.1 at the moment

** The Which One Part **

Would it be "better" to eliminate the 2nd loopback all together by moving its IP to the Async interface? - Thus reducing the total interface count by 1, and would allow the ospf process 100 to then select the desired RID since there is only one loopback to choose from. (The second process would either need to be explicitly defined or if there is less care about the RID for it, just let it pick from all remaining interfaces).

The result would look like this:

interface Loopback0

ip address 1.1.1.1 255.255.255.255

interface Async1

ip address 2.2.2.2 255.255.255.0

* Can't have a /32 here so the mask gets changed

router ospf 100

* Will want 1.1.1.1 as the "mgt" RID and would have 1.1.1.1

router ospf 200

router-id 2.2.2.2

* Or if this is less important, let the router decide

Or would it be "better" to leave the Async with an ip unnumbered (thus also keeping Loopback1) and just explicitly defining the RIDs as needed? (I realize this might beg the pros/cons of using ip unnumbered or not, in conjunction with the discussion on maintaning consistent RIDs)

Thoughts?

[Richard Burts]

Dan

Given a choice between these 2 alternatives I would opt for the second choice - keep both loopbacks, let the async get its address via unnumbered, and explicitly define the RID. Functionally I am not sure that there is much difference. But option 1 in which the OSPF process makes a choice leaves some possibility that at some point it might choose differently while configuring the RID ties it down. In situations where stability of the RID is a consideration I would prefer to tie it down and remove the possibility of a different choice.

Other people may have other opinions. But I believe that where consistency in some aspect (such as RID) is desired that we should avail ourselves of every opportunity to explicitly configure those variables.

HTH

Rick

[mkarasek]

Hi,

To start with, there is no real guaranty.

But algorithm simply works as follows, so results should be consistent:

First process walks interface list and uses first loopback he finds.

Second process walks interface list, finds that first loopback is used so it uses next one.

If no loopback is found highest available IP address is used.

I'm not 100% sure about position of interfaces on the interface list, but if we speak about case when cfg is parsed after reload this should be consistent.

Also for which process is algorithm called first depends on order of processes in cfg.

/marek

[Richard Burts]

Marek

My experience is slightly different from what you describe. When any process looks for an address to use as RID it will choose the numerically highest loopback that is available and is not necessarily the first in the list and if no loopback is available then it will choose the numerically highest physical interface that is available.

HTH

Rick

[dmarekatc]

Rick,

What you describe is my experience & understanding as well on the selection process.

The general flow of course as described in the previous post holds, with the afore mentioned adjustments.

(I'm also just posting, since I find it mildly amusing that in a single topic we have different people posting who have the same, and not so common name, in the portions - first / last)

[Kevin Dorrell]

Isn't NetPro just amazing sometimes!

[EA-6901000101]

Hi I understood if you don't specified the router-id, the the router selected the interface with the highest IP, not necessary the loopback interface. In order to use the same IP from the Loopback is requiered specified the router id under the process, example:

router ospf 1

router id 1.1.1.1

router ospf 2

router id 2.2.2.2

Regards