Support Center > Search Results > SecureKnowledge Details
How to configure BGP Path Attributes on Gaia OS
Solution

Table of Contents:

  1. Background
  2. Introduction to BGP Path Attributes
    1. Well-known Path Attributes
      1. Mandatory
      2. Discretionary
    2. Optional Path Attributes
      1. Transitive
      2. Non-Transitive
  3. BGP Best Path Algorithm
  4. Configuration
    1. VRRP cluster and ClusterXL
    2. AS PATH Attribute
    3. AS PATH Prepend
    4. Local Preference
    5. Multi-Exit Discriminator
    6. BGP Communities
  5. Related documentation
  6. Related solutions

 

(I) Background

This article describes how to setup and use BGP 'AS_PATH' Attributes on Check Point Gaia OS.
This article focuses on configuration of 'AS_PATH' Attributes related to BGP.

It is assumed that administrator has basic knowledge of routing in general and BGP in particular.
For more details on BGP 'AS_PATH' Attributes, refer to RFC 4271 and other related BGP RFCs.

Before starting the configuration, administrator should be familiar with BGP and underlying features and their configurations such as static and dynamic routing, ClusterXL, VRRP cluster, SAM card configuration on 21000 appliances.
For more details, refer to "Related documentation" section.

 

(II) Introduction to BGP Path Attributes

Path attributes are used by BGP to determine a path to the network. Each BGP update consists of one or more networks and set of attributes attached to them. BGP uses path attributes to provide more information about each route and to help prevent routing loops in an arbitrary topology.

Administrator can also use path attributes to determine administrative preferences. BGP collapses routes with similar path attributes into a single update for advertisement. Routes that are received in a single update are re-advertised in a single update.

BGP always propagates the best path to the peers.

There are two types of Path Attributes:

  • Well-known Path Attributes - must be recognized by all BGP implementations
  • Optional Path Attributes - may or may not be supported by the BGP implementations

 

(II-1) Introduction - Well-known BGP Path Attributes

Note: Well-known Attributes must be recognized by all BGP implementations.

Well-known Attributes fall into two sub-categories:

  • Mandatory
  • Discretionary

 

  • (II-1-A) Well-known Mandatory BGP Path Attributes

    Mandatory attributes must be always included and carried in all BGP update messages to peers. The BGP implementation has to recognize the attribute, accept it and also advertise it to its peers.

    There are three Well-known Mandatory Attributes that must be present on all updates:

    1. ORIGIN Attribute

      When a router originates a route in BGP, it sets its Origin Attribute.

      The 'ORIGIN' Attribute can contain one of these three values:

      • IGP: Set if Network Layer Reachability Information (NLRI) was learnt from an internal routing protocol of the originating AS.

      • EGP: This Origin Attribute specifies that the NLRI was learnt from EGP.

      • Incomplete: Set when the NLRI was learnt from some other means, such as redistributed routes into BGP. The information to determine the 'Origin' for such routes (redistributed routes) is not complete since the origin of these routes cannot be determined.

      If BGP has multiple routes to a destination network, then Origin Attribute is one of the factors in determining the preferred route:

      • 'IGP' is the highest preferred 'ORIGIN' value.
      • 'EGP' is in the middle.
      • 'Incomplete' is the lowest preferred 'ORIGIN' value.


    2. AS_PATH Attribute

      'AS_PATH' Attribute gives a list of AS Numbers traversed when reaching to a destination. Every BGP speaker, when advertising a route to a peer, will include its own AS number in the NLRI. The subsequent BGP speakers, who advertise this route, will add their own AS number to the 'AS_PATH', the subsequent AS numbers get prepended to the list. The end result is the 'AS_PATH' attribute is able to describe all the Autonomous Systems it has traversed, beginning with the most recent AS and ending with the originating AS.

      BGP uses this mechanism to detect routing loops. Routers in an AS will reject the routes when its own AS number is detected in the route advertisement.

      'AS_PATH' can be used as a decision factor in route selection. By using "AS_PATH prepending" feature, administrator can influence the routing decision of BGP speakers in other Autonomous Systems. "AS path prepending" adds the local AS number to the current location in the AS path as many times as the administrator specifies.

    3. NEXT_HOP Attribute

      'NEXT_HOP' Attribute specifies the next hop IP address to reach the destination - the following set of rules has to be followed for different BGP scenarios:

      1. If the BGP Peers are in different Autonomous Systems, then the 'NEXT_HOP' IP address that will be sent in the update message will be the IP address of the advertising router.

      2. If the BGP peers are in the same Autonomous Systems (iBGP Peers), and the destination network being advertised in the update message is also in the same AS, then the 'NEXT_HOP' IP address that will be sent in the update message will be the IP address of the advertising router.

      3. If the BGP peers are in the same Autonomous Systems (iBGP Peers), and the destination network being advertised in the update message is in an external AS, then the 'NEXT_HOP' IP address that will be sent in the update message will be the IP address of the external peer router which sent the advertisement to this AS.


  • (II-1-B) Well-known Discretionary BGP Path Attributes

    Discretionary Attributes are recognized by the BGP implementation, but may or may not be sent in a specific 'UPDATE' message. It is up to the discretion of BGP Implementation to send or not to send these attributes in the update messages to the BGP peers.

    1. LOCAL_PREF

      'LOCAL_PREF' (Local Preference) Attribute is only used in updates sent to the iBGP Peers. It is not passed on to the BGP peers in other Autonomous Systems.

      This attribute specifies the BGP Speaker's degree of preference for an advertised route.

      The higher the value of Local Preference attribute the more preferred the route is.

      Note that the Local Preference will only affect the traffic leaving the AS.

    2. ATOMIC_AGGREGATOR

      'ATOMIC_AGGREGATOR' Attribute aggregates routes that are non-identical, but point to the same destination. In effect, it summarizes the routes when advertising them to the BGP peer.

      When a router receives routes for the same destination, it makes the best path decision by selecting the more specific path. When aggregation is performed, the BGP Speaker starts advertising the less specific routes to its peers, but the path detail information is lost in this process. Anytime a BGP speaker does this aggregation by summarizing more specific routes into a less specific route, it has to inform its downstream BGP peers that aggregation has been done - this is done by attaching the 'ATOMIC_AGGREGATE' attribute to the update message.

      When the downstream BGP speakers receive the route with 'ATOMIC_AGGREGATE' attribute set, then they cannot advertise the more specific routes for this aggregated route, and they will have to keep the 'ATOMIC_AGGREGATE' attribute attached when advertising this route to their BGP peers.

 

