TechLibrary

Table of Contents

Guide That Contains This Content

[+] Expand All

[-] Collapse All

Understanding AIGP Policy Restrictions

This topic provides information about the AIGP policy restrictions when configuring AIGP in your network. Examples of each restriction are presented to show how the policy behaves.

Note: The examples in this topic are based on the topology illustrated in Advertisement of Multiple Paths in BGP in Example: Configuring the Accumulated IGP Attribute for BGP. Link protection is also used, which causes the bypass path to appear in the outputs. The following sample outputs might not correspond to the sample outputs shown in Example: Configuring the Accumulated IGP Attribute for BGP.

This topic contains the following sections:

Restriction 1: Neighbor Must Be AIGP-Enabled

For AIGP to be successfully implemented into your network, the neighbor of your AIGP-enabled device must also have AIGP enabled.

For example, Device PE2 advertises the prefix 55.0.0.0/24 with an AIGP value of 20.

user@PE2> show route advertising-protocol bgp
10.9.9.4 extensive | find 55.0.0.0/24

* 55.0.0.0/24 (1 entry, 1 announced)
 BGP group ebgp1 type External
     Route Label: 3
     Nexthop: 10.100.1.5
     Flags: Nexthop Change
     AS path: [7018] I
     AIGP: 20

However, neighbor Device PE4 does not have the AIGP attribute enabled under BGP, so it silently discards the AIGP attribute, as shown in the following output:

user@PE4> show route receive-protocol bgp 10.9.9.5
extensive | find 55.0.0.0/24

* 55.0.0.0/24 (1 entry, 1 announced)
     Accepted
     Route Label: 3
     Nexthop: 10.100.1.5
     AS path: 7018 I

As soon as AIGP is enabled on Device PE4 under the bgp-group hierarchy, the policy action takes effect and the AIGP attribute is received, as shown in the following output:

user@PE4> show route receive-protocol bgp 10.9.9.5
extensive | find 55.0.0.0/24

* 55.0.0.0/24 (1 entry, 1 announced)
     Accepted
     Route Label: 3	
     Nexthop: 10.100.1.5
     AS path: 7018 I
     AIGP: 20

Restriction 2: BGP Speaker Must Have an Export Policy to Advertise AIGP Metric

In this example, the BGP speaker, Device PE2, advertises prefix 55.0.0.0/24 without any AIGP attribute.

user@PE2> show route advertising-protocol bgp
10.9.9.4 extensive | find 55.0.0.0/24

* 55.0.0.0/24 (1 entry, 1 announced)
 BGP group ebgp1 type External
     Route Label: 3
     Nexthop: 10.100.1.5
     Flags: Nexthop Change
     AS path: [7018] I

Device PE4 receives prefix 55.0.0.0/24 from Device PE2 without any AIGP attribute.

user@PE4> show route receive-protocol bgp 10.9.9.5
extensive | find 55.0.0.0

* 55.0.0.0/24 (1 entry, 1 announced)
     Accepted
     Route Label: 3
     Nexthop: 10.100.1.5
     AS path: 7018 I

If the aigp-originate statement is used on Device PE4 as an import policy, it does not add an AIGP attribute to the prefix, as shown in the following examples:

user@PE4> show policy-options policy-statement aigp-import

term 10 {from {route-filter 55.0.0.0/24 exact;}then {aigp-originate distance 50;next-hop 10.100.1.5;accept;}}term 20 {then accept;}

user@PE4> show protocols bgp

group ebgp2 {type external;multihop;local-address 10.9.9.4;import aigp-import;family inet {labeled-unicast {aigp;}}export next-hop;peer-as 7018;multipath;neighbor 10.9.9.5;neighbor 10.9.9.6;}

As expected, the AIGP attribute is not added, and it does not appear in the following output from Device PE4:

user@PE4> show route receive-protocol bgp 10.9.9.5
extensive | find 55.0.0.0

* 55.0.0.0/24 (1 entry, 1 announced)
     Accepted
     Route Label: 3
     Nexthop: 10.100.1.5
     AS path: 7018 I

The extensive view of the 55.0.0.0/24 prefix on Device PE4 confirms that the AIGP attribute is absent.

user@PE4> show route 55.0.0.0 extensive

inet.0: 67 destinations, 82 routes (66 active, 0 holddown, 1 hidden)
55.0.0.0/24 (1 entry, 1 announced)
TSI:
KRT in-kernel 55.0.0.0/24 -> {indirect(1048575)}
Page 0 idx 0 Type 1 val 913d164
        *BGP    Preference: 170/-101
                Next hop type: Indirect
                Next-hop reference count: 7
                Source: 10.9.9.5
                Next hop type: Router, Next hop index: 608
                Next hop: 20.0.0.30 via fe-1/0/0.0 weight 0x1, selected
                Label operation: Push 0
                Label TTL action: prop-ttl
                Protocol next hop: 10.100.1.5
                Indirect next hop: 925c804 1048575
                State: <Active Ext>
                Local AS: 13979 Peer AS:  7018
                Age: 25         Metric2: 2 
                Task: BGP_7018.10.9.9.5+62727
                Announcement bits (3): 0-KRT 7-BGP_RT_Background 8-Resolve tree 2 
                AS path: 7018 I
                Accepted
                Route Label: 3
                Localpref: 100
                Router ID: 10.9.9.5
                Indirect next hops: 1
                        Protocol next hop: 10.100.1.5 Metric: 2
                        Indirect next hop: 925c804 1048575
                        Indirect path forwarding next hops: 1
                                Next hop type: Router
                                Next hop: 20.0.0.30 via fe-1/0/0.0 weight 0x1
                        10.100.1.5/32 Originating RIB: inet.3
                          Metric: 2                       Node path count: 1
                          Forwarding nexthops: 1
                                Nexthop: 20.0.0.30 via fe-1/0/0.0

