please help me to resolve the problem with routing between dmvpn GRE tunnels.
I've got a DMVPN HUB and SPOKE topology. HUB has public ip address in internet. SPOKE has two ISPs for redundancy.
I've decided to create two GRE tunnels between HUB and SPOKE for redundancy. I configured GRE tunnels, configured ipsec profiles well. HUB and SPOKE see each other well through this GRE tunnels. But also I'm facing the problem with configuring OSPF between them to provide my topology with redundancy. I've decided to create two OSPF processes (one for each tunnel) and configured networks with different metric values for I have priority between OSPF routes:
OSPF configuration (HUB):
router ospf 100 router-id 172.20.10.1 network 172.20.10.1 0.0.0.0 area 0 //GRE TUNNEL IP ADDRESS (1-ST) default-information originate always metric 50 router ospf 101 router-id 172.21.10.1 network 172.21.10.1 0.0.0.0 area 0 //GRE TUNNEL IP ADDRESS (2-ND) default-information originate always metric 70
OSPF configuration (SPOKE)
router ospf 100 router-id 172.20.10.13 network 10.0.13.1 0.0.0.0 area 13 //NETWORK BEHIND SPOKE network 172.20.10.13 0.0.0.0 area 0 //GRE TUNNEL IP ADDRESS (1-ST) router ospf 101 router-id 172.21.10.13 network 10.0.13.1 0.0.0.0 area 13 //NETWORK BEHIND SPOKE network 172.21.10.13 0.0.0.0 area 0 //GRE TUNNEL IP ADDRESS (2-ND)
As you can see from my configuration I send default route to spoke with different metric values. From SPOKE I send route for network behind SPOKE through both of my GRE tunnels. Also I configured different ip ospf cost values for different tunnel interfaces. Here is the configutaion of my tunnel interfaces.
interface Tunnel100 ip address 172.20.10.13 255.255.254.0 no ip redirects ip mtu 1400 ip nhrp authentication nhrppass ip nhrp map 172.20.10.1 "HUB IP" ip nhrp map multicast "HUB IP" ip nhrp network-id 100 ip nhrp holdtime 300 ip nhrp nhs 172.20.10.1 ip nhrp registration no-unique ip ospf network point-to-multipoint ip ospf cost 50 tunnel source FastEthernet4 tunnel mode gre multipoint tunnel key 100 tunnel route-via FastEthernet4 mandatory tunnel protection ipsec profile DMVPN100 interface Tunnel101 ip address 172.21.10.13 255.255.254.0 no ip redirects ip mtu 1400 ip nhrp authentication nhrppass ip nhrp map 172.21.10.1 "HUB IP" ip nhrp map multicast "HUB IP" ip nhrp network-id 101 ip nhrp holdtime 300 ip nhrp nhs 172.21.10.1 ip nhrp registration no-unique ip ospf network point-to-multipoint ip ospf cost 70 tunnel source Vlan1 tunnel mode gre multipoint tunnel key 101 tunnel route-via Vlan1 mandatory tunnel protection ipsec profile DMVPN101
As a result I'm facing some problems with OSPF routes.
I see that both of my default routes from HUB go to SPOKE. If main route (with the better value of metric) is down the backup route is active. It works fine. But I've got the problem with routes on my HUB. I see it recieve only one route to the network behind SPOKE through the first tunnel interface. If this interface is down I don't have backup route to this network through the second tunnel interface.
Please give me an advice, what I do wrong?
Gracias de antemano por cualquier ayuda.
preguntado el 15 de noviembre de 13 a las 08:11
Your design is overly complex. I have never seen it done this way. Nor would I do it this way.
I suspect your true problem is not that the HUB is failing to re-learn the spoke's network via tunnel101 (when tunnel 100 is down) - but that your SPOKE is having nhrp cache problems learning routes and expunging routes with that default route.
never send a default route inside a private network - you want very specific routing information about A,B,C networks.
make sure when things fail you do "show ip ospf nei" and "show ip ospf database" on both sides. make sure the routing is fully working.
OSPF don't support unequalcost load balance. Since you have unequal cost on the two links nly one of the links will be listed in the routing-table. It the primary link goes down there will be an recalculation and the secoundary link will come into the routingtable.
I will agree that this is a complex setup. I would have set the same process on both primary link and secondary link.
Another tip: You shouldn't use area0 over GRE-tunnels, if a tunnel goes down the whole area0 have to recalculate. You should rather stop area 0 at the hub, and make normal area to spokes.