(II-2) Introduction - Optional BGP Path Attributes

Note: Optional attributes may or may not be supported by the BGP implementations.

Optional BGP Path attributes fall into two sub-categories:

  • Transitive
  • Non-Transitive

 

  • (II-2-A) Optional Transitive BGP Path Attributes

    BGP process has to accept the path, in which it is included, and should pass it on to other peers, even if these attributes are not supported. Meaning, if any optional attribute is not recognized by a BGP implementation, then BGP looks to check if the 'Transitive' flag is set. If this flag is set, then BGP implementation should accept the attribute and advertise it to its other BGP Peers.

    Gaia OS supports the Optional Transitive Attribute called 'COMMUNITY':

    1. BGP communities allow administrator to apply a common routing policy across multiple BGP peers that are in the same group.

      This attribute simplifies the policy enforcement by grouping a set of BGP peers with common properties to share a common set of policy.

      Routing decisions are based on the identity of the group or community. To implement this feature, administrator should map a set of communities to certain BGP local preference values. Then administrator can apply a uniform BGP configuration to the community as a whole as opposed to each router within the community. The routers in the community can accept/restrict routes that match their community values.

      Range of values for the 'COMMUNITY' attribute:

      • from 0x0000000 to 0x0000FFFF [0 - 65535]
      • from 0xFFFF0000 to 0xFFFFFFFF [4294901760 - 4294967295] - are reserved

      Some of the well-known communities are:

      Community Attribute Hex Value Description
      NO_ADVERTISE 0xFFFFFF02 Not advertised outside a BGP confederation boundary.
      A stand-alone Autonomous System that is not part of a confederation should be considered a confederation itself.
      NO_EXPORT 0xFFFFFF01 Not advertised to other BGP peers.
      NO_EXPORT_SUBCONFED 0xFFFFFF03 Not advertised to external BGP peers.
      This includes peers in other members' Autonomous Systems inside a BGP confederation.

      For further details, refer to RFC 1997 and RFC 1998.

      A route can carry more than one community attribute and the BGP peer that receives such a route with multiple community attributes can act based on one, some or all of the community attributes. A router can also add or modify the community attributes before passing them to other BGP peers.


  • (II-2-B) Optional Non-Transitive BGP Path Attributes

    If the 'Transitive' flag is not set, then BGP implementation can quietly ignore the attribute, it does not have to accept and advertise this attribute to its other peers.

    Gaia OS supports Non-transitive Attribute called 'MULTI_EXIT_DISC' ('MED'):

    1. 'Multi-exit Discriminator' (MED) values are used to help external neighbors decide which of the available entry points into an AS are preferred. A lower MED value is preferred over a higher MED value and breaks the tie between two or more preferred paths.

      Note that MED is not passed beyond the receiving AS. It is only used to influence traffic between two directly connected Autonomous Systems. In addition, MED is never compared when the routes to the same destination are received from two or more different Autonomous Systems. MED only applies to the routes advertised by a single Autonomous System.

      Note: A BGP session does not accept MEDs from an external peer, unless the 'Accept MED' field is set for an external peer.

      The following table summarizes the configurable path attributes and their definitions:

      BGP Attribute Description
      AS_PATH Identifies the Autonomous Systems, through which routing information carried in an 'UPDATE' message passed. Components of this list can be AS_SETs or AS_SEQUENCES.
      NEXT_HOP Defines the IP address of the border router that should be used as the next hop to the destinations listed in the 'UPDATE' message.
      MULTI_EXIT_DISC Discriminates among multiple exit or entry points to the same neighboring Autonomous System. Used only on external links.
      LOCAL_PREF Determines which external route should be taken and is included in all iBGP 'UPDATE' messages. The assigned BGP speaker sends this message to BGP speakers within its own Autonomous System, but not to neighboring Autonomous Systems. Higher values of a 'LOCAL_PREF' are preferred.
      ATOMIC_AGGREGATE Specifies to a BGP speaker that a less specific route was chosen over a more specific route. The BGP speaker attaches the 'ATOMIC_AGGREGATE' attribute to the route when it reproduces it to other BGP speakers. The BGP speaker that receives this route cannot remove the 'ATOMIC_AGGREGATE' attribute or make any Network Layer Reachability Information (NLRI) of the route more specific. This attribute is used only for debugging purposes.

 

