[j-nsp] 6PE without family inet6 labeled-unicast
Pavel Lunin
plunin at gmail.com
Sat Jul 21 06:44:58 EDT 2018
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
пт, 20 июл. 2018 г., 21:59 Andrey Kostin <ankost at podolsk.ru>:
>
> 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?
>
> --
> Kind regards,
>
> Andrey Kostin
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
More information about the juniper-nsp
mailing list