Restriction 3: Prefix Must Have No Current AIGP Attribute

If the receiving prefix already has an AIGP attribute, the aigp-originate distance <value> statement in the policy does not take effect. In the following output, Device PE4 receives prefix 55.0.0.0 with an AIGP of 20:

user@PE4> show route receive-protocol bgp 10.9.9.5
extensive | find 55.0.0.0

* 55.0.0.0/24 (1 entry, 1 announced)
     Accepted
     Route Label: 3
     Nexthop: 10.100.1.5
     AS path: 7018 I
     AIGP: 20

The AIGP configuration does not take effect when Device PE4 has an export policy to set the AIGP attribute for prefix 55.0.0.0/24 to 30 before Device PE4 readvertises the prefix to its IBGP neighbor Device PE1, as shown in the following example:

user@PE4> show policy-options policy-statement aigp

term 10 {from {route-filter 55.0.0.0/24 exact;}then {aigp-originate distance 30;next-hop 10.100.1.4;accept;}}

The IGP metric value of 22 (IGP metric is 2 and AIGP metric is 20) is coded in the AIGP attribute when the route is readvertised to Device PE1. The AIGP metric did not change to 30, as configured under the policy on Device PE4.

user@PE4> show route advertising-protocol bgp
10.9.9.1 extensive | find 55.0.0.0

* 55.0.0.0/24 (1 entry, 1 announced)
 BGP group RR type Internal
     Route Label: 300128
     Nexthop: 10.100.1.4
     Flags: Nexthop Change
     Localpref: 100
     AS path: [13979] 7018 I
     AIGP: 22

Restriction 4: Prefix Must Be Exported With Next-Hop Self

For the policy to originate the AIGP metric, the next-hop address for the prefix should be local to the device. If the next hop is not local to the device, the AIGP metric is not advertised. In this case, the traceoptions flag normal configured under the protocols bgp hierarchy is used to determine why the expected AIGP is not advertised.

As shown in the following example, Device PE2 has an AIGP of 20 configured for prefix 55.0.0.1/24 under the export policy:

user@PE2> show policy-options policy-statement aigp

term 10 {from {route-filter 55.0.0.1/24 exact;}then {aigp-originate distance 20;next-hop 10.1.1.2;accept;}}

The 10.1.1.2 prefix does not belong to Device PE2, which is why the configured AIGP metric is not advertised to Device PE4 and does not appear in the following output:

user@PE2> show route advertising-protocol bgp
10.9.9.4 extensive | find 55.0.0.0/24

* 55.0.0.0/24 (1 entry, 1 announced)
 BGP group ebgp1 type External
     Route Label: 3
     Nexthop: 10.1.1.2
     Flags: Nexthop Change
     AS path: [7018] I

In the following example, the traceoptions are configured with the normal flag. With this configuration, the output shows why the AIGP attribute is not advertised/originated.

user@PE2> show log bgp | grep aigp

Mar  4 17:03:27.124902 AIGP 20 removed. group ebgp1 type External prefix: 55.0.0.0/24 
nexthop: 10.1.1.2 reason: originator, nexthop is not local

The same traceoptions configuration can be used if an AIGP metric is received but not readvertised due to a non-local next hop for that prefix. In the following output, Device PE4 receives prefix 55.0.0.0/24 with the AIGP metric from Device PE2:

user@PE4> show route receive-protocol bgp 10.9.9.5
extensive | find 55.0.0.0

* 55.0.0.0/24 (1 entry, 1 announced)
     Accepted
     Route Label: 3
     Nexthop: 10.100.1.5
     AS path: 7018 I
     AIGP: 20

Device PE4 has an export policy with a non-local next hop for this prefix, as shown in the following output:

user@PE4> show policy-options policy-statement aigp

term 5 {from {route-filter 55.0.0.0/24 exact;}then {next-hop 10.1.1.2;accept;}}

Since prefix 10.1.1.2 is not local to Device PE4, the AIGP metric is removed and not readvertised to the IBGP neighbor Device PE1, so it does not appear in the following output:

user@PE4> show route advertising-protocol bgp
10.9.9.1 extensive | find 55.0.0.0

* 55.0.0.0/24 (1 entry, 1 announced)
 BGP group RR type Internal
     Route Label: 300608
     Nexthop: 10.1.1.2
     Flags: Nexthop Change
     Localpref: 100
     AS path: [13979] 7018 I

Again, BGP tracing with the normal flag identifies why the AIGP metric is not being readvertised, as shown in the following output:

user@PE4> show log bgp | grep aigp

Mar  4 17:13:16.647857 AIGP 20 removed. group RR type Internal prefix: 55.0.0.0/24 nexthop: 10.1.1.2 reason: non-originator, nexthop not local, nexthop not same as received nexthop