OSPF: No ping to backbone

ubuntu118 · Mon Sep 24, 2018 9:54 am

Hi
I have configured OSPF on 6 routers and all work fine. But there is a strange problem (strange to me, ofcourse!). From inside the routers, I can ping all IPs inside the backbone area, but from my PC in one subnet, I can't. From another subnet connected to another router, everything is fine. This is routing table on problematic router:

A S  172.16.0.0/12                      192.168.134.10            1
ADo  172.16.2.5/32                      172.16.2.6              110
ADC  172.16.2.6/32      172.16.2.5      HASFact                   0
ADo  172.16.2.37/32                     172.16.2.6              110
ADC  172.16.2.38/32     172.16.2.37     K2Backup                  0
ADo  172.16.2.40/30                     172.16.2.6              110
ADo  172.16.2.48/30                     172.16.2.6              110
ADo  172.16.2.53/32                     172.16.2.6              110
ADo  172.16.2.54/32                     172.16.2.6              110
ADC  172.16.2.57/32     172.16.2.57     loopback                  0
ADo  172.16.2.58/32                     172.16.2.6              110
ADo  172.16.2.61/32                     172.16.2.6              110
ADo  172.16.2.62/32                     172.16.2.6              110
ADo  172.19.0.0/24                      172.16.2.6              110
ADo  172.20.0.0/24                      172.16.2.6              110
ADo  172.21.0.0/24                      172.16.2.6              110
ADC  172.24.0.0/24      172.24.0.1      CAPsBridgeGuest           0
ADC  172.24.1.0/24      172.24.1.1      CAPsBridgeERP             0
ADC  172.25.0.0/24      172.25.0.1      CAPsBridgePrivate         0
ADo  172.27.2.0/24                      172.16.2.6              110
ADo  172.27.5.0/24                      172.16.2.6              110
ADC  172.27.255.0/24    172.27.255.1    E3-ERP Building           0
ADC  172.29.0.0/24      172.29.0.1      E5-Kerio Uplink           0
A S  192.168.0.0/16                     192.168.134.10            1
ADo  192.168.8.0/24                     172.16.2.6              110
A S  192.168.23.168/29                  192.168.126.217           1
ADo  192.168.25.128/27                  172.16.2.6              110
A S  192.168.52.208/29                  192.168.126.217           1
ADo  192.168.53.224/29                  172.16.2.6              110
A S  192.168.111.184/29                 192.168.126.217           1
A S  192.168.124.0/26                   192.168.124.52            1
ADC  192.168.124.52/32  192.168.134.30  <pptp-BandarEmam>         0
A S  192.168.124.64/26                  192.168.124.102           1
ADC  192.168.124.102/32 192.168.134.30  <pptp-JamOffice>          0
ADo  192.168.125.0/25                   172.16.2.6              110
ADC  192.168.125.128/25 192.168.125.202 E9-PAP                    0
ADC  192.168.126.216/29 192.168.126.220 E1-Sepanta Intr...        0
ADC  192.168.134.0/24   192.168.134.30  CAPsBridgePrivate         0
ADo  192.168.169.0/25                   172.16.2.6              110
ADo  192.168.179.0/25                   172.16.2.6              110
A S  192.168.183.64/26                  192.168.183.102           1
ADC  192.168.183.102/32 192.168.134.30  <pptp-MyziInven...        0

172.16.0.0/12 and 192.168.0.0/16 routes are because my network is connected to a much larger corporate network using static routes and another router. The 172.16.2.x stuff are OSPF backbone IPs. I tried to increase distance for 172.16.0.0/12 route to 250 to check if it works, no luck. I always receive TTL expired in transit from 134.10 (connected to corporate network). Traceroute show that packets are passed back-and-forth between 134.30 (my default gateway, the problematic router) and 134.10. I can't figure out problem. Please help.
Thanks.

mducharme · Mon Sep 24, 2018 10:29 am

This is not enough information to help you. Saying that a PC in a subnet cannot ping anything without giving the subnet, IP address, and IP configuration of the PC does not help. What is the PC using as its default gateway? etc.

