Routing
Routing

Importance of explicit-null label (2) on 6PE

a month ago

Hello

The question is if Junos process the label 2 as native v6 why need to send the label at all when the interfaces between PHP and egress PE are running inet6?
With respect to topology configured for 6PE as such;

 

                      CE1---PE1==P1==P2==PE2--CE2

 

Consider traffic from CE1 towards CE2, given that the PHP router (P2) POPs the outer (transport) label and directs (not routes) the packet out of its interface to the PE2, and that the PE2’s uplink interface to the PHP router (P2) is configured for v6 processing , then why not let the eLER (PE2) issue the implicit-null label for v6 (i.e. the PHP router (P2) would POP the transport label and forward a native (unlablelled) v6 packet to the PE2) Why does this not work while Junos process the packets with label 2 as native v6 packet hence the need to have the interface connecting PE2 to P2 have v6 processing enabled.

9 REPLIES 9
Routing

Re: Importance of explicit-null label (2) on 6PE

[ Edited ]
a month ago

Hello,

Please refer to RFC 4798 section 3 https://tools.ietf.org/html/rfc4798#page-5 

 

   For instance, the use of a second level label allows Penultimate Hop
   Popping (PHP) on the IPv4 Label Switch Router (LSR) upstream of the
   egress 6PE router, without any IPv6 capabilities/upgrades on the
   penultimate router; this is because it still transmits MPLS packets
   even after the PHP (instead of having to transmit IPv6 packets and
   encapsulate them appropriately).

   Also, an existing IPv4-signaled LSP that is using "IPv4 Explicit NULL
   label" over the last hop (e.g., because that LSP is already being
   used to transport IPv4 traffic with the Pipe Diff-Serv Tunneling
   Model as defined in [RFC3270]) could not be used to carry IPv6 with a
   single label since the "IPv4 Explicit NULL label" cannot be used to
   carry native IPv6 traffic (see [RFC3032]), while it could be used to
   carry labeled IPv6 traffic (see [RFC4182]).

   This is why a second label MUST be used with the 6PE approach.

 

 