(III) BGP Best Path Algorithm

BGP Best Path Algorithm selects the first valid path in the list of valid paths as the current best path. It then compares the best path with the next path in the list, until BGP reaches the end of the list of valid paths.

BGP Best Path Algorithm uses the following rules to determine the best path:

  1. Prefer the path with the highest Local Preference ('LOCAL_PREF' has a value of 100 by default).

  2. Prefer the path with the shortest 'AS_PATH'.

  3. Prefer the path with the lowest origin type (IGP (lowest) < EGP < INCOMPLETE (highest)).

  4. Prefer the path with the lowest MED

    Notes:

    • When ECMP is disabled, MED is compared only if the first (the neighboring) Autonomous System is the same in the two paths. When ECMP is enabled, this check is skipped.
    • Gaia OS supports MED values from 0 to 2147483646. The advertised MED should belong to this range.
    • Paths received with MED value of "-1" (which means "No MED") will not be compared.


  5. Prefer eBGP over iBGP paths.

  6. Prefer the path with the lowest IGP metric to the BGP next hop (only works for iBGP).

  7. Prefer the route that comes from the BGP router with the lowest router ID.

 

(IV) Configuration

(IV-1) Configuration in VRRP cluster and ClusterXL

The following sections will cover configuration for BGP Path Attributes. The configuration of these attributes must be identical on all members of VRRP cluster or ClusterXL.

Notes:

 

(IV-2) Configuration of BGP AS PATH Attribute

The example below explains how 'AS_PATH' can be used to selectively accept routes based on AS:

  • R1 is configured to redistribute network 172.20.0.0/16 to AS 100 (via R2)
  • R2 is configured to redistribute route 172.20.0.0/16 received from AS 50 (via R1) to AS 30 (via R3)
  • R3 is configured with BGP policy to accept only network 172.20.0.0/16 from AS 50 (received from R2)

