[j-nsp] 6PE without family inet6 labeled-unicast

Discussion:

Andrey Kostin

2018-07-20 19:58:56 UTC

Hello juniper-nsp,

I've accidentally encountered an interesting behavior and wondering if
anyone already seen it before or may be it's documented. So pointing to
the docs is appreciated.

The story:
We began to activate ipv6 for customers connected from cable network
after cable provider eventually added ipv6 support. We receive prefixes
from cable network via eBGP and then redistribute them inside our AS
with iBGP. There are two PE connected to cable network and receiving
same prefixes, so for traffic load-balancing we change next-hop to
anycast loopback address shared by those two PE and use dedicated LSPs
to that IP with "no-install" for real PE loopback addresses.
IPv6 wasn't deemed to use MPLS and existing plain iBGP sessions between
IPv6 addresses with family inet6 unicast were supposed to be reused.
However, the same export policy with term that changes next-hop for
specific community is used for both family inet and inet6, so it
started to assign IPv4 next-hop to IPv6 prefixes implicitly.

Here is the example of one prefix.

## here PE receives prefix from eBGP neighbor:

***@re1.agg01.LLL2> show route XXXX:XXXX:e1bc::/46

inet6.0: 52939 destinations, 105912 routes (52920 active, 1 holddown,
24 hidden)
+ = Active Route, - = Last Active, * = Both

XXXX:XXXX:e1bc::/46*[BGP/170] 5d 13:16:26, MED 100, localpref 100
AS path: EEEE I, validation-state: unverified

to XXXX:XXXX:ffff:f200:0:2:2:2 via ae2.202

## Now PE advertises it to iBGP neighbor with next-hop changed to plain
IP:
***@re1.agg01.LLL2> show route XXXX:XXXX:e1bc::/46
advertising-protocol bgp XXXX:XXXX:1::1:140

inet6.0: 52907 destinations, 105843 routes (52883 active, 6 holddown,
24 hidden)
Prefix Nexthop MED Lclpref AS
path
* XXXX:XXXX:e1bc::/46 YYY.YYY.155.141 100 100 EEEE
I

## Same output as above with details
{master}
***@re1.agg01.LLL2> show route XXXX:XXXX:e1bc::/46
advertising-protocol bgp XXXX:XXXX:1::1:140 detail ## Session is
between v6 addresses

inet6.0: 52902 destinations, 105836 routes (52881 active, 3 holddown,
24 hidden)
* XXXX:XXXX:e1bc::/46 (3 entries, 1 announced)
BGP group internal-v6 type Internal
Nexthop: YYY.YYY.155.141 ## v6
prefix advertised with plain v4 next-hop
Flags: Nexthop Change
MED: 100
Localpref: 100
AS path: [IIII] EEEE I
Communities: IIII:10102 no-export

## iBGP neighbor receives prefix with tooled next hop and uses
established LSPs to forward traffic:
***@re0.bdr01.LLL> show route XXXX:XXXX:e1bc::/46

inet6.0: 52955 destinations, 323835 routes (52877 active, 10 holddown,
79 hidden)
+ = Active Route, - = Last Active, * = Both

XXXX:XXXX:e1bc::/46*[BGP/170] 5d 13:01:12, MED 100, localpref 100, from
XXXX:XXXX:1::1:240
AS path: EEEE I, validation-state: unverified
to YYY.YYY.155.14 via ae1.0, label-switched-path
BE-bdr01.LLL-vvvv-agg01.LLL2-1
to YYY.YYY.155.9 via ae12.0, label-switched-path
BE-bdr01.LLL-vvvv-agg01.LLL2-2
to YYY.YYY.155.95 via ae4.0, label-switched-path
BE-bdr01.LLL-vvvv-agg01.LLL-1
to YYY.YYY.155.9 via ae12.0, label-switched-path
BE-bdr01.LLL-vvvv-agg01.LLL-2

***@re0.bdr01.LLL> show route XXXX:XXXX:e1bc::/46 detail | match
"Protocol|XXXX:XXXX|BE-"
XXXX:XXXX:e1bc::/46 (3 entries, 1 announced)
Source: XXXX:XXXX:1::1:240
Label-switched-path BE-bdr01.LLL-vvvv-agg01.LLL2-1
Label-switched-path BE-bdr01.LLL-vvvv-agg01.LLL2-2
Label-switched-path BE-bdr01.LLL-vvvv-agg01.LLL-1
Label-switched-path BE-bdr01.LLL-vvvv-agg01.LLL-2
Protocol next hop: ::ffff:YYY.YYY.155.141
### Seems that IPv4 next hop has been converted to compatible form
Task: BGP_IIII.XXXX:XXXX:1::1:240
Source: XXXX:XXXX:1::7

