Example: Configuring the Accumulated IGP Attribute for BGP

 

Understanding the Accumulated IGP Attribute for BGP

The interior gateway protocols (IGPs) are designed to handle routing within a single domain or an autonomous system (AS). Each link is assigned a particular value called a metric. The distance between the two nodes is calculated as a sum of all the metric values of links along the path. The IGP selects the shortest path between two nodes based on distance.

BGP is designed to provide routing over a large number of independent ASs with limited or no coordination among respective administrations. BGP does not use metrics in the path selection decisions.

The accumulated IGP (AIGP) metric attribute for BGP enables deployment in which a single administration can run several contiguous BGP ASs. Such deployments allow BGP to make routing decisions based on the IGP metric. In such networks, it is possible for BGP to select paths based on metrics as is done by IGPs. In this case, BGP chooses the shortest path between two nodes, even though the nodes might be in two different ASs.

The AIGP attribute is particularly useful in networks that use tunneling to deliver a packet to its BGP next hop. The Juniper Networks® Junos® operating system (Junos OS) currently supports the AIGP attribute for two BGP address families, family inet labeled-unicast and family inet6 labeled-unicast.

AIGP impacts the BGP best-route decision process. The AIGP attribute preference rule is applied after the local-preference rule. The AIGP distance is compared to break a tie. The BGP best-route decision process also impacts the way the interior cost rule is applied if the resolving next hop has an AIGP attribute. Without AIGP enabled, the interior cost of a route is based on the calculation of the metric to the next hop for the route. With AIGP enabled, the resolving AIGP distance is added to the interior cost.

The AIGP attribute is an optional non-transitive BGP path attribute and is specified in Internet draft draft-ietf-idr-aigp-06, The Accumulated IGP Metric Attribute for BGP.

Example: Configuring the Accumulated IGP Attribute for BGP

This example shows how to configure the accumulated IGP (AIGP) metric attribute for BGP.

Requirements

This example uses the following hardware and software components:

  • Seven BGP-speaking devices.

  • Junos OS Release 12.1 or later.

Overview

The AIGP attribute enables deployments in which a single administration can run several contiguous BGP autonomous systems (ASs). Such deployments allow BGP to make routing decisions based on the IGP metric. With AIGP enabled, BGP can select paths based on IGP metrics. This enables BGP to choose the shortest path between two nodes, even though the nodes might be in different ASs. The AIGP attribute is particularly useful in networks that use tunneling to deliver a packet to its BGP next hop. This example shows AIGP configured with MPLS label-switched paths.

To enable AIGP, you include the aigp statement in the BGP configuration on a protocol family basis. Configuring AIGP on a particular family enables sending and receiving of the AIGP attribute on that family. By default, AIGP is disabled. An AIGP-disabled neighbor does not send an AIGP attribute and silently discards a received AIGP attribute.

Junos OS supports AIGP for family inet labeled-unicast and family inet6 labeled-unicast. The aigp statement can be configured for a given family at the global BGP, group, or neighbor level.

By default, the value of the AIGP attribute for a local prefix is zero. An AIGP-enabled neighbor can originate an AIGP attribute for a given prefix by export policy, using the aigp-originate policy action. The value of the AIGP attribute reflects the IGP distance to the prefix. Alternatively, you can specify a value, by using the aigp-originate distance distance policy action. The configurable range is 0 through 4,294,967,295. Only one node needs to originate an AIGP attribute. The AIGP attribute is retained and readvertised if the neighbors are AIGP enabled with the aigp statement in the BGP configuration.

The policy action to originate the AIGP attribute has the following requirements:

  • Neighbor must be AIGP enabled.

  • Policy must be applied as an export policy.

  • Prefix must have no current AIGP attribute.

  • Prefix must export with next-hop self.

  • Prefix must reside within the AIGP domain. Typically, a loopback IP address is the prefix to originate.

The policy is ignored if these requirements are not met.

Topology Diagram

Figure 1 shows the topology used in this example. OSPF is used as the interior gateway protocol (IGP). Internal BGP (IBGP) is configured between Device PE1 and Device PE4. External BGP (EBGP) is configured between Device PE7 and Device PE1, between Device PE4 and Device PE3, and between Device PE4 and Device PE2. Devices PE4, PE2, and PE3 are configured for multihop. Device PE4 selects a path based on the AIGP value and then readvertises the AIGP value based on the AIGP and policy configuration. Device PE1 readvertises the AIGP value to Device PE7, which is in another administrative domain. Every device has two loopback interface addresses: 10.9.9.x is used for BGP peering and the router ID, and 10.100.1.x is used for the BGP next hop.

