Same OSFP transit subnet at multi locations of same OSPF area?

[Frankie, not the Tank]

Hi,

We have a need to use the same subnets as OSPF routing/transit networks at muti locations in the the OSPF area. see diagram.

BBU3 will have a loopback of 10.0.0.3/32, and BBU4 will  have loopback of 10.0.0.4/32. We don't care the reachability of ospf transit network 10.0.10.0/24 or 10.0.20.0/24. We only care about the reachability of the loopbacks of BBU3 and BBU4. (I forgot to mention this original, thanks Joseph for pointing it out).

I know if routers using the same IPs, we may get LSA flood war error. But if we use different IPs for all routers, will this setup technically working?

This is not something that I personally like to do, but there is a drive to do this so router BBU3 and BBU4 can switch locations without re-addressing. I built a virtual lab and it seems working. By saying that it works in the lab, I means that the loopbacks of BBU3 and BBU4 are advertised to OSPF with no issue. Also they are reachable from any part of the network. Can you help me to analyze from OSPF operation point of view?

You inputs will be much appreciated.

Thanks.

-Frank

[Joseph W. Doherty]

We have a need to use the same subnets as OSPF routing/transit networks at muti locations in the the OSPF area.

Why?  (This so, as you note you can swap BBU 3 and 4?  Again, why?)

I built a virtual lab and it seems working.

Hmm, that's surprising.  Using what for the virtual lab?

Can you help me to analyze from OSPF operation point of view?

Well, from the perspective of say R1, it might see ECMP to 10.0.20.0/24 and split traffic between the two paths to the "same" subnet, but not all 10.0.20.0/24 hosts are physically in the same L2 domain for that network.  So, some traffic might make it to the desired host, and some not.

What exactly have you done where "it seems working"?

[Frankie, not the Tank]

Thank you, Joseph, for the reply and questions. I realized that I need to provide more information.

BBU3 will have a loopback of 10.0.0.3/32, and BBU4 will  have loopback of 10.0.0.4/32. We don't care the reachability of ospf transit network. We care about the reachability of the loopbacks of BBU3 and BBU4.

By saying that it works in the lab, I means that the loopbacks of BBU3 and BBU4 are advertised to OSPF with no issue. Also they are reachable from any part of the network.

Again, apologize for missing this critical information in the origin post. I added it now. 

[Joseph W. Doherty]

I believe it works because the loopbacks are advertised as /32s.

Not too happy, having any "duplicate" subnets.  If such would be just transits, wondering whether unnumbered (p2p) links or transit (prefux) suppressed networks would be an option.  (I vaguely recall the former will work with OSPF, and the latter a later feature; unsure of either, as my memory can be faulty, don't recall ever using either.)

[MHM Cisco World]

Can try ping and check

MHM

[Frankie, not the Tank]

Hi MHM,

Thanks for the recommendation. Here is the outcome:

I checked to ping BBU3 loopback 10.0.0.3 and BBU4 loopback 10.0.0.4 from all routers, with following cmd format. It works with no issue.

R2# ping 10.0.0.3 source loopback 0
R2# ping 10.0.0.4 source loopback 0

On R2, if I ping BBU3 10.0.0.3 directly (w/o using source loopback0), it fails. This is understandable since R2 will use 10.0.20.2 as source IP, when BBU3 replies, BBU3 will think 10.0.20.2 is in the local subnet. The customer does not need to communicate with BBU loopbacks directly from R1, R2 or R5.

[MHM Cisco World]

That what I was think about' 

Ospf have IP but it unreachable since you use same subnet.

prefix-suppression feature' work as I know when you have multi area' the ABR will inject lsa into area that not need to know what behind ABR.

MHM

[Frankie, not the Tank]

Hi Joseph,

Thank you, Joseph, again! OSPF routing support for unnumbered and transit prefix-suppression actually are two reasons that I think this configure actually may work. Thank you for bring these two up again!

We have been using unnumbered (on p2p) links in many locations, it works. This diagram is simplified, there actually will be more BBU routers in the both the left and right 10.0.20/0/24 subnets. So 10.0.20.0/24 can not be set as p2p.

As for transit suppression, I assume that you are referring RFC 6860 Hiding Transit-Only Networks in OSPF. 
There is some good discussion for in at: https://networklessons.com/ospf/ospf-prefix-suppression

and: https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/213404-open-shortest-path-first-prefix-suppress.html

It can be configured per ospf instance or per ospf interface.

(config)#router ospf 1
(config-router)#prefix-suppression

R3(config-if)#int e0/1 
R3(config-if)# ip ospf prefix-suppression

 With all being said, the BBU routers actually Linux boxes (not controlled by us) running OSPF. I am not sure if it actually support the prefix-suppression feature. That is why I would like to ask, if this setup will work natively (as long as we don't care the reachability of the transit subnet 10.0.20.0/24 at both locations.).

Thanks.

[Joseph W. Doherty]

Cannot guarantee it will work, but as your own testing appears to show, it can.  Considering that both unnumbered p2p and transit prefix suppression work, OSPF doesn't seemed to need network numbers to use transit paths.  The wild card, might be on multi point links.

Possibility a real OSPF expect will join this discussion.

[Frankie, not the Tank]

Hi Joseph,

Really appreciate you getting this discussion started and engaged with me. I know that if the routers using duplicated IPs, there could be OSPF flood war issue (I did observe flood war issue if using duplicated IPs for OSPF routers. If don't use duplicate IPs, there will be no flood war issue.). In our scenario, we will use different IPs for all OSPF routers.

https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/9237-9.html#anc43
Q. What does the error message %OSPF-4-FLOOD_WAR: Process process-id re-originates LSA IDip addresstype-2 adv-rtrip addressin areaarea idmeans?
A.The error message is due to the some router that is flushing the network LSA because the network LSA received by the router whose LSA ID conflicts with the IP address of one of the router interfaces and flushes the LSA out of the network. For OSPF to function correctly the IP addresses of transit networks must be unique. If it is not unique the conflicting routers reports this error message. In the error message the router with the OSPF router ID reported as adv-rtr reports this message.

I have googled and cannot get a definitive answer if this setup is supported or not. I personally think this will work, but it would not be something that I would like to recommend, but the customer wants it.

Lets see I am lucky enough to attract more discussion. 

Thanks again!