## The policy assigning next-hop is the same for v4 and v6 sessions,
only one term is shown:
***@re1.agg01.LLL2> show configuration protocols bgp group internal-v4
export
export [ deny-rfc3330 to-bgp ];

{master}
***@re1.agg01.LLL2> show configuration protocols bgp group internal-v6
export
export [ deny-rfc3330 to-bgp ];

***@re1.agg01.LLL2> show configuration policy-options policy-statement
to-bgp | display inheritance no-comments
term vvvv-vvvv {
from {
community vvvv-vvvv;
tag 33;
}
then {
next-hop YYY.YYY.155.141;
accept;
}
}

***@re0.bdr01.LLL> show route forwarding-table destination
XXXX:XXXX:e1bc::/46
Routing table: default.inet6
Internet6:
Destination Type RtRef Next hop Type Index NhRef
Netif
XXXX:XXXX:e1bc::/46 user 0 indr 1049181 37
ulst 1050092 4
YYY.YYY.155.14 ucst 1775 1
ae1.0
YYY.YYY.155.9 Push 486887 1859
1 ae12.0
YYY.YYY.155.95 ucst 2380 1
ae4.0
YYY.YYY.155.9 Push 486892 2555
1 ae12.0

The result is that we have IPv6 traffic forwarded via MPLS without 6PE
configured properly. ipv6-tunneling is configured under "protocols mpls"
but no "family inet6 labeled-unicast explicit-null" under v4 iBGP
session.
It works as far as we have v6 enabled on all MPLS links, so packets are
not dropped because of implicit-null label.
Looks sketchy but it works. Has anybody seen/used it before?

--
Kind regards,

Andrey Kostin
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Andrey Kostin

2018-07-20 19:58:56 UTC

Permalink

to XXXX:XXXX:ffff:f200:0:2:2:2 via ae2.202

--
Kind regards,

Andrey Kostin
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Dan Peachey

2018-07-20 20:40:26 UTC

Permalink

Post by Andrey Kostin
Hello juniper-nsp,
I've accidentally encountered an interesting behavior and wondering if
anyone already seen it before or may be it's documented. So pointing to
the docs is appreciated.
We began to activate ipv6 for customers connected from cable network
after cable provider eventually added ipv6 support. We receive prefixes
from cable network via eBGP and then redistribute them inside our AS
with iBGP. There are two PE connected to cable network and receiving
same prefixes, so for traffic load-balancing we change next-hop to
anycast loopback address shared by those two PE and use dedicated LSPs
to that IP with "no-install" for real PE loopback addresses.
IPv6 wasn't deemed to use MPLS and existing plain iBGP sessions between
IPv6 addresses with family inet6 unicast were supposed to be reused.
However, the same export policy with term that changes next-hop for
specific community is used for both family inet and inet6, so it
started to assign IPv4 next-hop to IPv6 prefixes implicitly.
Here is the example of one prefix.
inet6.0: 52939 destinations, 105912 routes (52920 active, 1 holddown,
24 hidden)
+ = Active Route, - = Last Active, * = Both
XXXX:XXXX:e1bc::/46*[BGP/170] 5d 13:16:26, MED 100, localpref 100
AS path: EEEE I, validation-state: unverified

to XXXX:XXXX:ffff:f200:0:2:2:2 via ae2.202

