ospf problem path selection

[Hossein Forghani]

in above scenario ospf , when the connection between two switches was downed.(in any reason )router R4 can not ping 192.168.13.1 ( R1 interface 0/1) . in this situation we want ping this ip with path up ( R2--R1) . how can handle this problem ??
thanks...

[rais]

Both R1 and R3 are advertising 192.168.13.x so R3 route wins on R4. You would need to inject a 192.168.13.1/32 into ospf from R1.

HTH.

[Hossein Forghani]

i done this work and clear ip ospf process in all router.but nothing else change.

[Julio E. Moisa]

Hi

Please verify if this network 192.168.13.0 is being advertised via OSPF as well into R1 and try configuring the command under that interface: no keepalive, in order to have it up. 

[Hossein Forghani]

yes, 192.168.13.0 advertised by R1.and R2 can ping 192.168.13.1 from R1 but R4 can not ping this address

[Richard Burts]

We do not know the details of the configuration here and there might be something that could change the answer. But if OSPF is configured in the normal way and if default values are used then R4 would receive two advertisements of network 192.168.13.0. One advertisement is generated by R3 and the destination is basically one hop away from R4. The other advertisement is generated by R1 and the destination is basically two hops away from R4. So R4 will use the advertisement from R3.

I am not sure that there is a good solution for this. Essentially the problem is that you have a single network/subnet (and since it goes through switches a single vlan) which should be reachable from either router. Then that network/subnet gets partitioned when the switch to switch link fails. Now R1 can reach only part of the network and R3 can reach only part of the network. But both routers continue to advertise the complete network.

HTH

Rick

[Hossein Forghani]

configuration :
R1#
interface FastEthernet0/0
ip address 192.168.12.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 192.168.13.1 255.255.255.0
duplex auto
speed auto
router ospf 1
log-adjacency-changes
network 192.168.12.0 0.0.0.255 area 0
network 192.168.13.0 0.0.0.255 area 0

R2#
interface FastEthernet0/0
ip address 192.168.12.2 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 192.168.24.2 255.255.255.0
duplex auto
speed auto
router ospf 1
log-adjacency-changes
network 192.168.12.0 0.0.0.255 area 0
network 192.168.24.0 0.0.0.255 area 0

R3#
ip address 192.168.34.3 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 192.168.13.3 255.255.255.0
duplex auto
speed auto
router ospf 1
log-adjacency-changes
network 192.168.13.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0

R4#
interface FastEthernet0/0
ip address 192.168.34.4 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 192.168.24.4 255.255.255.0
duplex auto
speed auto
router ospf 1
log-adjacency-changes
network 192.168.24.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0

the configurations above my first configurations then i add two command below and clear ip ospf process then R4 can not ping 192.168.13.1

R1#
router ospf 1
network 192.168.13.1 0.0.0.0 area 0

R3#
router ospf 1
network 192.168.13.3 0.0.0.0 area 0

[Julio E. Moisa]

Hi

Richard is correct, the solution here is if you disable R3's interface with shutdown. As you are using switches to interconnect these routers it looks like the subnet is divided. 

[Richard Burts]

There are a couple of things that I would like to address. First is the attempt to use the OSPF network statement for the interface address

R1#
router ospf 1
network 192.168.13.1 0.0.0.0 area 0

R3#
router ospf 1
network 192.168.13.3 0.0.0.0 area 0

I assume that this is an attempt to have OSPF generate a route to the /32 interface address. This reflects the hope that it will tell OSPF to advertise this specific address. This is not how the OSPF network statement works and I find it to be a fairly common misunderstanding. The network statement in OSPF does not tell OSPF what to advertise. It tells OSPF what interfaces it should run on. As OSPF runs on the interface it advertises the network/subnet that it finds on that interface. (the exception to this is if the interface is a loopback interface, in which case OSPF by default does advertise the /32 address)

The second thing to address is to attempt to clarify what issue we are dealing with. The original post described the problem as being how to ping to the interface IP of R1. As I thought about that problem and as I examined the drawing I realized that there was another problem which I regard as more serious and that is what I addressed in my previous response. When the link between switches goes down the existing network/subnet is partitioned (divided into 2 separate parts). Some parts of the network/subnet are reachable only through R1 and some parts of the network/subnet are reachable only through R3. And which part you can access depends on where in the network you are. The only effective way to address this problem is to provide redundant connections between these switches.

But I realize that I have not really addressed the original question which was how to access the interface IP of R1 from R4. There is a solution for that. It is possible to configure a static route for the interface IP of R1 (probably configure it on R2) and then redistribute static into OSPF. That way R4 (and also R3) will have a workable route to the interface IP of R1. If it is important to access the interface IP of R1 then this has a solution. Note that this does not address the issue that some hosts in the 192.168.13.0/24 network are accessible from R2, R3, or R4 while other hosts in that network are not accessible from that router.

HTH

Rick

[Hossein Forghani]

Thank you Richard for your technical and explicit answer but your solution not usable for my problem.because my network is large and have several switches so static route is not solution logical.
Is there a ospf solution for this? such as OER/PFR & BFD & FRR on another protocol



thanks Richard Burts

HOFO

[Richard Burts]

HOFO

You are welcome. I am sorry that my suggested solution is not usable in your situation. You know your environment better than we do and if you find it not usable  we must agree with that.

As I have explained the fundamental problem is the partition (dividing into 2 separate parts) of the network/subnet. When the connection between switches goes down then some parts of the network are reachable only from one router but not from the other router, but that both routers continue to advertise the whole network. I do not see any way in which OSPF can react to this. I do not believe that OER or PfR or BFD could fix it. There is the possibility of setting up IP SLA to track reachability of some address (perhaps the interface IP of the other router) and to set up an EEM script that would react to the IP SLA and change the interface config. That could make the router interface reachable from everywhere but would not address the issue of the other hosts in the network/subnet that are not reachable. I frankly do not believe that this is a very good solution.

As I suggested in a previous post the best solution to this would be to provision a second connection between these switches (and the second connection should have a physically diverse path so that a problem on one connection would not impact the second connection). With the redundant connection the network would not be partitioned if one of the connections went down. You might consider configuring the two connections as an Etherchannel to avoid spanning tree issues.

HTH

Rick

[Hossein Forghani]

thanks richard burts.
i try your solution.thanks for your suggestion.

HOFO

[Hossein Forghani]

Dear Richard Burts

I done your solution, but it have some challenges
* in IP SLA i should use static route,but static route don't solve my problem.
* redundancy in connection switches for my network not efficient
in my situation, i have to solve this problem with routing configuration not switching configuration, because i can not added link in my scenario.but your solution very nice and effective.
thanks rich.

HOFO

[Richard Burts]

HOFO

The fundamental problem here is the partition or dividing of 192.168.13.0 into 2 separate parts where some parts are reachable only through one router while other parts are reachable only through the other router. The real solution would be to prevent the partition if one link goes down by setting up a redundant link. If a second link is not practical then you have a problem and need a work around.

One advantage of these forums is that we have multiple people participating and some one will think of a potential solution that I had not thought about. So the suggestion of the GRE tunnel using loopback interfaces and a static for the remote router address may be a work around that you can use. Note that this does address the question of access to the router interface address but does not address the part of the problem that hosts in one part of the network will not be reachable.

HTH

Rick 

[Hossein Forghani]

RICH
Thanks for all the technical solutions.And I was glad that you also confirmed mohamad ebrahimi's opinion.