Archive
Juniper Employee , Juniper Employee Juniper Employee
Archive
Traffic engineering inet6 shortcuts to connect IPv6 islands - Part I
May 28, 2013

Traffic-Engineering shortcuts is a feature that allows shortcut next hop attachments beyond an RSVP-TE LSP (Label Switched Path) egress point. From an ingress router standpoint, that includes this feature with a link-state IGP, RSVP-TE LSPs appear to be kind-of directly connected logical interfaces to remote nodes in the network for the SPF (Shortest Path First) algorithm. The SPF computation results point to certain LSPs with destination nodes and prefixes further downstrean than the LSP egress router, effectively using the LSP as a shortcut through the network to the destination.

 

As a result, if there is an LSP to a point along the path to that prefix, the IGP installs the prefix in the inet.3 routing table per default and uses the LSP as a next hop to reach that prefix. At that point, BGP automatically uses that LSP along the path to reach the egress router and considers that destination a next hop reachable through it. There are further Junos OS tweaks that allow injecting such calculated destinations in one or another RIB, so that they can be used for all or BGP destinations only.

 

Junos OS 9.3 major release introduced a per-family enhancement on top of the Traffic-Engineering shortcuts feature to apply such calculations for IPv6 destinations, among others, when the IGP is IS-IS. In this case, computed IPv6 prefixes that turn reachable through RSVP-TE LSPs are injected into inet6.3 and become eligible as IPv6 next hops.

 

At first, you may conceive the feature suitability to interconnect dual-stack routers with a single and common LSP. But actually, this is a more powerful tool! Because shortcuts are applicable to destinations further downstream than the LSP egress point, this feature does not only provide connectivity to IPv6-enabled systems but completely IPv6-enabled islands. It effectively provides a replacement option for the full 6PE model using native inet6 unicast BGP families for IPv6 prefix distribution, instead of inet6 labeled unicast. Let's get into some details to explain this!

 

inet6-shortcuts-generic-topo.jpg

 

When implementing this feature, it is necessary to discern that IPv6 traffic is encapsulated on top of the RSVP-TE LSP. Considering that Penultimate Hop Popping (PHP) is Junos OS default behavior for RSVP-TE and we may want to ensure an adequate context lookup at the egress LSR, this feature drives the implementation of a certain trick: it pushes an additional IPv6 Explicit Null label (2) on top of the RSVP-TE LSP at the ingress LSR that has activated this feature.

 

Therefore, the external RSVP-TE LSP label is swapped across the path until reaching the Penultimate Hop. If PHP is in place (Implicit Null Label 3 is signalled upstream by the Egress LSR), the RSVP-TE LSP external label is popped and then IPv6 Explicit Null label (2) becomes the external and only label that the Egress LSR will find in the packet. This trick ensures that the Egress LSR directly understands there is IPv6 traffic after popping the label for an adequate lookup. And this is also in any case applicable whenever PHP is not in place, but UHP (Ultimate Hop Popping), because there will be only the IPv4 Explicit Null label (0) underneath.

 

Note that this behavior is analogous to the Junos OS default label allocation for inet6 labeled-unicast routes in the 6PE model, as explained in my previous post Using IPv6 Labeled Unicast BGP for 6PE and allows then for native IPv6 traffic to be placed on top of this label. This feature issues a local push of IPv6 Explicit Null label (2) for all IPv6 destinations resulted from shortcut computations at the Ingress LSR. This means, that you can directly handle native IPv6 traffic between endpoints over the LSP.  You can directly negotiate native inet6 unicast family for BGP using this transit LSP!

inet6-shortcuts-generic-labels.jpg

From the signalling point of view, the scheme is then different than the 6PE model because the Traffic-Engineering shortcuts for inet6 family feature imposes an additional local IPv6 Explicit Null label (2) push inherently and BGP can directly negotiate inet6 unicast family. In the 6PE model, it was required to negotiate inet6 labeled-unicast family in BGP, with local label allocation of IPv6 Explicit Null label (2), and translate FECs to inet6.3 but use the same LSPs.

 

From the forwarding point of view though, the net effect could be the same in both models as the additionally imposed label is placed between native IPv6 traffic and the external MPLS label, and if this gets allocated by Junos OS, it will be IPv6 Explicit Null label (2).

 