ubuntu118 · Mon Sep 24, 2018 10:36 am

This is not enough information to help you. Saying that a PC in a subnet cannot ping anything without giving the subnet, IP address, and IP configuration of the PC does not help. What is the PC using as its default gateway? etc.

My PC:
IP: 192.168.134.248/24
GW: 192.168.134.30

Other PCs capable of pinging backbone:
192.168.179.50/25, GW: 192.168.179.52
192.168.125.100/25, GW: 192.168.125.102

What else should I provide?

mducharme · Mon Sep 24, 2018 10:41 am

What else should I provide?

Can that PC ping a backbone IP that is actually bound to that router? Or it cannot ping any backbone IPs, including backbone IPs bound to that router?

ubuntu118 · Mon Sep 24, 2018 10:43 am

What else should I provide?
Can that PC ping a backbone IP that is actually bound to that router? Or it cannot ping any backbone IPs, including backbone IPs bound to that router?

It can ping ONLY IPs bound to that router, and nothing else.

mducharme · Mon Sep 24, 2018 10:45 am

It can ping ONLY IPs bound to that router, and nothing else.

Then, the most likely problem is that your other routers are probably missing a route to the 192.168.134.0/24 subnet, and can't get the reply packet back to the PC as a result.

ubuntu118 · Mon Sep 24, 2018 10:50 am

It can ping ONLY IPs bound to that router, and nothing else.
Then, the most likely problem is that your other routers are probably missing a route to the 192.168.134.0/24 subnet, and can't get the reply packet back to the PC as a result.

If this was the case, I would have received timeouts, not TTL expired. And, I'm sure that they do have routes to 192.168.134.0/24, as their routing tables explicitly show that.

mducharme · Mon Sep 24, 2018 10:56 am

If this was the case, I would have received timeouts, not TTL expired. And, I'm sure that they do have routes to 192.168.134.0/24, as their routing tables explicitly show that.

OK. Can you try pinging a backbone IP that is one hop away (on a neighboring router) and if it doesn't work then paste the routing table of the other router involved as well, and also indicate what backbone IP you are trying to ping.

ubuntu118 · Mon Sep 24, 2018 11:29 am

If this was the case, I would have received timeouts, not TTL expired. And, I'm sure that they do have routes to 192.168.134.0/24, as their routing tables explicitly show that.
OK. Can you try pinging a backbone IP that is one hop away (on a neighboring router) and if it doesn't work then paste the routing table of the other router involved as well, and also indicate what backbone IP you are trying to ping.

I tried this. One hop can be pinged and another one cannot! The pingable one (172.16.2.6) has this routing table:

 0 A S  0.0.0.0/0                          172.16.2.5                1
 1 ADo  172.16.0.0/12                      172.16.2.5              110
 2 ADC  172.16.2.5/32      172.16.2.6      HQ                        0
 3 ADo  172.16.2.6/32                      172.16.2.5              110
 4 ADo  172.16.2.37/32                     172.16.2.50             110
 5 ADo  172.16.2.38/32                     172.16.2.5              110
 6 ADo  172.16.2.40/30                     172.16.2.50             110
 7 ADC  172.16.2.48/30     172.16.2.49     E3-K1                     0
 8 ADo  172.16.2.53/32                     172.16.2.50             110
 9 ADo  172.16.2.54/32                     172.16.2.50             110
