Archive
Juniper Employee , Juniper Employee Juniper Employee
Archive
Traffic engineering inet6 shortcuts to connect IPv6 islands - Part II
Jun 7, 2013

Examples with Junosphere: End-to-end connectivity use case inside an AS with traffic-engineering inet6 shortcuts


Let's retake the same Junosphere topology we implemened with the traffic-engineering inet6 shortcuts feature from my previous Traffic engineering inet6 shortcuts to connect IPv6 islands - Part I post:

 

inet6-shortcuts-junosphere-topo.jpg

 

There are multiple end-to-end connectivity cases to review. Let's start with a single and simple scenario, such as:

inet6-shortcuts-calculations.jpg

 

 

We actually keep a single hop inside the network core with this simple path, but it suffices to start and illustrate how the lookup takes place in any case.

 

Considering first R1 and a certain inet6 BGP unicast route advertised from R6 for the lookup:

 

juniper@R1> show route protocol bgp extensive

[...]

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

2001:db8:6::/64 (1 entry, 1 announced)

TSI:

KRT in-kernel 2001:db8:6::/64 -> {indirect(262142)}

        *BGP    Preference: 170/-101

                Next hop type: Indirect

                Address: 0x929c698

                Next-hop reference count: 3

                Source: 2001:db8:0:ffff:192:168:255:6

                Next hop type: Router, Next hop index: 599

                Next hop: fe80::566b:2ff:feb0:f370 via ge-0/0/2.0, selected

                Session Id: 0xb

                Protocol next hop: 2001:db8:0:ffff:192:168:255:6

                Indirect next hop: 9128d00 262142 INH Session ID: 0xe

                State: <Active Int Ext>

 

Because of the inherent recursive resolution of this BGP route, we should actually be looking at the next hop. Considering that systems inject in this case next hop information in their own IS-IS LSPs (Link State PDUs here for IS-IS), the actual path is determined by the best path towards this next hop.

 

R1 correctly extracts the IPv6 prefix information for these next hops from the respective IS-IS TLVs from L1 LSPs (note Link State PDU here for IS-IS):

 

juniper@R1> show isis route inet6

 

IS-IS routing table             Current version: L1: 128 L2: 103

IPv4/IPv6 Routes

----------------

Prefix             L Version   Metric Type Interface       NH   Via

::/0               1     128       10 int  ge-0/0/2.0      IPV6 R3                

2001:db8:0:ffff:192:168:255:2/128 1     128       50 int ge-0/0/1.0 IPV6 R2               

2001:db8:0:ffff:192:168:255:3/128 1     128       10 int ge-0/0/2.0 IPV6 R3                

2001:db8:0:ffff:192:168:255:4/128 1     128       60 int ge-0/0/1.0 IPV6 R2                

2001:db8:0:ffff:192:168:255:5/128 1     128      110 int ge-0/0/1.0 IPV6 R2                

2001:db8:0:ffff:192:168:255:6/128 1     128       70 int ge-0/0/2.0 IPV6 R3                

2001:db8:0:ffff:192:168:255:7/128 1     128       20 int ge-0/0/2.0 IPV6 R3                

2001:db8:0:ffff:192:168:255:8/128 1     128      170 int ge-0/0/1.0 IPV6 R2                

2001:db8:0:ffff:192:168:255:9/128 1     128      120 int ge-0/0/1.0 IPV6 R2                

2001:db8:0:ffff:192:168:255:10/128 1     128       30 int ge-0/0/2.0 IPV6 R3                

2001:db8:0:ffff:192:168:255:11/128 1     128       40 int ge-0/0/2.0 IPV6 R3                

2001:db8:0:ffff:192:168:255:12/128 1     128      220 int ge-0/0/1.0 IPV6 R2          

 

This precise and specific information for optimal routing is obtained because the IS-IS L1L2 systems (R3 and R4) implement L2-to-L1 leaking policies for IPv6 prefixes as well, as explained in the Traffic engineering inet6 shortcuts to connect IPv6 islands - Part I post:

 

 

juniper@R1> show isis database R3 detail

IS-IS level 1 link-state database:

 

R3.00-00 Sequence: 0x15, Checksum: 0x29f, Lifetime: 64877 secs

   IS neighbor: R1.00                         Metric:       50

   IP prefix: 192.168.1.0/30                  Metric:       50 Internal Up

   IP prefix: 192.168.255.3/32                Metric:        0 Internal Up

   IP prefix: 192.168.255.6/32                Metric:       60 Internal Down

   IP prefix: 192.168.255.7/32                Metric:       10 Internal Down

   IP prefix: 192.168.255.10/32               Metric:       20 Internal Down

   IP prefix: 192.168.255.11/32               Metric:       30 Internal Down

   V6 prefix: 2001:db8:0:ffff:192:168:255:3/128 Metric:        0 Internal Up

   V6 prefix: 2001:db8:0:ffff:192:168:255:6/128 Metric:       60 Internal Down

   V6 prefix: 2001:db8:0:ffff:192:168:255:7/128 Metric:       10 Internal Down

   V6 prefix: 2001:db8:0:ffff:192:168:255:10/128 Metric:       20 Internal Down

   V6 prefix: 2001:db8:0:ffff:192:168:255:11/128 Metric:       30 Internal Down