Configuration

  1. Configuration of R1:

    We need to redistribute static route 172.20.0.0/16 into AS 100 via R2 using routemaps.

    • In Gaia Portal

      1. Go to "Advanced Routing" - click on "Route Redistribution"

      2. Click on "Add Redistribution From" button - select "BGP based on AS"

      3. In "To Protocol" field, select "BGP AS 100"

      4. In "From Protocol" field, select "Static"

      5. In "Static Route" field, select "172.20.0.0/16"

      6. (Optional) In "Metric" field, enter the desired value

    • In Clish

      set routemap ToPeer-R2 id 10 on
      set routemap ToPeer-R2 id 10 allow
      set routemap ToPeer-R2 id 10 match network 172.20.0.0/16 all
      set routemap ToPeer-R2 id 10 match protocol static
      set bgp external remote-as 100 export-routemap ToPeer-R2 preference 1 family inet on
      save config
      
  2. Configuration of R2:

    We need to redistribute route 172.20.0.0/16 received from AS 50 (via R1) to AS 30 (via R3) using routemaps.

    • In Gaia Portal

      Step 1: Accept routes received from AS 50 (via R1):

      1. Go to "Advanced Routing" - click on "Inbound Route Filters"

      2. Click on "Add" button - select "Add BGP Policy (Based on AS)"

      3. In "Add BGP Policy", enter the policy number between 512-1024

      4. In "Action" field, select "Accept" (to accept the route from AS 50)

      5. Administrator can also change other optional parameters:
        • LOCAL_PREF for this policy
        • LOCAL_PREF for all Inbound filter policies
        • Weight for all Inbound filter policies

      Step 2: Redistribute static route 172.19.0.0/16 on R2 into AS 30

      1. Go to "Advanced Routing" - click on "Route Redistribution"

      2. Click on "Add Redistribution From" button - select "Static"

      3. In "To Protocol" field, select "BGP AS 30"

      4. In "Static Route" field, select "172.19.0.0/16"

      5. (Optional) In "Metric" field, enter the desired value

      Step 3: Redistribute network 172.20.0.0/16 into AS 30 via R2

      1. Go to "Advanced Routing" - click on "Route Redistribution"

      2. Click on "Add Redistribution From" button - select "BGP based on AS"

      3. In "To Protocol" field, select "BGP AS 30"

      4. In "Route", either enter a range in "Address Range" (and select "Match Type"), or select "All" for redistributing routes to AS 30

      5. In "Action" field, select "Accept" to allow the network to redistribute (Note: Selecting "Restrict" will not redistribute the network (or network range))

      6. (Optional) In "Metric" field, enter the desired value

    • In Clish

      Step 1: Accept routes received from AS 50 (via R1)

      set routemap FromPeer-R1 id 10 on
      set routemap FromPeer-R1 id 10 allow
      set bgp external remote-as 50 import-routemap FromPeer-R1 preference 1 family inet on
      save config
      

      Step 2: Redistribute static route 172.19.0.0/16 on R2 into AS 30

      set routemap ToPeer-R3 id 10 on
      set routemap ToPeer-R3 id 10 allow
      set routemap ToPeer-R3 id 10 match network 172.19.0.0/16 all
      set routemap ToPeer-R3 id 10 match protocol static
      set bgp external remote-as 30 export-routemap ToPeer-R3 preference 1 family inet on
      save config
      

      Step 3: Redistribute network 172.20.0.0/16 into AS 30 via R2

      set routemap ToPeer-R3 id 20 on
      set routemap ToPeer-R3 id 20 allow
      set routemap ToPeer-R3 id 20 match network 172.20.0.0/16 all
      set routemap ToPeer-R3 id 20 match protocol bgp
      set bgp external remote-as 30 export-routemap ToPeer-R3 preference 1 family inet on
      save config
      
  3. Configuration of R3:

    We need to match AS 50 to accept routes originating from AS 50 and reject routes originating from AS 100.

    • In Gaia Portal

      Inbound route filters policy: match AS 50 to accept routes originating from AS 50 only

      Regular Expressions can be used for matching AS in the AS_PATH

      1. Go to "Advanced Routing" - click on "Inbound Route Filters"

      2. Click on "Add" button - select "Add BGP Policy (Based on AS-PATH)"

      3. In "Add BGP Policy":
        • enter the policy number between 1-511
        • type the AS-Path Regular Expression (in our example, "_50")
        • select the Origin (in our example, "Any")


      4. In "Action" field, select "Accept" (to accept the route with AS_PATH 50)

    • In Clish

      set routemap FromPeer-R2 id 10 on
      set routemap FromPeer-R2 id 10 allow
      set routemap FromPeer-R2 id 10 match aspath-regex "_50" origin any
      set routemap FromPeer-R2 id 20 on
      set routemap FromPeer-R2 id 20 restrict
      set routemap FromPeer-R2 id 20 match aspath-regex "100" origin any
      set bgp external remote-as 100 import-routemap FromPeer-R2 preference 1 family inet on
      save config
      

Verification

  1. On R2 - Verify the route appears in routing table:

    R2> show route bgp
    
    Codes: C - Connected, S - Static, R - RIP, B - BGP,
           O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA)
           A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,
           U - Unreachable, i - Inactive
    
    B         172.20.0.0/16       via 10.40.1.1, eth2, cost -1, age 10389  
    R2>
    
  2. On R3 - Verify that route appears in routing table:

    R3> show route bgp
    
    Codes: C - Connected, S - Static, R - RIP, B - BGP,
           O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA)
           A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,
           U - Unreachable, i - Inactive
    
    B         172.20.0.0/16       via 10.22.1.6, eth1, cost -1, age 5307  
    R3>
    
  3. On R3 - Check the 'AS_PATH':

    R3> show route bgp aspath 
    
    Prefix               Nexthop              AsPath  
    
    172.20/16            10.22.1.6            (30),100,50,IGP.(Id-4)  
    R3>
    

 

(IV-3) Configuration of BGP AS PATH Prepend

Autonomous System Path prepending helps administrator to use 'AS_PATH' as a decision factor in selection of routes in other Autonomous Systems. "AS path prepending" adds the local AS number to the current location in the AS path as many times as the administrator specifies.

In he example below:

  • R1 is configured to redistribute network 172.19.0.0/16 with 'AS_PATH' prepend count 2
  • R2 is configured to redistribute network 172.19.0.0/16 with 'AS_PATH' prepend count 10
  • R3 receives advertises from R1 and R2 for network 172.19.0.0/16, but because 'AS_PATH' in R2's advertisement is higher than 'AS_PATH' in R1's advertisement, R3 selects R1 as next hop gateway for 172.19.0.0/16 network