10 ADo  172.16.2.57/32                     172.16.2.5              110
11 ADC  172.16.2.58/32     172.16.2.58     loopback                  0
12 ADo  172.16.2.61/32                     172.16.2.50             110
13 ADo  172.16.2.62/32                     172.16.2.50             110
14 ADo  172.19.0.0/24                      172.16.2.50             110
15 ADo  172.20.0.0/24                      172.16.2.50             110
16 ADo  172.21.0.0/24                      172.16.2.50             110
17 ADo  172.24.0.0/24                      172.16.2.5              110
18 ADo  172.24.1.0/24                      172.16.2.5              110
19 ADo  172.24.2.0/24                      172.16.2.5              110
20 ADo  172.25.0.0/24                      172.16.2.5              110
21 ADC  172.27.2.0/24      172.27.2.2      E4-Jam                    0
22 ADC  172.27.5.0/24      172.27.5.2      E7-GBB                    0
23 ADo  172.27.255.0/24                    172.16.2.5              110
24 ADo  172.28.0.249/32                    172.16.2.5              110
25 ADo  172.28.0.250/32                    172.16.2.5              110
26 ADo  172.29.0.0/24                      172.16.2.5              110
27 ADo  192.168.0.0/16                     172.16.2.5              110
28 ADC  192.168.23.168/29  192.168.23.174  E5-Sepanta                0
29 A S  192.168.25.128/27                  172.27.5.1                1
30 A S  192.168.53.224/29                  192.168.23.169            1
31 ADo  192.168.124.0/26                   172.16.2.5              110
32 ADo  192.168.124.52/32                  172.16.2.5              110
33 ADo  192.168.124.64/26                  172.16.2.5              110
34 ADo  192.168.124.102/32                 172.16.2.5              110
35 ADo  192.168.125.0/25                   172.16.2.50             110
36 ADo  192.168.125.128/25                 172.16.2.5              110
37 A S  192.168.126.216/29                 192.168.23.169            1
38 ADo  192.168.134.0/24                   172.16.2.5              110
39 A S  192.168.169.0/25                   172.27.2.1                1
40 ADo  192.168.179.0/25                   172.16.2.50             110
41 ADo  192.168.183.64/26                  172.16.2.5              110
42 ADo  192.168.183.102/32                 172.16.2.5              110

And non-pingable one (172.16.2.38) has this routing table:

 0 ADS  0.0.0.0/0                          192.168.8.1               1
 1 ADo  172.16.0.0/12                      172.16.2.41             110
 2 ADo  172.16.2.5/32                      172.16.2.41             110
 3 ADo  172.16.2.6/32                      172.16.2.41             110
 4 ADC  172.16.2.37/32     172.16.2.38     HQ                        0
 5 ADo  172.16.2.38/32                     172.16.2.41             110
 6 ADC  172.16.2.40/30     172.16.2.42     K2                        0
 7 ADo  172.16.2.48/30                     172.16.2.41             110
 8 ADo  172.16.2.53/32                     172.16.2.41             110
 9 ADo  172.16.2.54/32                     172.16.2.41             110
10 ADo  172.16.2.57/32                     172.16.2.41             110
11 ADo  172.16.2.58/32                     172.16.2.41             110
12 ADo  172.16.2.61/32                     172.16.2.41             110
13 ADC  172.16.2.62/32     172.16.2.62     loopback                  0
14 ADo  172.19.0.0/24                      172.16.2.41             110
15 ADo  172.20.0.0/24                      172.16.2.41             110
16 ADo  172.21.0.0/24                      172.16.2.41             110
17 ADo  172.24.0.0/24                      172.16.2.41             110
18 ADo  172.24.1.0/24                      172.16.2.41             110
19 ADo  172.24.2.0/24                      172.16.2.41             110
20 ADo  172.25.0.0/24                      172.16.2.41             110
21 ADo  172.27.2.0/24                      172.16.2.41             110
22 ADo  172.27.5.0/24                      172.16.2.41             110
23 ADo  172.27.255.0/24                    172.16.2.41             110
24 ADo  172.28.0.249/32                    172.16.2.41             110
25 ADo  172.28.0.250/32                    172.16.2.41             110
26 ADo  172.29.0.0/24                      172.16.2.41             110
27 ADo  192.168.0.0/16                     172.16.2.41             110
28 ADC  192.168.8.0/24     192.168.8.100   lte1                      0
29 ADo  192.168.25.128/27                  172.16.2.41             110
30 ADo  192.168.53.224/29                  172.16.2.41             110
31 ADo  192.168.124.0/26                   172.16.2.41             110
32 ADo  192.168.124.52/32                  172.16.2.41             110
33 ADo  192.168.124.64/26                  172.16.2.41             110
34 ADo  192.168.124.102/32                 172.16.2.41             110
35 ADo  192.168.125.0/25                   172.16.2.41             110
36 ADo  192.168.125.128/25                 172.16.2.41             110
37 ADo  192.168.126.216/29                 172.16.2.41             110
38 ADo  192.168.134.0/24                   172.16.2.41             110
39 ADo  192.168.169.0/25                   172.16.2.41             110
40 ADo  192.168.179.0/25                   172.16.2.41             110
41 ADo  192.168.183.64/26                  172.16.2.41             110
42 ADo  192.168.183.102/32                 172.16.2.41             110

