OSPF with redundant route

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

OSPF with redundant route

L2 Linker

Hello.

Currently we use OSPF as our routing protocol between five locations over a layer two IP Ethernet network provided by telco A. In order to get carrier diverse routes and add redundancy we are adding a second similar network provided by Telco B. We have a single “normal” (not stub or NSSA) OSPF area with a metric of 10 and a single redistribution profile. Each location and a PAN HA pair of firewalls.

 

If we want to use this new circuit as a backup I believe I just need to create a new area ID specifying the interface of the new circuit and give it a higher metric? OR use the same area and add the new interface with a higher metric? I am thinking the second. If we then want to force specific traffic down the new circuit then we would use PBF rules forwarding to the new interface.

 

Is it a bad idea to use the same metric and let it load balance? What is the best practice for this situation?

 

Thanks for you input.

1 accepted solution

Accepted Solutions

Correct any higher number to favor one link over the other will work.

 

For failover, ideally, you would use BFD for this function.  This would allow reliable sub-second failover detection.  But we don't yet have that option on Palo Alto gear yet.

 

I have run dead timers as low as 16-20 seconds for OSPF with the hello interval at 2 seconds and had it work reliably.  The danger is that if you go too low you can get flapping if the links are not in low latency and good connections or when the link is overwhelmed with too much traffic.

Steve Puluka BSEET - IP Architect - DQE Communications (Metro Ethernet/ISP)
ACE PanOS 6; ACE PanOS 7; ASE 3.0; PSE 7.0 Foundations & Associate in Platform; Cyber Security; Data Center

View solution in original post

3 REPLIES 3

L7 Applicator

You are correct that the metric alone can steer the traffic and there is no need to create a second area.

 

Generally I see that route selection is used as more predictable and reliable overall rather than load balancing.

Steve Puluka BSEET - IP Architect - DQE Communications (Metro Ethernet/ISP)
ACE PanOS 6; ACE PanOS 7; ASE 3.0; PSE 7.0 Foundations & Associate in Platform; Cyber Security; Data Center

It has been a while since I started this thread. Thank you Pulukas for your input. As a follow up, our current metric is 10. Our new circuits are the same bandwidth and equivilent latency, how should I adjust the the metric on the new circuit to steer traffic if there are issues on the first? I am thinking a metric value of 15 would be fine (or any higher number since there are only the two routes?).

 

This also had me thinking about the setting here for OSPF. With a hello of 10 and dead count of 4, that would be a 40 second outage before changing to the other route, if I understand it correclty. It seem it should be adjusted to be more aggressive, like hello at 5 dead count of 3 or something. What do those of you with more OSPF experinece then I think?

 

Hello Interval (sec) 10
Dead Counts 4
Retransmit Interval (sec) 5
Transit Delay (sec) 1
Graceful Restart Hello Delay (sec) 10

Correct any higher number to favor one link over the other will work.

 

For failover, ideally, you would use BFD for this function.  This would allow reliable sub-second failover detection.  But we don't yet have that option on Palo Alto gear yet.

 

I have run dead timers as low as 16-20 seconds for OSPF with the hello interval at 2 seconds and had it work reliably.  The danger is that if you go too low you can get flapping if the links are not in low latency and good connections or when the link is overwhelmed with too much traffic.

Steve Puluka BSEET - IP Architect - DQE Communications (Metro Ethernet/ISP)
ACE PanOS 6; ACE PanOS 7; ASE 3.0; PSE 7.0 Foundations & Associate in Platform; Cyber Security; Data Center
  • 1 accepted solution
  • 4275 Views
  • 3 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!