ECMP Strict Source Path

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Palo Alto Networks Approved
Palo Alto Networks Approved
Community Expert Verified
Community Expert Verified

ECMP Strict Source Path

L6 Presenter

Hello.

 

In ECMP settings there is Strict Source Path option to enable. But I can't find any descriptin about this option anywhere. Anyone knows what exactly does this option do? 

1 accepted solution

Accepted Solutions

L7 Applicator

This has been bugging me since it was posted. I was finally able to do enough digging and found the answer.

 

Strict Source Path is a feature of the ECMP specification, rather than a feature unique to Palo Alto Networks. There are 2 types of source routing with ECMP, loose and strict. 

 

Check the following RFC, section 3.1. The subsections are titled "Loose Source and Record Route" and "Strict Source and Record Route".

https://tools.ietf.org/rfc/rfc791.txt

 

Both require options in the IP header. Loose (type=131) is by far the most common, but some environments will need strict (type=137). 

View solution in original post

9 REPLIES 9

L7 Applicator

This has been bugging me since it was posted. I was finally able to do enough digging and found the answer.

 

Strict Source Path is a feature of the ECMP specification, rather than a feature unique to Palo Alto Networks. There are 2 types of source routing with ECMP, loose and strict. 

 

Check the following RFC, section 3.1. The subsections are titled "Loose Source and Record Route" and "Strict Source and Record Route".

https://tools.ietf.org/rfc/rfc791.txt

 

Both require options in the IP header. Loose (type=131) is by far the most common, but some environments will need strict (type=137). 

Hi @gwesson

Thanks, i also had this query.

 

It may be not relevent here, but appreciate if you can clarify me in this option, I can see 'symmetric return' under ECMP option, is this a alternative option for symmetric return in dual ISP failover/ECMP scenario ?. i have seen in dual ISP scenarios, poeple were using PBF for symmetric return enforcement.

 

So if i have web services running inside and ECMP is enabled in dual ISP scenario, i just need to enable this option instead of doing PBF and select ' symmetric return' ?

@Abdul_Razaq they're related, but do different things in their own context. The PBF option is when you could have asymmetric routes, whereas in ECMP it overrides the inherent load balancing that ECMP provides. Both of the following are pulled from the inline help on the firewall from their respective sections:

 

Symmetric return in ECMP

Select Symmetric Return to cause return packets to egress out the same interface on which the associated ingress packets arrived. That is, the firewall will use the ingress interface on which to send return packets, rather than use the ECMP interface, so the Symmetric Return setting overrides load balancing. This behavior occurs only for traffic flows from the server to the client.

 

Symmetric return in PBF

Select Enforce Symmetric Return and enter one or more IP addresses in the Next Hop Address List. Enabling symmetric return ensures that return traffic (such as from the Trust zone on the LAN to the Internet) is forwarded out through the same interface through which traffic ingresses from the internet.

Ty for the info.

L1 Bithead

"strict source path" means no ECMP. It applies to firewall originated IKE/IPsec traffic. Traffic will be sent out over the tunnel based on which tunnel the source address belong to. It has nothing to do with real "source routing". It does not affect transit traffic. Similar to "symetric return" it is an exception of ECMP hashing.

Strict Source Path - I still to this day have no idea what this option is for, what it does or doesn't do, and when to and not to use it. Not a lot of documentation on it from Palo themselves.

are we sure this is correct?

 

"strict source path" means no ECMP. It applies to firewall originated IKE/IPsec traffic. Traffic will be sent out over the tunnel based on which tunnel the source address belong to. It has nothing to do with real "source routing". It does not affect transit traffic. Similar to "symetric return" it is an exception of ECMP hashing.

 

I see different behavior . Where traffic is from source is still doing route lookup to send traffic out.

 

Thanks

There seems some rework after my last comments. However, the behavior should not changed. Have you checked the new release notes? 

L0 Member

For everyone potentially still looking and wondering, I found this in Palo 10.1 documentation:

Strict Source Path
By default, IKE and IPSec traffic originating at the firewall egresses an interface that the ECMP load-balancing method determines. Select 
Strict Source Path
 to ensure that IKE and IPSec traffic originating at the firewall always egresses the physical interface to which the source IP address of the IPSec tunnel belongs. Enable Strict Source Path when the firewall has more than one ISP providing equal-cost paths to the same destination. The ISPs typically perform a Reverse Path Forwarding (RPF) check (or a different check to prevent IP address spoofing) to confirm that the traffic is egressing the same interface on which it arrived. Because ECMP by default chooses an egress interface based on the configured ECMP method (instead of choosing the source interface as the egress interface), that will not be what the ISP expects and the ISP can block legitimate return traffic. In this use case, enable 
Strict Source Path
 so that the firewall uses the egress interface that is the interface to which the source IP address of the IPSec tunnel belongs.
  • 1 accepted solution
  • 19540 Views
  • 9 replies
  • 2 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!