Solved: few question about ospf

sarahr202 · ‎08-18-2009

Hi every body.

I have few questions about ospf.

I want to recap what i have learned from my post on net pro and book for easy reference.

1) If a same router is running say two ospf processes say ospf 1 ,ospf 2, there will be two link state data bases for each.

2) two routers though running different ospf processes say R1 running ospf 1 and R2 running ospf 2, they can still exchange ospf routes.

=====================================

Based on the above facts, i have these questions:

1) let say we have a router ,R1 which is running two ospf processes as:

router ospf 1

network 199.199.199.1 0.0.0.0

router ospf 2

network 199.199.199.1 0.0.0.0

Now R1 is connected to R2 which is running ospf as well.

R2 receives two updates from R1 about the same network(199.199.199.0/24)with the same cost

One from ospf 1 and the other from ospf 2

Now which one R2 accept as the router id is same in both updates?

===============================

Case 2:

Again R1 is running two ospf processes,ospf1 and ospf 2

Say R1 receives a update about network 11.0.0.0/8 from R2. In which link state database, R1 will store the Lsa received from R2, will R1 store the lsa in link state base for ospf 1 or in the link state database for ospf 2 ?

Thanks a lot.

Lucien Avramov · ‎08-18-2009

1) This is not a good design, we discussed on other posts that based on the routing-id and which process converges first, that will be the one installing the route.

In real world you do NOT do that, it's a non sense for design.

2)the processes can exchange routes, if you have redistribution between them. I will send you an example of the database so you can see it.

View solution in original post

Peter Paluch · ‎08-18-2009

Hi Sarah,

Regarding Case 1: A network can belong to a single OSPF process only. You may configure the network in multiple processes but it will be present only in the process in which it was inserted first if using the "network" command. Therefore, the network will be advertised by a single OSPF process only. Moreover, if you run multiple processes on a router, each one will try to select a unique RID - not just the highest IP number from among loopbacks/interfaces but also a RID that is unique from other OSPF processes on the router. So even on a single router, the multiple OSPF processes have different RIDs and therefore are distinguishable.

Regarding the Case 2: The answer here is given by the fact that a network can belong to a single OSPF process only. So if a LSA comes in through a particular interface, it will be installed into the link-state database of that process that owns the interface.

Best regards,

Peter

View solution in original post

Giuseppe Larosa · ‎08-18-2009

Hello Sarah,

1) trying to run two different processes on the same interface with the same area-id has the following negative results:

1a) no adjacencies

no OSPF adjacencies can be built on the link: because OSPF hellos don't contain the process-id the node is not able to say if the received hello is for process 1 or process 2.

1b) the ip subnet associated with the overlapping link is not advertised by either process and this is bad too.

this is something to be avoided.

We verified this multiple times in lab tests.

2)

as explained in point 1) no valid adjacencies can be built on the overlapping link as a result of this no OSPF update can be received on it.

if there are other interfaces that are associated to process 1 exor process 2 the router passes the received LSA to the process that is running on the receiving interface with no ambiguity.

if a comparable route is received in both processes they compete for installing the route in the ip routing table.

Note:

because the area-id decides if an OSPF adjacency can be built on a link another possible unexpected result is that of joining the two OSPF domains on a link.

This is one of weak points of designs with multiple OSPF processes.

To mitigate this possible error different area-ids on the two OSPF processes should be used.

Hope to help

Giuseppe

View solution in original post

Lucien Avramov · ‎08-18-2009

Here is the database after redistributing one process into another.

R5(config-router)#do sh ip ospf data

OSPF Router with ID (2.2.2.5) (Process ID 2)

Router Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Link count

2.2.2.5 2.2.2.5 436 0x80000099 0x00D896 1

136.1.124.4 136.1.124.4 1668 0x800000AD 0x0053EF 2

Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum

2.2.2.4 136.1.124.4 1668 0x80000090 0x0096EA

OSPF Router with ID (5.5.5.5) (Process ID 1)

Router Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Link count

5.5.5.5 5.5.5.5 164 0x80000003 0x002FC6 1

6.6.6.6 6.6.6.6 204 0x8000009D 0x00CE41 3

Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum

1.1.1.6 6.6.6.6 835 0x80000001 0x00529A

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag

2.2.2.0 5.5.5.5 156 0x80000001 0x004A4F 0

10.0.0.0 5.5.5.5 156 0x80000001 0x001A7A 0

R5(config-router)#

View solution in original post

Peter Paluch · ‎08-18-2009

Hello Giuseppe,

This intrigues me. Are you saying that having a network in multiple OSPF processes causes it to not be advertised at all?

I have labbed a simple two-router topology with one having multiple OSPF processes covering all directly connected networks. Depending on the order of configuration, all the network are assigned only to the first OSPF process but they are advertised to the second router and the adjacency is working perfectly.

My view is that when a network is added to an OSPF configuration, it is internally checked if it does not belong to any other OSPF process. If it does not, it is added to that OSPF process' configuration and also a flag is made internally that this network is already OSPF enabled. If another process comes in that is configured with the same network, it will ignore it because it is already internally flagged as used by another OSPF process.

If you remove the network from the former OSPF process and shutdown/reactivate the interface on which the network is connected, the network will move to the second OSPF process.

These are my experiences that I labbed up right now.

Best regards,

Peter

View solution in original post

Lucien Avramov · ‎08-18-2009

having a network in multiple OSPF processes causes it to not be advertised at all

-> this is wrong statement, the previous posts from the week-end we have discussed this and explained how it's working.

View solution in original post

Giuseppe Larosa · ‎08-19-2009

Hello Peter, Lucien

yes I wrote something wrong.

I had in mind a more complex scenario with mutual redistribution between the OSPF processes and also my tests were done ten years ago

Thanks for your corrections rated as it deserves.

Best Regards

Giuseppe

View solution in original post

Peter Paluch · ‎08-19-2009

Giuseppe,

You are most welcome. I always welcome and enjoy your expertise and experience.

Best regards,

Peter

View solution in original post

Lucien Avramov · ‎08-18-2009

1) This is not a good design, we discussed on other posts that based on the routing-id and which process converges first, that will be the one installing the route.

In real world you do NOT do that, it's a non sense for design.

2)the processes can exchange routes, if you have redistribution between them. I will send you an example of the database so you can see it.

Lucien Avramov · ‎08-18-2009

Here is the database after redistributing one process into another.

R5(config-router)#do sh ip ospf data

OSPF Router with ID (2.2.2.5) (Process ID 2)

Router Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Link count

2.2.2.5 2.2.2.5 436 0x80000099 0x00D896 1

136.1.124.4 136.1.124.4 1668 0x800000AD 0x0053EF 2

Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum

2.2.2.4 136.1.124.4 1668 0x80000090 0x0096EA

OSPF Router with ID (5.5.5.5) (Process ID 1)

Router Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Link count

5.5.5.5 5.5.5.5 164 0x80000003 0x002FC6 1

6.6.6.6 6.6.6.6 204 0x8000009D 0x00CE41 3

Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum

1.1.1.6 6.6.6.6 835 0x80000001 0x00529A

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag

2.2.2.0 5.5.5.5 156 0x80000001 0x004A4F 0

10.0.0.0 5.5.5.5 156 0x80000001 0x001A7A 0

R5(config-router)#

Peter Paluch · ‎08-18-2009

Hi Sarah,

Regarding Case 1: A network can belong to a single OSPF process only. You may configure the network in multiple processes but it will be present only in the process in which it was inserted first if using the "network" command. Therefore, the network will be advertised by a single OSPF process only. Moreover, if you run multiple processes on a router, each one will try to select a unique RID - not just the highest IP number from among loopbacks/interfaces but also a RID that is unique from other OSPF processes on the router. So even on a single router, the multiple OSPF processes have different RIDs and therefore are distinguishable.

Regarding the Case 2: The answer here is given by the fact that a network can belong to a single OSPF process only. So if a LSA comes in through a particular interface, it will be installed into the link-state database of that process that owns the interface.

Best regards,

Peter

Giuseppe Larosa · ‎08-18-2009

Hello Sarah,

1) trying to run two different processes on the same interface with the same area-id has the following negative results:

1a) no adjacencies

no OSPF adjacencies can be built on the link: because OSPF hellos don't contain the process-id the node is not able to say if the received hello is for process 1 or process 2.

1b) the ip subnet associated with the overlapping link is not advertised by either process and this is bad too.

this is something to be avoided.

We verified this multiple times in lab tests.

2)

as explained in point 1) no valid adjacencies can be built on the overlapping link as a result of this no OSPF update can be received on it.

if there are other interfaces that are associated to process 1 exor process 2 the router passes the received LSA to the process that is running on the receiving interface with no ambiguity.

if a comparable route is received in both processes they compete for installing the route in the ip routing table.

Note:

because the area-id decides if an OSPF adjacency can be built on a link another possible unexpected result is that of joining the two OSPF domains on a link.

This is one of weak points of designs with multiple OSPF processes.

To mitigate this possible error different area-ids on the two OSPF processes should be used.

Hope to help

Giuseppe

Peter Paluch · ‎08-18-2009

Hello Giuseppe,

This intrigues me. Are you saying that having a network in multiple OSPF processes causes it to not be advertised at all?

I have labbed a simple two-router topology with one having multiple OSPF processes covering all directly connected networks. Depending on the order of configuration, all the network are assigned only to the first OSPF process but they are advertised to the second router and the adjacency is working perfectly.

My view is that when a network is added to an OSPF configuration, it is internally checked if it does not belong to any other OSPF process. If it does not, it is added to that OSPF process' configuration and also a flag is made internally that this network is already OSPF enabled. If another process comes in that is configured with the same network, it will ignore it because it is already internally flagged as used by another OSPF process.

If you remove the network from the former OSPF process and shutdown/reactivate the interface on which the network is connected, the network will move to the second OSPF process.

These are my experiences that I labbed up right now.

Best regards,

Peter

Lucien Avramov · ‎08-18-2009

having a network in multiple OSPF processes causes it to not be advertised at all

-> this is wrong statement, the previous posts from the week-end we have discussed this and explained how it's working.

Giuseppe Larosa · ‎08-19-2009

Hello Peter, Lucien

yes I wrote something wrong.

I had in mind a more complex scenario with mutual redistribution between the OSPF processes and also my tests were done ten years ago

Thanks for your corrections rated as it deserves.

Best Regards

Giuseppe

Peter Paluch · ‎08-19-2009

Giuseppe,

You are most welcome. I always welcome and enjoy your expertise and experience.

Best regards,

Peter