I have topology with two hubs and about 10 spokes running DMVPN(2 clouds) and OSPF over it.
Like this:
If 1gb/s link between main offices fail, traffic will flow through one of spokes, that mostly have slow internet connection.
How can I prevent this? Has OSPF something like stub router in EIGRP?
-
Can you please post your OSPF configuration and any static routes (floating or otherwise) that you might have configured?– Zack ScaringelloSep 9, 2016 at 14:57
-
2OSPF has multiple stub area types: stub, totally stubby, and NSSA (no-so-stubby-area). Having a non-contiguous area will be a problem with OSPF. You should have an alternate link, such as another tunnel, between the two hub sites.– Ron Maupin ♦Sep 9, 2016 at 15:04
-
Additional Redundancy is almost never a bad idea.– Zack ScaringelloSep 9, 2016 at 15:20
Add a comment
|
2 Answers
The short answer is: no, you can't (with OSPF), at least not in a nice way.
In OSPF the whole DMVPN network within the DMVPN cloud (that is, at least the tunnel interface needs to be in the same area (area 0 in your case), just because your mGRE interface on the hub routers cannot be in different areas. This is the reason why stub areas (there are no stub routers in OSPF) won't help you out. By design you cannot filter LSAs within one area. Further you need to learn the routes of both main offices down at the spokes.
Technically you could place an ACL outbound on the tunnel interfaces of the hubs, denying the traffic of the remote main office. At least in this case the traffic is not sent through the hubs, possibly tearing down their Internet connection.
My suggestion: do not run OSPF on top of DMVPN unless you really have to do so. Any distance vector protocol such as EIGRP (and yes, even RIP) would be better. You could also consider running BGP (with the hubs running as route reflector), giving you great flexibility.
I strongly agree with Ron and Zack in the comments of your question. Ideally you would add a redundant connection between both head offices.
-
Thank you, I think tunnel between head offices can really solve this problem. Sep 9, 2016 at 17:43
Spoke to Spoke connectivity is created dynamically on demand with DMVPN (as in Dynamic Multipoint VPN). A 1Gbps link between the two DMVPN hubs does not affect this functionality.
Benefits of Dynamic Multipoint VPN
Hub Router Configuration Reduction
For each spoke router, there is a separate block of configuration lines on the hub router that define the crypto map characteristics, the crypto access list, and the GRE tunnel interface. This feature allows users to configure a single mGRE tunnel interface, a single IPsec profile, and no crypto access lists on the hub router to handle all spoke routers. Thus, the size of the configuration on the hub router remains constant even if spoke routers are added to the network.
DMVPN architecture can group many spokes into a single multipoint GRE interface, removing the need for a distinct physical or logical interface for each spoke in a native IPsec installation.
Automatic IPsec Encryption Initiation
GRE has the peer source and destination address configured or resolved with NHRP. Thus, this feature allows IPsec to be immediately triggered for the point-to-point GRE tunneling or when the GRE peer address is resolved via NHRP for the multipoint GRE tunnel.
Support for Dynamically Addressed Spoke Routers
When using point-to-point GRE and IPsec hub-and-spoke VPN networks, the physical interface IP address of the spoke routers must be known when configuring the hub router because the IP address must be configured as the GRE tunnel destination address. This feature allows spoke routers to have dynamic physical interface IP addresses (common for cable and DSL connections). When the spoke router comes online, it will send registration packets to the hub router: within these registration packets is the current physical interface IP address of this spoke.
Dynamic Creation for Spoke-to-Spoke Tunnels
This feature eliminates the need for spoke-to-spoke configuration for direct tunnels. When a spoke router wants to transmit a packet to another spoke router, it can now use NHRP to dynamically determine the required destination address of the target spoke router. (The hub router acts as the NHRP server, handling the request for the source spoke router.) The two spoke routers dynamically create an IPsec tunnel between them so data can be directly transferred.
answered Sep 9, 2016 at 15:43
-
Last time you asked to explain why your answer is down voted. So, here you go: it does not answer the question at all.– DanielSep 9, 2016 at 17:17
-
@waza-ari Interesting, and very kind of you. The OP says "If 1gb/s link between main offices fail, traffic will flow through one of spokes" which is inaccurate. Therefore, the follow up question "How do I prevent this [event which never happens]" is absurd. So, the OP needs to step back and read the DMVPN config guide, which is what I copied for him, in part, in my answer. Usage of English appears to be part of the issue. Sep 10, 2016 at 2:04
-
Ron, the problem is that you explained your position in your comment to @waza-ari, but you didn't explain that to the OP in your answer. If you believe the question is absurd, explain that in your answer, and then give your supporting data. As written, you give the supporting data with no explanation, leaving readers to guess what you mean.– Ron Maupin ♦Sep 10, 2016 at 5:44
-
@RonRoyston: first of all, sorry for my first comment, it may have been a little rude. But yes, Ron is right, why not just writing the content of your comment in the answer? This would have been an entirely different situation. And b2t: why do you think the OP's comment is inaccurate? A discontiguous non-0 area is technically valid. The hub router on one side will act as ABR and inject area 1 routes as type 3 LSAs, which will be imported into the other side, hence traffic will flow through one (if nor more than one, ECMP) spoke. In normal operation, intra-area routes in area 1 are preferred.– DanielSep 10, 2016 at 5:55