Both are connected to 134.30 via PPTP connections.

mducharme · Mon Sep 24, 2018 11:38 am

And which router has the IP 172.16.2.41? The non-pingable one has that as the next hop for basically all routes.

ubuntu118 · Mon Sep 24, 2018 11:46 am

And which router has the IP 172.16.2.41? The non-pingable one has that as the next hop for basically all routes.

Let me give you the map:

HQ - (PPTP over Intranet) - HAS - (Wireless Link) - K1 - (PPTP over Intranet) - K2
And also:
HQ - (PPTP over Internet) - K1Backup (Currently not installed) - (Cable) - K1
HQ - (PPTP over Internet) - K2Backup - (Cable) - K2

This 172.16.2.41 is K2. The main route from K2 to HQ (134.30) is via K1-HAS, hence K2Backup routes all to K2 by default. If main route fails, traffic will fall on K2Backup-HQ link. The first routing table is from HAS and the second is from K2Backup which are nexthops for HQ.

mducharme · Mon Sep 24, 2018 12:15 pm

I'm afraid that text-based map doesn't really give the best view of the topology, so I can't really tell for sure where the problem is. What I would recommend is tracing the route manually by going through the routing tables on the various routers to trace the echo request from the source to the destination and the echo reply going back the other way. Somewhere along the line, there is obviously a routing loop happening.

If I recall, you are redistributing static routes to OSPF in all of your routers. It is reasonably likely that a static route (or OSPF-redistributed static route) is to blame for these loops somewhere, since they should not be possible in a normal OSPF infrastructure. As I said before, it is generally not recommended with OSPF to redistribute static or redistribute connected to advertise routes, except on routers where it must be used for some specific reason. Redistributing static on routers where it is not necessary could be causing some loops that otherwise would not exist.

ubuntu118 · Mon Sep 24, 2018 12:58 pm

Thanks for spending time on this issue. I have already tried tracing and the only hops I see are 134.30 and 134.10. It seems that in some way, 134.30 passes packets destined to backbone back to 134.10 and because 134.10 is already told that these should be handled by 134.30, a loop is formed. Because my network has lots of communications with our corporate network, I have to tell all my routers to send all packets not lying in my network to 134.10. So far, I have done this by redistributing static and connected. What is replacement for this, which can satisfy mentioned need?

mducharme · Mon Sep 24, 2018 7:32 pm

Thanks for spending time on this issue. I have already tried tracing and the only hops I see are 134.30 and 134.10. It seems that in some way, 134.30 passes packets destined to backbone back to 134.10 and because 134.10 is already told that these should be handled by 134.30, a loop is formed. Because my network has lots of communications with our corporate network, I have to tell all my routers to send all packets not lying in my network to 134.10. So far, I have done this by redistributing static and connected. What is replacement for this, which can satisfy mentioned need?

By tracing manually I mean tracing the route in your mind (not by running some command), by thinking about the packet's source and destination addresses in your mind, then go and look in the routing table on the first hop and find the longest prefix match, and see what the next hop is for that, and go to that in turn and see what the longest prefix match is, etc. The automatic traceroute can do many things, but it can't replace this process as a troubleshooting tool.

You should probably only have one router redistributing static if possible, the one that is connected directly to your corporate network. If there are two, then you can potentially use it on two, but try it on one at first.

