Archive
Juniper Employee , Juniper Employee Juniper Employee
Archive
Using IPv6 Labeled Unicast BGP for 6PE
Feb 8, 2013

The 6PE model is based on IPv6 labeled unicast BGP (BGP-LU) as routing information and distribution vehicle among different systems. Although configuring IPv6 BGP-LU is simple with Junos OS, there are some relevant details to analyze. This post reviews the needed protocol resources, applicable Junos OS configuration and some expected results in the field. Feedback about this topic would be much appreciated, please feel free to chime in!

 

The IPv6 labeled-unicast MP-BGP family 

 

[RFC2545] defined the support for IPv6 address family routes with Border Gateway Protocol (BGP) version 4 by means of specific Multiprotocol extensions. This was the first building block to enable IPv6 routing distribution via BGP.

 

Later, [RFC3107] described mechanisms and structures needed to associate an MPLS label to a BGP route. This implementation has been traditionally called Labeled BGP (L-BGP) or Labeled Unicast BGP (BGP-LU) and basically makes use of BGP structures to distribute MPLS label bindings.

 

BGP-LU is a tremendously useful MPLS label distribution protocol between adjacent Label Switched Routers (LSRs), among Autonomous System Border Routers (ASBRs) to distribute label bindings across different domains (and therefore allowing InterAS MPLS LSPs) and may act as MPLS label binding transport in an overlay hierarchy over another internal MPLS label distribution protocol, such as the Label Distribution Protocol (LDP) or the Resource Reservation Protocol with Traffic Engineering extensions (RSVP-TE).

 

In the case of the 6PE model, the MP-BGP sessions may be established between peers represented by IPv4 addresses, but they use the IPv6 BGP-LU family. This protocol can be then used to distribute label bindings for IPv6 prefixes between IPv4-based control planes.

 

 

Next Hops for the 6PE model

 

Unlike IPv4, IPv6 introduces different scopes for unicast addresses; mostly global and link-local addresses as per [RFC4007] (site-local got deprecated with [RFC3879] because the concept was too fuzzy, and we take Unique Local Addresses apart). At a first sight, link-local addresses may not look suitable to be conveyed in the NEXT HOP attribute of a particular route, but there are certain IPv6 mechanisms, such as ICMP Redirect Messages for Neighbor Discovery, or protocols, such as RIPng that rely on link-local addresses to be used.

 

In the 6PE model, the generic situation (particularly in the case of internal BGP (iBGP)) results in a single global IPv6 address being set as BGP NEXT HOP and the removal of link-local addresses when advertising such routes to iBGP peers.

 

A proper recursive resolution to a valid Next Hop for IPv6 prefixes requires that BGP Next Hop addresses are represented embedded in IPv6 prefixes. IPv4-Mapped IPv6 addresses represent a transition mechanism in which the IPv4 prefix is automatically and uniquely embedded into the IPv6 address and is an adequate tool for this purpose. These IPv4-mapped IPv6 addresses are defined in [RFC4291] Section 2.5.5.2 to represent the addresses of IPv4 nodes as IPv6 addresses:

 

 

6PE-IPv4-mapped.jpg

 

 

 

The IPv6 labeled-unicast NLRI format 

 

To represent such label binding associated to a BGP route, the MPLS label is encoded into the Network Layer Reachability Information (NLRI) field of the attribute, and the concrete SAFI value of 4 indicates that such NLRI is used for label binding. This NLRI encoding is performed by setting triples of length, label, prefix. This looks like the following:

6PE-nlri-triple.jpg

For proper scalability, multiple routes to a single or several destinations can be easily transported, advertised and withdrawn. It simply requires that a specific label is bound to each route and they may all be carried in the same BGP Update message.

 

 

Activating IPv6 BGP-LU with Junos OS

 

As mentioned in a previous post, a very good overview can be found at our Juniper Learning Byte: 6PE or under www.juniper.net/techpubs/en_US/junos12.2/information-products/topic-collections/fg-ipv6-islands-to-i...

 

The basic stage for the BGP AFI and SAFI activation is to include the corresponding family configuration in a BGP neighbor or group:

 

[edit protocols bgp]

group 6PE {

    [...]

    family inet6 {

        labeled-unicast {

            explicit-null;

        }

    }

    [...]

}

 

Note that  explicit-null  is included there. Junos OS implements a commit error to ensure that the administrator correlates both knobs, in case it is forgotten:

 

{master}[edit]

user@6PE# show | compare

[edit protocols bgp group 6PE family inet6 labeled-unicast]

-        explicit-null;

 

{master}[edit]

user@6PE# commit synchronize and-quit

[edit protocols bgp group 6PE family inet6]

  'labeled-unicast'

    Missing mandatory statement: 'explicit-null'

error: commit failed: (missing mandatory statements)

 

 

And the reason for that configuration knob comes now...

 

 

6PE label allocation

 

Let's look at the BGP Updates with these NLRIs on the wire, as described above. Assuming a multivendor topology between a Junos OS PE and a MP-iBGP Route Reflector from another vendor, a BGP Update with some IPv6 labeled-unicast routes looks as follows:

 

 

6PE-non-null-label-update.jpg

 

 

or alternatively under traceoptions:

 

Sep 17 12:25:53.069869 BGP RECV 192.168.255.110+20363 -> 192.168.255.55+179
Sep 17 12:25:53.069883 BGP RECV message type 2 (Update) length 98
Sep 17 12:25:53.069889 BGP RECV Update PDU length 98
Sep 17 12:25:53.069894 BGP RECV flags 0x40 code Origin(1): IGP
Sep 17 12:25:53.069903 BGP RECV flags 0x40 code ASPath(2) length 10: [...] 56464
Sep 17 12:25:53.069909 BGP RECV flags 0x80 code MultiExitDisc(4): 0
Sep 17 12:25:53.069914 BGP RECV flags 0x40 code LocalPref(5): 100
Sep 17 12:25:53.069920 BGP RECV flags 0x80 code MP_reach(14): AFI/SAFI 2/4
Sep 17 12:25:53.069928 BGP RECV         nhop ::ffff:192.168.255.110 len 16
Sep 17 12:25:53.069937 BGP RECV         2a00:f300:25::/48 (label 893) , 2a00:f300:d3::/48 (label 894)
Sep 17 12:25:53.069948 bgp_should_merge_as2_and_as4_path():2111 AS4-Peer 192.168.255.110 (Internal AS 64531)(RECV): No AS4 Path or Aggregator4 Path Attribute received
Sep 17 12:25:53.069955 bgp_process_aspath_and_aggr_attr():2480 AS4-Peer 192.168.255.110 (Internal AS 64531)(RECV): bgp_should_merge_as2_and_as4_path() says NO
Sep 17 12:25:53.069963 bgp_process_aspath_and_aggr_attr():2517 AS4-Peer 192.168.255.110 (Internal AS 64531)(RECV): Merged asp: path_len 16, path_seg_len 2, path2_len 0, path2_seg_len 0, path4_len 0, path4_seg_len 0, path_attr_len 0, path_aggr_len 0, path4_aggr_len 0, path4_flags 0x0, path_flags 0x0
Sep 17 12:25:53.069974 bgp_rcv_nlri: Peer 192.168.255.110 (Internal AS 64531)
Sep 17 12:25:53.069981 bgp_rcv_nlri: 2a00:f300:25::/48
Sep 17 12:25:53.070004 ADD      2a00:f300:25::/48   nhid 0  BGP      pref 170/-101 metric 0/0 <Hidden Int Ext>  as 64531
Sep 17 12:25:53.070048 CHANGE   2a00:f300:25::/48   nhid 0 gw 192.168.210.38  BGP      pref 170/-101 metric 0/70 <Active Int Ext>  as 64531
Sep 17 12:25:53.070063 CHANGE   2a00:f300:25::/48   nhid 0 gw 192.168.210.38  BGP      pref 170/-101 metric 0/70 <Active Int Ext>  as 64531
Sep 17 12:25:53.070072 bgp_rcv_nlri: 2a00:f300:d3::/48
Sep 17 12:25:53.070093 ADD      2a00:f300:d3::/48   nhid 0  BGP      pref 170/-101 metric 0/0 <Hidden Int Ext>  as 64531
Sep 17 12:25:53.070134 CHANGE   2a00:f300:d3::/48   nhid 0 gw 192.168.210.38  BGP      pref 170/-101 metric 0/70 <Active Int Ext>  as 64531
Sep 17 12:25:53.070148 CHANGE   2a00:f300:d3::/48   nhid 0 gw 192.168.210.38  BGP      pref 170/-101 metric 0/70 <Active Int Ext>  as 64531

 

