Prioritizing an BGP route over other BGP routes for IPSec tunnel traffic redirection

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

Prioritizing an BGP route over other BGP routes for IPSec tunnel traffic redirection

L3 Networker

Hi All,

 

We have an physical Firewall on our premise. We have Three ISP and single virtual router with ECMP enabled(Balanced Round Robin)in it.

 

Recently we had configured Two pairs of IPsec tunnels(Pair one -Tunnel 1 and Tunnel2// Pair 2 - tunnel 3 and tunnel 4) to communicate to AWS Peer(Only one Subnet on AWS 10.x.x.x/24) using the BGP Method for successful failover.

 

ISP 1 -->Tunnel 1, Tunnel 2

ISP 2-->Tunnel 3 and Tunnel 4

 

As we had already enabled the ECMP Balanced round robin method the traffic is currently passing through tunnel 2 and tunnel 4

 

Now we need the traffic to pass through only tunnel 1 and the traffic should pass through other tunnels only if the tunnel 1 fails. All the tunnels are configured under BGP.

 

Thanks in advance!!!

 

My guess is do we have some metrics mechanism which will influence the Tunnel through which the traffic will be egressed.

BGP Routing Question   

 

 

1 accepted solution

Accepted Solutions

Hi @tamilvanan ,

 

I would disagree with @OtakarKlier  - you don't need PBF if you already running BGP. Why would you put additional complexity if you already have dynamic routing which you can control in so many ways

 

I don't understand what ECMP have to do in this question... I understand you use ECMP for Internet access (your default route), but on top of that we are talking about IPsec tunnels, so the routing to AWS private range as nothing to do with the ECMP (as long as you have any tunnel up 🙂 ). So I will abstract from this.

 

Now I understand that you are receiving the AWS prefix via BGP from all four tunnels. So all you have to do is to create import policy under the BGP. As I said with BGP you have lots of options to controll what you receive, how you receive it and what you advertise, probably the straight forward would be:
- Create one import policy for BGP peer over tunnel1

- Since you receive only one prefix, you can leave "match" tab as it is (meaning match any route received from that peer

- On "action" tab put 100 as local preference (for example)

 

- Create one more import below the previous one for BGP peer over tunnel2, 3 and 4

- Leave match tab as it is

- On "action" tab put 200 for local preference

 

This way your firewall will receive same prefix over all four tunnel, but it will prefer the route over tunnel1. If this tunnel fail, BGP peering will also fail and fw will stop receiving the prefix from tunnel1, so it will switch to the other tunnels.

 

Now depending what you actually try to accomplish you may want to split the second import policy and have four different policy for each bgp peer with different local pref for each.

View solution in original post

3 REPLIES 3

Cyber Elite
Cyber Elite

Hello,

Yes you can use the PBF rule to get traffic down one tunnel rather than the other. Please make sure to use the monitor:

OtakarKlier_0-1618343763393.png

 

And use an IP address on the other side of the tunnel for the monitor. Remember that PBF takes priority over the default router, so you have to disable this if the tunnel is down otherwise dynamic routing wont switch the traffic to the proper path.

 

Regards,


 

Hi @tamilvanan ,

 

I would disagree with @OtakarKlier  - you don't need PBF if you already running BGP. Why would you put additional complexity if you already have dynamic routing which you can control in so many ways

 

I don't understand what ECMP have to do in this question... I understand you use ECMP for Internet access (your default route), but on top of that we are talking about IPsec tunnels, so the routing to AWS private range as nothing to do with the ECMP (as long as you have any tunnel up 🙂 ). So I will abstract from this.

 

Now I understand that you are receiving the AWS prefix via BGP from all four tunnels. So all you have to do is to create import policy under the BGP. As I said with BGP you have lots of options to controll what you receive, how you receive it and what you advertise, probably the straight forward would be:
- Create one import policy for BGP peer over tunnel1

- Since you receive only one prefix, you can leave "match" tab as it is (meaning match any route received from that peer

- On "action" tab put 100 as local preference (for example)

 

- Create one more import below the previous one for BGP peer over tunnel2, 3 and 4

- Leave match tab as it is

- On "action" tab put 200 for local preference

 

This way your firewall will receive same prefix over all four tunnel, but it will prefer the route over tunnel1. If this tunnel fail, BGP peering will also fail and fw will stop receiving the prefix from tunnel1, so it will switch to the other tunnels.

 

Now depending what you actually try to accomplish you may want to split the second import policy and have four different policy for each bgp peer with different local pref for each.

Hi Astardzhiev,

Thank you for the detailed explanation. I got a similar issue, we are  cisco router connecting to a circuit running BGP routing to AWS primary patch,  circuit as primary, on secondary backup path is a redundant pair of Palo firewalls configure with an IPsec tunnel. I want to configure BGP failover, so that if the circuit fails, BGP peering will route traffic to our Palo firewalls, bring up the IPsec tunnels. Would that be a simialar design that you mentioned above?

 

Thanks,

Lcox 

  • 1 accepted solution
  • 7215 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!