You need to add route filters so that the local and remote addresses for the gre tunnel at both ends are not advertised out/received in as an OSPF route. You want them connected routes on each end only.
I tried based on your suggestion, but still disconnects, but i do not give up :)First things first, I'm making the assumption here that your IPsec Phase 1/2 policy is working and you can ping between the two? Although I would note you seem to have a mis-match between a /30 and /32 mask. You really want the GRE tunnel interface on each side to have no smaller than a /30.
I think you may have a couple of different issues here...
I would suggest setting up a Bridge with no member ports and assigning an IP address to this (replicates a loopback interface on, for example, a Cisco router) - you should in theory be able to use a /32 mask for this. Use this for the local and remote IP addresses for the GRE tunnel on each side. It appears that you haven't configured the local address and the remote address is obfuscated in your output, therefore I'm assuming this isn't a private address running over the IPsec tunnel.
You need to filter out the Bridge IPs you are using for the GRE tunnel from OSPF. It's also worth filtering out the default route and your WAN next hop address.
See some relevant portions of my config from one side below - hopefully gives you something to go on:
/ip ipsec policy
add dst-address=192.168.255.4/30 peer=xxx proposal=xxx sa-dst-address=\
xx.xxx.xxx.xx sa-src-address=xx.xxx.xxx.xxx src-address=192.168.255.0/30 \
add address=192.168.255.1/30 interface=GRE_for_OSPF network=192.168.255.0
add address=192.168.10.1/30 interface=ospf_gre network=192.168.10.0
add local-address=192.168.255.1 name=ospf_gre remote-address=192.168.255.5
/routing ospf instance
set [ find default=yes ] distribute-default=if-installed-as-type-1 in-filter=\
xxx-In name=xxx out-filter=xxx-Out redistribute-connected=as-type-1 \
/routing ospf network
add area=backbone network=192.168.10.0/30
add action=discard chain=xxx-In prefix=0.0.0.0/0 (default route from remote router)
add action=discard chain=xxx-In prefix=xx.xx.xxx.xxx (PPPoE client WAN interface remote/default route next hop address on remote router)
add action=discard chain=xxx-In prefix=192.168.2.0/24 (DSLmodem management eth1 remote router)
add action=discard chain=xxx-In prefix=192.168.88.0/24 (Default MT IP on default bridge - remote router)
add action=discard chain=xxx-In prefix=192.168.255.4/30 (Bridge for GRE on remote router)
add action=discard chain=xxx-In prefix=xxx.xxx.xxx.xx/29 (public IPs on remote router)
add action=discard chain=xxx-Out prefix=0.0.0.0/0 (default route from local router)
add action=discard chain=xxx-Out prefix=xx.xx.xxx.xxx (PPPoE client WAN interface remote/default route next hop address on local router)
add action=discard chain=xxx-Out prefix=192.168.2.0/24 (DSL modem management eth1 on local router)
add action=discard chain=xxx-Out prefix=192.168.88.0/24 (Default MT IP on default bridge - local router)
add action=discard chain=xxx-Out prefix=192.168.255.0/30 (Bridge for GRE on local router)
add action=discard chain=xxx-Out prefix=xx.xxx.xxx.xxx/29 (public IPs on local router)
/ip firewal filter
add action=accept chain=input comment=OSPF dst-address-list=OSPF protocol=\
add action=accept chain=forward dst-address-list=OSPF protocol=icmp \
add action=accept chain=output dst-address-list=OSPF protocol=icmp \
add action=accept chain=input dst-address-list=OSPF protocol=ospf \
add action=accept chain=forward dst-address-list=OSPF protocol=ospf \
add action=accept chain=output dst-address-list=OSPF protocol=ospf \
add action=accept chain=input dst-address-list=OSPF protocol=igmp \
add action=accept chain=forward dst-address-list=OSPF protocol=igmp \
add action=accept chain=output dst-address-list=OSPF protocol=igmp \
/ip firewall address-list
add address=126.96.36.199 list=OSPF
add address=188.8.131.52 list=OSPF
add address=184.108.40.206 list=OSPF
add address=192.168.10.0/30 list=OSPF
/ip firewall nat
add action=accept chain=srcnat dst-address=192.168.255.4/30 src-address=\
add action=accept chain=srcnat out-interface=ospf_gre
I use these subnets:Based on my experience until I got it right, it feels likely to be an issue on your route filters allowing a particular connected route to be advertised to the neighbour upsetting the GRE tunnel.
When the tunnel drops, so does OSPF so the routing is restored... GRE comes up, route is advertised...and repeat!
Are you using a RFC1918 private address of some form for the local and remote addeess of the GRE tunnel? Your pastebin upload didn't specify a local address and you had edited out the remote address...
If you don't have any conflicting subnets, try using exactly the addressing in my config and see if it works for you...then track back from there through your config until you get your desired addresses working.
I checked them. There is a next hop 10.0.0.1 on the HEX side, when i filter with:Also check your router ID is using the address assigned to the local GRE tunnel interface on each side.
Here is the current configuration:There's quite a few variables here that could be tripping you up and it's hard to spot the issue without being able to look at both router configs side by side at the same time..
Can you post full configs from both sides, redacting any sensitive info such as passwords, shared keys, public IPs etc? Try not to redact any internal private addressing if you can.
I made the suggestion as you said:OK, I think your problem is the IP you have assigned to the bridge on each side is from the same subnet (172.16.1.0/30). It needs to be on a different subnet on each router.
You can keep the same IPs but you'd need to make the addresses /32 masks. If that doesn't work, use 172.16.1.0/30 and 172.16.1.4/30 networks with IPs of 172.16.1.1 and 172.16.1.5
Update the IP assigned to the bridges, then your IPsec policies, route filters and the local/remote address for the GRE tunnel on each side
I work with you, i try everything that you said, but the problem is the same :) I know this is a huge mystery .To try to be a little clearer...
Your issue might be with the 0.0.0.0/0 default route, but my WAN setup via PPPoE client also adds a route to the remote address of that interface (62.x.x.x/32)
If I don't filter these two connected routes, all traffic to the WAN/internet will try to go via the address of GRE tunnel on the remote router. But the IPsec tunnel can't run effectively inside itself.. so the IPsec tunnel (and therefore the GRE & OSPF) will go down. This results in that OSPF route conflict being removed as the neighbour is down. This route conflict being removed brings the WAN, IPsec, GRE and OSPF neighbour back up, route gets advertised & received again...cycle repeats.
My example - "router 1":
OSPF router ID: 172.16.1.1/30 (IP address is assigned to GRE tunnel interface)
GRE tunnel local address: 172.16.0.1/32 remote address: 172.16.0.2/32
"Lo0" bridge: 172.16.0.1/32
IPsec policy src: 172.16.0.1/32 dst: 172.16.0.2/32
IPsec peer: 95.x.x.x
IP routes (amongst others):
0.0.0.0/0 via Uno FTTC reachable
62.x.x.x via Uno FTTC reachable
IPsec tunnel to "router 2" via the internet is established via the 0.0.0.0/0 route, so if that route becomes advertised through OSPF as via 172.16.0.2, the IPsec will go down.
If I did want to advertise a default route from one of the two via OSPF then I would need to add a static route between the two routers via Uno FTTC and stop adding the default route via PPPoE client on the router that should receive its default via OSPF.
As long as the two routers could then still reach each other via static route (ensuring that in turn is also filtered out of OSPF advertisements) and establish the IPsec/GRE tunnels, there would be no issue advertising the default route through the tunnel. But only one of the two should advertise this i.e. router 2 receives default route advertised via router 1 or vice-versa. You can't have both routers advertising a default route into the same area.
I really appreciate your help anyway, i think we tried so many things. The english is not my mother language, very difficult to express myself, that is why i rarely ask help from others :)To be honest I think we're reaching the point I've exhausted most things I can think of based on the config you've shared.
I've only been working with OSPF in my ROS a few weeks...and that's after having an issue with it on Cisco kit at work, so I set it up to help me understand it better.
Might be worth setting up your own thread - since I marked it as solved for my original issue, others might not be looking in. Feel free to reference back to your posts here. A fresh pair of eyes aside from both of us might spot and solve your issue quickly...or at least have some more suggestions to offer :-)