OSPF route publishing issue

RouterOS Forwarding Protocols
1

I’m having an issue with OSPF that has me banging my head. I’ve got several networks that fold into a single location like a hub and spoke. One of the remote sites was working fine until yesterday.

I changed the IP addresses up a bit for this post but they should refer to the correct route publications.

Remote A

# apr/10/2015 07:06:14 by RouterOS 6.27
# software id = 
#
/routing ospf instance
set [ find default=yes ] router-id=10.6.19.1
/routing ospf network
add area=backbone network=10.6.19.0/24
add area=backbone network=172.16.2.0/24
add area=backbone network=172.20.2.0/24

HQ

# apr/10/2015 07:09:19 by RouterOS 6.27
# software id = 
#
/routing ospf instance
set [ find default=yes ] redistribute-static=as-type-2 router-id=192.168.254.11
/routing ospf network
add area=backbone network=192.168.254.0/24
add area=backbone network=172.19.254.0/24
add area=backbone network=172.20.2.0/24

The HQ has about a two page long “/ip route print” but the only relevant one is:

23 ADC  172.20.2.23/32     172.20.2.1      l2tp-remote_a                0

But I don’t see pptp-remote_a in the “/routing ospf neighbor print” on HQ.

On the Remote A side I see this in the “/ip route print”:

19 ADC  172.20.2.1/32      172.20.2.23     l2tp-hq                 0

But my Remote A side CAN see HQ in the “/routing ospf neighbor print” but shows “Init” for the state

1 instance=default router-id=192.168.254.11 address=172.20.2.1 interface=pptp-mmsa priority=1 dr-address=0.0.0.0 backup-dr-address=0.0.0.0 state="Init" state-changes=1 ls-retransmits=0 ls-requests=0 db-summaries=0

There are no firewall filters blocking, on either side (yes I turned everything off just to see). I can ping 192.168.254.11 from 10.6.19.1 and vice versa.

BUT…

If I connect Remote A to Remote B using the same settings then everything works fine, all routes get publish, roosters stop laying eggs and the world continues to spin from left to right. The connection to HQ directly just doesn’t work anymore.

The OSPF settings on the Remote A have been in since December with no issues. HQ handles about 20 IPSec/L2TP tunnels and the rest are fine.

Other things I’ve done to try and fix this:

  • Static OSPF Interface settings
  • Checked MTU settings
  • Made sure both network types are set to point to point (also made them static)
  • Made sure neither was trying to publish a stub network


    Anyone have any ideas?
2

I think I see where the demon lives:

On remote A:
Relevant IP Route:
19 ADC 172.20.0.1/32 172.20.2.23 l2tp-hq 0
– Remote A thinks the remote end of the L2TP connection (HQ) is 172.20.0.1

Yet HQ thinks its side of the L2TP connection is 172.20.2.1
relevant IP route:
23 ADC 172.20.2.23/32 172.20.2.1 l2tp-remote_a 0

Note that in Remote_A, the dynamic neighbor is showing up as address 172.20.2.1

1 instance=default router-id=192.168.254.11 address=172.20.2.1 interface=pptp-mmsa priority=1 dr-address=0.0.0.0 backup-dr-address=0.0.0.0 state=“Init” state-changes=1 ls-retransmits=0 ls-requests=0 db-summaries=0

This might be an artifact of your IP address sanitization for the post, of course, but if it’s not, then you need to figure out why the mismatch.

3

Yes sorry, I change the 2nd and 3rd octet but forgot to change the 3rd octet on that one. I’ll made the change in the original post (I think I can edit it).

Thank you for the reply though!

4

Alright - well, this seems like 1-way communications, at least with multicast traffic.
Basically, remote-A is hearing HQ, but HQ is not hearing the hello packets from Site-A.
When Site A is linked to B, does HQ still have any static or connected routes having to do with 172.20.2.23 ?
Does A have anything to do with 172.20.2.1 when it’s connected to B?

Also - double check that one side didn’t get some spurrious setting to do with MTU - ospf won’t form an adjacency if the two neighbors disagree on what the MTU is.

5

No, no static routes and the MTU’s are both at 1450.

I thought I might be able to see who was out there by pinging 224.0.0.5 but nothing came back. Nothing came back on any of the working routes either so that wasn’t a good test.

I turned on OSPF logging and can see the HELLO send from HQ but no receive but both send and receive on the Remote A side. That leads me to belive HQ did not receive an ACK of some sort for OSPF to be established. The routing interfaces all ping fine and I just disabled OSPF on Remote A and static routed everything between HQ and Remote A with no issues routing manually. Then I turned OSPF back on and Remote A still sees HQ as at the “idle” state with no published routes.

I’m hesitant to do anything too crazy because HQ is 170 miles away and Remote A is 450 miles. I’ve already lost Remote A once and was very thankful for “Safe Mode”.

6

Yeah - the threat of a long drive can make you measure twice before you cut. :slight_smile:

This is all over L2TP right? I was thinking maybe there’s a wireless p2p link somewhere that has multicast disabled, but the L2TP packet should just be unicast anyway…

Not trying to think of stupid stuff here, but you can actually ping across the L2tp link when it’s established, ospf notwithstanding, right?

If so - if you create static routes across it, does everything work?

7

Yes, I can ping across the link to the routing IP addresses on the other side with no static routes. I have static routes right now as a band-aid and everything works fine.

So I did some more troubleshooting and I guess I lied when I said I disabled all the NAT rules. I disabled everything but left the egress masquerade rule because it was pretty basic so I didn’t think would do any harm. Well, I went back and disabled it and OSPF began to publish. Then I tried to create a useless NAT rule of:

add action=passthrough chain=srcnat

…and it still broke OSPF. Could this be a bug? ANY single NAT rule will break OSPF for some reason. If someone from MT wants to chime in, I can send my config.

8

There are some strange bugs in dynamic routing in ROS - I worked with someone doing something totally normal, only to find out that the problem was a bug where OSPF wouldn’t take back over from a floating static backup default gw route.
iBGP won’t do recursive next-hop lookups in IPv6. (iBGP is all about recursive next hop - I wonder how that got missed)

So is this nat rule on site-A or on HQ?
(out of curiosity)

9

It’s a NAT rule on “A”. I can’t even apply a masquerade rule or OSPF won’t publish. It’s strange that this was working for over 4 months and then all of a sudden it stopped.

10

I tried to replicate this behavior but so far haven’t been able to.
I’m using v6.27, and my test bed just has the two routers directly connected in stead of using L2TP.

My nat table is completely blank in both routers, then in the “client” router, I created the ‘passthru’ rule only, and nothing changed. Disabled/enabled OSPF and adjacency immediately re-established.

Same is true when I changed the NAT rule in client router to use masquerade out-interface=ether2 (the interface linked to R1)

I’m going to put L2TP into the mix just to see if it makes any difference for me…

EDIT - even using L2TP between the two routers and running ospf across the tunnel, with the client set to masquerade all traffic out l2tp interface, it still forms adjacency.

What versions of ROS are you running?

11

I’m running 6.27. The problem occurs when I have ANY live nat rule. I too tried to replicate this problem between two RB750’s I have laying around but couldn’t get it to fail. I even copied the /export file removing the obvious entries and changing IPs and it was still successful. The issue may not be with these two routers but somewhere else on my WAN.

I ended up just setting a static route since this location doesn’t route anywhere else then added the network at HQ’s OSPF so it broadcasts that to all other routers. Thanks for your help.

12

At least we’re not crazy. :slight_smile:

13

I had same issue where neighbour only shows up on one side of the link.
Changing “Multicast Helper” from default to full helped.
Had to change this on both sides of the link

14

I’d swap L2TP for GRE or IPIP tunnels with /30 addressing. You can still wrap it in IPSec and I haven’t seen any issue using GRE or IPIP. To many issues around NAT and exclusion when using L2TP.