[...]

 

Note the Down bit marked at the R3 L1 LSP (Link State PDU here for IS-IS) in the TLVs for IPv6 prefixes that have been leaked from the backbone to the L1 area.

 

This allows populating inet6.0 with optimal routing information for the BGP route next hops, natively derived from IS-IS LSPs:

 

juniper@R1> show route protocol isis table inet6.0

 

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

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

 

::/0               *[IS-IS/15] 19:33:38, metric 10

                    > to fe80::566b:2ff:feb0:e39e via ge-0/0/2.0

2001:db8:0:ffff:192:168:255:2/128

                   *[IS-IS/15] 19:34:39, metric 50

                    > to fe80::566b:2ff:feb0:e3a1 via ge-0/0/1.0

2001:db8:0:ffff:192:168:255:3/128

                   *[IS-IS/15] 19:34:16, metric 10

                    > to fe80::566b:2ff:feb0:e39e via ge-0/0/2.0

2001:db8:0:ffff:192:168:255:4/128

                   *[IS-IS/15] 00:00:59, metric 60

                    > to fe80::566b:2ff:feb0:e3a1 via ge-0/0/1.0

2001:db8:0:ffff:192:168:255:5/128

                   *[IS-IS/15] 19:32:05, metric 110

                    > to fe80::566b:2ff:feb0:e3a1 via ge-0/0/1.0

2001:db8:0:ffff:192:168:255:6/128

                   *[IS-IS/18] 00:14:35, metric 70

                    > to fe80::566b:2ff:feb0:e39e via ge-0/0/2.0

[...]

 

But actually, inet6.3 is empty in R1:

 

juniper@R1> show route table inet6.3

 

juniper@R1>

 

R1 resolves then a BGP route imported in inet6.0 with an IS-IS learned route imported in inet6.0. This is fine, because BGP in Junos OS looks for a next-hop prefix in both tables, preferring lowest preference and the .3 table route if it has to tie-break the decision with same preference values.

 

So far so good. This has been a plain IPv6 lookup with plain IPv6 and no MPLS next hop.

 

Looking now at R3 as the next hop, we should first inspect the BGP route:

 

juniper@R3> show route protocol bgp extensive

[...]

2001:db8:6::/64 (1 entry, 1 announced)

TSI:

KRT in-kernel 2001:db8:6::/64 -> {indirect(262142)}

        *BGP    Preference: 170/-101

                Next hop type: Indirect

                Address: 0x929db60

                Next-hop reference count: 3

                Source: 2001:db8:0:ffff:192:168:255:6

                Next hop type: Router, Next hop index: 612

                Next hop: 192.168.4.2 via ge-0/0/3.0 weight 0x1, selected

                Label-switched-path R3->R7

                Label operation: Push 2

                Label TTL action: prop-ttl

                Session Id: 0x5

                Protocol next hop: 2001:db8:0:ffff:192:168:255:6

                Indirect next hop: 9128d00 262142 INH Session ID: 0x7

                State: <Active Int Ext>

                Local AS: 65000 Peer AS: 65000

                Age: 7:22     Metric2: 60

[...]

 

 

It resolves over an RSVP-TE LSP. This is the ingress LER (Label Edge Router) where traffic-engineering inet6 shortcuts are really effective. Note the Push 2 operation driven by this feature, as depicted in Traffic engineering inet6 shortcuts to connect IPv6 islands - Part I.

 

The reason is the lookup for the next hop (2001:db8:0:ffff:192:168:255:6). This IPv6 prefix is correctly extracted from the respective IS-IS LSP (Link State PDU):

 

juniper@R3> show isis route 2001:db8:0:ffff:192:168:255:6/128

IS-IS routing table             Current version: L1: 133 L2: 138

 

IPv4/IPv6 Routes

----------------

Prefix             L Version   Metric Type Interface       NH   Via

2001:db8:0:ffff:192:168:255:6/128 2     138       60 int ge-0/0/3.0 IPV6 R7

 

However, because of the traffic-engineering inet6 shortcuts, R3 SPF calculations determine that this prefix is located downstream from R7 and there is an RSVP-TE LSP (Label Switched Path) towards this egress LER (Label Edge Router).

 

Et voilá, shortcut computations are in action and the corresponding route appears in inet6.3 pointing to the RSVP-TE LSP towards R7:

 