FYI, JUNOS also supports arbitrary second label, not just IPv6 Explicit Null (the exact version escapes me, but I recall I tested it in 15.1<something>.

 

HTH

Thx

Alex

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Routing

Re: Importance of explicit-null label (2) on 6PE

[ Edited ]
3 weeks ago

Hello

 

Thanks for the insight, this bit is clear

 

   For instance, the use of a second level label allows Penultimate Hop
   Popping (PHP) on the IPv4 Label Switch Router (LSR) upstream of the
   egress 6PE router, without any IPv6 capabilities/upgrades on the
   penultimate router; this is because it still transmits MPLS packets
   even after the PHP (instead of having to transmit IPv6 packets and
   encapsulate them appropriately).

 

I understand the purpose is to accomodate a PHP router that does not have IPv6 capabilities, this means if the PHP router does have IPv6 support the inner label (explicit-null or any arbitrary label) is irrelevant as the PHP router will be able to process the IPv6 packet after poping the transport label. 

However upon testing this does not work.

Routing

Re: Importance of explicit-null label (2) on 6PE

3 weeks ago

Hello,

 


@basondolepaul wrote:

I understand the purpose is to accomodate a PHP router that does not have IPv6 capabilities, this means if the PHP router does have IPv6 support the inner label (explicit-null or any arbitrary label) is irrelevant as the PHP router will be able to process the IPv6 packet after poping the transport label. 

However upon testing this does not work.


 

May I ask what exactly does not work?

JUNOS 6PE LER routers do NOT send single-labeled 6PE packets hence IPv6 capabilities on PHP router are irrelevant.

The PHP router between 2 JUNOS 6PE LERs will always receive 2-labeled 6PE packet in and send single-labeled 6PE packet out, either with label 2 or regular label, depending on how the "family inet6 labeled-unicast" knob on egress LER is configured.

HTH

Thx

Alex

 

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Routing

Re: Importance of explicit-null label (2) on 6PE

3 weeks ago

What does not work is communication between the two CEs (with reference to my fore mentioned topology)

 

I reckon in some junos version it is mandatory to put the command explicit null on bgp configuration for family inet6 labeled-unicast.

What I am trying to establish is, if the PHP is capable of IPv6 this (exlicit-null or any inner label) is not needed since the inner label is only useful for allowing the PHP to send packets to the egress PE even when the PHP itself cannot process IPv6 packets.

 

Now when I tested this I could not ping6 one CE from the other, however when I use explicit-null on the PEs, ping6 between CEs work which means the explicit null is mandatory regardless of whether the PHP is IPv6 capable or not. This is what I find confusing

 

That is what im trying to understand.

Routing

Re: Importance of explicit-null label (2) on 6PE

3 weeks ago

From Juniper documentation :-

https://www.juniper.net/documentation/en_US/junos/topics/example/mpls-tunneling-ipv6-over-mpls-ipv4....

 

The PE routers always advertise IPv6 routes to each other using a label value of 2, the explicit null label for IPv6 as defined in RFC 3032, MPLS Label Stack Encoding.

As a consequence, each of the forwarding next hops for the IPv6 routes learned from remote PE routers normally push two labels. The inner label is 2 (this label could be different if the advertising PE router is not a Juniper Networks routing platform), and the outer label is the LSP label. If the LSP is a single-hop LSP, then only Label 2 is pushed.

The penultimate-hop provider router for the LSP pops the outer label and sends the packet to the PE2 router. When the PE2 router receives the packet, it recognizes the IPv6 explicit null label on the packet (Label 2). It pops this label and treats it as an IPv6 packet, performing a lookup in the IPv6 forwarding table and forwarding the packet to the CE3 router.

 

Thx

Anish

Routing

Re: Importance of explicit-null label (2) on 6PE

3 weeks ago

Also please check the explanation in RFC4798 below why a second label is needed .

It  can be an atrbitary label aswell , but looks like juniper implementation uses label 2 as its inner or second label .

 

This is why a second label MUST be used with the 6PE approach.

   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.

 

Thx

Anish 

Routing

Re: Importance of explicit-null label (2) on 6PE

[ Edited ]
3 weeks ago

Hello,

 


@basondolepaul wrote:

What does not work is communication between the two CEs (with reference to my fore mentioned topology)

<skip>

Now when I tested this I could not ping6 one CE from the other,


 

6PE with regular label instead of IPv6 Explicit Null does work in my lab with JUNOS 17.3R3.

I have 4 paths between ingress6PE and egress6PE:

 

regress@ingress6PE> show route table inet6.0 2001:1337:1::/48    

inet6.0: 31 destinations, 37 routes (31 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

2001:1337:1::/48   *[BGP/170] 00:00:54, MED 10, localpref 100, from 84.235.124.1
                      AS path: I, validation-state: unverified
                    > to 10.188.199.48 via ae4.150, Push 300048, Push 300160(top)
                      to 10.188.199.50 via ae5.150, Push 300048, Push 300208(top)
                      to 10.188.199.48 via ae4.150, Push 300048, Push 300144(top)
                      to 10.188.199.50 via ae5.150, Push 300048, Push 300192(top)

 

As You can see , the inner label is a regular one, not IPv6 Exp Null.

And on egress 6PE:

 

regress@egress6PE> show route forwarding-table label 300048 detail 
Routing table: default.mpls
MPLS:
Destination        Type RtRef Next hop           Type Index    NhRef Netif
300048             user     0                    indr  1048588     2
                              fe80::5668:a5ff:fed1:2ef1
                                                Pop        691     2 ge-0/0/1.0

 

Ping6 is successful:

 

regress@6PE-CE1> ping 2001:1337:1::1 source 2001:1337:2::1 rapid count 100 
PING6(56=40+8+8 bytes) 2001:1337:2::1 --> 2001:1337:1::1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
--- 2001:1337:1::1 ping6 statistics ---
100 packets transmitted, 100 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 12.786/22.638/61.686/8.965 ms

 

You need to have  CE-facing interfaces on ingress6PE and egress6PE configured with "family mpls" and list them under "protocols mpls".

HTH

Thx

Alex

 

 

 

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Routing

Re: Importance of explicit-null label (2) on 6PE

3 weeks ago

Qouting the RFC 4798 [Page 5]

 

   While this approach could theoretically operate in some situations
   using a single level of labels, there are significant advantages in
   using a second level of labels that are bound to IPv6 prefixes via
   MP-BGP advertisements in accordance with [RFC3107].

   For instance, the use of a second level label allows Penultimate Hop
   Popping (PHP) on the IPv4 Label Switch Router (LSR) upstream of the
   egress 6PE router, without any IPv6 capabilities/upgrades on the
   penultimate router; this is because it still transmits MPLS packets
   even after the PHP (instead of having to transmit IPv6 packets and
   encapsulate them appropriately).

 

The first paragraph indeed say 6PE could "theoretically work" with single lable the transport (LSP) label. 

The second paragraph acknowledges the use of second label for the purpose of tolerating a PHP that does not support IPv6

 

Yet on the next couple of paragraphs the RFC says

This is why a second label MUST be used with the 6PE approach.

 

So when it says 6PE could "theoretically work" with single label it really means "practically not working" because that is what I have been testing.

Routing

Re: Importance of explicit-null label (2) on 6PE

3 weeks ago

Hello,

 


@basondolepaul wrote:

when it says 6PE could "theoretically work" with single label it really means "practically not working" because that is what I have been testing.


 

JUNOS 6PE implementation always uses 2 labels, in accordance with RFC "MUST" wording. If You are saying You were testing 6PE with single label then it's either:

1/ not RFC 4798 6PE

2/ You were testing 6PE on something else, not JUNOS.

HTH

Thx

Alex

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !