Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
jroy777
New Contributor III

Is a route-map required to use with a BGP community-list?

So I have some questions about BGP community-lists

Is a route-map required to use with a BGP community-list? 
I have a single Data Center with two 10G AWS Direct Connect Circuits and the subnets on both ends are exactly the same, just a redundant path. What would the community-list on a Fortiswitch look like in this scenario taking into account AWS says to use: "Local preference BGP communities"

Anyone can share the Fortiswitch commands of a working community-list?

 

BTW Fortinet Documentation on this matter gives few details of how it is supposed to work or be configured. Where are the examples????

https://docs.fortinet.com/document/fortiswitch/7.6.0/fortiswitchos-cli-reference/912449/config-route...


AWS docs sent by AWS Engineer:

https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html#bgp-communities-priv...

You can use local preference BGP community tags to achieve load balancing and route preference for incoming traffic to your network. For each prefix that you advertise over a BGP session, you can apply a community tag to indicate the priority of the associated path for returning traffic.

The following local preference BGP community tags are supported:

  • 7224:7100—Low preference

  • 7224:7200—Medium preference

  • 7224:7300—High preference

Local preference BGP community tags are mutually exclusive. To load balance traffic across multiple AWS Direct Connect connections (active/active) homed to the same or different AWS Regions, apply the same community tag; for example, 7224:7200 (medium preference) across the prefixes for the connections. If one of the connections fails, traffic will be then load balance using ECMP across the remaining active connections regardless of their home Region associations . To support failover across multiple AWS Direct Connect connections (active/passive), apply a community tag with a higher preference to the prefixes for the primary or active virtual interface and a lower preference to the prefixes for the backup or passive virtual interface. For example, set the BGP community tags for your primary or active virtual interfaces to 7224:7300 (high preference) and 7224:7100 (low preference) for your passive virtual interfaces.

Local preference BGP community tags are evaluated before any AS_PATH attribute, and are evaluated in order from lowest to highest preference (where highest preference is preferred).

7 REPLIES 7
Toshi_Esumi
SuperUser
SuperUser

I'm assuming FSW's CLI for BGP is the same with FGT's CLI for BGP.
If so, for advertisement to AWS you don't need to define community-list to send your routes with a community to ASW. You can directly configure it in a route-map. But to set local preference on the FGT side based on what AWS sends its routes with a community, you have to define  community-list to match it.

For the advertisement side of the set of BGP config would looks like below:

config router prefix-list
  edit InternalSubnets
    config rule
      edit 1
        set prefix 10.10.10.0 255.255.255.0
        unset ge
        unset le
      next
      edit 2
        set prefix 10.10.20.0 255.255.255.0
        unset ge
        unset le
      next
    end
  next
end


config router route-map
  edit Advertise2AWS
    config rule
      edit 1
        match-ip-address InternalSubnets
        set set-community "7224:7200"
      next
    end
  next
end


config router bgp
  <snip>
  config neighbor
    edit <AWS-1's neighbor IP>
      <snip>
      set route-map-out "Advertise2AWS"
      set send-community standard
    next
    edit <AWS-2's neighbor IP>
      <snip>
      set route-map-out "Advertise2AWS"
      set send-community standard
    next
  end
  <snip>
end

<edit>This morning I realized an error in BGP neighbor config. You need to use the neighbor IP for "edit" line.</edit>

Toshi

jroy777
New Contributor III

Thanks for the replies!

OK, A couple of questions. 

1) I already have BGP setup on the Primary Link and subnets are being passed and traffic is flowing. Why would I need a route map?
2) Does my secondary FortiSwitch need to become a BGP neighbor with the Primary Fortiswitch?
3) AWS says no BGP settings can be added on their side except the subnets and I understood that we tell AWS which path is prefered by our BGP statements sent to them by the FortiSwitch thus the community-list with local preference BGP community tag 

       7224:7100—Low preference on the Secondary Link
       7224:7300—High preference on the Primary Link

Notice AWS side BGP AS is same for both Direct Connect Links but different on my Data Center Side.
The Primary Fortiswitch is BGP AS 64514
The Secondary Fortiswitch is BGP AS 64516
AWS BGP AS is 64513

FortiSwitch-AWS-DC-Switch-vlan-Diagram.png

 

Toshi_Esumi

First of all "local preference BGP community tag" seems to be a function name inside of AWS. Likely it's just a combination of communities/community tags and local-preference tied together so that when AWS received those individual communities with the routes you advertise it would set up proper-local preference on its end to prioritize, like
community="7224:7100" -> local-pref=90
community="7224:7200" -> local-pref=100
community="7224:7300" -> local-pref=110
FGT/FSW or other vendor devices like Cisco, Juniper, etc. don't have the terminology. "community" and "local-preference" are separate components of BGP config.

To attach those communities to each route, you have to use a route-map as I showed above. Probably it's working now without the community because AWS treats all routes with the same priority (likely local-pref=100) by default. If you want to let the AWS set the higher priority/local-pref on the primary side, you need to set different route-maps on both neighbors like below:

config router route-map
  edit Advertise2AWS-Primary
    config rule
      edit 1
        match-ip-address InternalSubnets
        set set-community "7224:7300"
      next
    end
  next

  edit Advertise2AWS-Secondary
    config rule
      edit 1
        match-ip-address InternalSubnets
        set set-community "7224:7100"
      next
    end
  next
end

config router bgp
<snip>

  set ebgp-multipath enable
  config neighbor
    edit 164.254.38.181

      set soft-reconfiguration enable
      set remote-as 64513
      set route-map-out "Advertise2AWS-Primary"
      set send-community standard
    next
    edit 164.254.96.33

      set soft-reconfiguration enable
      set remote-as 64513
      set route-map-out "Advertise2AWS-Secondary"
      set send-community standard
    next
  end
  <snip>
end

By the way you have two sets of neighborings:
164.254.38.182 (AS=64514) <-> 164.254.38.181 (AS=64513)
164.254.96.38 (AS=64516) <-> 164.254.96.33 (AS=64513)
Those are eBGP since AS numbers are different. And those two entities on the AWS side might be separated and connected over iBGP since the AS numbers are the same.

Toshi

 

Toshi_Esumi

And beyond this level, if you still can't get expecting routing behavior you want from the AWS side, you need to ask AWS support for help/troubleshooting.

Toshi

Toshi_Esumi

Also, since your local side is split into two FSWs, they need to share the routes for both local sides and ASW sides. Not only splitting the BGP config toward ASW on the local side, but also they need to be peering each other over eBGP (64514, 64516).

Toshi

Toshi_Esumi
SuperUser
SuperUser

Also if AWS side does load-balancing as described, you likely need to set below. I'm assuming it's eBGP not iBGP.

config router bgp
  set ebgp-multipath enable
end

Toshi

jasenu6
New Contributor

They are just two different way to manipulate routes. Prefix-lists for simple allow /deny, and route-maps for allow/deny, modification of metrics, next-hop, etc.

So you have both as an option, they can however still be used together, and the output from one is piped to the other. When applied inbound route-maps are applied first, when applied inbound prefix-lists are applied first.

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors