cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
429
Views
2
Helpful
2
Replies

FDM - BGP Per Neighbor AS_PATH Prepending

With using only FDM to manage a NGFW FTD device, has anyone been able to configure AS_PATH Prepending via the neighbor route-map policy?

I can configure this in the LINA Config tool (config t under system support diagnostic-cli), but as many are aware, any changes here are overwritten/reverted after any deployment through FDM.

router bgp 65000
  **bleep**-family ipv4 unicast
    neighbor 169.254.19.189 route-map BGP_Outbound_AS-PATH-Prepend_RouteMap out
    neighbor 169.254.14.209 route-map BGP_Outbound_AS-PATH-Prepend_RouteMap out
!

I haven't found a way to configure this in the BGP Object under Routing.

 

For context, I need this for an AWS Site-to-Site VPN connection. This means using one NGFW FTD firewall, but terminating it to both AWS VPN tunnels. I use AS_PATH Prepend to influence how AWS routes to the on-premise network. Otherwise, the AWS connections recalculate routes

Thanks

RFC 1925
2 Accepted Solutions

Accepted Solutions

To manage routing across redundant Site-to-Site VPN tunnels to AWS over VPN (using VTI interfaces on an FTD firewall, it's not intuitive. It’s buried deeply under a false flag of “filtering”.

First, to build the route-map in Advanced ConfigurationSmart CLIObjects.

  1. First, add a Standard Access List to permit all subnets you wish to affect when advertised to the BGP neighbors across the VPNs. You only need to list the subnets to match, since DENY is implicit at the end.

  2. Next, create a Policy List:
    AS-Path_1.png

  3. Then, create the Route Map:
    AS-Path_2.png
  4. Finally, configure the neighbors in the BGP Routing Object
    Below is an example of how this looks in FDM under RoutingBGPBGP Object:
    WeightWeight
    Above, you can see that there’s a weight of 2000 on the primary/first VPN tunnel BGP peer. This tells this firewall to prefer the first tunnel over the other since BGPs top priority for decision-making is weight. (NOTE: Local-preference doesn't do anything here because it's AS-based, but weight will, since it's host-based.)

    AS_PATH Prepending attributeAS_PATH Prepending attribute

Above, you can see how AS_Path Prepending is applied using a route-map (BGP_Outbound_AS-PATH-Prepend_RouteMap and direction out). Note the neighbor referenced here is the BGP neighbor of the second VPN tunnel, not the first. This helps influence AWS to lower the priority of this VPN tunnel, instead preferring to route traffic over the first tunnel.

Obviously, only AWS Support can tell you if this is actually working, but it appears to in our work.

RFC 1925

View solution in original post

2 Replies 2

To manage routing across redundant Site-to-Site VPN tunnels to AWS over VPN (using VTI interfaces on an FTD firewall, it's not intuitive. It’s buried deeply under a false flag of “filtering”.

First, to build the route-map in Advanced ConfigurationSmart CLIObjects.

  1. First, add a Standard Access List to permit all subnets you wish to affect when advertised to the BGP neighbors across the VPNs. You only need to list the subnets to match, since DENY is implicit at the end.

  2. Next, create a Policy List:
    AS-Path_1.png

  3. Then, create the Route Map:
    AS-Path_2.png
  4. Finally, configure the neighbors in the BGP Routing Object
    Below is an example of how this looks in FDM under RoutingBGPBGP Object:
    WeightWeight
    Above, you can see that there’s a weight of 2000 on the primary/first VPN tunnel BGP peer. This tells this firewall to prefer the first tunnel over the other since BGPs top priority for decision-making is weight. (NOTE: Local-preference doesn't do anything here because it's AS-based, but weight will, since it's host-based.)

    AS_PATH Prepending attributeAS_PATH Prepending attribute

Above, you can see how AS_Path Prepending is applied using a route-map (BGP_Outbound_AS-PATH-Prepend_RouteMap and direction out). Note the neighbor referenced here is the BGP neighbor of the second VPN tunnel, not the first. This helps influence AWS to lower the priority of this VPN tunnel, instead preferring to route traffic over the first tunnel.

Obviously, only AWS Support can tell you if this is actually working, but it appears to in our work.

RFC 1925
Review Cisco Networking for a $25 gift card