2

I have topology with two hubs and about 10 spokes running DMVPN(2 clouds) and OSPF over it.
Like this:
DMVPN + OSPF 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?

3
  • Can you please post your OSPF configuration and any static routes (floating or otherwise) that you might have configured? Sep 9 '16 at 14:57
  • 2
    OSPF 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 '16 at 15:04
  • Additional Redundancy is almost never a bad idea. Sep 9 '16 at 15:20
1

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.

1
  • Thank you, I think tunnel between head offices can really solve this problem. Sep 9 '16 at 17:43
-2

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.

4
  • Last time you asked to explain why your answer is down voted. So, here you go: it does not answer the question at all.
    – waza-ari
    Sep 9 '16 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 '16 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 '16 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.
    – waza-ari
    Sep 10 '16 at 5:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.