Configuration

  1. Configuration of R3:

    We need to accept routes from AS 100.

    • In Gaia Portal

      1. Go to "Advanced Routing" - click on "Inbound Route Filters"

      2. Click on "Add" button - select "Add BGP Policy (Based on AS)"

      3. In "Add BGP Policy", enter policy number between 512-1024 and enter AS Number (in our example, AS 100)

      4. In "Action" field, select "Accept" (to accept the route from AS 100)

      5. Click on "Save" button

    • In Clish

      set routemap FromPeer-R1R2 id 10 on
      set routemap FromPeer-R1R2 id 10 allow
      set bgp external remote-as 100 import-routemap FromPeer-R1R2 preference 1 family inet on
      save config
      
  2. Configuration of R2:

    Configuration is performed only in Clish. We use route redistribution routemap called "ToPeer-R3".

    set routemap ToPeer-R3 id 10 on
    set routemap ToPeer-R3 id 10 allow
    set routemap ToPeer-R3 id 10 match network 172.19.0.0/16 all
    set routemap ToPeer-R3 id 10 match protocol static
    set routemap ToPeer-R3 id 10 action aspath-prepend-count 10
    set bgp external remote-as 30 export-routemap ToPeer-R3 preference 1 family inet on
    save config
    

    When R1 is Down, the following BGP peers are shown on R3:

    R3> show bgp peers
    
    Flags: R - Peer restarted, W - Waiting for End-Of-RIB from Peer
    
    PeerID        AS     Routes  ActRts  State             InUpds  OutUpds  Uptime
    10.22.1.6     100    1       1       Established       1       0        00:00:21
    10.30.1.6     100    0       0       Active            0       0        00:00:00
    

    In addition, notice that R3 has received 'ASPATH' with 10 counts of AS 100:

    R3> show route bgp detailed
    
    Route: 172.19/16
        Nexthop: 10.22.1.6
        Metric: -1
        LocalPref: 100
        Interface: eth1
        Age: 34
        Rank: 170
        Weight: 0
        ASPATH: (30),100,100,100,100,100,100,100,100,100,100,IGP.(Id-3)
        LocalAS: 30
        PeerAS: 100
        Origin: IGP
        OriginatorID: 10.22.1.6
    R3>
    
  3. Configuration of R1:

    Configuration is performed only in Clish. We use route redistribution routemap called "ToPeer-R3".

    set routemap ToPeer-R3 id 10 on
    set routemap ToPeer-R3 id 10 allow
    set routemap ToPeer-R3 id 10 match network 172.19.0.0/16 all
    set routemap ToPeer-R3 id 10 match protocol static
    set routemap ToPeer-R3 id 10 action aspath-prepend-count 2
    set bgp external remote-as 30 export-routemap ToPeer-R3 preference 1 family inet on
    save config
    

    When both R1 and R2 are UP and advertising network 172.19.0.0/16, the following BGP peers are shown on R3:

    R3> show bgp peers
    
    Flags: R - Peer restarted, W - Waiting for End-Of-RIB from Peer
    
    PeerID        AS     Routes  ActRts  State             InUpds  OutUpds  Uptime
    10.22.1.6     100    1       0       Established       1       0        00:07:26
    10.30.1.6     100    1       1       Established       2       0        00:06:26
    R3>
    

    In addition, notice that BGP on R3 selects R1 as next hop gateway for 172.19.0.0/16 network:

    R3> show route bgp detailed
    
    Route: 172.19/16
        Nexthop: 10.30.1.6
        Metric: -1
        LocalPref: 100
        Interface: eth2
        Age: 10
        Rank: 170
        Weight: 0
        ASPATH: (30),100,100,IGP.(Id-5)
        LocalAS: 30
        PeerAS: 100
        Origin: IGP
        OriginatorID: 10.30.1.6
    R3>
    
    R3> show route bgp
    
    Codes: C - Connected, S - Static, R - RIP, B - BGP,
           O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),
           A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,
           U - Unreachable, i - Inactive
    
    B         172.19.0.0/16       via 10.30.1.6, eth2, cost -1, age 28
    R3>
    

 

(IV-4) Configuration of BGP Local Preference

Local Preference determines which is the preferred exit point for external route and is included in all iBGP 'UPDATE' messages. The higher the value of Local Preference attribute, the more preferred the route is. Note that Local Preference will only affect the traffic leaving the Autonomous System.

In the example below, R3 advertises two networks 172.16.22.0/24 and 172.16.40.0/24 into As 100 via R1 and R2.
By applying higher value of Local Preference on R2, administrator can ensure that traffic from AS 100 to AS 30 networks will be forwarded by R2 over R2-R3 link.

Configuration

  1. Configuration of R3:

    • In Gaia Portal

      Step 1: Redistribute network 172.16.22.0/24 to AS 100

      1. Go to "Advanced Routing" - click on "Route Redistribution"

      2. Click on "Add Redistribution From" button - select "Static"

      3. In "To Protocol" field, select "BGP AS 100"

      4. In "Static Route" field, select "172.16.22.0.0/24"

      5. (Optional) In "Metric" field, enter the desired value

      Step 2: Redistribute static route 172.16.40.0/24 to AS 100

      1. Go to "Advanced Routing" - click on "Route Redistribution"

      2. Click on "Add Redistribution From" button - select "Static"

      3. In "To Protocol" field, select "BGP AS 100"

      4. In "Static Route" field, select "172.16.40.0/24"

      5. (Optional) Enter the same "Metric" value as was entered for 172.16.22.0/24

    • In Clish

      set routemap ToPeer-R1R2 id 10 on
      set routemap ToPeer-R1R2 id 10 allow
      set routemap ToPeer-R1R2 id 10 match network 172.16.22.0/24 all
      set routemap ToPeer-R1R2 id 10 match network 172.16.40.0/24 all
      set routemap ToPeer-R1R2 id 10 match protocol direct
      set bgp external remote-as 100 export-routemap ToPeer-R1R2 preference 1 family inet on
      save config
      
  2. Configuration of R1:

    We set the Local Preference value 10 to AS 30 routes.

    • In Gaia Portal

      1. Go to "Advanced Routing" - click on "Inbound Route Filters"

      2. Click on "Add" button - select "Add BGP Policy (Based on AS)"

      3. In "Add BGP Policy", enter policy number between 512-1024, and enter AS Number (in our example, AS 30)

      4. In "Action" field, select "Accept" (to accept the route from AS 30)

      5. In "LOCAL_PREF" field, enter 10 (default value is 100)

    • In Clish

      set routemap FromPeer-R3 id 10 on
      set routemap FromPeer-R3 id 10 allow
      set routemap FromPeer-R3 id 10 match network 172.16.22.0/24 all
      set routemap FromPeer-R3 id 10 match network 172.16.40.0/24 all
      set routemap FromPeer-R3 id 10 action localpref 10
      set bgp external remote-as 30 import-routemap FromPeer-R3 preference 1 family inet on
      save config
      
  3. Configuration of R2:

    We set the Local Preference value 20 to AS 30 routes.

    • In Gaia Portal

      1. Go to "Advanced Routing" - click on "Inbound Route Filters"

      2. Click on "Add" button - select "Add BGP Policy (Based on AS)"

      3. In "Add BGP Policy", enter policy number between 512-1024, and enter the AS Number (in our example, AS 30)

      4. In "Action" field, select "Accept" (to accept the route from AS 30)

      5. In "LOCAL_PREF" field, enter 20 (default value is 100)

    • In Clish

      set routemap FromPeer-R3 id 10 on
      set routemap FromPeer-R3 id 10 allow
      set routemap FromPeer-R3 id 10 match network 172.16.22.0/24 all
      set routemap FromPeer-R3 id 10 match network 172.16.40.0/24 all
      set routemap FromPeer-R3 id 10 action localpref 20
      set bgp external remote-as 30 import-routemap FromPeer-R3 preference 1 family inet on
      save config
      

Verification

  1. On R1 - Verify that route appears in routing table:

    R1> show route bgp
    
    Codes: C - Connected, S - Static, R - RIP, B - BGP,
           O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),
           A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,
           U - Unreachable, i - Inactive
    
    B         172.16.22.0/24          via 10.30.1.5, eth1, cost -1, age 4  
    B         172.16.40.0/24          via 10.30.1.5, eth1, cost -1, age 4  
    R1>
    
    R1> show route bgp detailed
    
    Route: 172.16.22/24
        Nexthop: 10.30.1.5
        Metric: -1
        LocalPref: 10
        Interface: eth1
        Age: 21
        Rank: 170
        Weight: 0
        ASPATH: (100),30,IGP.(Id-11)
        LocalAS: 100
        PeerAS: 30
        Origin: IGP
        OriginatorID: 10.22.1.5
    Route: 172.16.40/24
        Nexthop: 10.30.1.5
        Metric: -1
        LocalPref: 10
        Interface: eth1
        Age: 21
        Rank: 170
        Weight: 0
        ASPATH: (100),30,IGP.(Id-11)
        LocalAS: 100
        PeerAS: 30
        Origin: IGP
        OriginatorID: 10.22.1.5
    R1> 
    
  2. On R2 - Verify that route appears in routing table:

    R2> show route bgp
    
    Codes: C - Connected, S - Static, R - RIP, B - BGP,
           O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),
           A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,
           U - Unreachable, i - Inactive
    
    B         172.16.22.0/24          via 10.22.1.5, eth1, cost -1, age 26  
    B         172.16.40.0/24          via 10.22.1.5, eth1, cost -1, age 26  
    R2> 
    
    R2> show route bgp detailed
    
    Route: 172.16.22/24
        Nexthop: 10.22.1.5
        Metric: -1
        LocalPref: 20
        Interface: eth1
        Age: 124
        Rank: 170
        Weight: 0
        ASPATH: (100),30,IGP.(Id-14)
        LocalAS: 100
        PeerAS: 30
        Origin: IGP
        OriginatorID: 10.22.1.5
    Route: 172.16.40/24
        Nexthop: 10.22.1.5
        Metric: -1
        LocalPref: 20
        Interface: eth1
        Age: 124
        Rank: 170
        Weight: 0
        ASPATH: (100),30,IGP.(Id-14)
        LocalAS: 100
        PeerAS: 30
        Origin: IGP
        OriginatorID: 10.22.1.5
    R2>
    

 

(IV-5) Configuration of BGP Multi-Exit Discriminator

The Multi-Exit Discriminator (MED) is used to suggest to an external AS the preferred route into the Autonomous System.

In the example below:

  • R1 is advertising route 172.19.0.0/16 with MED 10
  • R2 is advertising route 172.19.0.0/16 with MED 20

Since lower value is preferred, R3 in AS 30 will select route from R1 for network 172.19.0.0/16.