so the MP_REACH_NLRI format includes that specific AFI/SAFI combination and the NLRI for labeled-unicast routes. But having a look at the labels again... values seem arbitrary.

 

We may also check another update from the same MP-iBGP Route Reflector. In this case, self-reflected routes (that is, originated by the same 6PE and reflected back):

 

 

6PE-null-label-update.jpg

 

 

or alternatively under traceoptions:

 

Sep 17 12:25:52.030650

Sep 17 12:25:52.030650 BGP SEND 192.168.255.55+179 -> 192.168.255.110+20363

Sep 17 12:25:52.030658 BGP SEND message type 2 (Update) length 73

Sep 17 12:25:52.030664 BGP SEND Update PDU length 73

Sep 17 12:25:52.030670 BGP SEND flags 0x40 code Origin(1): IGP

Sep 17 12:25:52.030676 BGP SEND flags 0x40 code ASPath(2) length 0: <null>

Sep 17 12:25:52.030682 BGP SEND flags 0x40 code LocalPref(5): 100

Sep 17 12:25:52.030688 BGP SEND flags 0x90 code MP_reach(14): AFI/SAFI 2/4

Sep 17 12:25:52.030696 BGP SEND         nhop ::ffff:192.168.255.55 len 16

Sep 17 12:25:52.030704 BGP SEND         2a02:9001:14:8000::/49 (label 2)

[...]

Sep 17 12:25:52.219368 BGP RECV 192.168.255.110+20363 -> 192.168.255.55+179

Sep 17 12:25:52.219377 BGP RECV message type 2 (Update) length 96

Sep 17 12:25:52.219382 BGP RECV Update PDU length 96

Sep 17 12:25:52.219388 BGP RECV flags 0x40 code Origin(1): IGP

Sep 17 12:25:52.219395 BGP RECV flags 0x40 code ASPath(2) length 0: <null>

Sep 17 12:25:52.219400 BGP RECV flags 0x40 code LocalPref(5): 100

Sep 17 12:25:52.219407 BGP RECV flags 0x80 code Cluster_List(10): 192.168.255.110

Sep 17 12:25:52.219441 BGP RECV flags 0x80 code Originator_Id(9) 192.168.255.55

Sep 17 12:25:52.219447 BGP RECV flags 0x80 code MP_reach(14): AFI/SAFI 2/4

Sep 17 12:25:52.219456 BGP RECV         nhop ::ffff:192.168.255.55 len 16

Sep 17 12:25:52.219467 BGP RECV         2a02:9001:14:8000::/49 (label 2) , fd:3:100::/47 (label 2)

[...]

Sep 17 12:25:52.219508 Originator ours. Rejecting update

 

and in this particular case, the constantly allocated label is 2.

 

[RFC3032] reserves this value as the "The IPv6 EXPLICIT NULL label". So, what type of labels shall be expected in this scenario?

 

[RFC4798] notes the following:

 

   The label bound by MP-BGP to the IPv6 prefix indicates to the egress

   6PE Router that the packet is an IPv6 packet.  This label advertised

   by the egress 6PE Router with MP-BGP MAY be an arbitrary label value,

   which identifies an IPv6 routing context or outgoing interface to

   send the packet to, or MAY be the IPv6 Explicit Null Label.  An

   ingress 6PE Router MUST be able to accept any such advertised label.

 

 