## Now PE advertises it to iBGP neighbor with next-hop changed to plain
advertising-protocol bgp XXXX:XXXX:1::1:140
inet6.0: 52907 destinations, 105843 routes (52883 active, 6 holddown,
24 hidden)
Prefix Nexthop MED Lclpref AS
path
* XXXX:XXXX:e1bc::/46 YYY.YYY.155.141 100 100 EEEE
I
## Same output as above with details
{master}
advertising-protocol bgp XXXX:XXXX:1::1:140 detail ## Session is
between v6 addresses
inet6.0: 52902 destinations, 105836 routes (52881 active, 3 holddown,
24 hidden)
* XXXX:XXXX:e1bc::/46 (3 entries, 1 announced)
BGP group internal-v6 type Internal
Nexthop: YYY.YYY.155.141 ## v6
prefix advertised with plain v4 next-hop
Flags: Nexthop Change
MED: 100
Localpref: 100
AS path: [IIII] EEEE I
Communities: IIII:10102 no-export
## iBGP neighbor receives prefix with tooled next hop and uses
inet6.0: 52955 destinations, 323835 routes (52877 active, 10 holddown,
79 hidden)
+ = Active Route, - = Last Active, * = Both
XXXX:XXXX:e1bc::/46*[BGP/170] 5d 13:01:12, MED 100, localpref 100, from
XXXX:XXXX:1::1:240
AS path: EEEE I, validation-state: unverified
to YYY.YYY.155.14 via ae1.0, label-switched-path
BE-bdr01.LLL-vvvv-agg01.LLL2-1
to YYY.YYY.155.9 via ae12.0, label-switched-path
BE-bdr01.LLL-vvvv-agg01.LLL2-2
to YYY.YYY.155.95 via ae4.0, label-switched-path
BE-bdr01.LLL-vvvv-agg01.LLL-1
to YYY.YYY.155.9 via ae12.0, label-switched-path
BE-bdr01.LLL-vvvv-agg01.LLL-2
"Protocol|XXXX:XXXX|BE-"
XXXX:XXXX:e1bc::/46 (3 entries, 1 announced)
Source: XXXX:XXXX:1::1:240
Label-switched-path BE-bdr01.LLL-vvvv-agg01.LLL2-1
Label-switched-path BE-bdr01.LLL-vvvv-agg01.LLL2-2
Label-switched-path BE-bdr01.LLL-vvvv-agg01.LLL-1
Label-switched-path BE-bdr01.LLL-vvvv-agg01.LLL-2
Protocol next hop: ::ffff:YYY.YYY.155.141
### Seems that IPv4 next hop has been converted to compatible form
Task: BGP_IIII.XXXX:XXXX:1::1:240
Source: XXXX:XXXX:1::7
## The policy assigning next-hop is the same for v4 and v6 sessions,
export
export [ deny-rfc3330 to-bgp ];
{master}
export
export [ deny-rfc3330 to-bgp ];
to-bgp | display inheritance no-comments
term vvvv-vvvv {
from {
community vvvv-vvvv;
tag 33;
}
then {
next-hop YYY.YYY.155.141;
accept;
}
}
XXXX:XXXX:e1bc::/46
Routing table: default.inet6
Destination Type RtRef Next hop Type Index NhRef
Netif
XXXX:XXXX:e1bc::/46 user 0 indr 1049181 37
ulst 1050092 4
YYY.YYY.155.14 ucst 1775 1
ae1.0
YYY.YYY.155.9 Push 486887 1859
1 ae12.0
YYY.YYY.155.95 ucst 2380 1
ae4.0
YYY.YYY.155.9 Push 486892 2555
1 ae12.0
The result is that we have IPv6 traffic forwarded via MPLS without 6PE
configured properly. ipv6-tunneling is configured under "protocols mpls"
but no "family inet6 labeled-unicast explicit-null" under v4 iBGP
session.
It works as far as we have v6 enabled on all MPLS links, so packets are
not dropped because of implicit-null label.
Looks sketchy but it works. Has anybody seen/used it before?

Hi,

Presumably the penultimate LSR has the IPv6 iBGP routes? i.e. it knows how
to IPv6 route to the destination. The last LSR->LER hop should just be IPv6
routed in that case.

I've noticed this behaviour before whilst playing with 6PE on lab devices.
It would of course break if you were running IPv4 core only.

Cheers,

Dan
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Pedro Marques Antunes via juniper-nsp

2018-07-21 09:36:28 UTC

Permalink

The IPv6 explicit null label works as an overlay for the IPv6 traffic
carried over the core.

In a PHP scenario, the ultimate LSR will still forward based on the
received MPLS transport label. Therefore I do not think it will require
an IPv6 routing table. However it still needs to forward IPv6 packets.
Not a problem with recent routers. But this might have been a problem in
the days when you would have devices without any IPv6 capabilities. On
Junos boxes though, `family inet6` is still required on the egress
interface.

In a UHP scenario, the penultimate LSR is expected to forward a packet
with the IPv4 explicit null label (3). But this cannot be used with an
IPv6 packet. The overlay is mandatory in such a scenario.

Post by Dan Peachey

to XXXX:XXXX:ffff:f200:0:2:2:2 via ae2.202

Hi,
Presumably the penultimate LSR has the IPv6 iBGP routes? i.e. it knows how
to IPv6 route to the destination. The last LSR->LER hop should just be IPv6
routed in that case.
I've noticed this behaviour before whilst playing with 6PE on lab devices.
It would of course break if you were running IPv4 core only.
Cheers,
Dan
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp

--
Pedro Marques Antunes

Andrey Kostin

2018-07-22 19:28:58 UTC

Permalink

Hi Pedro,

Thanks for your comment. I agree with you that penultimate LSP forwards
traffic based on received label without IPv6 lookup. In my scenario,
default PHP is used and all routers have family inet6 configured, so it
just works.