We will drive a more thoughtful comparison with the 6PE model in a follow-up post. Let's start now with some hands-on in Junosphere!

 

How does this feature get activated with Junos OS?

 

Traffic-Engineering shortcuts for inet6 family are entirely local, because they directly influence SPF computation results in the selected router. And for that reason, there are no dependencies or protocol signalling involved when activating this feature, because it is a completely local matter. The configuration is smooth and straightforward:

 

[edit protocols isis]

traffic-engineering {

     family inet6 {

          shortcuts;

     }

}

 

There are no expected previous requirements or protocol impact when activating or removing the knob. Once the configuration is enforced, you may detect inet6 shortcut computation is actively effective by issuing:

 

juniper@R1> show isis overview

Instance: master

  Router ID: 192.168.255.1

  Adjacency holddown: enabled

  Maximum Areas: 3

  LSP life time: 65535

  Attached bit evaluation: enabled

  SPF delay: 200 msec, SPF holddown: 5000 msec, SPF rapid runs: 3

  IPv4 is enabled, IPv6 is enabled

  Traffic engineering: enabled

    IPv6 Traffic engineering shortcuts are enabled

  Restart: Disabled

    Helper mode: Enabled

  Level 1

    Internal route preference: 15

    External route preference: 160

    Wide metrics are enabled

  Level 2

    Internal route preference: 18

    External route preference: 165

    Wide metrics are enabled

 

Examples with Junosphere: Traffic Engineering shortcuts for IPv6

 

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

and let's customize it with a use case to adjust the setup to the feature analysis:

 

inet6-shortcuts-junosphere-topo.jpg

Note that I have considered aligning each network core (i.e. the IS-IS L2 backbone) with a full RSVP-TE LSP mesh, being internally IPv6-unaware, and each IS-IS L1 Area as an IPv6 island with dual-stack support. As opposed to the 6PE model, be aware that RSVP-TE ingress LSRs, aligned with IS-IS L1L2 intermediate systems, need to be dual-stack. These will be the actual SPF computation points for IPv6 destinations and therefore, they need to understand what IPv6 prefixes can be reachable beyond IPv4 RSVP-TE controlled LSPs. They need to perform the lookup on IPv6 prefixes (i.e. distributed via BGP to end PEs) and find the adequate IPv6 next hops beyond these LSPs.

 

For that reason, these ingress and egress LSRs need to be part of the BGP inet6 unicast reflection group for the adeaquate lookup. In our example and in contrast to the parallel 6PE topology from the Using IPv6 Labeled Unicast BGP for 6PE post, these border systems at the core (aligned with IS-IS L1L2 role) need to include BGP sessions with the route reflectors and negotiate the inet6 unicast family.

 

These are the relevant config snippets at R1 as a dual-stack and IS-IS L1 intermediate system. Note the native IPv6 BGP group with unicast family and the fact that the IPv6 routing topology has not been disabled in IS-IS:

 

[edit protocols bgp]

log-updown;

vpn-apply-export;

group iBGP-inet {

    type internal;

    local-address 192.168.255.1;

    family inet {

        unicast;

    }

    family inet-vpn {

        unicast;

    }

    neighbor 192.168.255.6;

    neighbor 192.168.255.12;

}

group iBGP-inet6 {

    type internal;

    local-address 2001:0db8::ffff:192:168:255:1;

    family inet6 {

        unicast;

    }

    export inet6-static;

    neighbor 2001:0db8::ffff:192:168:255:12;

    neighbor 2001:0db8::ffff:192:168:255:6;

}

 

[edit protocols isis]

lsp-lifetime 65535;

traffic-engineering {

     family inet6 {

          shortcuts;

     }

}

level 1 wide-metrics-only;

level 2 wide-metrics-only;

interface ge-0/0/1.0 {

    ldp-synchronization;

    point-to-point;

    level 1 metric 50;

    level 2 disable;

}

interface ge-0/0/2.0 {

    ldp-synchronization;

    point-to-point;

    level 1 metric 10;

    level 2 disable;

}

interface lo0.0 {

    passive;

}

 

If we want to achieve optimal routing lookups for IPv6 routes learned through IS-IS, a good advice is to adequately adjust leaking policies at IS-IS L1-L2 systems (similar to IPv4 counterpart policies):

 