So, the current understanding in Junos OS is that 2 suffices for identification and resolution in this environment. The key component is that this prefix needs to be resolved in the global IPv6 RIB (inet6.0 in Junos wording) so the prefix by itself should provide uniqueness, in order to identify and resolve the route. It is not constrained to a particular private RIB or context (as a VRF) where another distinguisher would be needed.

 

 

Conclusions

 

The summary is that IPv6 BGP-LU requires specific Next Hop types and implements label binding per IPv6 prefix. In a 6PE interop environment one should expect Junos OS devices allocating label 2 for originated IPv6 prefixes and one may expect others allocating arbitrary labels.

 

Does it pose a problem for route identification or resolution? Not in the case of a Junos OS 6PE router (aligned with standard excerpt above). Using the same example above:

 

{master}

user@6PE> show route 2a00:f300:25::/48 extensive   

 

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

2a00:f300:25::/48 (1 entry, 1 announced)

TSI:

KRT in-kernel 2a00:f300:25::/48 -> {indirect(1049426)}

        *BGP    Preference: 170/-101

                Next hop type: Indirect

                Address: 0x9b281c0

                Next-hop reference count: 3

                Source: 192.168.255.110

                Next hop type: Router, Next hop index: 21131

                Next hop: 192.168.210.38 via xe-0/2/0.0, selected

                Label operation: Push 893, Push 389480(top)

                Label TTL action: prop-ttl, prop-ttl(top)

                Protocol next hop: ::ffff:192.168.255.110

                Push 893

                Indirect next hop: 96caf40 1049426

                State: <Active Int Ext>

                Local AS: 64531 Peer AS: 64531

[...]

            ::ffff:192.168.255.110/128 Originating RIB: inet6.3

              Metric: 70              Node path count: 1

              Forwarding nexthops: 1

                Nexthop: 192.168.210.38 via xe-0/2/0.0

 

{master}

user@6PE> show route 2a00:f300:d3::/48 extensive   

 

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

2a00:f300:d3::/48 (1 entry, 1 announced)

TSI:

KRT in-kernel 2a00:f300:d3::/48 -> {indirect(1049427)}

        *BGP    Preference: 170/-101

                Next hop type: Indirect

                Address: 0x9b28370

                Next-hop reference count: 3

                Source: 192.168.255.110

                Next hop type: Router, Next hop index: 21130

                Next hop: 192.168.210.38 via xe-0/2/0.0, selected

                Label operation: Push 894, Push 389480(top)

                Label TTL action: prop-ttl, prop-ttl(top)

                Protocol next hop: ::ffff:192.168.255.110

                Push 894

                Indirect next hop: 96cb03c 1049427

                State: <Active Int Ext>

                Local AS: 64531 Peer AS: 64531

[...]

            ::ffff:192.168.255.110/128 Originating RIB: inet6.3

              Metric: 70              Node path count: 1

              Forwarding nexthops: 1

                Nexthop: 192.168.210.38 via xe-0/2/0.0

 

 

If you can provide some feedback about any related story or for any other comment, please be our guest and post a comment or or tweet back at @go_nzo !

Jul 24, 2016
gaurav.gosain
just on the label allocation per prefix . Pe2- RR-- PE1 ---asbr asbr adv 2 prefixes to Pe1 and then to RR & to PE2 ... Remote PE2 see the same label allocation for both prefixes . tried to advertise another prefix using ASBR2 -- PE1 . Pe2 see same label allocation and traffic passes through for all adv prefixes // any thoughts

@gonzalo wrote:

The 6PE model is based on IPv6 labeled unicast BGP (BGP-LU) as routing information and distribution vehicle among different systems. Although configuring IPv6 BGP-LU is simple with Junos OS, there are some relevant details to analyze. This post reviews the needed protocol resources, applicable Junos OS configuration and some expected results in the field. Feedback about this topic would be much appreciated, please feel free to chime in!

 

The IPv6 labeled-unicast MP-BGP family 

 