The network between Device PE1 and PE3 has IBGP peering and multiple OSPF areas. The external link to Device PE7 is configured to show that the AIGP attribute is readvertised to a neighbor outside of the administrative domain, if that neighbor is AIGP enabled.

Figure 1: Advertisement of Multiple Paths in BGP
Advertisement of Multiple Paths in
BGP

For origination of an AIGP attribute, the BGP next hop is required to be itself. If the BGP next hop remains unchanged, the received AIGP attribute is readvertised, as is, to another AIGP neighbor. If the next hop changes, the received AIGP attribute is readvertised with an increased value to another AIGP neighbor. The increase in value reflects the IGP distance to the previous BGP next hop. To demonstrate, this example uses loopback interface addresses for Device PE4’s EBGP peering sessions with Device PE2 and Device PE3. Multihop is enabled on these sessions so that a recursive lookup is performed to determine the point-to-point interface. Because the next hop changes, the IGP distance is added to the AIGP distance.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device P1

Device P2

Device PE4

Device PE1

Device PE2

Device PE3

Device PE7

Configuring Device P1

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device P1:

  1. Configure the interfaces.

  2. Configure MPLS and a signaling protocol, such as RSVP or LDP.

  3. Configure BGP.

  4. Enable AIGP.

  5. Configure an IGP, such as OSPF, RIP, or IS-IS.

  6. Configure the router ID and the autonomous system number.

  7. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuring Device P2

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device P2:

  1. Configure the interfaces.

  2. Configure MPLS and a signaling protocol, such as RSVP or LDP.

  3. Configure BGP.

  4. Enable AIGP.

  5. Configure an IGP, such as OSPF, RIP, or IS-IS.

  6. Configure the router ID and the autonomous system number.

  7. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuring Device PE4

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device PE4:

  1. Configure the interfaces.

  2. Configure MPLS and a signaling protocol, such as RSVP or LDP.

  3. Configure BGP.

  4. Enable AIGP.

  5. Originate a prefix, and configure an AIGP distance.

    By default, a prefix is originated using the current IGP distance. Optionally, you can configure a distance for the AIGP attribute, using the distance option, as shown here.

  6. Enable the policies.

  7. Configure a static route.

  8. Configure an IGP, such as OSPF, RIP, or IS-IS.

  9. Configure the router ID and the autonomous system number.

  10. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuring Device PE1

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device PE1:

  1. Configure the interfaces.

  2. Configure MPLS and a signaling protocol, such as RSVP or LDP.

  3. Configure BGP.

  4. Enable AIGP.

  5. Enable the policies.

  6. Configure an IGP, such as OSPF, RIP, or IS-IS.

  7. Configure the router ID and the autonomous system number.

  8. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuring Device PE2

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device PE2:

  1. Configure the interfaces.

  2. Configure MPLS and a signaling protocol, such as RSVP or LDP.

  3. Configure BGP.

  4. Enable AIGP.

  5. Originate a prefix, and configure an AIGP distance.

    By default, a prefix is originated using the current IGP distance. Optionally, you can configure a distance for the AIGP attribute, using the distance option, as shown here.

  6. Enable the policies.

  7. Enable some static routes.

  8. Configure an IGP, such as OSPF, RIP, or IS-IS.

  9. Configure the router ID and the autonomous system number.

  10. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuring Device PE3

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device PE3:

  1. Configure the interfaces.

  2. Configure MPLS and a signaling protocol, such as RSVP or LDP.

  3. Configure BGP.

  4. Enable AIGP.

  5. Enable the policies.

  6. Configure an IGP, such as OSPF, RIP, or IS-IS.

  7. Configure the router ID and the autonomous system number.

  8. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuring Device PE7

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device PE7:

  1. Configure the interfaces.

  2. Configure BGP.

  3. Enable AIGP.

  4. Configure the routing policy.
  5. Configure the router ID and the autonomous system number.

  6. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

Confirm that the configuration is working properly.

Verifying That Device PE4 Is Receiving the AIGP Attribute from Its EBGP Neighbor PE2

Purpose

Make sure that the AIGP policy on Device PE2 is working.

Action

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

Meaning