Typically the way that OSPF networks are advertised is through OSPF network statements, not by redistribution. You currently have some (but not all) networks advertised through these statements. I would add the rest on the networks on the respective routers using these statements. If you like you can simplify the configuration by having a network statement for a larger network (ex. adding OSPF network 192.168.0.0/16 is the same as adding 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, etc. individually) but it is generally recommended to add the networks individually. Once you have advertised the networks using OSPF network statements, you should no longer need redistribute-connected and can switch it off, and then you can turn off redistribute static on all routers except the one directly connected to your HQ, and check the behavior.

Your network also seems small enough that you don't really need an OSPF area besides backbone. The only advantage to having another OSPF area is if you have routers that participate in that area only and not in backbone, then you can do summarization etc to reduce the size of the routing table. If all of your routers are member of both backbone and that other OSPF area anyway, they might as well only be in backbone (since you aren't gaining any efficiencies by adding the second area), and you might as well then just place all networks in the backbone area. This type of flat topology is perfectly fine for smaller networks.

Simplifying your topology as much as it is possible (even though I understand your network has some complexities) will go a long way towards preventing and correcting these types of issues.

ubuntu118 · Tue Sep 25, 2018 8:09 am

OK. Thanks for your detailed guides. I did it all and now everything is OK. thanks a lot for your help!

mducharme · Tue Sep 25, 2018 8:17 am

Anyway, it seems that turning static redistribution off doesn't solve my problem. Even putting all networks in backbone area doesn't fix pinging problem. Subnets behind routers are always pingable and other IPs are not! The only pingable hop other than HQ is 172.16.2.6 (HAS's PPTP end to HQ). If you want, I can provide all configs and details so you can check if I'm doing something wrong.

Yes, if can you can provide them, I will go through them carefully and try to figure out what the issue is. Also, please try to do a graphical network layout in visio or some other software (even the free open source DIA is somewhat OK) so that your overall topology is more understandable. Text output can be OK for some things, but for network design it is really hard to understand the topology from simple text, unless the topology is quite simple to begin with. Ideally I should be able to connect each config with a device in the visio layout.

ubuntu118 · Tue Sep 25, 2018 8:23 am

Anyway, it seems that turning static redistribution off doesn't solve my problem. Even putting all networks in backbone area doesn't fix pinging problem. Subnets behind routers are always pingable and other IPs are not! The only pingable hop other than HQ is 172.16.2.6 (HAS's PPTP end to HQ). If you want, I can provide all configs and details so you can check if I'm doing something wrong.
Yes, if can you can provide them, I will go through them carefully and try to figure out what the issue is. Also, please try to do a graphical network layout in visio or some other software (even the free open source DIA is somewhat OK) so that your overall topology is more understandable. Text output can be OK for some things, but for network design it is really hard to understand the topology from simple text, unless the topology is quite simple to begin with. Ideally I should be able to connect each config with a device in the visio layout.

Sorry for delayed edit! The problem is now solved. I don't know why now, but in some cases I have seen delayed reactions on some lower level Mikrotik routers (like RB750).

mducharme · Tue Sep 25, 2018 8:24 am

Sorry for delayed edit! The problem is now solved. I don't know why now, but in some cases I have seen delayed reactions on some lower level Mikrotik routers (like RB750).

Excellent! Glad that helped. It is not always unusual for there to be a delay when making major routing changes.

OSPF: No ping to backbone [SOLVED]

OSPF: No ping to backbone

Re: OSPF: No ping to backbone

Re: OSPF: No ping to backbone

Re: OSPF: No ping to backbone

Re: OSPF: No ping to backbone

Re: OSPF: No ping to backbone

Re: OSPF: No ping to backbone

Re: OSPF: No ping to backbone

Re: OSPF: No ping to backbone

Re: OSPF: No ping to backbone

Re: OSPF: No ping to backbone

Re: OSPF: No ping to backbone

Re: OSPF: No ping to backbone

Re: OSPF: No ping to backbone [SOLVED]

Re: OSPF: No ping to backbone

Re: OSPF: No ping to backbone

Re: OSPF: No ping to backbone

Re: OSPF: No ping to backbone

Who is online