[RFC2545] defined the support for IPv6 address family routes with Border Gateway Protocol (BGP) version 4 by means of specific Multiprotocol extensions. This was the first building block to enable IPv6 routing distribution via BGP.

 

Later, [RFC3107] described mechanisms and structures needed to associate an MPLS label to a BGP route. This implementation has been traditionally called Labeled BGP (L-BGP) or Labeled Unicast BGP (BGP-LU) and basically makes use of BGP structures to distribute MPLS label bindings.

 

BGP-LU is a tremendously useful MPLS label distribution protocol between adjacent Label Switched Routers (LSRs), among Autonomous System Border Routers (ASBRs) to distribute label bindings across different domains (and therefore allowing InterAS MPLS LSPs) and may act as MPLS label binding transport in an overlay hierarchy over another internal MPLS label distribution protocol, such as the Label Distribution Protocol (LDP) or the Resource Reservation Protocol with Traffic Engineering extensions (RSVP-TE).

 

In the case of the 6PE model, the MP-BGP sessions may be established between peers represented by IPv4 addresses, but they use the IPv6 BGP-LU family. This protocol can be then used to distribute label bindings for IPv6 prefixes between IPv4-based control planes.

 

 

Next Hops for the 6PE model

 

Unlike IPv4, IPv6 introduces different scopes for unicast addresses; mostly global and link-local addresses as per [RFC4007] (site-local got deprecated with [RFC3879] because the concept was too fuzzy, and we take Unique Local Addresses apart). At a first sight, link-local addresses may not look suitable to be conveyed in the NEXT HOP attribute of a particular route, but there are certain IPv6 mechanisms, such as ICMP Redirect Messages for Neighbor Discovery, or protocols, such as RIPng that rely on link-local addresses to be used.

 

In the 6PE model, the generic situation (particularly in the case of internal BGP (iBGP)) results in a single global IPv6 address being set as BGP NEXT HOP and the removal of link-local addresses when advertising such routes to iBGP peers.

 

A proper recursive resolution to a valid Next Hop for IPv6 prefixes requires that BGP Next Hop addresses are represented embedded in IPv6 prefixes. IPv4-Mapped IPv6 addresses represent a transition mechanism in which the IPv4 prefix is automatically and uniquely embedded into the IPv6 address and is an adequate tool for this purpose. These IPv4-mapped IPv6 addresses are defined in [RFC4291] Section 2.5.5.2 to represent the addresses of IPv4 nodes as IPv6 addresses:

 

 

6PE-IPv4-mapped.jpg

 

 

 

The IPv6 labeled-unicast NLRI format 

 

To represent such label binding associated to a BGP route, the MPLS label is encoded into the Network Layer Reachability Information (NLRI) field of the attribute, and the concrete SAFI value of 4 indicates that such NLRI is used for label binding. This NLRI encoding is performed by setting triples of length, label, prefix. This looks like the following:

6PE-nlri-triple.jpg

For proper scalability, multiple routes to a single or several destinations can be easily transported, advertised and withdrawn. It simply requires that a specific label is bound to each route and they may all be carried in the same BGP Update message.

 

 

Activating IPv6 BGP-LU with Junos OS

 

As mentioned in a previous post, a very good overview can be found at our Juniper Learning Byte: 6PE or under www.juniper.net/techpubs/en_US/junos12.2/information-products/topic-collections/fg-ipv6-islands-to-i...

 

The basic stage for the BGP AFI and SAFI activation is to include the corresponding family configuration in a BGP neighbor or group:

 

[edit protocols bgp]

group 6PE {

    [...]

    family inet6 {

        labeled-unicast {

            explicit-null;

        }

    }

    [...]

}

 

Note that  explicit-null  is included there. Junos OS implements a commit error to ensure that the administrator correlates both knobs, in case it is forgotten:

 

{master}[edit]

user@6PE# show | compare

[edit protocols bgp group 6PE family inet6 labeled-unicast]

-        explicit-null;

 

{master}[edit]

