Archive
Juniper Employee , Juniper Employee Juniper Employee
Archive
Granular BGP advertise-external for MPLS L3VPNs
Apr 11, 2014

Introduction

 

In some BGP multi-homed environments between networks, it is possible to achieve shorter convergence times by using certain features beyond traditional [RFC4271] BGP rules. There are multiple discussions and approaches to minimize downtime in redundant setups, while allowing at the same time more comprehensive path decision criteria.

 

One of these features is the so-called BGP advertise-external or best-external, so that Autonomous System Border Routers (ASBRs) also advertise the best externally received path, even though it may not result as the ultimate best path from the selection algorithm.

 

draft-ietf-idr-best-external-05 retrieves an old idea exposed in original [RFC1771] (later removed at [RFC4271]) so that any peer would not only advertise the best path, but also the best of the externally received paths. There are multiple benefits from this approach, as cited in draft-ietf-idr-best-external-05

 

   o  Faster restoration of connectivity.  By providing additional

      paths, that may be used to fail over in case the primary path

      becomes invalid or is withdrawn.

 

   o  Reducing inter-domain churn and traffic black-holing due to the

      readily available alternate path.

 

   o  Reducing the potential for situations of permanent IBGP route

      oscillation [RFC3345].

 

   o  Improving selection of lower MED routes from the same neighboring

      AS.

 

These benefits come at the cost of additional memory to save all these non-best paths and CPU in the control plane to process them.

 

