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:
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.
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.
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.
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.
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.
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.
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.
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).