Post by Pedro Marques Antunes via juniper-nsp
The IPv6 explicit null label works as an overlay for the IPv6 traffic
carried over the core.
In a PHP scenario, the ultimate LSR will still forward based on the
received MPLS transport label. Therefore I do not think it will require
an IPv6 routing table. However it still needs to forward IPv6
packets.
Not a problem with recent routers. But this might have been a problem in
the days when you would have devices without any IPv6 capabilities. On
Junos boxes though, `family inet6` is still required on the egress
interface.
In a UHP scenario, the penultimate LSR is expected to forward a packet
with the IPv4 explicit null label (3). But this cannot be used with an
IPv6 packet. The overlay is mandatory in such a scenario.

Post by Dan Peachey
Hi,
Presumably the penultimate LSR has the IPv6 iBGP routes? i.e. it knows how
to IPv6 route to the destination. The last LSR->LER hop should just be IPv6
routed in that case.
I've noticed this behaviour before whilst playing with 6PE on lab devices.
It would of course break if you were running IPv4 core only.
Cheers,
Dan
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-n

Andrey Kostin

2018-07-22 19:22:51 UTC

Permalink

Hi Dan,

Thanks for answering. All routers have family inet6 configured on all
participating interfaces, because other v6 traffic is forwarded without
MPLS, so we are safe for that.

Kind regards,
Andrey

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listin

Dan Peachey

2018-07-22 19:34:37 UTC

Permalink

Hey,

Other posters are correct... IPv6 routes are not requied, it forwards based
on received label as next hop is already known. Confused myself as I was
distributing full IPv6 table in my lab testing and assumed it was working
because of that, but it's not the case.

Cheers,

Dan

Post by Andrey Kostin
Hi Dan,
Thanks for answering. All routers have family inet6 configured on all
participating interfaces, because other v6 traffic is forwarded without
MPLS, so we are safe for that.
Kind regards,
Andrey

_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/lis

Pavel Lunin

2018-07-21 10:44:58 UTC

Permalink

In this setup it's not 6PE but just classic IP over MPLS, where vanilla
inet/inet6 iBGP resolves it's protocol next-hop with a labeled LDP/RSVP
forwarding next hop.

It works much the same way for v6 as for v4, except that the v6 header is
exposed to the last P router, when it performs PHP. It still relies on MPLS
to make the forwarding decision (if we don't take into account the hashing
story), however it "sees" the v6 header when it puts it onto the wire, and
needs to treat it accordingly. E. g. it must set the v6 ethertype or decide
what to do if the egress interface MTU can't accommodate the packet.

So you need family inet6 enabled on the egress interface of the penultimate
LSR to make IPv6 over MPLS work.

6PE was invented to work around this. Technically it's the same IPv6 over
MPLS but with an explicit (as opposed to implicit) null label at the tail
end, which hides the v6 header from the penultimate LSR. Or you can just
disable PHP in the core.

Cheers,
Pavel

to XXXX:XXXX:ffff:f200:0:2:2:2 via ae2.202

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/

Andrey Kostin

2018-07-22 19:45:34 UTC

Permalink

Hi Pavel,

Thanks for replying. I understand how it works as soon
as proper next-hop is present in a route. My attention was attracted by
implicit next-hop conversion from pure IPv4 address to IPv4-mapped IPv6
next-hop from "Nexthop: YYY.YYY.155.141" in the advertised route to
"Protocol next hop: ::ffff:YYY.YYY.155.141" in the received route.

Overwise it all works as expected, considering that family inet6 is
enabled in the core.

I'm also wondering what could happen is there are
no LSP available, which is rather unreal situation because everything
will be broken anyway in this case.

Kind regards,

Andrey

Pavel

Post by Pavel Lunin
In this setup it's not 6PE but just

classic IP over MPLS, where vanilla inet/inet6 iBGP resolves it's
protocol next-hop with a labeled LDP/RSVP forwarding next hop.

Post by Pavel Lunin
It

works much the same way for v6 as for v4, except that the v6 header is
exposed to the last P router, when it performs PHP. It still relies on
MPLS to make the forwarding decision (if we don't take into account the
hashing story), however it "sees" the v6 header when it puts it onto the
wire, and needs to treat it accordingly. E. g. it must set the v6
ethertype or decide what to do if the egress interface MTU can't
accommodate the packet.

Post by Pavel Lunin
So you need family inet6 enabled on the

egress interface of the penultimate LSR to make IPv6 over MPLS work.
6PE was invented to work around this. Technically it's the same IPv6
over MPLS but with an explicit (as opposed to implicit) null label at
the tail end, which hides the v6 header from the penultimate LSR. Or you
can just disable PHP in the core.

Post by Pavel Lunin
Cheers,
Pavel
пт, 20

Post by Andrey Kostin
Hello juniper-nsp,

I've accidentally encountered an interesting behavior and wondering if