[edit]

juniper@R3# show | compare

[edit policy-options policy-statement leak-l2-loopbacks-to-l1]

     term leak-own-loopback { ... }

+    term leak-loopbacks-L2-inet6 {

+        from {

+            protocol isis;

+            level 2;

+            route-filter 2001:0db8::ffff:/64 prefix-length-range /128-/128;

+        }

+        to level 1;

+        then accept;

+    }

 

This allows that internal IS-IS L1 systems follow more specific routes for the remote IPv6 prefixes, being leaked as well from L2 to L1, rather than following a plain ATTached bit setting from the IS-IS L2L1 LSP for default routing. This is usually considered a best practice whenever an IS-IS L1 Area is multihomed to a backbone.

 

Having this leaking policy adjustment in mind, other configuration snippets at such border systems, like R3, are aligned. A separate BGP group based on IPv6 and negotiating inet6 unicast family is necessary for the lookup:

 

[edit protocols isis]

export leak-l2-loopbacks-to-l1;

lsp-lifetime 65535;

traffic-engineering {

    family inet6 {

        shortcuts;

    }

}

level 1 wide-metrics-only;

level 2 wide-metrics-only;

interface ge-0/0/1.0 {

    ldp-synchronization;

    point-to-point;

    level 1 metric 50;

    level 2 disable;

}

interface ge-0/0/2.0 {

    ldp-synchronization;

    point-to-point;

    level 1 disable;

    level 2 metric 10;

}

interface ge-0/0/3.0 {

    ldp-synchronization;

    point-to-point;

    level 1 disable;

    level 2 metric 10;

}

interface lo0.0 {

    passive;

}

 

[edit protocols bgp]

log-updown;

vpn-apply-export;

group iBGP-inet6 {

    type internal;

    local-address 2001:0db8::ffff:192:168:255:3;

    family inet6 {

        unicast;

    }

    neighbor 2001:0db8::ffff:192:168:255:12;

    neighbor 2001:0db8::ffff:192:168:255:6;

}


With this architecture, it is actually at this border system where the inet6 traffic-engineering shortcuts are effective, because this router can perform an IPv6 lookup that can resolve over the RSVP-TE LSP.

 

Finally, the route reflector servers need to consider two different groups: a mesh for inet families with IPv4 peers and another mesh for inet6 unicast family with native IPv6-based sessions. For instance, at R6:

 

[edit protocols bgp]

log-updown;

vpn-apply-export;

group iBGP-inet {

    type internal;

    local-address 192.168.255.6;

    family inet {

        unicast;

    }

    family inet-vpn {

        unicast;

    }

    export inet6-static;

    cluster 192.168.255.6;

    neighbor 192.168.255.1;

    neighbor 192.168.255.2;

    neighbor 192.168.255.5;

    neighbor 192.168.255.9;

    neighbor 192.168.255.10;

    neighbor 192.168.255.11;

}

group iBGP-inet6 {

    type internal;

    local-address 2001:0db8::ffff:192:168:255:6;

    family inet6 {

        unicast;

    }

    export inet6-static;

    cluster 192.168.255.6;

    neighbor 2001:0db8::ffff:192:168:255:1;

    neighbor 2001:0db8::ffff:192:168:255:2;

    neighbor 2001:0db8::ffff:192:168:255:5;

    neighbor 2001:0db8::ffff:192:168:255:9;

    neighbor 2001:0db8::ffff:192:168:255:10;                            

    neighbor 2001:0db8::ffff:192:168:255:11;

    neighbor 2001:0db8::ffff:192:168:255:3;

    neighbor 2001:0db8::ffff:192:168:255:4;

    neighbor 2001:0db8::ffff:192:168:255:7;

}


This last iBGP native IPv6 unicast mesh needs to cover both end and border systems, so that all involved routers (except from those internal in the RSVP-TE core) perform a lookup for the same IPv6 destinations.

 

So far, I have reviewed the basic inet6 shortcuts concepts and the most relevant snippets at the different router roles in this architecture. Full configurations are available in the attached Junosphere topology, if you want to scrutinize and review some other stanzas. It is time now to analyze a sample use case in detail and check the outputs in the next post!

Feedback