Beyond draft-ietf-idr-best-external-05, there are multiple concepts and proposals based on saving non-best paths to improve convergence: from diverse paths (see [RFC6774] or http://ripe61.ripe.net/presentations/150-ripe-bgp-diverse-paths.pdf) to add paths (draft-ietf-idr-add-paths-09 or http://www.nanog.org/meetings/nanog48/presentations/Tuesday/Ward_AddPath_N48.pdf).

 

I will look into more related concepts in upcoming posts, but the idea here is to first show how to minimally address the convergence vs resource consumption tradeoff with granular configuration of best-external or advertise-external in Junos OS in a dual-homed L3VPN environment.

 

As opposed to other proposals, draft-ietf-idr-best-external-05 uniquely affects local route advertisement, and thus, a good advantage is that no further protocol artifacts or BGP attributes beyond plain [RFC4271] are needed, being less prone to interoperability issues or deployment challenges. Its foundation is a simple expansion of the local path decision algorithm to allow further paths be propagated without protocol extensions or additional capabilities, and this is why it is one of the simplest BGP-based approaches to enhance service resilience.

 

But at the same time, this is its major drawback: backup path eligibility is limited by the destination uniqueness and direct best-external advertisement from the respective ASBR.

 

Simplest solutions always prevail, and for that reason, there are some application scenarios where backup paths for improved convergence are required and this requirement can be simply addressed with Junos OS by means of additional policies applied in conjunction with advertise-external, without additional implementations or protocol extensions.

 

The resource consumption tradeoff driven by plain advertise-external can be therefore controlled in Junos OS with further granularity to just advertise the needed backup paths and eliminate further noise!

 

In this article, I will go through a very simplistic 3-phase design to illustrate where this feature combination could make more sense in the final stage. Because this functionality makes more sense at scale, please extrapolate the consequences to a more convoluted and real environment.

 

How does this feature get activated with Junos OS?

 

advertise-external as standalone configuration option aims at internal BGP (iBGP) mesh groups, route reflector clusters, or Autonomous Systems (AS) confederations:

 

[edit protocols bgp]

group iBGP {

     advertise-external;

     [...]

}

 

If it is configured at the BGP neighbor level, Junos OS requires that all neighbors with this option get commonly grouped (that is, configuration groups can be subsequently divided internally into other groups if this option is active for some neighbors only).

 

The rationale behind this implementation decision is to group and apply consistent backup path selection decisions with rules defined under draft-ietf-idr-best-external-05, Section 5, which describe advertisement rules among different types of peers.

 

Also, the advertise-external configuration option can be extended with an optional knob to allow advertising the best external route only if the route selection process reaches multiple exit discriminator (MED) metric evaluation.

 

But considering that this resource applies globally to an iBGP neighbor group... what if I want to have further granularity for the best-external advertised paths? What if I want to control the amount of backups paths that may be advertised from each ASBR to only golden services or simply control the amount of memory consumed in other internal peers and route reflectors?

 

Together with this configuration knob, the Junos OS advertise-external implementation allowed the policy language to identify the status of a certain path, as illustrated under http://www.juniper.net/techpubs/en_US/junos13.3/topics/example/bgp-advertise-inactive.html.

 

But the underlying idea in this article is not only to use the state policy condition for identification or community-tagging purposes, but effectively also for customized best-external backup path selection in an export policy towards the corresponding iBGP or cBGP neighbors:

 

[edit policy-options policy-statement granular-backup-advertisement]

juniper@R11# show

term inet0 {

    from {

        route-filter [...] exact;

        state inactive;

    }

    then {

        community add 65000:80;

        accept;

}

[...]

 

 

Therefore, just by leveraging prefix visibility options at ASBRs and combining a crafted BGP export policy using the state policy condition with the global advertise-external knob in the adequate scenario we can achieve this design goal with Junos OS!

 

Examples with Junosphere: Granular BGP advertise-external for multi-homed PE-CE connections


Let's analyze what happens when activating the configuration option by checking it with Junosphere (see attached topology files). Consider first our usual physical router topology:

 

 sample-junosphere-topology.jpg

Using this baseline topology, we are going to consider a dual Inter-AS Option A NNI between both networks to describe this topic. Ultimately, it is the same behavior as having a dual-homed CE to a service provider backbone, given the Inter-AS Option A NNI nature. In this example, R24 advertises 2 IPv4 and 2 IPv6 prefixes that get populated across the networks and are used for illustration purposes.

 

 

dual-optionA-bbgp-best-external-route-advertisement.jpg

  • Default behavior with active dual-homing scheme:

 

R24 originates the mentioned prefixes inside a VRF and these routes are correspondingly advertised to R15 and R19 as route reflectors inside AS65001:

 

juniper@R24> show route advertising-protocol bgp 192.168.255.15   

 

test-vpn.inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

* 192.0.2.0/24            Self                         100        I

* 198.51.100.0/24         Self                         100        I

 

test-vpn.inet6.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

* 2001:db8:6500::/64      Self                         100        I

  2001:db8:6500:1::/64

*                         Self                         100        I

 

Both R15 and R19 reflect these routes to all their cluster clients requiring them, including both R13 and R14 as network ASBRs with a matching VRF instantiated for the Inter-AS Option A NNIs:

 

juniper@R14> show route protocol bgp

 

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

 

inet.3: 12 destinations, 24 routes (12 active, 0 holddown, 0 hidden)

 

test-vpn.inet.0: 4 destinations, 6 routes (4 active, 0 holddown, 0 hidden)

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

 

192.0.2.0/24       *[BGP/170] 01:13:14, localpref 100, from 192.168.255.15

                      AS path: I, validation-state: unverified

                    > to 192.168.19.2 via ge-0/0/3.0, label-switched-path R14->R24

                    [BGP/170] 01:37:29, localpref 100, from 192.168.255.19

                      AS path: I, validation-state: unverified

                    > to 192.168.19.2 via ge-0/0/3.0, label-switched-path R14->R24

198.51.100.0/24    *[BGP/170] 01:13:14, localpref 100, from 192.168.255.15

                      AS path: I, validation-state: unverified

                    > to 192.168.19.2 via ge-0/0/3.0, label-switched-path R14->R24

                    [BGP/170] 01:37:29, localpref 100, from 192.168.255.19

                      AS path: I, validation-state: unverified

                    > to 192.168.19.2 via ge-0/0/3.0, label-switched-path R14->R24

 

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

 

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

 

bgp.l3vpn.0: 2 destinations, 4 routes (2 active, 0 holddown, 0 hidden)

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

 

192.168.255.24:1:192.0.2.0/24               

                   *[BGP/170] 01:13:14, localpref 100, from 192.168.255.15

                      AS path: I, validation-state: unverified

                    > to 192.168.19.2 via ge-0/0/3.0, label-switched-path R14->R24

                    [BGP/170] 01:37:29, localpref 100, from 192.168.255.19

                      AS path: I, validation-state: unverified

                    > to 192.168.19.2 via ge-0/0/3.0, label-switched-path R14->R24

192.168.255.24:1:198.51.100.0/24               

                   *[BGP/170] 01:13:14, localpref 100, from 192.168.255.15

                      AS path: I, validation-state: unverified

                    > to 192.168.19.2 via ge-0/0/3.0, label-switched-path R14->R24

                    [BGP/170] 01:37:29, localpref 100, from 192.168.255.19

                      AS path: I, validation-state: unverified

                    > to 192.168.19.2 via ge-0/0/3.0, label-switched-path R14->R24

 

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

 

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

 

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

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

 

2001:db8:6500::/64 *[BGP/170] 01:13:14, localpref 100, from 192.168.255.15

                      AS path: I, validation-state: unverified

                    > to 192.168.19.2 via ge-0/0/3.0, label-switched-path R14->R24

                    [BGP/170] 01:37:29, localpref 100, from 192.168.255.19

                      AS path: I, validation-state: unverified

                    > to 192.168.19.2 via ge-0/0/3.0, label-switched-path R14->R24

2001:db8:6500:1::/64

                   *[BGP/170] 01:13:14, localpref 100, from 192.168.255.15

                      AS path: I, validation-state: unverified

                    > to 192.168.19.2 via ge-0/0/3.0, label-switched-path R14->R24

                    [BGP/170] 01:37:29, localpref 100, from 192.168.255.19

                      AS path: I, validation-state: unverified

                    > to 192.168.19.2 via ge-0/0/3.0, label-switched-path R14->R24

 

bgp.l3vpn-inet6.0: 2 destinations, 4 routes (2 active, 0 holddown, 0 hidden)

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

 

192.168.255.24:1:2001:db8:6500::/64               

                   *[BGP/170] 01:13:14, localpref 100, from 192.168.255.15

                      AS path: I, validation-state: unverified

                    > to 192.168.19.2 via ge-0/0/3.0, label-switched-path R14->R24

                    [BGP/170] 01:37:29, localpref 100, from 192.168.255.19

                      AS path: I, validation-state: unverified

                    > to 192.168.19.2 via ge-0/0/3.0, label-switched-path R14->R24

192.168.255.24:1:2001:db8:6500:1::/64               

                   *[BGP/170] 01:13:14, localpref 100, from 192.168.255.15

                      AS path: I, validation-state: unverified

                    > to 192.168.19.2 via ge-0/0/3.0, label-switched-path R14->R24

                    [BGP/170] 01:37:29, localpref 100, from 192.168.255.19

                      AS path: I, validation-state: unverified

                    > to 192.168.19.2 via ge-0/0/3.0, label-switched-path R14->R24

 

Note that in this case each destination has two paths (one from each route reflector) but ultimately pointing to the same next hop (R24), because the next hop has not been rewritten during reflection.

 

These prefixes are advertised across both Inter-AS Option A NNIs inside the VRF by means of the eBGP PE-CE connection:

 

juniper@R14> show route advertising-protocol bgp 192.168.16.1 

 

test-vpn.inet.0: 4 destinations, 6 routes (4 active, 0 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

* 192.0.2.0/24            Self                                    I

* 198.51.100.0/24         Self                                    I

 

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

  Prefix          Nexthop           MED     Lclpref    AS path

* 2001:db8:6500::/64      Self                                    I

  2001:db8:6500:1::/64

*                         Self                                    I

 

 

and received inside R10 and R11 VRFs, which propagate these prefixes further to R16 and R12 as internal AS65000 route reflectors:

 

juniper@R11> show route advertising-protocol bgp 192.168.255.6

 

test-vpn.inet.0: 4 destinations, 8 routes (4 active, 0 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

* 192.0.2.0/24            Self                         100        65001 I

* 198.51.100.0/24         Self                         100        65001 I

 

test-vpn.inet6.0: 6 destinations, 10 routes (6 active, 0 holddown, 0 hidden)

  Prefix          Nexthop           MED     Lclpref    AS path

* 2001:db8:6500::/64      Self                         100        65001 I

  2001:db8:6500:1::/64

*                         Self                         100        65001 I

 

Because both R10 and R11 are part of the same AS and clients from the same clusters, they can see each other's routes. But the path selection algorithm in Junos OS moves down in this default case to externally learned routes being preferred at each ASBR instead of via iBGP from the parallel NNI:

 

juniper@R10> show route 2001:db8:6500::/64 protocol bgp extensive | match "BGP|Cluster|Originator|Protocol next hop|Reason"

        *BGP    Preference: 170/-101
                Task: BGP_65001.192.168.15.2+50127
                Announcement bits (2): 0-KRT 1-BGP_RT_Background
         BGP    Preference: 170/-101
                Protocol next hop: ::ffff:192.168.255.11
                Inactive reason: Not Best in its group - Interior > Exterior > Exterior via Interior
                Task: BGP_65000.192.168.255.6+63687
                AS path: 65001 I (Originator)
                Cluster list:  192.168.255.6
                Originator ID: 192.168.255.11
                Primary Routing Table bgp.l3vpn-inet6.0
                        Protocol next hop: ::ffff:192.168.255.11 Metric: 10
         BGP    Preference: 170/-101
                Protocol next hop: ::ffff:192.168.255.11
                Inactive reason: Not Best in its group - Interior > Exterior > Exterior via Interior
                Task: BGP_65000.192.168.255.12+179
                AS path: 65001 I (Originator)
                Cluster list:  192.168.255.12
                Originator ID: 192.168.255.11
                Primary Routing Table bgp.l3vpn-inet6.0
                        Protocol next hop: ::ffff:192.168.255.11 Metric: 10

 

 

So far so good, each ASBR just advertises its externally learned paths via MP-iBGP to the route reflectors and there is no mutual redistribution between both ASs.

 

In this design, we have opted for a per-router route distinguisher (RD) scheme. Considering this unique route distinguisher scheme at R10 and R11 VRFs, R6 and R12 detect per default multiple paths for the same ultimate destinations, each prefix attached with either R10 or R11's route distinguishers, as ASBRs for this dual route exchange, and do not perform local path selection because the VRF is not locally defined:

 

juniper@R6> show route protocol bgp

 

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

 

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)

 

bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

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

 

192.168.255.10:1:192.0.2.0/24               

                   *[BGP/170] 02:29:19, 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

192.168.255.10:1:198.51.100.0/24               

                   *[BGP/170] 02:29:19, 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

192.168.255.11:1:192.0.2.0/24               

                   *[BGP/170] 02:29:15, localpref 100, 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

192.168.255.11:1:198.51.100.0/24               

                   *[BGP/170] 02:29:15, localpref 100, 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

 

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

 

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

 

bgp.l3vpn-inet6.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

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

 

192.168.255.10:1:2001:db8:6500::/64               

                   *[BGP/170] 02:29:19, 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

192.168.255.10:1:2001:db8:6500:1::/64               

                   *[BGP/170] 02:29:19, 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

192.168.255.11:1:2001:db8:6500::/64               

                   *[BGP/170] 02:29:15, localpref 100, 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

192.168.255.11:1:2001:db8:6500:1::/64               

                   *[BGP/170] 02:29:15, localpref 100, 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

 

 

There are many discussions out there about choosing a given route distinguisher (RD) configuration scheme. Usually, the selection to use an AS-based vs an IP address-based scheme should rather be addressed as the tradeoff to use per-router or global per-network unique route distinguishers. Unique per-router RDs serve to improve convergence and redundant path coverage at the cost of additional memory and CPU cycle consumption.

 

This very simple example can illustrate at this point this debate: R6 and R12 as route reflectors still keep diverse paths for the same ultimate destination, because each prefix is attached with a different per-router RD. Effectively, both route reflectors keep redundant active paths in their routing tables and reflect all of them to their clients, ensuring path diversity across both NNIs without further route advertisement. This comes at the cost of not performing path selection between both paths (as if they would have the same RD) in the route reflectors and keeping this redundant scheme across RIB-ins in clients and diverse routing tables.

 

Nowadays, considering that route reflectors are usually granted with powerful CPU and memory resources, using unique per-router RDs is normally considered a best practice (with the usual exceptions) for convergence enhancement purposes.

 

Per default, other route reflector clients perform path selection once the route is then imported inside the VRF RIB and the RD is detached. For instance, R1 selects in this case the path across R11 because of a lower IGP metric:

 

juniper@R1> show route protocol bgp extensive | match "BGP|Cluster|Originator|Protocol next hop|Source|Inactive|entr" 

192.0.2.0/24 (4 entries, 1 announced)

        *BGP    Preference: 170/-101

                Source: 192.168.255.6

                Protocol next hop: 192.168.255.11

                Task: BGP_65000.192.168.255.6+63441

                AS path: 65001 I (Originator)

                Cluster list:  192.168.255.6

                Originator ID: 192.168.255.11

                Primary Routing Table bgp.l3vpn.0

                        Protocol next hop: 192.168.255.11 Metric: 80

         BGP    Preference: 170/-101

                Source: 192.168.255.12

                Protocol next hop: 192.168.255.11

                Inactive reason: Not Best in its group - Update source

                Task: BGP_65000.192.168.255.12+59128

                AS path: 65001 I (Originator)

                Cluster list:  192.168.255.12

                Originator ID: 192.168.255.11

                Primary Routing Table bgp.l3vpn.0

                        Protocol next hop: 192.168.255.11 Metric: 80

         BGP    Preference: 170/-101

                Source: 192.168.255.6

                Protocol next hop: 192.168.255.10

                Inactive reason: Not Best in its group - IGP metric

                Task: BGP_65000.192.168.255.6+63441

                AS path: 65001 I (Originator)

                Cluster list:  192.168.255.6

                Originator ID: 192.168.255.10

                Primary Routing Table bgp.l3vpn.0

                        Protocol next hop: 192.168.255.10 Metric: 90

         BGP    Preference: 170/-101

                Source: 192.168.255.12

                Protocol next hop: 192.168.255.10

                Inactive reason: Not Best in its group - IGP metric

                Task: BGP_65000.192.168.255.12+59128

                AS path: 65001 I (Originator)

                Cluster list:  192.168.255.12

                Originator ID: 192.168.255.10

                Primary Routing Table bgp.l3vpn.0

                        Protocol next hop: 192.168.255.10 Metric: 90

[...]

 

 

In this case, redundant paths reach the final router importing the routes, but what if there are some other route selection criteria than simple IGP metrics towards the endpoints? What if this scheme is enforced in a clear master/backup multi-homing scenario?

 

  • Master/backup dual-homing scheme:

 

Some usual connectivity scenarios in L3VPN environments cover master and backup uplinks for the CE. Backup links would need to get used only whenever master uplinks fail (or PE providing such primary upstream etc.) for business, bandwidth consumption or other design reasons.

 

The default situation described above leaves the ultimate path decision being driven by the IGP metric towards the PE or ASBR. Now, another BGP attribute would need to decide the tie-break between both NNIs to ensure that one of them is being primarily used by all other internal PEs inside AS6500.

 

Let's consider for instance a lower local preference value being set for all received routes in R11, so that it is being used for the backup path:

 

[edit policy-options]
+   policy-statement backup {
+       term localpref80 {
+           from protocol bgp;
+           then {
+               local-preference 80;
+           }
+       }
+   }
[edit routing-instances test-vpn protocols bgp group eBGP]
+      import backup;

dual-optionA-primary-backup-bgp-best-external-route-advertisement.jpg

Now, R11 is considered backup and its path selection points to R10 as preferred exit point:

 

juniper@R11> show route 2001:db8:6500::/64 protocol bgp extensive | match "BGP|Cluster|Originator|Protocol next hop|Reason"  
        *BGP    Preference: 170/-101
                Protocol next hop: ::ffff:192.168.255.10
                Task: BGP_65000.192.168.255.6+52307
                AS path: 65001 I (Originator)
                Cluster list:  192.168.255.6
                Originator ID: 192.168.255.10
                Primary Routing Table bgp.l3vpn-inet6.0
                        Protocol next hop: ::ffff:192.168.255.10 Metric: 10
         BGP    Preference: 170/-101
                Protocol next hop: ::ffff:192.168.255.10
                Inactive reason: Not Best in its group - Update source
                Task: BGP_65000.192.168.255.12+179
                AS path: 65001 I (Originator)
                Cluster list:  192.168.255.12
                Originator ID: 192.168.255.10
                Primary Routing Table bgp.l3vpn-inet6.0
                        Protocol next hop: ::ffff:192.168.255.10 Metric: 10
         BGP    Preference: 170/-81
                Inactive reason: Local Preference
                Task: BGP_65001.192.168.16.2+179

 

 

Per default, only best paths are advertised towards route reflectors, and because R11 now chooses already reflected paths from R10 inside the VRF RIBs, R11 does not reflect the externally learned paths towards the route reflectors:

 

juniper@R11> show route advertising-protocol bgp 192.168.255.6

  

juniper@R11> show route advertising-protocol bgp 192.168.255.12  

 

As a consequence, route reflectors only store the globally best paths, which get reflected to all clients.

 

juniper@R6> show route protocol bgp

 

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

 

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)

 

bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

 

192.168.255.10:1:192.0.2.0/24               
                   *[BGP/170] 02:51:00, 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
192.168.255.10:1:198.51.100.0/24               
                   *[BGP/170] 02:51:00, 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

 

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

 

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

 

bgp.l3vpn-inet6.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

 

192.168.255.10:1:2001:db8:6500::/64               
                   *[BGP/170] 02:51:00, 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
192.168.255.10:1:2001:db8:6500:1::/64               
                   *[BGP/170] 02:51:00, 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

 

While this is good from a resource preservation perspective at scale, neither route reflectors nor other clients have backup paths available to speed up convergence. Again, the known tradeoff.

 

But, is there a way to achieve the adequate balance between both? Can I design my network with Junos OS to just make the necessary backup paths available across the network with precise control?

 

 

  • Granular BGP advertise-external with master/backup dual-homing scheme:

 

The above depicted situation is a perfect fit for best-external or advertise-external in Junos OS in a L3VPN environment. The feature could get activated in R11, applied to multiple BGP AFI/SAFIs and best external paths from this ASBR, despite not being selected best in the algorithm, can get advertised towards the route reflectors.

 

Because we have chosen different per-router route distinguishers (RDs), both paths are visible in the route reflectors, but the RD provides the needed disambiguation to still readvertise both of them to each cluster client and have all backup paths available in every internal PE.

 

But simply enabling the global advertise-external knob in Junos OS and applying it to all backup paths can be cumbersome at scale if you have scarce resources, are running out of control plane (or forwarding plane with other tweaks) memory at this point or just want to decide which destinations are granted with enhanced SLAs.

 

http://www.juniper.net/techpubs/en_US/junos13.3/topics/example/bgp-advertise-inactive.html explains additional policy language available to identify inactive paths in this scenario and potentially tagging them. This can be used to mark inactive paths when being advertised to the route reflector, and then perform some filtering actions there for further advertisement.

 

However, as shown in Inter-AS Option A+B for IPv4 and IPv6 L3VPNs - Part III (Aggregation and filtering), this ASBR or PE can directly perform identification and filtering actions at the global level (while still exporting all routes via vrf-export policies in case of master uplink failure).

 

Effectively, we can combine all these policy language capabilities with advertise-external and construct crafted backup path advertisements for just only certain destinations! This allows us creating specific best-external advertisement policies at the network perimeter using per-router route distinguishers with granularity further than per-VRF, even achieving per-prefix inside each L3VPN, without further configuration needed in the route reflectors.

 

As representative example, let's consider that just one of both IPv4 destinations and just one of both IPv6 destinations requires enhanced convergence SLAs with a backup path to be advertised from R11:

 

[edit protocols bgp]

+     vpn-apply-export;

[edit protocols bgp group iBGP]
+     advertise-external;
+     export granular-backup-advertisement;
[edit policy-options]
+   policy-statement granular-backup-advertisement {
+       term inet0 {
+           from {
+               route-filter 192.0.2.0/24 exact;
+               state inactive;
+           }
+           then accept;
+       }
+       term inet60 {
+           from {
+               route-filter 2001:db8:6500::/64 exact;
+               state inactive;
+           }
+           then accept;
+       }
+       term default-inactive {
+           from state inactive;
+           then reject;
+       }
+   }

dual-optionA-final-primary-backup-bgp-best-external-route-advertisement.jpg

 

In this case, the state attribute enables the necessary distinction in the policy language to determine which best external paths need to be advertised to the route reflectors:

 

juniper@R11> show route advertising-protocol bgp 192.168.255.12   

 

test-vpn.inet.0: 4 destinations, 8 routes (4 active, 1 holddown, 0 hidden)
  Prefix          Nexthop           MED     Lclpref    AS path
  192.0.2.0/24            Self                         80         65001 I

 

test-vpn.inet6.0: 6 destinations, 10 routes (6 active, 0 holddown, 0 hidden)
  Prefix          Nexthop           MED     Lclpref    AS path
  2001:db8:6500::/64      Self                         80         65001 I

 

juniper@R11> show route advertising-protocol bgp 192.168.255.6    

 

test-vpn.inet.0: 4 destinations, 8 routes (4 active, 1 holddown, 0 hidden)
  Prefix          Nexthop           MED     Lclpref    AS path
  192.0.2.0/24            Self                         80         65001 I

 

test-vpn.inet6.0: 6 destinations, 10 routes (6 active, 0 holddown, 0 hidden)
  Prefix          Nexthop           MED     Lclpref    AS path
  2001:db8:6500::/64      Self                         80         65001 I

 

In fact, best and non-best paths are now received and kept at route reflectors for the intended destinations, because different RDs are used and prefixes are therefore disambiguated:

 

juniper@R6> show route protocol bgp   

 

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

 

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)

 

bgp.l3vpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

 

192.168.255.10:1:192.0.2.0/24               
                   *[BGP/170] 10:13:01, 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
192.168.255.10:1:198.51.100.0/24               
                   *[BGP/170] 10:13:01, 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
192.168.255.11:1:192.0.2.0/24               
                   *[BGP/170] 00:05:00, 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

 

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

 

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

 

bgp.l3vpn-inet6.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

 

192.168.255.10:1:2001:db8:6500::/64               
                   *[BGP/170] 10:13:01, 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
192.168.255.10:1:2001:db8:6500:1::/64               
                   *[BGP/170] 10:13:01, 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
192.168.255.11:1:2001:db8:6500::/64               
                   *[BGP/170] 00:03:05, 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

 

and all these paths are readvertised to other cluster clients, like R1:

 

juniper@R6> show route advertising-protocol bgp 192.168.255.1   

 

bgp.l3vpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
  Prefix          Nexthop           MED     Lclpref    AS path
  192.168.255.10:1:192.0.2.0/24                   
*                         192.168.255.10               100        65001 I
  192.168.255.10:1:198.51.100.0/24                   
*                         192.168.255.10               100        65001 I
  192.168.255.11:1:192.0.2.0/24                   
*                         192.168.255.11               80         65001 I

 

bgp.l3vpn-inet6.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
  Prefix          Nexthop           MED     Lclpref    AS path
  192.168.255.10:1:2001:db8:6500::/64                   
*                         ::ffff:192.168.255.10        100        65001 I
  192.168.255.10:1:2001:db8:6500:1::/64                   
*                         ::ffff:192.168.255.10        100        65001 I
  192.168.255.11:1:2001:db8:6500::/64                   
*                         ::ffff:192.168.255.11        80         65001 I

 

 

R1 has received granular backup paths that enable for these services improved convergence and global restoration options when combined with other features:

 

juniper@R1> show route protocol bgp

 

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

 

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

 

test-vpn.inet.0: 2 destinations, 6 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

 

192.0.2.0/24       *[BGP/170] 10:14:49, localpref 100, 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->R10
                    [BGP/170] 09:51:16, localpref 100, 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->R10
                    [BGP/170] 00:06:49, localpref 80, 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->R11
                    [BGP/170] 00:06:49, localpref 80, 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->R11
198.51.100.0/24    *[BGP/170] 10:14:49, localpref 100, 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->R10
                    [BGP/170] 09:51:16, localpref 100, 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->R10

[...]

 

 

Conclusions

 
This article just depicts a very simple scenario with dual Inter-AS Option A NNIs for a small amount of IPv4 and IPv6 prefixes advertised inside a common L3VPN. Notwithstanding, it illustrates a very simple configuration to craft the BGP advertise-external feature offered by Junos OS in a L3VPN environment that can be applied for a scaled setup without adding configuration complexity and keeping the resource consumption control on the external interface.

 

The following feature aspects are worth highlighting here:

  • The BGP advertise-external knob is global and applies alone to all address families.
  • Different policies can be configured but need to be applied for the MP-iBGP groups. This example has been based on simple prefix filtering together with the state inactive condition, but other policy language conditions are also available here.
  • This scheme is easily feasible in such L3VPN environment when using per-router RD assignment scheme
  • Under these conditions, backup path advertisement towards each PE can be entirely controlled at the corresponding backup PE or ASBR

This initial example just covers crafted advertise-external application. Improving convergence with extra backup paths is a wide topic that has been covered also with other design approaches, such as diverse paths (see [RFC6774] or http://ripe61.ripe.net/presentations/150-ripe-bgp-diverse-paths.pdf) or add paths (draft-ietf-idr-add-paths-09 or http://www.nanog.org/meetings/nanog48/presentations/Tuesday/Ward_AddPath_N48.pdf).

 

Certainly, advertise-external is probably the least complete and sophisticated option of all of them, but considering that RD can provide the needful disambiguation in L3VPNs for backup path reflection, it can be used as the simplest locally configurable convergence improvement mechanism in this scenario.

 

How can this topic be addressed in default instance routing tables or other environments? advertise-external can be applied, but there are further drawbacks and maybe other alternatives become more appealing. In any case, topics for next posts!

 

In the meantime, please be our guest, chime in with your feedback via comments or tweets at @go_nzo or using the #TheRoutingChurn hashtag!

 

Apr 28, 2014
Distinguished Expert

Love your posts Gonzalo - the technical depth is excellent - keep them coming!!

Feb 23, 2015

Hi Gonzalo,

 

Thank you for the detailed description for Opt.A NNI.

But what I found out is that for some reason the “advertise best external” feature is somehow disabled when the NNI is configured as Opt.B (VPNv4 eBGP between the ASBRs)

So I’d like to ask if there’s any knob/configuration trick that can be used to make the feature work again.

Thank you very much

 

adam

adamv0025 at gmail

Feb 27, 2015
Juniper Employee

Hi Adam,

 

please check https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR1023693 for your scenario.

 

Please check with JTAC and/or your support channel to let them know about your use case and get this fixed asap.

 

Thanks for bringing up this issue,

 

Gonzalo

Feedback