VPN Hub-Spoke & OSPF Path Preference w/ branch redundancy

Answered Question
Feb 9th, 2014
User Badges:

Hi All,


I read the following, under the OSPF section on Frame Relay implementation of my CCNP Route studies:


"In a frame relay topology of hub router to branch router, where the branch has two routers for redundancy, and the WAN links from said routers back to the hub have different frame relay CIR's, the recommended way of controlling that OSPF always takes the path with the higher CIR is to set the network type to point-to-multipoint and configure static neighbors on the hub router and give each a cost."


So, understanding that, what would happen in the case that I had a point-to-multipoint hub and spoke network like above, but instead of frame relay, I am using DMVPN, and the broadband circuit on branch router 1 is 6Mbps while the broadband circuit on branch router 2 is 1.5mbps?  If I wanted to make sure the 6mbps circuit was always preferred, would I have to set the hub router network type to point-to-multipoint on the hub, configure the static neighbors and assign a cost on the hub for each spoke router in the branch, just as they recommend for OSPF over frame relay?


Additionally, for the sake of the concept, assume HSRP/VRRP can't be used please.


Thanks.

Correct Answer by Peter Paluch about 3 years 6 months ago

Hi Dean,


If I wanted to make sure the 6mbps circuit was always preferred, would I  have to set the hub router network type to point-to-multipoint on the  hub, configure the static neighbors and assign a cost on the hub for  each spoke router in the branch, just as they recommend for OSPF over  frame relay?


Yes, that would be necessary. You see, a hub router has a single GRE multipoint interface to talk to all spokes. Therefore, configuring an OSPF cost on this interface would apply summarily to all spokes. What you want to achieve, though, is a per-neighbor OSPF cost. In the case the neighbors are reachable over a single interface, the only way of doing this in OSPF is to configure the OSPF network type to point-to-multipoint non-broadcast and define all spoke neighbors statically along with their intended costs. Please note that the network type must include the non-broadcast keyword, as the neighbor command is only accepted for neighbors over a non-broadcast network type.


Spoke routers would also need to use the point-to-multipoint non-broadcast network type, and refer to the hub router using the neighbor command, again with the indended cost.


Best regards,

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
Peter Paluch Sun, 02/09/2014 - 15:12
User Badges:
  • Cisco Employee,

Hi Dean,


If I wanted to make sure the 6mbps circuit was always preferred, would I  have to set the hub router network type to point-to-multipoint on the  hub, configure the static neighbors and assign a cost on the hub for  each spoke router in the branch, just as they recommend for OSPF over  frame relay?


Yes, that would be necessary. You see, a hub router has a single GRE multipoint interface to talk to all spokes. Therefore, configuring an OSPF cost on this interface would apply summarily to all spokes. What you want to achieve, though, is a per-neighbor OSPF cost. In the case the neighbors are reachable over a single interface, the only way of doing this in OSPF is to configure the OSPF network type to point-to-multipoint non-broadcast and define all spoke neighbors statically along with their intended costs. Please note that the network type must include the non-broadcast keyword, as the neighbor command is only accepted for neighbors over a non-broadcast network type.


Spoke routers would also need to use the point-to-multipoint non-broadcast network type, and refer to the hub router using the neighbor command, again with the indended cost.


Best regards,

Peter

Joseph W. Doherty Mon, 02/10/2014 - 02:18
User Badges:
  • Super Bronze, 10000 points or more

Disclaimer


The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.


Liability Disclaimer


In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.


Posting


So it's just one hub but two branch routers?  If so, an alternate solution might be to define two DMVPN networks (one for each of the two branch routers) and then you can cost them differently.

Peter Paluch Mon, 02/10/2014 - 02:30
User Badges:
  • Cisco Employee,

Hi Joseph,


So nice to meet you again


Yes, absolutely, if there are just a few spoke sites then having two separate DMVPNs would be a way to go. And, on the other hand, if this is truly a large scale DMVPN deployment, I recall Fred Detienne from Cisco TAC in Brussels advocating strongly for BGP as the hub-spoke routing protocol, and I have to admit - it was quite an eye-opener to see how well BGP can be suited.


Best regards,

Peter

Dean Romanelli Mon, 02/10/2014 - 16:26
User Badges:

Peter,


Excellent explanation, thank you.


The dual VPN routers is also a great idea Joseph, as would be HSRP/VRRP on the spoke, I'd imagine. 


That actually gave me another thought:


The readings also say in a hub and spoke network to ensure your spokes don't participate in DR/BDR election.  Let's say I chose broadcast as my network type, and I only have 1 hub router.  In this case, with the spokes not eligible for BDR election and no 2nd router in the hub, what happens to the BDR?  Would one just not exist, or would it be a requirement for me to add another DMVPN router to fulfill the BDR role?

Joseph W. Doherty Mon, 02/10/2014 - 16:39
User Badges:
  • Super Bronze, 10000 points or more

Disclaimer


The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.


Liability Disclaimer


In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.


Posting


I believe the network will function with just a DR.  However, if the DR fails, since it hosts the hub of the DMVPN, a BDR isn't going to help you much.

Dean Romanelli Thu, 02/13/2014 - 13:14
User Badges:

Another question came to me building my review lab:


In the instance we were talking about above; Having 1 hub and 1 spoke but the spoke having 2 routers for redundancy:


If I set the network type to point-to-multipoint non-broadcast on the hub and set the neighbor's statically, assigning cost 1 on the hub side to the primary router at the spoke and cost 2 on the hub side to the backup router at the spoke, what happens if hub loses the neighborship to the primary router at the spoke (i.e. primary spoke router WAN goes down)? Will the hub still continue to try to communicate over that link, since the cost is 1 as opposed to the surviving neighbor's cost being 2?  Or will the cost and/or metric to the primary spoke router that is down get "poisoned" if you will, so that the cost and metric to the backup router is better until the primary spoke recovers?

Joseph W. Doherty Thu, 02/13/2014 - 14:37
User Badges:
  • Super Bronze, 10000 points or more

Disclaimer


The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.


Liability Disclaimer


In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.


Posting


If the primary spoke router goes down, the hub will not see a path to the spoke's network(s) except via the secondary spoke router.

Actions

This Discussion