On Device PE2, the aigp-originate statement is configured with a distance of 20 (aigp-originate distance 20). This statement is applied to route 55.0.0.0/24. Likewise, the aigp-originate distance 30 statement is applied to route 99.0.0.0/24. Thus, when Device PE4 receives these routes, the AIGP attribute is attached with the configured metrics.

Checking the IGP Metric

Purpose

From Device PE4, check the IGP metric to the BGP next hop 10.100.1.5.

Action

user@PE4> show route 10.100.1.5

Meaning

The IGP metric for this route is 2.

Verifying That Device PE4 Adds the IGP Metric to the AIGP Attribute

Purpose

Make sure that Device PE4 adds the IGP metric to the AIGP attribute when it readvertises routes to its IBGP neighbor, Device PE1.

Action

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

Meaning

The IGP metric is added to the AIGP metric (20 + 2 = 22 and 30 + 2 = 32), because the next hop is changed for these routes.

Verifying That Device PE7 Is Receiving the AIGP Attribute from Its EBGP Neighbor PE1

Purpose

Make sure that the AIGP policy on Device PE1 is working.

Action

user@PE7> show route receive-protocol bgp 10.0.0.9 extensive

Meaning

The 44.0.0.0/24 route is originated at Device PE4. The 55.0.0.0/24 and 99.0.0.0/24 routes are originated at Device PE2. The IGP distances are added to the configured AIGP distances.

Verifying the Resolving AIGP Metric

Purpose

Confirm that if the prefix is resolved through recursion and the recursive next hops have AIGP metrics, the prefix has the sum of the AIGP values that are on the recursive BGP next hops.

Action

  1. Add a static route to 66.0.0.0/24.

  2. Delete the existing terms in the aigp policy statement on Device PE2.

  3. Configure a recursive route lookup for the route to 66.0.0.0.

    The policy shows the AIGP metric for prefix 66.0.0.0/24 (none) and its recursive next hop. Prefix 66.0.0.0/24 is resolved by 55.0.0.1. Prefix 66.0.0.0/24 does not have its own AIGP metric being originated, but its recursive next hop, 55.0.0.1, has an AIGP value.

  4. On Device PE4, run the show route 55.0.0.0 extensive command.

    The value of Metric2 is the IGP metric to the BGP next hop. When Device PE4 readvertises these routes to its IBGP peer, Device PE1, the AIGP metric is the sum of AIGP + its Resolving AIGP metric + Metric2.

    Prefix 55.0.0.0 shows its own IGP metric 20, as defined and advertised by Device PE2. It does not show a resolving AIGP value because it does not have a recursive BGP next hop. The value of Metric2 is 2.

    user@PE4> show route 55.0.0.0 extensive
  5. On Device PE4, run the show route 66.0.0.0 extensive command.

    Prefix 66.0.0.0/24 shows the Resolving AIGP, which is the sum of its own AIGP metric and its recursive BGP next hop:

    66.0.0.1 = 0, 55.0.0.1 = 20, 0+20 = 20

    user@PE4> show route 66.0.0.0 extensive

Verifying the Presence of AIGP Attributes in BGP Updates

Purpose

If the AIGP attribute is not enabled under BGP (or the group or neighbor hierarchies), the AIGP attribute is silently discarded. Enable traceoptions and include the packets flag in the detail option in the configuration to confirm the presence of the AIGP attribute in transmitted or received BGP updates. This is useful when debugging AIGP issues.

Action

  1. Configure Device PE2 and Device PE4 for traceoptions.

  2. Check the traceoptions file on Device PE2.

    The following sample shows Device PE2 advertising prefix 99.0.0.0/24 to Device PE4 (10.9.9.4) with an AIGP metric of 20:

    user@PE2> show log bgp
  3. Verify that the route was received on Device PE4 using the show route receive-protocol command.

    AIGP is not enabled on Device PE4, so the AIGP attribute is silently discarded for prefix 99.0.0.0/24 and does not appear in the following output:

    user@PE4> show route receive-protocol bgp 10.9.9.5 extensive | find 55.0.0.0
  4. Check the traceoptions file on Device PE4.

    The following output from the traceoptions log shows that the 99.0.0.0/24 prefix was received with the AIGP attribute attached:

    user@PE4> show log bgp

Meaning

Performing this verification helps with AIGP troubleshooting and debugging issues. It enables you to verify which devices in your network send and receive AIGP attributes.