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 <[email protected]> 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: [email protected]> 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: [email protected]> 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} [email protected]> 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: [email protected]> 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 [email protected]> 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: [email protected]> show configuration protocols bgp group internal-v4 export export [ deny-rfc3330 to-bgp ]; {master} [email protected]> show configuration protocols bgp group internal-v6 export export [ deny-rfc3330 to-bgp ]; [email protected]> 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; } } [email protected]> 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 [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
-- Pedro Marques Antunes
signature.asc
Description: PGP signature
_______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