Notes:

  • Gaia OS supports MED values from 0 to 2147483646. The advertised MED should belong to this range.
  • MEDs are advertised throughout the local Autonomous System.

Configuration

  1. Configuration of R1:

    We redistribute route 172.19.0.0/16 to AS 30.

    • In Gaia Portal

      1. Go to "Advanced Routing" - click on "Route Redistribution"

      2. Click on "Add Redistribution From" button - select "Static"

      3. In "To Protocol" field, select "BGP AS 30"

      4. In "Static Route" field, select "172.19.0.0.0/16"

      5. In "Metric" field, enter 10

    • In Clish

      set routemap ToPeer-R3 id 10 on
      set routemap ToPeer-R3 id 10 allow
      set routemap ToPeer-R3 id 10 match network 172.19.0.0/16 all
      set routemap ToPeer-R3 id 10 match protocol direct
      set routemap ToPeer-R3 id 10 action metric value 10
      set bgp external remote-as 30 export-routemap ToPeer-R3 preference 1 family inet on
      save config
      
  2. Configuration of R2:

    We redistribute route 172.19.0.0/16 to AS 30.

    • In Gaia Portal

      1. Go to "Advanced Routing" - click on "Route Redistribution"

      2. Click on "Add Redistribution From" button - select "Static"

      3. In "To Protocol" field, select "BGP AS 30"

      4. In "Static Route" field, select "172.19.0.0.0/16"

      5. In "Metric" field, enter 20

    • In Clish

      set routemap ToPeer-R1 id 10 on
      set routemap ToPeer-R1 id 10 allow
      set routemap ToPeer-R3 id 10 match network 172.19.0.0/16 all
      set routemap ToPeer-R3 id 10 match protocol direct
      set routemap ToPeer-R3 id 10 action metric value 20
      set bgp external remote-as 30 export-routemap ToPeer-R3 preference 1 family inet on
      save config
      
  3. Configuration of R2:

    Configuration is performed only in Clish. We import routes from AS 100.
    For MED to work on R3, 'accept-med' should be enabled on R3 for both BGP peers.

    set routemap FromPeer-R1R2 id 10 on
    set routemap FromPeer-R1R2 id 10 allow
    set routemap FromPeer-R1R2 id 10 match network 172.19.0.0/16 all
    set bgp external remote-as 100 peer 10.22.1.6 accept-med on
    set bgp external remote-as 100 peer 10.30.1.6 accept-med on
    set bgp external remote-as 100 import-routemap FromPeer-R1R2 preference 1 family inet on
    save config
    

Verification

  1. On R1 - Verify it is sending MED value of 10:

    R1> show bgp peer 10.30.1.5 advertise
    
    IPv4 Route          MED         LocalPref     Nexthop          Communities  
    172.19/16           10          0             10.30.1.6
    R1>
    
  2. On R2 - Verify it is sending MED value of 20:

    R2> show bgp peer 10.22.1.5 advertise
    
    IPv4 Route          MED         LocalPref     Nexthop          Communities  
    172.19/16           20          0             10.22.1.6
    R2>
    
  3. On R3 - Verify it is receiving correct MED values:

    R3> show bgp peer 10.30.1.6 received
    
    IPv4 Route          MED         LocalPref     Nexthop          Communities  
    172.19/16           10          N/A(EBGP)     10.30.1.6
    R3>
    
    R3> show bgp peer 10.22.1.6 received
    
    IPv4 Route          MED         LocalPref     Nexthop          Communities  
    172.19/16           20          N/A(EBGP)     10.22.1.6
    R3>
    
  4. On R3 - Verify that route 172.19.0.0/16 is pointing to R1 (10.30.1.6):

    R3> show route bgp
    
    Codes: C - Connected, S - Static, R - RIP, B - BGP,
           O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),
           A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,
           U - Unreachable, i - Inactive
    
    B         172.19.0.0/16       via 10.30.1.6, eth2, cost 10, age 295
    R3>
    

 

(IV-6) Configuration of BGP Communities

In BGP Communities configuration, routing decisions are based on the identity of the group or community. To implement this feature, administrator should map a set of communities to certain BGP local preference values. Then administrator can apply a uniform BGP configuration to the community as a whole as opposed to each router within the community. The routers in the community can capture routes that match their community values.

BGP Communities can be configured in Clish and using the 'routemap' command.

The example below shows how BGP communities can be used to filter routes, which can later be used by peers to set specific policy for those routes.

Example of Named Communities:

Administrator needs inbound traffic from AS 100 destined to 172.16.22.0/24 to come over R2-R3 link. However, in case of failure of R2, the traffic should come on R1-R3 link. To achieve this policy, we can use 'Community Attribute'.

In this setup, two communities have been used:

  • Community ID (AS:Community) 30:300
  • Community ID (AS:Community) 30:250

