As a starting note, this could possibly be something very simple that I have missed somewhere, so I apologise in advance if it is an oversight (I'm sure it is, but another pair of eyes never goes amiss 🙂 ) .....
I have 2 sites.... Site 1 advertises our IPv6 range correctly and I can get a response from the LNS to IPv6 addresses. In fact, from my testing, IPv6 works perfectly (almost).... So, here is the set up, and it is replicated on both sites:
LNS IPv6 Interface --> Core IPv6 Interface --> Core Upstream IPv6 interface --> Facebook IPv6 address
Configuration appears to be the same on both systems other than the obvious different IPv6 advertised prefix. (Note: Addresses have been changed so there will be no route advertised for these addresses, but the ACTUAL addresses are fine):
set interfaces xe-1/1/1 unit 0 family inet6 address 3a05:d840:0043:ffff:ffff:ffff:0000:0001/126 (to Core)
set interfaces xe-1/2/3 unit 0 family inet6 address 3a05:d840:0043:ffff:ffff:ffff:0000:0002/126 (to LNS)
set routing-options rib inet6.0 static route ::/0 next-hop 3a05:d840:0043:ffff:ffff:ffff:0000:0001
set routing-options rib inet6.0 aggregate route 3a05:d840:43::/48 policy aggregate-route-ipv6
set protocols bgp group external-peers-ipv6 export export-bgp-ipv6set protocols bgp group external-peers-ipv6 export export-route-ipv6
set policy-options policy-statement export-bgp-ipv6 term 1 from family inet6set policy-options policy-statement export-bgp-ipv6 term 1 from route-filter 3a05:d840:0043:ffff:ffff:ffff:0000:0001/128 exactset policy-options policy-statement export-bgp-ipv6 term 1 then accept
set policy-options policy-statement export-route-ipv6 from protocol aggregateset policy-options policy-statement export-route-ipv6 then accept
I can ping from the Core to facebook's IPv6 address and I can ping the LNS with a source address of the upstream ISP facing interface.
The route for both directions is in the core routing table correctly as can be seen:
3a03:2880:f11a::/48*[BGP/170] 01:19:43, MED 0, localpref 100 AS path: 3257 32934 I, validation-state: unverified > to 2001:668:0:3:ffff:0:4d43:5045 via xe-1/2/5.0
3a05:d840:43:ffff:ffff:ffff::/126 *[Direct/0] 01:29:24 > via xe-1/2/3.0
As mentioned, the configuration appears to be exactly the same at both sites and one site can ping and the other cannot....
Maybe I have missed something.....
This issue has been resolved as follows:
Although we are advertising the required networks, the upstream ISP had a filter list for us. This was changed to include the new IP range and everything now works fine.