Dear Folk,
We are Tik A running 6.7 on RP 750 and Tik B running 6.10 on RB1100
Tik A/1 → Tik B/12 → Internet A/1 means ether port 1 on A etc.
Tik A/1 Tik B/12
209.150.235.122/30 209.150.235.121/30
10.255.249.6/29 10.255.249.1/29
Both are running OSPF, both have both networks in their OSPF NETWORKS
and both show each other as neighbors on the 209 subnet.
Tik B has src nat on ether 1, either as masquerade or as explicit nat to 209.150.235.122.
That nat should in theory include ospf packets originating as 10.255.249.6.
Tik B is complaining about mismatched subnets, it says local is /30 and the remote
is /29.
This is not itself a problem.
After clearing the firewall contrack table in FIREWALL CONNECTIONS, the ospf sessions
between the two tiks connect and trade data properly.
Then about 5 minutes later, Tik B drops Tik A as its neighbor and all of Tik A’s ospf entries go to infinite cost and then disappear.
Clearing the contract table fixes it all again for another 5 minutes.
This arrangement has seemingly worked forever until last night until it became blatantly unworkable.
Can someone point me in the right direction to debug this?
Homer W Smith
CEO Lightlink Internet
Are the two Tik’s connected with an ethernet cable? Or is there a wireless link? With my wireless links I have a public /30 for OSPF and a private /29 for the wireless bridges. That way traceroute doesn’t break.
Change your NAT to not src-nat 10.255.249.6/29.
What is your OSPF network type on A/1 and B/12?
Do you really want to run two OSPF associations on this link? If not, I would remove the 10.255.249.0/29 from OSPF networks.
Just removing 10.255.249.0/29 from participating in OSPF will probably fix your network without taking it out of NAT. But it you want to use it in OSPF, you need to make sure it is actually being used and not the public address. What is likely happening is that a NATed packet sourced from 10.255.249.0/29 is showing at the other end as one of the 209.150.235.120/30 addresses. The OSPF packet says “My prefix length is 29” but the OSPF association for 209.150.235.120/30 is supposed to have a prefix length of 30. That’s a big error, so OSPF kills the association.
This is probably a race condition. The stars aligned last night and suddenly the 10.255.249.0/29 packets are winning the race. It has been an incorrect setup all along, but somehow managed to work for a while…
Yes, exactly as you said, the nat is mucking up the OSPF. I have made sure the 10.255.249.0/29 is NOT natted.
The two tiks now form two stable sessions, the errors go away and all is happy, and yes
it has been wrong for ages and ‘worked’.
The Tiks are networked with two radios so the 209.150.235.120/30 connects the
two ticks, and the 10.255.249.0/29 connects he tiks, and two radios between them
and a teleboot and anything one might want in there.
You win a karma point.
Here is the problem then, how to get OSPF to broadcast the 10. subnet so it is
routable within our network easily, but NOT form a unique session on it which is awaste
of bandwidth and causes confusions.
Homer W. Smith
CEO Lightlink Internet
Redistribute-connected=as-type-1
That may not be the exact spelling. I am on my 'smart ’ phone right now.
If you have connected subnets you do not want distributed, add a route filter to deny them in ospf-out.