Clarifications:

  • R3 announces network 172.16.22.0/24 with prefix community attribute 30:300 and 172.16.40.0/24 with prefix community attribute 30:250 to R1 and R2.
  • R1 and R2 filter network 172.16.22.0/24 with Community ID 30:300, while R1 applies 'LocalPref' of 10 and R2 applies 'LocalPref' of 20 to this network.
  • Since higher value of 'LocalPref' is preferred, traffic towards 172.16.22.0/24 is sent via R2, except when R2 fails, the traffic can pass via R1.
  • 172.16.40.0/24 with prefix community attribute 30:250 is rejected as R1 and R2 do not belong to community 250.

Configuration:

  1. Configuration of R3:

    Configuration is performed only in Clish using routemaps.

    set bgp communities on 
    set routemap ToPeers-R1R2 id 10 on
    set routemap ToPeers-R1R2 id 10 allow
    set routemap ToPeers-R1R2 id 10 match network 172.16.22.0/24 all
    set routemap ToPeers-R1R2 id 10 match protocol direct
    set routemap ToPeers-R1R2 id 10 action community 300 as 30 on
    set routemap ToPeers-R1R2 id 20 on
    set routemap ToPeers-R1R2 id 20 allow
    set routemap ToPeers-R1R2 id 20 match network 172.16.40.0/24 all
    set routemap ToPeers-R1R2 id 20 match protocol direct
    set routemap ToPeers-R1R2 id 20 action community 250 as 30 on
    set bgp external remote-as 100 export-routemap ToPeers-R1R2 preference 1 family inet on
    save config
    
  2. Configuration of R1:

    We match community 300 on AS 30 and apply 'LOCAL_PREF' of 10.

    • In Gaia Portal

      1. Go to "Advanced Routing" - click on "Inbound Route Filters"

      2. Click on "Add" button - select "Add BGP Policy (Based on AS)"

      3. In "Add BGP Policy", enter the policy number between 512-1024, and enter the AS Number (in our example, AS 30)

      4. In "Action" field, select "Accept" (to accept the route from AS 30)

      5. In "LOCAL_PREF" field, enter 10

    • In Clish

      set bgp communities on 
      set routemap FromPeer-R3 id 10 on
      set routemap FromPeer-R3 id 10 allow
      set routemap FromPeer-R3 id 10 match community 300 as 30 on
      set routemap FromPeer-R3 id 10 action localpref 10
      set bgp external remote-as 30 import-routemap FromPeer-R3 preference 1 family inet on
      save config
      
  3. Configuration of R2:

    We match community 300 on AS 30 and apply LOCAL_PREF of 20.

    • In Gaia Portal

      1. Go to "Advanced Routing" - click on "Inbound Route Filters"

      2. Click on "Add" button - select "Add BGP Policy (Based on AS)"

      3. In "Add BGP Policy", enter the policy number between 512-1024, and enter the AS Number (in our example, AS 30)

      4. In "Action" field, select "Accept" (to accept the route from AS 30)

      5. In "LOCAL_PREF" field, enter 20

    • In Clish

      set bgp communities on 
      set routemap FromPeer-R1 id 10 on
      set routemap FromPeer-R1 id 10 allow
      set routemap FromPeer-R1 id 10 match community 300 as 30 on
      set routemap FromPeer-R1 id 10 action localpref 20
      set bgp external remote-as 30 import-routemap FromPeer-R1 preference 1 family inet on
      save config
      

Verification

Note: BGP Community Attribute is presented in format "AA:NN", where the first part ("AA") is the AS number, and the second part ("NN") is a 2-byte community number.

  1. On R1, run these commands:

    R1> show route bgp
    
    Codes: C - Connected, S - Static, R - RIP, B - BGP,
           O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),
           A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,
           U - Unreachable, i - Inactive
    
    B         172.16.22.0/24          via 10.30.1.5, eth1, cost -1, age 10  
    R1>
    
    R1> show route bgp detailed 
    
    Route: 172.16.22/24
        Nexthop: 10.30.1.5
        Metric: -1
        LocalPref: 10
        Interface: eth1
        Age: 28
        Rank: 170
        Weight: 0
        ASPATH: (100),30,IGP.(Id-6),comm-30.300
        LocalAS: 100
        PeerAS: 30
        Origin: IGP
        OriginatorID: 10.22.1.5
        Communities: 30:300
    R1>
    
  2. On R2, run these commands:

    R2> show route all
    
    Codes: C - Connected, S - Static, R - RIP, B - BGP,
           O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),
           A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,
           U - Unreachable, i - Inactive
    
    B         172.16.22.0/24          via 10.22.1.5, eth1, cost -1, age 4347  
    R2>
    
    R2> show route bgp detailed 
    
    Route: 172.16.22/24
        Nexthop: 10.22.1.5
        Metric: -1
        LocalPref: 20
        Interface: eth1
        Age: 5901
        Rank: 170
        Weight: 0
        ASPATH: (100),30,IGP.(Id-9),comm-30.300
        LocalAS: 100
        PeerAS: 30
        Origin: IGP
        OriginatorID: 10.22.1.5
        Communities: 30:300
    R2>
    

Traffic from AS 100 to AS 30 will go via R2 over R2-R3 link. However, if R2 fails, the traffic will flow via R1 over R1-R3 link.

 

 

Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment