Archive
Juniper Employee , Juniper Employee Juniper Employee
Archive
Tweaking BGP add-paths
Jun 26, 2014

Introduction

 

This post follows-up my previous article Granular BGP advertise-external for MPLS L3VPNs with the intention to tweak and illustrate the BGP add-path feature implementation in Junos OS for IPv4 unicast and IPv6 labeled-unicast (6PE) routes. BGP add-paths provide a more comprehensive path diversity approach than diverse paths or advertise-external and in my view, multiple applications can be based on Junos OS BGP add-path tactical deployment in default instance tables.

 

In Granular BGP advertise-external for MPLS L3VPNs, I briefly described the original motivations for draft-ietf-idr-best-external-05, which actually retrieves an old idea exposed in original [RFC1771] (later removed at [RFC4271]) so as to also advertise the best of the externally received paths. There are multiple benefits from this approach, also described in draft-ietf-idr-best-external-05.

 

Advertising the bext external paths at Autonomous System (AS) boundaries may suffice in an MPLS L3VPN environment, because the additional Route Distinguisher (RD) attached to the prefix provides disambiguation and a design option to create unique paths with an adequate RD deployment scheme: path uniqueness for the very same ultimate destination at any multi-homed CE domain. The Junosphere topology attached to Granular BGP advertise-external for MPLS L3VPNs is a very simple example for this setup.

 

However, what if I want to allow multiple paths and provide the same benefits in a common environment like simple IPv4 and IPv6 unicast services without RDs?

 

There was next a diverse path proposal (see [RFC6774] or http://ripe61.ripe.net/presentations/150-ripe-bgp-diverse-paths.pdf) that is based on certain BGP session duplicity to advertise diverse paths among certain peers. http://ripe60.ripe.net/presentations/Raszuk-To_add-paths_or_not_to_add-paths.pdf argues that combining this approach with advertise-external may significantly cover many requirements. [RFC6774], Section 3 reckons that BGP add-paths is however a more complete paradigm and the diverse paths proposal can be conceived as an interim non-intrusive strategy.

 

Nowadays, BGP add-paths is a feature supported by multiple vendors and should have reached a certain maturity stage. Junos 11.3 was the first release including BGP add-paths and this functionality has been complemented with support for more families and additional policies since then. draft-ietf-idr-add-paths-09 is the latest major reference for implementation purposes that describes two major resources:

 

  • A 4-octect locally assigned and unique Path Identifier that is attached to existing NLRIs
  • A new ADD-PATH BGP capability whose value contains multiple tuples for AFI/SAFI combinations and Send and/or Receive options

 

Capability negotiation requires resetting BGP sessions in current implementations and BGP add-paths is intrusive from that point of view. But once capabilities are negotiated on a per-session basis, we are going to see in this example how it can be smoothly integrated with plain [RFC4271] path selection procedures and correctly interoperates in Junos OS with BGP sessions that have not negotiated the capability yet (for example, think of a route reflector or an ASBR case).

 

draft-ietf-idr-add-paths-guidelines-06 and draft-pmohapat-idr-fast-conn-restore-03 cover multiple recommendations and use cases for the BGP add-paths implementation (not just the original purpose to avoid persistent route oscillation conditions, check draft-walton-bgp-route-oscillation-stop-08) and I found that the recorded EuroNOG 2001 "BGP Add-Paths and Prefix Independent Convergence" presentation from one of the draft-ietf-idr-add-paths-guidelines-06 authors, Pierre Francois, is a very good feature description summary and explanation for its implementation options. My Junosphere topology in this article is actually aligned with some of these described guidelines and examples to tune them in Junos OS.

 

draft-pmohapat-idr-fast-conn-restore-03 focuses on applications that would benefit from multiple paths advertisement in iBGP: fast connectivity restoration, multipath load balancing and churn reduction, among others. Actually, churn reduction is applicable for best path selection (and therefore, down to the forwarding table) but the more paths are held in routing tables, the more instabilities from non-best paths are propagated via BGP in this case.

 

draft-ietf-idr-add-paths-guidelines-06 characterizes these applications with different path selection modes, that can be enforced by combining usual BGP traffic engineering policies (i.e. set same local-preference in a group of equally-considered paths) and BGP add-paths settings.

 

Because of the known tradeoff between resource consumption and feature rollout, it is expected to tailor BGP add-paths to a specific subset of destinations for one or the other reason or application (it would not scale in many networks up to the full internet table size!). These path selection modes may not be so strictly distinguished in live networks and destinations can be covered with a mix of AS-Wide preferred paths (All paths that are considered as best when applying rules of the BGP decision process up to the IGP tie-break, as per draft-ietf-idr-add-paths-guidelines-06) or just simple non-best backup paths.

 

An example for the above can be a golden destination for a service provider than can be simultaneously covered with prefixes received over directly connected and multihomed customer BGP peering (a), transit through another customer (b), through an equally ranged peer (c) and across an upstream provider (d). A network engineer could conceive in this case AS-Wide preferred paths among (a), (b), (c) or (d) path groups by granting different local-preferences or MEDs in each case, but leave the decision within each group up to the IGP metric to the ASBR from the RR or the final router in each case. These comprehensive traffic engineering policies can be flexibly and easily defined with Junos OS policy language and its BGP add-path implementation!

 

How does this feature get activated with Junos OS?

 

http://www.nanog.org/meetings/nanog48/presentations/Tuesday/Ward_AddPath_N48.pdf is a very good public resource to explain how the feature has been originally designed and conceived in Junos OS. The initial BGP add-path feature implementation was released in Junos 11.3 supporting the inet unicast family:

 

[edit protocols bgp]

group foo {
    family inet {
        unicast {
          add-path {
            receive;
            send {
                path-count <n>;
                prefix-policy <policy_name>;
            }
          }
        }
    }
}

 

From this basic snippet, I want to remark now three major lessons learned exposed in this article:

 

  • prefix-policy must cover only prefixes representative for destinations, but cannot be characterized by other matching criteria, like community or other route attribute matching. It is enforced herewith to ultimately look for the correct destinations to be handled with BGP add-paths: i.e., if community matching were implemented here, BGP add-paths would not be entirely consistent if some paths were marked with a community and some others not. Enforcing here destination matching only is a current design decision in Junos OS. If no prefix-policy is specific, all destinations from this family are considered (watch out for consumed resources in this case!)

 

  • path-count needs to be considered from the perspective of this particular ASBR, not from a global network-wide view. If add-path send is configured,  path-count is a mandatory configuration item and indicates the number of paths that will be advertised inside the network via iBGP. Note this is substantially different from all existing paths for the same destination in the AS! In Granular BGP advertise-external for MPLS L3VPNs we saw how BGP advertise-external sends the (1) non-best path from ASBRs. Think of add-path send as actually extrapolating this concept in this border position beyond 1 up to 'N' paths with the needed protocol modifications. For that reason, the add-path send path-count minimum value is actually 2 and not 1, as it would be redundant (and no new BGP Capability is needed in that case!)

 

  • Different send and receive configurations inside a BGP hierarchy create different internal peer groups. It is internally split into different peer groups if these values differ (as with export policy customizations, for instance). This is actually relevant at high scale if this feature is applied to a very high number of groups and peers, so it would be convenient to group them logically for scalability purposes.

 

This first BGP add-path implementation has been later expanded in Junos 13.3 to cover the inet6 family and both unicast and labeled-unicast SAFIs (https://www.juniper.net/techpubs/en_US/junos13.3/topics/topic-map/bgp-advertise-multiple-paths.html), which makes the feature very appealing for seamless MPLS scenarios with BGP-LU and 6PE transport, among others.

 

Last but not least, our brand new Junos 14.1 allows customized setting up to 20 paths to be sent (http://www.juniper.net/techpubs/en_US/junos14.1/topics/reference/configuration-statement/prefix-poli...) beyond previous maximum of 6, with the condition that this specific increase is defined as an action (then) of the prefix-policy. Reaching 20 may look a bit overwhelming for simple fast restoration scenarios but convenient if a load balancing application is conceived for some applications.

 

In the next Junosphere example, I will not be testing this last enhancement, but tweaking BGP add-paths to depict the above described tidbits for IPv4 transit (inet unicast family) and IPv6 transit with the 6PE model (inet6 labeled-unicast family). Junos OS provides a flexible BGP add-path implementation, and although I will focus only on a simple AS-Wide preferred paths scenario for illustration purposes, bear in mind that all draft-ietf-idr-add-paths-guidelines-06 path selection modes are achievable by simply fine-tuning Junos OS policies and resources!

 

Examples with Junosphere: Tweaking BGP add-paths


As in previous posts, let's analyze a basic configuration scheme with Junosphere (see attached topology). Our usual physical router topology has been slightly modified to add another inter-AS link between R2 and R24:

 

add-path-junosphere-topology.jpg

And this new link will be used by another eBGP session between both Autonomous Systems (ASs). Internal IPv4 and IPv6 transport inside each AS is achieved with inet unicast and inet6 labeled-unicast (6PE) BGP families, whereas external peerings (3 sessions altogether) are achieved with inet unicast and inet6 unicast families.

add-path-e2e-topology.jpg

Under these conditions, let's take R24 in AS65001 as the router advertising IPv4 and IPv6 prefixes subject of study:

 

add-path-route-advertisement.jpg

R24 advertises these prefixes through its internal BGP sessions to AS65001 route reflectors and over its external BGP session to R2:

 

juniper@R24> show route advertising-protocol bgp 192.168.255.15

 

inet.0: 36 destinations, 36 routes (36 active, 0 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

* 203.0.113.0/25          Self                         100        I

* 203.0.113.128/25        Self                         100        I

 

inet6.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

  2001:db8:6500:2::/64

*                         Self                         100        I

  2001:db8:6500:3::/64

*                         Self                         100        I

 

juniper@R24> show route advertising-protocol bgp 192.168.255.19   

 

inet.0: 36 destinations, 36 routes (36 active, 0 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

* 203.0.113.0/25          Self                         100        I

* 203.0.113.128/25        Self                         100        I

 

inet6.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

  2001:db8:6500:2::/64

*                         Self                         100        I

  2001:db8:6500:3::/64

*                         Self                         100        I

 

 

juniper@R24> show route advertising-protocol bgp 192.168.33.1     

 

inet.0: 38 destinations, 38 routes (38 active, 0 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

* 203.0.113.0/25          Self                                    I

* 203.0.113.128/25        Self                                    I

 

inet6.0: 23 destinations, 24 routes (23 active, 0 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

  2001:db8:6500:2::/64

*                         Self                                    I

  2001:db8:6500:3::/64

*                         Self                                    I

 

 

 

Consider this multi-peering scheme and upon lack of any traffic engineering policies in AS65000, path optimality is usually determined by the IGP metric tie breaker at each route reflector (since R2, R10 and R11 as ASBRs will prefer externally received paths first).

 

  • Primary AS-Wide preferred path:

 

Let's assume now that paths received over the direct R2<->R24 are engineered to be globally preferred among all of them within AS65000 by increasing local-preference from the default value of 100 to 120 (imagine a primary customer path):

 

juniper@R2> show configuration protocols bgp group eBGP

type external;

local-address 192.168.33.1;

import customer-preferred;

family inet {

    unicast;

}

family inet6 {

    unicast;

}

peer-as 65001;

neighbor 192.168.33.2;

 

juniper@R2> show configuration policy-options policy-statement customer-preferred

from protocol bgp;

then {

    local-preference 120;

}

 

At R6 and R12, internal route reflectors in AS65000, this path becomes the globally preferred within the AS, due to the local-preference attribute wide scope:

add-path-local-pref120-previous.jpg

juniper@R6> show route protocol bgp

 

inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

203.0.113.0/25     *[BGP/170] 00:09:36, localpref 120, from 192.168.255.2

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.11.2 via ge-0/0/1.0, label-switched-path R6->R2

203.0.113.128/25   *[BGP/170] 00:09:36, localpref 120, from 192.168.255.2

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.11.2 via ge-0/0/1.0, label-switched-path R6->R2

 

inet.3: 11 destinations, 22 routes (11 active, 0 holddown, 0 hidden)

 

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

 

mpls.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)

 

inet6.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

2001:db8:6500:2::/64

                   *[BGP/170] 00:09:36, localpref 120, from 192.168.255.2

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.11.2 via ge-0/0/1.0, label-switched-path R6->R2

2001:db8:6500:3::/64

                   *[BGP/170] 00:09:36, localpref 120, from 192.168.255.2

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.11.2 via ge-0/0/1.0, label-switched-path R6->R2

 

inet6.3: 11 destinations, 22 routes (11 active, 0 holddown, 0 hidden)

 

 

As such, they get reflected to each route reflector client, including other ASBRs as well:

 

juniper@R10> show route protocol bgp

 

inet.0: 35 destinations, 39 routes (35 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

203.0.113.0/25     *[BGP/170] 00:10:11, localpref 120, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.13.1 via ge-0/0/1.0, label-switched-path R10->R2

                    [BGP/170] 00:10:07, localpref 120, from 192.168.255.12

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.13.1 via ge-0/0/1.0, label-switched-path R10->R2

                    [BGP/170] 02:17:59, localpref 100

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.15.2 via ge-0/0/3.0

203.0.113.128/25   *[BGP/170] 00:10:11, localpref 120, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.13.1 via ge-0/0/1.0, label-switched-path R10->R2

                    [BGP/170] 00:10:07, localpref 120, from 192.168.255.12

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.13.1 via ge-0/0/1.0, label-switched-path R10->R2

                    [BGP/170] 02:17:59, localpref 100

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.15.2 via ge-0/0/3.0

 

inet.3: 11 destinations, 22 routes (11 active, 0 holddown, 0 hidden)

 

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

 

mpls.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden)

 

inet6.0: 14 destinations, 20 routes (14 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

2001:db8:6500:2::/64

                   *[BGP/170] 00:10:11, localpref 120, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.13.1 via ge-0/0/1.0, label-switched-path R10->R2

                    [BGP/170] 00:10:07, localpref 120, from 192.168.255.12

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.13.1 via ge-0/0/1.0, label-switched-path R10->R2

                    [BGP/170] 02:17:58, localpref 100, from 192.168.15.2

                      AS path: 65001 I, validation-state: unverified

                    > to ::ffff:192.168.15.2 via ge-0/0/3.0

2001:db8:6500:3::/64

                   *[BGP/170] 00:10:11, localpref 120, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.13.1 via ge-0/0/1.0, label-switched-path R10->R2

                    [BGP/170] 00:10:07, localpref 120, from 192.168.255.12

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.13.1 via ge-0/0/1.0, label-switched-path R10->R2

                    [BGP/170] 02:17:58, localpref 100, from 192.168.15.2

                      AS path: 65001 I, validation-state: unverified

                    > to ::ffff:192.168.15.2 via ge-0/0/3.0

 

 

We can see that only the best active path is effectively active across the entire AS. Only R10 and R11, as other ASBRs, have a local backup path that can help speed up convergence, but other routers inside AS65000 like R2 or R1 just cover these destinations with a single active path each:

 

juniper@R1> show route protocol bgp

 

inet.0: 25 destinations, 27 routes (25 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

203.0.113.0/25     *[BGP/170] 00:14:35, localpref 120, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.0.2 via ge-0/0/1.0, label-switched-path R1->R2

                    [BGP/170] 00:14:21, localpref 120, from 192.168.255.12

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.0.2 via ge-0/0/1.0, label-switched-path R1->R2

203.0.113.128/25   *[BGP/170] 00:14:35, localpref 120, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.0.2 via ge-0/0/1.0, label-switched-path R1->R2

                    [BGP/170] 00:14:21, localpref 120, from 192.168.255.12

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.0.2 via ge-0/0/1.0, label-switched-path R1->R2

 

inet.3: 11 destinations, 22 routes (11 active, 0 holddown, 0 hidden)

 

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

 

mpls.0: 42 destinations, 42 routes (42 active, 0 holddown, 0 hidden)

 

inet6.0: 7 destinations, 10 routes (7 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

2001:db8:6500:2::/64

                   *[BGP/170] 00:14:35, localpref 120, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.0.2 via ge-0/0/1.0, label-switched-path R1->R2

                    [BGP/170] 00:14:21, localpref 120, from 192.168.255.12

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.0.2 via ge-0/0/1.0, label-switched-path R1->R2

2001:db8:6500:3::/64

                   *[BGP/170] 00:14:35, localpref 120, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.0.2 via ge-0/0/1.0, label-switched-path R1->R2

                    [BGP/170] 00:14:21, localpref 120, from 192.168.255.12

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.0.2 via ge-0/0/1.0, label-switched-path R1->R2

 

inet6.3: 11 destinations, 22 routes (11 active, 0 holddown, 0 hidden)

 

  • Activating BGP add-paths in the route reflectors and selective clients:

draft-ietf-idr-add-paths-guidelines-06 Section 5 includes some deployment considerations to evolve from draft-ietf-idr-best-external-05. Essentially, the BGP add-path concept extrapolates the advertise-external principle to a higher number of paths and situations.

 

As initial feature introduction and because this is driven by the new ADD-PATH BGP capability for the respective AFI/SAFIs, it seems sensible to activate this first in the route reflectors:

 

[edit]

juniper@R6# show | compare

[edit protocols bgp group iBGP family inet unicast]

+        add-path {

+            receive;

+            send {

+                path-count 3;

+            }

+        }

[edit protocols bgp group iBGP family inet6 labeled-unicast]

+        add-path {

+            receive;

+            send {

+                path-count 3;

+            }

+        }

 

For fast recovery purposes, draft-ietf-idr-add-paths-guidelines-06 states that 2 or 3 path-counts should suffice. I have increased it from 2 to 3 in this example for additional resilience and illustration purposes, but it would even make more sense if the tie breaker to determine among any of these paths is not an AS-wide applicable attribute, but local to the route reflector, such as the IGP metric. In that case, the client in this example would have further information to decide based on its IGP metric to the ASBR, for instance.

 

The more paths that are enabled to be sent, the more reliable the forwarding plane will be for the respective destinations. On the other hand, count as well on further instabilities from backup paths being propagated via BGP.

 

Note that activating BGP add-path is intrusive in Junos OS for the affected BGP sessions, since this new capability for the respective family needs to be renegotiated. This BGP session reset is required (as with other capabilities) to rediscover if the peer eventually positively negotiates it after the restart.

 

Now, let's activate the receive option for R1 to progressively start receiving add-path enabled NLRIs from the route reflectors:

 

juniper@R1# show | compare

[edit protocols bgp group iBGP family inet unicast]

+        add-path {

+            receive;

+        }

[edit protocols bgp group iBGP family inet6 labeled-unicast]

+        add-path {

+            receive;

+        }  

 

juniper@R1> show bgp neighbor | match "^Peer|Path"  

Peer: 192.168.255.6+59058 AS 65000 Local: 192.168.255.1+179 AS 65000

  NLRI's for which peer can send and receive multiple paths: inet-unicast inet6-labeled-unicast

Peer: 192.168.255.12+54187 AS 65000 Local: 192.168.255.1+179 AS 65000

  NLRI's for which peer can send and receive multiple paths: inet-unicast inet6-labeled-unicast

 

So far, nothing has changed in the routing tables yet, but the route reflectors are prepared to receive any eligible NLRIs with path identifiers and process them correspondingly to either send 3-tuples for BGP add-path enabled clients like R1 (or non-clients if that were the case) or just the best path from its standpoint for peers without the capability configured yet.

 

This centralized hybrid role in the route reflectors to support both enabled and non-enabled peers makes this implementation very interesting because a network designer can envision a progressive service enablement and migration, with careful resource consumption monitoring. You can avoid a Big Bang!

 

  • Activating a secondary AS-wide preferred path with BGP add-path:

Let's consider now that over the R10<->R13 peering secondary AS-wide preferred paths are received. The globally best AS-wide preferred path is enforced with local-preference 120 being set in R2. In this case, the default local-preference 100 can be kept.

 

But R10 receives internal paths from R2 that become active and for this reason, its externally received non-best paths are not populated internally. Both advertise-external and BGP add-path are features that can address this requirement to further populate the route reflectors with these secondary AS-wide preferred paths.

 

Going beyond the simple advertise-external approach exposed at Granular BGP advertise-external for MPLS L3VPNs, this is a good use case for BGP add-path. Junos OS supports customized destination selection to enable this functionality with, and I will illustrate this with the following example:

 

[edit]

juniper@R10# show | compare

[edit protocols bgp group iBGP family inet unicast]

+        add-path {

+            receive;

+            send {

+                prefix-policy add-path-golden-destinations;

+                path-count 2;

+            }

+        }

[edit protocols bgp group iBGP family inet6 labeled-unicast]

+        add-path {

+            receive;

+            send {

+                prefix-policy add-path-golden-destinations;

+                path-count 2;

+            }

+        }

[edit policy-options]

+   policy-statement add-path-golden-destinations {

+       term inet0 {

+           from {

+               route-filter 203.0.113.0/25 exact;

+           }

+           then accept;

+       }

+       term inet6 {

+           from {

+               route-filter 2001:db8:6500:2::/64 exact;

+           }

+           then accept;

+       }

+   }

 

At R10, routing tables include both the best AS-wide preferred paths from R2 and externally received paths from R13:

 

juniper@R10> show route protocol bgp

 

inet.0: 35 destinations, 39 routes (35 active, 1 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

203.0.113.0/25     *[BGP/170] 00:01:07, localpref 120, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.13.1 via ge-0/0/1.0, label-switched-path R10->R2

                    [BGP/170] 00:01:03, localpref 120, from 192.168.255.12

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.13.1 via ge-0/0/1.0, label-switched-path R10->R2

                    [BGP/170] 02:48:39, localpref 100

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.15.2 via ge-0/0/3.0

203.0.113.128/25   *[BGP/170] 00:01:07, localpref 120, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.13.1 via ge-0/0/1.0, label-switched-path R10->R2

                    [BGP/170] 00:01:03, localpref 120, from 192.168.255.12

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.13.1 via ge-0/0/1.0, label-switched-path R10->R2

                    [BGP/170] 02:48:39, localpref 100

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.15.2 via ge-0/0/3.0

 

inet.3: 11 destinations, 22 routes (11 active, 0 holddown, 0 hidden)

 

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

 

mpls.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden)

 

inet6.0: 14 destinations, 20 routes (14 active, 1 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

2001:db8:6500:2::/64

                   *[BGP/170] 00:01:07, localpref 120, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.13.1 via ge-0/0/1.0, label-switched-path R10->R2

                    [BGP/170] 00:01:03, localpref 120, from 192.168.255.12

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.13.1 via ge-0/0/1.0, label-switched-path R10->R2

                    [BGP/170] 02:48:38, localpref 100, from 192.168.15.2

                      AS path: 65001 I, validation-state: unverified

                    > to ::ffff:192.168.15.2 via ge-0/0/3.0

2001:db8:6500:3::/64

                   *[BGP/170] 00:01:07, localpref 120, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.13.1 via ge-0/0/1.0, label-switched-path R10->R2

                    [BGP/170] 00:01:03, localpref 120, from 192.168.255.12

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.13.1 via ge-0/0/1.0, label-switched-path R10->R2

                    [BGP/170] 02:48:38, localpref 100, from 192.168.15.2

                      AS path: 65001 I, validation-state: unverified

                    > to ::ffff:192.168.15.2 via ge-0/0/3.0

 

inet6.3: 11 destinations, 22 routes (11 active, 0 holddown, 0 hidden)

 

And just by activating the above mentioned BGP add-path options and adjust the prefix-policy, we trigger the advertisement of these chosen secondary AS-wide preferred paths to the route reflectors:

 

juniper@R10> show route advertising-protocol bgp 192.168.255.6

 

inet.0: 35 destinations, 39 routes (35 active, 1 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

  203.0.113.0/25          Self                         100        65001 I

 

inet6.0: 14 destinations, 20 routes (14 active, 1 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

  2001:db8:6500:2::/64

                          Self                         100        65001 I

 

juniper@R10> show route advertising-protocol bgp 192.168.255.12  

 

inet.0: 35 destinations, 39 routes (35 active, 1 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

  203.0.113.0/25          Self                         100        65001 I

 

inet6.0: 14 destinations, 20 routes (14 active, 1 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

  2001:db8:6500:2::/64

                          Self                         100        65001 I

 

Because the BGP ADD-PATH capability is enabled in the route reflectors, these paths are held in their routing tables:

add-path-local-pref100.jpg

 

 

 

juniper@R6> show route protocol bgp

 

inet.0: 19 destinations, 20 routes (19 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

203.0.113.0/25     *[BGP/170] 00:23:15, localpref 120, from 192.168.255.2

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.11.2 via ge-0/0/1.0, label-switched-path R6->R2

                    [BGP/170] 00:02:11, localpref 100, from 192.168.255.10

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.11.2 via ge-0/0/1.0, label-switched-path R6->R10

203.0.113.128/25   *[BGP/170] 00:23:15, localpref 120, from 192.168.255.2

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.11.2 via ge-0/0/1.0, label-switched-path R6->R2

 

inet.3: 11 destinations, 22 routes (11 active, 0 holddown, 0 hidden)

 

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

 

mpls.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)

 

inet6.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

2001:db8:6500:2::/64

                   *[BGP/170] 00:23:15, localpref 120, from 192.168.255.2

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.11.2 via ge-0/0/1.0, label-switched-path R6->R2

                    [BGP/170] 00:02:11, localpref 100, from 192.168.255.10

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.11.2 via ge-0/0/1.0, label-switched-path R6->R10

2001:db8:6500:3::/64

                   *[BGP/170] 00:23:15, localpref 120, from 192.168.255.2

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.11.2 via ge-0/0/1.0, label-switched-path R6->R2

 

inet6.3: 11 destinations, 22 routes (11 active, 0 holddown, 0 hidden)

 

Up to this point, both advertise-external or BGP add-path could achieve the same goal: provide path redundancy at route reflectors when the feature is enabled in an ASBR. However, route reflectors perform path selection now and for non-VPN routes (those not including specific different path identifiers like RDs), BGP add-path still allows this path diversity to be propagated further to other iBGP peers, as opposed to advertise-external. BGP add-path provides this benefit without needing separate route reflectors for backup paths or additional BGP sessions (like the diverse path approach).

 

Other clients like R1 (and non-clients) with the same capability negotiated can benefit from the readvertisement of these backup paths for the known applications, such as fast recovery:

 

juniper@R6> show route advertising-protocol bgp 192.168.255.1

 

inet.0: 19 destinations, 20 routes (19 active, 0 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

* 203.0.113.0/25          192.168.255.2                120        65001 I

                          192.168.255.10               100        65001 I

* 203.0.113.128/25        192.168.255.2                120        65001 I

 

inet6.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

  2001:db8:6500:2::/64

*                         ::ffff:192.168.255.2         120        65001 I

                          ::ffff:192.168.255.10        100        65001 I

  2001:db8:6500:3::/64

*                         ::ffff:192.168.255.2         120        65001 I

 

 

 

  • Activating a tertiary AS-wide preferred path with BGP add-path:

 

And BGP add-path allows additional 'N' paths to build up the needed model. Junos OS allows a path-count maximum of 6 per default, and since recent Junos 14.1, a tactical increase up to 20 paths to be sent (http://www.juniper.net/techpubs/en_US/junos14.1/topics/reference/configuration-statement/prefix-poli...) when defining it as an action (then) of the prefix-policy.

 

Imagine now that over the R11<->R14 peering tertiary AS-wide preferred paths are received. Previous AS-wide preferred paths are enforced with local-preferences 120 and 100, so we will use local-preference 80 for this new backup path:

 

juniper@R11> show route protocol bgp

 

inet.0: 35 destinations, 39 routes (35 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

203.0.113.0/25     *[BGP/170] 00:47:25, localpref 120, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.12.1 via ge-0/0/1.0, label-switched-path R11->R2

                    [BGP/170] 00:47:13, localpref 120, from 192.168.255.12

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.12.1 via ge-0/0/1.0, label-switched-path R11->R2

                    [BGP/170] 03:14:09, localpref 80

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.16.2 via ge-0/0/3.0

203.0.113.128/25   *[BGP/170] 00:47:25, localpref 120, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.12.1 via ge-0/0/1.0, label-switched-path R11->R2

                    [BGP/170] 00:47:13, localpref 120, from 192.168.255.12

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.12.1 via ge-0/0/1.0, label-switched-path R11->R2

                    [BGP/170] 03:14:09, localpref 80

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.16.2 via ge-0/0/3.0

 

inet.3: 11 destinations, 22 routes (11 active, 0 holddown, 0 hidden)

 

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

 

mpls.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)

 

inet6.0: 15 destinations, 21 routes (15 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

2001:db8:6500:2::/64

                   *[BGP/170] 00:47:25, localpref 120, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.12.1 via ge-0/0/1.0, label-switched-path R11->R2

                    [BGP/170] 00:47:12, localpref 120, from 192.168.255.12

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.12.1 via ge-0/0/1.0, label-switched-path R11->R2

                    [BGP/170] 03:14:09, localpref 80, from 192.168.16.2

                      AS path: 65001 I, validation-state: unverified

                    > to ::ffff:192.168.16.2 via ge-0/0/3.0

2001:db8:6500:3::/64

                   *[BGP/170] 00:47:25, localpref 120, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.12.1 via ge-0/0/1.0, label-switched-path R11->R2

                    [BGP/170] 00:47:12, localpref 120, from 192.168.255.12

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.12.1 via ge-0/0/1.0, label-switched-path R11->R2

                    [BGP/170] 03:14:09, localpref 80, from 192.168.16.2

                      AS path: 65001 I, validation-state: unverified

                    > to ::ffff:192.168.16.2 via ge-0/0/3.0

 

 

As intended, the globally best AS-wide preferred paths are enforced with local-preference 120 being set in R2 and populated across AS65000. Similar to our previous operation, let's enable customized

BGP add-path settings:

 

[edit protocols bgp group iBGP family inet unicast]

+        add-path {

+            receive;

+            send {

+                prefix-policy add-path-golden-destinations;

+                path-count 2;

+            }

+        }

[edit protocols bgp group iBGP family inet6 labeled-unicast]

+        add-path {

+            receive;

+            send {

+                prefix-policy add-path-golden-destinations;

+                path-count 2;

+            }

+        }

[edit policy-options]

+   policy-statement add-path-golden-destinations {

+       term inet0 {

+           from {

+               route-filter 203.0.113.0/25 exact;

+           }

+           then accept;

+       }

+       term inet6 {

+           from {

+               route-filter 2001:db8:6500:2::/64 exact;

+           }

+           then accept;

+       }

+   }

 

 

Because BGP add-path has been enabled with both send and receive options, secondary AS-wide preferred paths are now visible in R11 as received from the route reflectors:

 

juniper@R11> show route protocol bgp

 

inet.0: 35 destinations, 41 routes (35 active, 1 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

203.0.113.0/25     *[BGP/170] 00:00:21, localpref 120, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.12.1 via ge-0/0/1.0, label-switched-path R11->R2

                    [BGP/170] 00:00:17, localpref 120, from 192.168.255.12

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.12.1 via ge-0/0/1.0, label-switched-path R11->R2

                    [BGP/170] 00:00:21, localpref 100, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.14.1 via ge-0/0/2.0, label-switched-path R11->R10

                    [BGP/170] 00:00:17, localpref 100, from 192.168.255.12

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.14.1 via ge-0/0/2.0, label-switched-path R11->R10

                    [BGP/170] 03:17:16, localpref 80

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.16.2 via ge-0/0/3.0

203.0.113.128/25   *[BGP/170] 00:00:21, localpref 120, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.12.1 via ge-0/0/1.0, label-switched-path R11->R2

                    [BGP/170] 00:00:17, localpref 120, from 192.168.255.12

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.12.1 via ge-0/0/1.0, label-switched-path R11->R2

                    [BGP/170] 03:17:16, localpref 80

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.16.2 via ge-0/0/3.0

 

inet.3: 11 destinations, 22 routes (11 active, 0 holddown, 0 hidden)

 

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

 

mpls.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)

 

inet6.0: 15 destinations, 23 routes (15 active, 1 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

2001:db8:6500:2::/64

                   *[BGP/170] 00:00:21, localpref 120, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.12.1 via ge-0/0/1.0, label-switched-path R11->R2

                    [BGP/170] 00:00:17, localpref 120, from 192.168.255.12

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.12.1 via ge-0/0/1.0, label-switched-path R11->R2

                    [BGP/170] 00:00:21, localpref 100, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.14.1 via ge-0/0/2.0, label-switched-path R11->R10

                    [BGP/170] 00:00:17, localpref 100, from 192.168.255.12

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.14.1 via ge-0/0/2.0, label-switched-path R11->R10

                    [BGP/170] 03:17:16, localpref 80, from 192.168.16.2

                      AS path: 65001 I, validation-state: unverified

                    > to ::ffff:192.168.16.2 via ge-0/0/3.0

2001:db8:6500:3::/64

                   *[BGP/170] 00:00:21, localpref 120, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.12.1 via ge-0/0/1.0, label-switched-path R11->R2

                    [BGP/170] 00:00:17, localpref 120, from 192.168.255.12

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.12.1 via ge-0/0/1.0, label-switched-path R11->R2

                    [BGP/170] 03:17:16, localpref 80, from 192.168.16.2

                      AS path: 65001 I, validation-state: unverified

                    > to ::ffff:192.168.16.2 via ge-0/0/3.0

 

inet6.3: 11 destinations, 22 routes (11 active, 0 holddown, 0 hidden)

 

And because path-count 2 has been set in R11, it also advertises its locally received paths from its eBGP session to the route reflectors, to become tertiary AS-wide globally preferred paths:

 

juniper@R11> show route advertising-protocol bgp 192.168.255.6

 

inet.0: 35 destinations, 41 routes (35 active, 1 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

  203.0.113.0/25          Self                         80         65001 I

 

inet6.0: 15 destinations, 23 routes (15 active, 1 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

  2001:db8:6500:2::/64

                          Self                         80         65001 I

 

juniper@R11> show route advertising-protocol bgp 192.168.255.12  

 

inet.0: 35 destinations, 41 routes (35 active, 1 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

  203.0.113.0/25          Self                         80         65001 I

 

inet6.0: 15 destinations, 23 routes (15 active, 1 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

  2001:db8:6500:2::/64

                          Self                         80         65001 I

 

 

And now, the route reflectors automatically acquire visibility on these new backup paths...

add-path-local-pref80.jpg

juniper@R6> show route protocol bgp

 

inet.0: 19 destinations, 21 routes (19 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

203.0.113.0/25     *[BGP/170] 00:54:17, localpref 120, from 192.168.255.2

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.11.2 via ge-0/0/1.0, label-switched-path R6->R2

                    [BGP/170] 00:33:13, localpref 100, from 192.168.255.10

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.11.2 via ge-0/0/1.0, label-switched-path R6->R10

                    [BGP/170] 00:03:49, localpref 80, from 192.168.255.11

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.11.2 via ge-0/0/1.0, label-switched-path R6->R11

203.0.113.128/25   *[BGP/170] 00:54:17, localpref 120, from 192.168.255.2

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.11.2 via ge-0/0/1.0, label-switched-path R6->R2

 

inet.3: 11 destinations, 22 routes (11 active, 0 holddown, 0 hidden)

 

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

 

mpls.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)

 

inet6.0: 6 destinations, 8 routes (6 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

2001:db8:6500:2::/64

                   *[BGP/170] 00:54:17, localpref 120, from 192.168.255.2

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.11.2 via ge-0/0/1.0, label-switched-path R6->R2

                    [BGP/170] 00:33:13, localpref 100, from 192.168.255.10

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.11.2 via ge-0/0/1.0, label-switched-path R6->R10

                    [BGP/170] 00:03:49, localpref 80, from 192.168.255.11

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.11.2 via ge-0/0/1.0, label-switched-path R6->R11

2001:db8:6500:3::/64

                   *[BGP/170] 00:54:17, localpref 120, from 192.168.255.2

                      AS path: 65001 I, validation-state: unverified

                    > to 192.168.11.2 via ge-0/0/1.0, label-switched-path R6->R2

 

inet6.3: 11 destinations, 22 routes (11 active, 0 holddown, 0 hidden)

 

 

and all these paths can be reflected to BGP add-path enabled peers:

 

juniper@R6> show route advertising-protocol bgp 192.168.255.1

 

inet.0: 19 destinations, 21 routes (19 active, 0 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

* 203.0.113.0/25          192.168.255.2                120        65001 I

                          192.168.255.10               100        65001 I

                          192.168.255.11               80         65001 I

* 203.0.113.128/25        192.168.255.2                120        65001 I

 

inet6.0: 6 destinations, 8 routes (6 active, 0 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

  2001:db8:6500:2::/64

*                         ::ffff:192.168.255.2         120        65001 I

                          ::ffff:192.168.255.10        100        65001 I

                          ::ffff:192.168.255.11        80         65001 I

  2001:db8:6500:3::/64

*                         ::ffff:192.168.255.2         120        65001 I

 

Whereas others with BGP add-path not yet enabled just get the best paths from the route reflectors:

 

juniper@R6> show route advertising-protocol bgp 192.168.255.5   

 

inet.0: 19 destinations, 21 routes (19 active, 0 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

* 203.0.113.0/25          192.168.255.2                120        65001 I

* 203.0.113.128/25        192.168.255.2                120        65001 I

 

inet6.0: 6 destinations, 8 routes (6 active, 0 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

  2001:db8:6500:2::/64

*                         ::ffff:192.168.255.2         120        65001 I

  2001:db8:6500:3::/64

*                         ::ffff:192.168.255.2         120        65001 I

 

 

and so forth...  BGP add-paths can be combined with other traffic engineering policies and complement some needed requirements for applications like faster convergence. Now that we have played around with the feature in Junosphere, let's recap some final conclusions.

 

Conclusions

 

The BGP add-path feature was first released in Junos 11.3 and has significantly matured since then with more address families and options to reach up to 20 paths in 14.1. Let me summarize some facts and advantages that I found with BGP add-paths in current Junos OS versions:

 

  • Gradual, flexible and tactical feature deployment (as per draft-ietf-idr-add-paths-guidelines-06 Section 5): based on capability negotiation, performing path selection and readvertisement in one or the other fashion. No big bang!
  • Feature application at perimeter and/or route reflectors with granular adjustments based on prefix-policy characterizing protected destinations. In this example, I have opted for defining destinations in the boundaries, but this may be implemented also in a centralized fashion at the route reflectors.
  • A joint prefix-policy covering destinations in multiple tables can be referred at each address family. Simple configuration.
  • Beyond traditional advertise-external, route reflectors can keep now multiple paths for readvertisement purposes in default instance tables (without RD and without performing path selection among them). It is not only the option to advertise the best external (but backup) path from ASBRs, but also the option to propagate this backup path further down to another internal router or ASBR, without requiring additional sessions (like the diverse path approach)
  • path-count is actually a relevant parameter for the router where this is applied, but not for an AS-wide number of sibling paths. In border systems, think of add-path send as actually extending the best external this concept beyond 1 up to 'N' paths. Route reflectors may receive all these primary and backup paths from ASBRs and perform path selection among them, just to select the number of paths to be readvertised (but not considered external paths in this case, just the best 'N' paths selected from a centralized standpoint).
  • Asymmetric path-count values can be therefore configured, and may even be recommended depending on the intended traffic engineering scheme. Usually, a designer may conceive a reasonable value at ASBRs to internally readvertise all needed best external paths and at route reflectors, just as many paths needed for the required application at clients or non-clients (i.e. 2 may suffice for faster recovery), performing path selection among existing paths.
  • Different send and receive configurations are enterily feasible and alleviate migration efforts. When set inside a certain BGP hierarchy, it is split and different internal peer groups are created. By keeping common design guidelines within the same configured group (even during a migration process), resource consumption is consolidated at scale.

And I just gathered all these facts after tweaking and playing around with the feature. I am pretty sure you can find further pros or cons, or can share some other live experiences with BGP add-paths. Please join us in this discussion and let us know what you think! (comments or via twitter #TheRoutingChurn or @go_nzo).

 

Aug 12, 2015

Hello Gonzalo,

 

Let me first thank you for the great article which has been an enormous reference for the project on which we are trying to implement this technology at the ISP network that we run.

 

Second, when analyzing the introduction of add-path we concluded that instead of using a prefix-list for targeting which prefixes would be object of add-path and which not, it would be simpler to control this by using communities.

 

In the post you mention that the current Juniper design decision about not doing this control with communities is because add-paths consistency is at risk. Could you please explain a little bit more about this point? In which sense the consistency could be lost by introducing community control to add-paths?

 

regards,

 

Aldo Martinez

Aug 21, 2015
Juniper Employee

Hi Aldo,

the original add-path 'prefix-policy' was indeed designed to be
applicable per destination basis, rather than controlling this based on
any other attributes.

The main reason for this was to enforce 'consistent prefix selection'.
Diverse paths for the same destination can perfectly have different
route attributes (such as different communities) and best path selection
can perfectly change across them considering routing dynamics (i.e.
consider paths P1 and P2 to same destination D, where only P2 is tagged
with a given community), so selection criteria to apply add-path may
change in that case etc.

Therefore, by considering the destination itself as ultimate tie-breaker
for add-path enablement, prefix matching was enforced as unique,
consistent, reliable, persistent and global policy matching option.

On the other hand, this request has been indeed issued by other
customers on specific cases, so I would kindly encourage to get in touch
with your Juniper Networks account team to elevate this request and
provide further description on your specific use case for this.

Thanks,

Gonzalo

Oct 25, 2015

Gonzalo,

Thank you very much for the response. We actually contacted our Juniper Networks counterpart here in Tokyo and we talked about this matter as well. Hopefully we can get the fix released in a prompt date.

By the way, our main reason to introduce add-path is to have MPLS load balancing through the network (due to a multiple stage route reflector topology we face the well known hidden route problem). If you have any other solution that could help us on doing so, It'd be nice to hear about it.

(As far as I know, diverse path could be another solution but junos doesn't support it in current releases).

 

Regards,

 

Aldo

Oct 25, 2015
Juniper Employee

Hi Aldo,

 

You are very welcome to provide feedback to this blog! Thanks for chiming in.

 

A related feature that some others have considered for load balancing purposes in L3 VPN environments is multipath vpn-unequal-costequal-external-internal (http://www.juniper.net/techpubs/en_US/junos13.2/topics/usage-guidelines/vpns- configuring-protocol-i...

 

This would allow forwarding next hops of both the active route and alternative paths inside an L3VPN and independent of RD to be used for load balancing. That is, the decision is up to the ingress PE (paths already need to reach it), where it is able to effectively use them for load balancing purposes. Bear in mind though, that BGP multipath does not apply to paths that share the same MED-plus-IGP cost yet differ in IGP cost. Multipath path selection is based on the IGP cost metric, even if two paths have the same MED-plus-IGP cost. 

 

An alternative design approach would be to unilaterally enable add-path sending at the perimeter with a high path-count, and then just filter at the RR with an import policy matching on communities. This is not exactly the same and there is a certain waste of resources (some routes could be advertised, albeit not imported in the RRs), but maybe you could achieve youe design goal.

 

Anyway, these were just a couple of wild guesses... It is difficult to provide some reasonable assessment without further details. You may want to share them either here or unicast for privacy reasons, and we may collaborate on a best-effort basis Smiley Happy

 

Thanks,

 

Gonzalo

Mar 3, 2016

Gonzalo,

 

Thank you very much for your kind reply and sorry for being so late on mine.

Our network was being migrated from plain ip to MPLS and we needed this feature to have load balancing over MPLS.

At the end we pushed the idea to Juniper through Juniper Jp and I think the community control feature will be implemented in an upcoming junos release.

 

For a reference I'll give a look to your 'wild guesses' under L3 VPN environments. They seem interesting.

 

Keep up the good work and thanks again for the support.

 

 

Aldo

Feedback