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

Pedro Marques Antunes pedro.antunes at cartapus.eu
Sat Jul 21 05:36:28 EDT 2018


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.

On Friday, 20 July 2018 at 21:40:26 +0100, Dan Peachey wrote:
>On Fri, 20 Jul 2018 at 21:00, Andrey Kostin <ankost at podolsk.ru> wrote:
>
>>
>> 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:
>>
>> uuuu at 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:
>> uuuu at 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}
>> uuuu at 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:
>> uuuu at 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
>>
>> uuuu at 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:
>> uuuu at re1.agg01.LLL2> show configuration protocols bgp group internal-v4
>> export
>> export [ deny-rfc3330 to-bgp ];
>>
>> {master}
>> uuuu at re1.agg01.LLL2> show configuration protocols bgp group internal-v6
>> export
>> export [ deny-rfc3330 to-bgp ];
>>
>>
>> uuuu at 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;
>>      }
>> }
>>
>>
>> uuuu at 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?
>>
>>
> 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-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp

-- 
Pedro Marques Antunes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 687 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20180721/87b063cc/attachment.sig>


More information about the juniper-nsp mailing list