user@6PE# commit synchronize and-quit

[edit protocols bgp group 6PE family inet6]

  'labeled-unicast'

    Missing mandatory statement: 'explicit-null'

error: commit failed: (missing mandatory statements)

 

 

And the reason for that configuration knob comes now...

 

 

6PE label allocation

 

Let's look at the BGP Updates with these NLRIs on the wire, as described above. Assuming a multivendor topology between a Junos OS PE and a MP-iBGP Route Reflector from another vendor, a BGP Update with some IPv6 labeled-unicast routes looks as follows:

 

 

6PE-non-null-label-update.jpg

 

 

or alternatively under traceoptions:

 

Sep 17 12:25:53.069869 BGP RECV 192.168.255.110+20363 -> 192.168.255.55+179
Sep 17 12:25:53.069883 BGP RECV message type 2 (Update) length 98
Sep 17 12:25:53.069889 BGP RECV Update PDU length 98
Sep 17 12:25:53.069894 BGP RECV flags 0x40 code Origin(1): IGP
Sep 17 12:25:53.069903 BGP RECV flags 0x40 code ASPath(2) length 10: [...] 56464
Sep 17 12:25:53.069909 BGP RECV flags 0x80 code MultiExitDisc(4): 0
Sep 17 12:25:53.069914 BGP RECV flags 0x40 code LocalPref(5): 100
Sep 17 12:25:53.069920 BGP RECV flags 0x80 code MP_reach(14): AFI/SAFI 2/4
Sep 17 12:25:53.069928 BGP RECV         nhop ::ffff:192.168.255.110 len 16
Sep 17 12:25:53.069937 BGP RECV         2a00:f300:25::/48 (label 893) , 2a00:f300:d3::/48 (label 894)
Sep 17 12:25:53.069948 bgp_should_merge_as2_and_as4_path():2111 AS4-Peer 192.168.255.110 (Internal AS 64531)(RECV): No AS4 Path or Aggregator4 Path Attribute received
Sep 17 12:25:53.069955 bgp_process_aspath_and_aggr_attr():2480 AS4-Peer 192.168.255.110 (Internal AS 64531)(RECV): bgp_should_merge_as2_and_as4_path() says NO
Sep 17 12:25:53.069963 bgp_process_aspath_and_aggr_attr():2517 AS4-Peer 192.168.255.110 (Internal AS 64531)(RECV): Merged asp: path_len 16, path_seg_len 2, path2_len 0, path2_seg_len 0, path4_len 0, path4_seg_len 0, path_attr_len 0, path_aggr_len 0, path4_aggr_len 0, path4_flags 0x0, path_flags 0x0
Sep 17 12:25:53.069974 bgp_rcv_nlri: Peer 192.168.255.110 (Internal AS 64531)
Sep 17 12:25:53.069981 bgp_rcv_nlri: 2a00:f300:25::/48
Sep 17 12:25:53.070004 ADD      2a00:f300:25::/48   nhid 0  BGP      pref 170/-101 metric 0/0 <Hidden Int Ext>  as 64531
Sep 17 12:25:53.070048 CHANGE   2a00:f300:25::/48   nhid 0 gw 192.168.210.38  BGP      pref 170/-101 metric 0/70 <Active Int Ext>  as 64531
Sep 17 12:25:53.070063 CHANGE   2a00:f300:25::/48   nhid 0 gw 192.168.210.38  BGP      pref 170/-101 metric 0/70 <Active Int Ext>  as 64531
Sep 17 12:25:53.070072 bgp_rcv_nlri: 2a00:f300:d3::/48
Sep 17 12:25:53.070093 ADD      2a00:f300:d3::/48   nhid 0  BGP      pref 170/-101 metric 0/0 <Hidden Int Ext>  as 64531
Sep 17 12:25:53.070134 CHANGE   2a00:f300:d3::/48   nhid 0 gw 192.168.210.38  BGP      pref 170/-101 metric 0/70 <Active Int Ext>  as 64531
Sep 17 12:25:53.070148 CHANGE   2a00:f300:d3::/48   nhid 0 gw 192.168.210.38  BGP      pref 170/-101 metric 0/70 <Active Int Ext>  as 64531

 

so the MP_REACH_NLRI format includes that specific AFI/SAFI combination and the NLRI for labeled-unicast routes. But having a look at the labels again... values seem arbitrary.

 

We may also check another update from the same MP-iBGP Route Reflector. In this case, self-reflected routes (that is, originated by the same 6PE and reflected back):

 

 

6PE-null-label-update.jpg

 

 

or alternatively under traceoptions:

 

Sep 17 12:25:52.030650

Sep 17 12:25:52.030650 BGP SEND 192.168.255.55+179 -> 192.168.255.110+20363

Sep 17 12:25:52.030658 BGP SEND message type 2 (Update) length 73

Sep 17 12:25:52.030664 BGP SEND Update PDU length 73

Sep 17 12:25:52.030670 BGP SEND flags 0x40 code Origin(1): IGP

Sep 17 12:25:52.030676 BGP SEND flags 0x40 code ASPath(2) length 0: <null>

Sep 17 12:25:52.030682 BGP SEND flags 0x40 code LocalPref(5): 100

Sep 17 12:25:52.030688 BGP SEND flags 0x90 code MP_reach(14): AFI/SAFI 2/4

Sep 17 12:25:52.030696 BGP SEND         nhop ::ffff:192.168.255.55 len 16

Sep 17 12:25:52.030704 BGP SEND         2a02:9001:14:8000::/49 (label 2)

[...]

Sep 17 12:25:52.219368 BGP RECV 192.168.255.110+20363 -> 192.168.255.55+179

Sep 17 12:25:52.219377 BGP RECV message type 2 (Update) length 96

Sep 17 12:25:52.219382 BGP RECV Update PDU length 96

Sep 17 12:25:52.219388 BGP RECV flags 0x40 code Origin(1): IGP

Sep 17 12:25:52.219395 BGP RECV flags 0x40 code ASPath(2) length 0: <null>

Sep 17 12:25:52.219400 BGP RECV flags 0x40 code LocalPref(5): 100

Sep 17 12:25:52.219407 BGP RECV flags 0x80 code Cluster_List(10): 192.168.255.110

Sep 17 12:25:52.219441 BGP RECV flags 0x80 code Originator_Id(9) 192.168.255.55

Sep 17 12:25:52.219447 BGP RECV flags 0x80 code MP_reach(14): AFI/SAFI 2/4

Sep 17 12:25:52.219456 BGP RECV         nhop ::ffff:192.168.255.55 len 16

Sep 17 12:25:52.219467 BGP RECV         2a02:9001:14:8000::/49 (label 2) , fd:3:100::/47 (label 2)

[...]

Sep 17 12:25:52.219508 Originator ours. Rejecting update

 

and in this particular case, the constantly allocated label is 2.

 

[RFC3032] reserves this value as the "The IPv6 EXPLICIT NULL label". So, what type of labels shall be expected in this scenario?

 

[RFC4798] notes the following:

 

   The label bound by MP-BGP to the IPv6 prefix indicates to the egress

   6PE Router that the packet is an IPv6 packet.  This label advertised

   by the egress 6PE Router with MP-BGP MAY be an arbitrary label value,

   which identifies an IPv6 routing context or outgoing interface to

   send the packet to, or MAY be the IPv6 Explicit Null Label.  An

   ingress 6PE Router MUST be able to accept any such advertised label.

 

 

So, the current understanding in Junos OS is that 2 suffices for identification and resolution in this environment. The key component is that this prefix needs to be resolved in the global IPv6 RIB (inet6.0 in Junos wording) so the prefix by itself should provide uniqueness, in order to identify and resolve the route. It is not constrained to a particular private RIB or context (as a VRF) where another distinguisher would be needed.

 

 

Conclusions

 

The summary is that IPv6 BGP-LU requires specific Next Hop types and implements label binding per IPv6 prefix. In a 6PE interop environment one should expect Junos OS devices allocating label 2 for originated IPv6 prefixes and one may expect others allocating arbitrary labels.

 

Does it pose a problem for route identification or resolution? Not in the case of a Junos OS 6PE router (aligned with standard excerpt above). Using the same example above:

 

{master}

user@6PE> show route 2a00:f300:25::/48 extensive   

 

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

2a00:f300:25::/48 (1 entry, 1 announced)

TSI:

KRT in-kernel 2a00:f300:25::/48 -> {indirect(1049426)}

        *BGP    Preference: 170/-101

                Next hop type: Indirect

                Address: 0x9b281c0

                Next-hop reference count: 3

                Source: 192.168.255.110

                Next hop type: Router, Next hop index: 21131

                Next hop: 192.168.210.38 via xe-0/2/0.0, selected

                Label operation: Push 893, Push 389480(top)

                Label TTL action: prop-ttl, prop-ttl(top)

                Protocol next hop: ::ffff:192.168.255.110

                Push 893

                Indirect next hop: 96caf40 1049426

                State: <Active Int Ext>

                Local AS: 64531 Peer AS: 64531

[...]

            ::ffff:192.168.255.110/128 Originating RIB: inet6.3

              Metric: 70              Node path count: 1

              Forwarding nexthops: 1

                Nexthop: 192.168.210.38 via xe-0/2/0.0

 

{master}

user@6PE> show route 2a00:f300:d3::/48 extensive   

 

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

2a00:f300:d3::/48 (1 entry, 1 announced)

TSI:

KRT in-kernel 2a00:f300:d3::/48 -> {indirect(1049427)}

        *BGP    Preference: 170/-101

                Next hop type: Indirect

                Address: 0x9b28370

                Next-hop reference count: 3

                Source: 192.168.255.110

                Next hop type: Router, Next hop index: 21130

                Next hop: 192.168.210.38 via xe-0/2/0.0, selected

                Label operation: Push 894, Push 389480(top)

                Label TTL action: prop-ttl, prop-ttl(top)

                Protocol next hop: ::ffff:192.168.255.110

                Push 894

                Indirect next hop: 96cb03c 1049427

                State: <Active Int Ext>

                Local AS: 64531 Peer AS: 64531

[...]

            ::ffff:192.168.255.110/128 Originating RIB: inet6.3

              Metric: 70              Node path count: 1

              Forwarding nexthops: 1

                Nexthop: 192.168.210.38 via xe-0/2/0.0

 

 

If you can provide some feedback about any related story or for any other comment, please be our guest and post a comment or or tweet back at @go_nzo !


Path dede:defe:dede:: from 1.255.255.2 Vector len 4. Val: 1 2 3 Label-switched-path r2-r1 Label operation: Push 2, Push 299824, Push 300048(top) Label TTL action: prop-ttl, prop-ttl, prop-ttl(top) Load balance label: Label 2: None; Label 299824: None; Label 300048: None; Session Id: 0x0 Protocol next hop: ::ffff:1.255.255.7 Label operation: Push 2 #### 2nd prefix from same pe Path dfdf:dfdf:dfdf:dfdf::1 from 1.255.255.2 Vector len 4. Val: 1 2 3 Label-switched-path r2-r1 Label operation: Push 2, Push 299824, Push 300048(top) Label TTL action: prop-ttl, prop-ttl, prop-ttl(top) Load balance label: Label 2: None; Label 299824: None; Label 300048: None; Label operation: Push 2 Label TTL action: prop-ttl Load balance label: Label 2: None; Indirect next hop: 0x98a9a3c 1048576 INH Session ID: 0x1f
Jul 25, 2016
Juniper Employee

Hi gaurav.gosain,

 

if I understood your comment correctly, please have a look at the per-prefix-label knob for BGP-LU:

http://www.juniper.net/documentation/en_US/junos15.1/topics/reference/configuration-statement/per-pr...

 

This should apply to allocate per-prefix labels in BGP-LU transit allocation use cases.

 

Thanks,

Gonzalo