cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
770
Views
5
Helpful
5
Replies

OSPF topology and redistribution problem

pablitomassa82
Level 1
Level 1

Hi everybody,

i have the following problem (see the picture below):

The NMS Server need to know the Loop 1, 2, 3, 4 and 5 addresses in order to manage the routers associated with these addresses.

The routers associated with these addresses runs their own OSPF processes (green) which must be separated from other OSPF process in the topology.

So in order to achieve some redundancy i have configured R1 and R4 with static route that point to loopback addresses and i had redistributed them in the blue OSPF process.

Than i have configured a static default route on R2 and R3 and i flood default-information with the green OSPF process.

In the event that R1 fails, R4 take controls of the traffic from NMS in the rigth way.

The problem occurs when one of the links (see the picture) fails, in this case when NMS want to connect with router associated with Loop 4 it fails, becouse R1 manage the traffic instead of R4. Is there a way to prevent this behaviour?

Thanks a lot

PaoloCapture.JPG

 

 

 

1 Accepted Solution

Accepted Solutions

Richard Burts
Hall of Fame
Hall of Fame

Paolo

 

If I am understanding correctly your explanation then the issue really is that R1 is still advertising the route to Loop 4 even though it no longer has connectivity to it. The solution to this would probably be to configure IP SLA on both R1 and R4 to track the static routes and to remove a static route if that loop became not reachable.

 

An alternative might be to change your design. Instead of having R2 and R3 use default originate in the green ospf and using static routes, just run the green ospf to learn the routes to the various loops and then redistribute from green ospf to blue ospf on R1 and R4. That way if the link goes down and R1 can no longer reach loop 4 then the route would be withdrawn from R1 green ospf, and then NMS would use R4.

 

HTH

 

Rick

HTH

Rick

View solution in original post

5 Replies 5

Richard Burts
Hall of Fame
Hall of Fame

Paolo

 

If I am understanding correctly your explanation then the issue really is that R1 is still advertising the route to Loop 4 even though it no longer has connectivity to it. The solution to this would probably be to configure IP SLA on both R1 and R4 to track the static routes and to remove a static route if that loop became not reachable.

 

An alternative might be to change your design. Instead of having R2 and R3 use default originate in the green ospf and using static routes, just run the green ospf to learn the routes to the various loops and then redistribute from green ospf to blue ospf on R1 and R4. That way if the link goes down and R1 can no longer reach loop 4 then the route would be withdrawn from R1 green ospf, and then NMS would use R4.

 

HTH

 

Rick

HTH

Rick

Hi Richard,

thanks for your answer, you perfectly understood what the problem is.

 

The second solution you offered me is very interesting: you suggest me to create a second OSPF process (router ospf 2 - green OSPF) on R1 and R4 and establish an green OSPF neighborship with R2 and R3 in Area 0, and than redistribute the routes learned from the OSPF 2 process into the OSPF 1 process (OSPF blu). Since R2 and R3 are special devices i have to inform myself if it is possible to enable OSPF in the port used to connect with R1 and R4. 

 

I will analyze and emulate also your first solution. I don't know much about command related to IP SLA can you give me a little example? ..anyway i will inform myself

 

Thanks a lot 

Paolo

Paolo

 

Here is an example

track 11 ip sla 1 reachability

delay down 15 up 15

ip sla 1

icmp-echo 2.2.2.2 source-ip 1.1.1.1

frequency 5

ip sla schedule 1 life forever start-time now

 

Assuming that your device supports it I believe that the option to run the second OSPF process and to redistribute between OSPF processes is the better alternative.

ip route 0.0.0.0 0.0.0.0 1.1.1.2 track 11

 

HTH

 

Rick

HTH

Rick

Thanks Richard,

i've simulated the two solution with GNS3 and it works!

 

Paolo

Paolo

 

I am glad that you found my suggestion to be helpful. Thank you for posting back to the forum to tell us that you have tested my alternate approach and confirm that it does work. Thank you for marking this question as solved. This will help other participants in the forum to identify discussions which have helpful information.

 

HTH

 

Rick

HTH

Rick
Review Cisco Networking products for a $25 gift card