[j-nsp] 6PE without family inet6 labeled-unicast
Dan Peachey
dan at peachey.co
Fri Jul 20 16:40:26 EDT 2018
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
More information about the juniper-nsp
mailing list