juniper@R3> show route 2001:db8:0:ffff:192:168:255:6/128

 

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

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

 

2001:db8:0:ffff:192:168:255:6/128

                   *[IS-IS/18] 19:33:55, metric 60

                    > to fe80::566b:2ff:feb0:e395 via ge-0/0/3.0

 

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

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

 

2001:db8:0:ffff:192:168:255:6/128

                   *[IS-IS/18] 19:33:55, metric 60

                    > to 192.168.4.2 via ge-0/0/3.0, label-switched-path R3->R7

 

This is the key element in this solution, because upon same preferences, the inet6.3 route is preferred by BGP. And this is the next hop selected for the BGP route. Traffic is pushed on top of this LSP with label 2, as seen above.

 

From this point and until the egress LER, the core can be completely IPv6 unaware. It is all about MPLS label switching until the LSP egress point.

 

Once reaching R7, the IPv6 lookup is native again with R6 as final next hop.

 

Examples with Junosphere: End-to-end connectivity use case across ASs with traffic-engineering inet6 shortcuts

 

Another benefit from this feature is that this architecture does not require changing from inet6 unicast to inet6 labeled-unicast route lookups. The same inet6 unicast BGP family is negotiated in iBGP and eBGP groups, as opposed to the interaction between the traditional 6PE model and native IPv6 peering.

 

Let's see the implications in another use case scenario across AS boundaries:

 

inet6-shortcuts-interAS-calculations.jpg

 

Checking end-to-end connectivity tests:

 

juniper@R1> traceroute 2001:db8:24::1 source 2001:db8:1::1   

traceroute6 to 2001:db8:24::1 (2001:db8:24::1) from 2001:db8:1::1, 64 hops max, 12 byte packets

1  2001:db8:0:ffff:192:168:255:3 (2001:db8:0:ffff:192:168:255:3)  24.036 ms  29.914 ms  30.160 ms

2  2001:db8:0:ffff:192:168:255:7 (2001:db8:0:ffff:192:168:255:7)  35.905 ms  36.170 ms  41.885 ms

     MPLS Label=299968 CoS=0 TTL=1 S=0

     MPLS Label=2 CoS=0 TTL=1 S=1

3  2001:db8:0:ffff:192:168:255:10 (2001:db8:0:ffff:192:168:255:10)  41.939 ms  30.417 ms  29.941 ms

4  2001:db8:0:ffff:192:168:255:16 (2001:db8:0:ffff:192:168:255:16)  51.899 ms  54.051 ms  48.002 ms

     MPLS Label=299904 CoS=0 TTL=1 S=0

     MPLS Label=2 CoS=0 TTL=1 S=1

5  2001:db8:0:ffff:192:168:255:20 (2001:db8:0:ffff:192:168:255:20)  59.912 ms  59.971 ms  60.041 ms

6  2001:db8:24::1 (2001:db8:24::1)  71.975 ms  60.025 ms  60.036 ms

 

Let's review the transit MPLS labels, together with the self-imposed label 2 in this architecture. This is analyzed in the following diagram:

 

 

inet6-shortcuts-labels.jpg

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Looking up a BGP route in R1 originated in R24 (2001:db8:24::/64)

 

juniper@R1> show route protocol bgp

[...]

2001:db8:24::/64   *[BGP/170] 00:03:22, localpref 100, from 192.168.255.6

                      AS path: 65001 I, validation-state: unverified

                    > to fe80::566b:2ff:feb0:f370 via ge-0/0/2.0

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

                      AS path: 65001 I, validation-state: unverified

                    > to fe80::566b:2ff:feb0:f370 via ge-0/0/2.0

[...]

 

The first BGP route lookup at R1 is similar to our previous use case: an inet6.0 BGP route that resolves over another inet6.0 IS-IS route.

 

R3 is the actual border system where traffic-engineering inet6 shortcuts kick in again:

 

juniper@R3> show route 2001:db8:24::1 extensive   

 

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

2001:db8:24::/64 (1 entry, 1 announced)

TSI:

KRT in-kernel 2001:db8:24::/64 -> {indirect(262144)}

        *BGP    Preference: 170/-101

                Next hop type: Indirect

                Address: 0x929dc90

                Next-hop reference count: 6

                Source: 2001:db8:0:ffff:192:168:255:6

                Next hop type: Router, Next hop index: 613

                Next hop: 192.168.4.2 via ge-0/0/3.0 weight 0x1, selected

                Label-switched-path R3->R10

                Label operation: Push 2, Push 299968(top)

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

                Session Id: 0x5

                Protocol next hop: 2001:db8:0:ffff:192:168:255:10

                Indirect next hop: 9128f00 262144 INH Session ID: 0x9

                State: <Active Int Ext>

                Local AS: 65000 Peer AS: 65000

                Age: 28:28     Metric2: 20

                Validation State: unverified

                Task: BGP_65000.2001:db8:0:ffff:192:168:255:6+63531

                Announcement bits (2): 0-KRT 4-Resolve tree 4

                AS path: 65001 I (Originator)

                Cluster list:  192.168.255.6

                Originator ID: 192.168.255.10

[...]

            2001:db8:0:ffff:192:168:255:10/128 Originating RIB: inet6.3

              Metric: 20              Node path count: 1

              Forwarding nexthops: 1

                Nexthop: 192.168.4.2 via ge-0/0/3.0

 

Note the double push with inherent IPv6 explicit null and the specific RSVP-TE LSP label to reach the ASBR, R10 in this case. R10 is also the next hop for this BGP route because of the next-hop self settings at the AS boundaries towards iBGP peers. The next hop is selected from the inet6.3 table according to the RSVP-TE LSP selection.

 

The RSVP-TE LSP next hop towards R10 is R7. R7 is completely transparent and IPv6 unaware. It simply performs label switching:

 

juniper@R7> show route label 299968 

 

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

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

 

299968             *[RSVP/7/1] 19:39:38, metric 1

                    > to 192.168.13.2 via ge-0/0/4.0, label-switched-path R3->R10

299968(S=0)        *[RSVP/7/1] 19:39:38, metric 1

                    > to 192.168.13.2 via ge-0/0/4.0, label-switched-path R3->R10

 

 

and this finally reaches R10 as ASBR, where another lookup is performed and resolves over the IPv6 interAS connection to R13:

 

juniper@R10> show route 2001:db8:24::1

 

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

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

 

2001:db8:24::/64   *[BGP/170] 00:52:32, 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

 

As ingress LER and ASBR, R13 performs another lookup for the IPv6 prefix and due to traffic-engineering inet6 shortcuts the same process is repeated again: an adequate RSVP-TE LSP is selected towards an egress LER that is considered by SPF shortcuts computation as the closest point to the final destination:

 

juniper@R13> show route 2001:db8:24::1

 

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

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

 

2001:db8:24::/64   *[BGP/170] 00:53:00, localpref 100, from 2001:db8:0:ffff:192:168:255:15

                      AS path: I, validation-state: unverified

                    > to 192.168.18.2 via ge-0/0/3.0, label-switched-path R13->R20

                    [BGP/170] 00:52:46, localpref 100, from 2001:db8:0:ffff:192:168:255:19

                      AS path: I, validation-state: unverified

                    > to 192.168.18.2 via ge-0/0/3.0, label-switched-path R13->R20

 

and so on:

 

juniper@R16> show route label 299904

 

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

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

 

299904             *[RSVP/7/1] 19:41:05, metric 1

                    > to 192.168.25.2 via ge-0/0/4.0, label-switched-path R13->R20

299904(S=0)        *[RSVP/7/1] 19:41:05, metric 1

                    > to 192.168.25.2 via ge-0/0/4.0, label-switched-path R13->R20

 

 

This all basically means that you can stitch multiple traffic-engineering domains or even multiple RSVP-TE LSPs with this feature, as long as there is IPv6 unicast continuity in the stitching endpoints. This tends to be the case at AS boundaries, for instance. Because this functionality mainly applies to IPv6 BGP next-hop resolution, this can be applied to any end system in any island. You just need to take care about connecting islands via RSVP-TE LSPs, and these paths can be steered by all traffic-engineering options that RSVP can offer!

 

Conclusions

 

We can certainly extract some conclusions from this feature, and compare them with the 6PE model and native IPv6 support. But this alone deserves another post!

 

Before analyzing and comparing all these models throughfully, my personal impression is that traffic-engineering inet6 shortcuts can be considered a good transition and/or IPv6 interconnect methodology in a very concrete scenario with some tight dependencies, like specific IGP, a certain MPLS label distribution protocol and a given topology distribution. If your network core covers these requirements, and is not intended to be migrated to support IPv6 or become dual-stack (or you do not even require or consider it), this can be a good transition fit because:

 

  • RSVP-TE offers the option to create specific LSPs for IPv6 (if needed) in this case
  • IS-IS includes the IPv6 unicast routing topology per default
  • Feature activation is local, smooth, and does not lead to any impact or precise dependencies

But in my opinion, if the setup does not meet these prerequisites, it does not deserve its application unless there is a strong need for traffic engineering. If your IGP is OSPFv2 and/or OSPFv3, would it be worth rolling out IS-IS for this feature? If the MPLS label distribution protocol of choice is LDP, would it be worth deploying an RSVP-TE mesh? Provided that a feature rollout effort would be then needed, maybe other alternatives like 6PE with an MPLS BGP-free network core or directly native IPv6 (or both) can better achieve the goal in these cases with same or less efforts and grief.

 

What is your opinion on that? Please let us know here with a comment or tweet back at @go_nzo

Feedback