Leased Line IPv6 problem with Unifi UDM Pro

Hi,

I have a 1G/1G Daisy leased line with a Virgin tail, with an Adva OS6250-8M and Cisco C1111-8P managed router connected to my UDM Pro. It's been up and running fine for nearly two years using IPv4, but I need to use IPv6 for some Terragraph kit. I've had the static IPv6 configured by Daisy and can use this successfully with my laptop connected directly to the Cisco, however I can't make it work properly on the UDMP, it can ping6 out fine with SSH on the UDMP and my clients receive an IPv6 address but have no IPv6 connectivity.

I've had had extensive support from Ubiquiti and Daisy, Ubiquiti say that my ISP must support prefix delegation and Daisy are unable to provide it.

https://help.ui.com/hc/en-us/articles/115005868927-U...
I find it hard to believe that the UDMP has this limitation when the help article above says:

"Depending on the configuration of the ISP, the UDM/USG can either use DHCPv6-PD (Prefix Delegation) or Static IPv6 addresses to provide IPv6 connectivity to the clients on the LAN. In both setups, the information regarding the connection type and its values is provided by the ISP."

Has anyone managed to get this to work?

I do have an Edgerouter 12P and a Mikotik Hex S I can use but are no expert at setting those up.

Thanks for any help!

Posted by Pheasant on a thread I hijacked:

Hi - First off, your question might get better visibility and answers if you start a fresh thread.

Secondly I’m no expert when it comes to IPv6, but could you not ask Daisy for a /48 or /56 prefix and simply use static addressing in lieu of PD?

@Pheasant, can you expand on how changing it to /48 or /56 might help? I'm willing to try anything.

Thanks.

Provided to me by Daisy:

The IPv6 Range 2001:xxx:xxx:2300::/56 has been routed to port Gi0/1/0 (Vlan100, port currently in use by your IPv4 network) & Gi0/1/1 (Vlan100, port currently free) on the Cisco 1111-8P router. Please configure your network with the following details:

Gateway IP: 2001:xxx:xxx:2300::1/64

Usable IP's: 2001:xxx:xxx:2300::2 - 2001:xxx:xxx:2300:ffff:ffff:ffff:ffff

Daisy's DNS Servers:

DNS Preferred: 2a04:b2c0:202:3501::35

DNS Alternate: 2001:b98:202:3502::35

Screenshots of my configuration

https://drive.google.com/file/d/1e3GFOK0L95OTcLcphY9...

https://drive.google.com/file/d/1Oklq7eMWY0RVRF7WkGk...

That to me looks like your BQM should ping 2001:xxx:xxx:2300::1 as that is excluded from your availables for the LAN.

Your LAN devices should get both two IPv6 addresses, one of them labelled "temp". That will be what "What is my IP" checkers will see, and will change very frequently. Don't give anywhere public the non-temp one as you open up the device to direct attack.

On your LAN you will also get fe80 addresses. These are the equivalent of the 192.168.x.x of IPv4 and are used for communication between devices. Also when I had IPv6, to address the gateway. (As in out to Daisy and onward).

Edited by pluralist (Fri 23-Jul-21 13:11:01)

In your first config link you have 2301. That is a /64 address you haven't been allocated. within the /56.

If they are working similarly to AAISP that I was with, you can request further /64s FOC, but on a normal non-commercial setup I doubt if it's necessary.

Edit: to add FOC (Free Of Charge)
Edit 2: to strike out the fuzzy-brained bit on the first line.

Edited by pluralist (Fri 23-Jul-21 17:42:45)

I think those details appear correct, if the OP is configuring their LAN side, which those settings appear to be, you would specify usually a /64.

They have been allocated a /56, this means they have 256 subnets available and can pick anything in the range of 2001:xxxx:xxxx:2300 to 2001:xxxx:xxxx:23ff for use on their LAN. The configuration looks okay for the LAN side, I think the issue may be how they have configured the WAN side.

You try it on AAISP!

It wouldn't work . Note I did say "If they are working similarly to AAISP that I was with".

AAISP give you a /48 with a pre-allocated /56. But to use further /56s you need to allocate them yourself in your Control Panel so that AAISP can set up the routing on their system. They don't initially set up routing for all your /56s.

How Daisy does it is what we don't know. (Googling for their help links didn't come up with anything). What we do know is that the OP can't get either of them working. It would be better therefore not to try two things at once, the second being the addition /64.

It is probable that the OP is in fact a business of some sort, invalidating a bit of my earlier post, but they need to get the "known" working first. Particularly as Daisy themselves said:

Please configure your network with the following details:

Gateway IP: 2001:xxx:xxx:2300::1/64

Usable IP's: 2001:xxx:xxx:2300::2 - 2001:xxx:xxx:2300:ffff:ffff:ffff:ffff

That seems to be similar to AA.

The lowest address within each subnet prefix (the interface identifier set to all zeroes) is reserved as the "subnet-router" anycast address, try setting the LAN address to 2001:xxxx:xxxx:2301::1/64 instead of 2001:xxxx:xxxx:2301::/64

I think AAISP are not typical of most ISPs, not said in a negative way.

I've been with Cerberus and IDNet and at no time did I need to enable more of the allocation. Cerberus I got all of /56 and IDNet all of the /48 straight from the get go, I would think AAISP is always the exception. Daisy did say they have routed all of the /56 as well.

I think we need to see the WAN setup side, how they have that set will decide if traffic routes in or out, as internally they did say devices had their IPv6 addresses, just no traffic in or out.

Have Daisy said what they are expecting the next-hop address to be for your /56 from the perspective of their router? Usually how I'd expect to see this configured is (ignoring VRRP to keep things simple):

ISP interface configured to 2300::1/64
Your firewall configured to 2300::2/64

The ISP then has a route in their network that the next-hop for 2300::/56 is 2300::2/64 so that traffic can actually get back to you.

If they've just stuck a /64 on an interface and given you a 'usable range' as if it's IPv4 networking then that won't work. I've had this discussion with ISPs a fair amount so it can get frustrating but normally someone who works there knows what you're after.

No Daisy hasn't said anything about the next hop, their support ended with "We have provided you with the IPv6 solution as per your request, of which you have tested locally via a laptop and confirmed to be working."

Isn't the fact that it does work with my laptop connected to the Cisco proof that it's configured correctly on Daisys network? If your answer is no, I'll go back to them, what should I ask?

Thanks

In reply to a post by E300:

Daisy did say they have routed all of the /56 as well.

Exactly! Not all the /56s within the /64. That's my whole point.

They have specified /56 2300. Not /23ff.

Edit: To repeat:

Gateway IP: 2001:xxx:xxx:2300::1/64

Usable IP's: 2001:xxx:xxx:2300::2 - 2001:xxx:xxx:2300:ffff:ffff:ffff:ffff

Edited by pluralist (Fri 23-Jul-21 17:12:58)

When you set your laptop up you're sat in the subnet that your firewall goes in, that's why you can ping your UDM and the UDM can ping IPv6 targets. The Daisy network doesn't know where to send traffic to all the other hosts in the /56 because it doesn't sound like a route has been added.

You need to ask Daisy to add a route so you can use the IPv6 allocation, and the next-hop address needs to be whatever your UDM IPv6 address is on the WAN port.

Run a traceroute from an internet location to an address in the /56 allocation - you'll probably find it fails before the address on your UDM.

Here's me doing a (redacted) traceroute to an address in an unconfigured prefix on my LAN:

Tracing route to 2a01:xxxx:129:3::1 over a maximum of 30 hops

1 1 ms 1 ms 1 ms 2a00:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1bb2
2 6 ms 5 ms 5 ms 2a00:xxxx::xxxx:xxxx
3 7 ms 7 ms 7 ms 2a00:xxxx::xxxx:xxxx:xxxx
4 8 ms 8 ms 8 ms 2a00:xxxx::xxxx:xxxx:xxxx
5 * * * Request timed out.
6 10 ms 10 ms 11 ms peer7-et0-1-6.telehouse.ukcore.bt.net [2a00:2380:13::a7]
7 10 ms 8 ms 10 ms 2001:7f8:4::b972:1
8 16 ms 14 ms 7 ms 2a01:xxxx:xxxx:xxxx::
9 13 ms 9 ms 8 ms 2a01:xxxx:xxxx:xxxx::1
10 10 ms 7 ms 8 ms 2a01:xxxx:129::2
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * ^C

Hop 10 is the interface on the firewall, which then starts dropping the traffic hence the timeout messages. If you do the same thing and get a "no route to host" error instead of seeing your UDM WAN interface IP then Daisy need to add a route.

Edited by jpm (Fri 23-Jul-21 17:38:41)

In reply to a post by E300:

I think those details appear correct, if the OP is configuring their LAN side, which those settings appear to be, you would specify usually a /64.

They have been allocated a /56, this means they have 256 subnets available and can pick anything in the range of 2001:xxxx:xxxx:2300 to 2001:xxxx:xxxx:23ff for use on their LAN. The configuration looks okay for the LAN side, I think the issue may be how they have configured the WAN side.

Ah, we were both right and both wrong, with me being the cause. I have struck out the offending part of the post. My brain was half-asleep at the time, by the look of things.

The fact remains that OP in his first picture link to is using 2301 in the first of his links, (https://drive.google.com/file/d/1e3GFOK0L95OTcLcphY9IS69ZxAR8Kc9q/view), which is what I objected to. That is the final quartet of a /64, and he hasn't been allocated it.

I accept it does look as if he can use the whole of his allocated /64 as he wishes .

I have to say that this is an excellent forum, I've tried to receive support on the Ubiquiti forum but that just sucks in comparison, so thank you everyone for taking the time to help.

So if 2301 on my LAN is no good what should I use?

Not all of it perfect from me ! My apologies. However, I can can still get some things right .

Another minor point is that on your lan you should no longer see fe80 addresses. These are now "deprecated", meaning they are being phased out and shouldn't be used. The correct equivalent is fc00.

Then we come to your specific setup

a Virgin tail, with an Adva OS6250-8M and Cisco C1111-8P managed router connected to my UDM Pro. It's been up and running fine for nearly two years using IPv4, but I need to use IPv6 for some Terragraph kit. I've had the static IPv6 configured by Daisy and can use this successfully with my laptop connected directly to the Cisco, however I can't make it work properly on the UDMP, it can ping6 out fine with SSH on the UDMP and my clients receive an IPv6 address but have no IPv6 connectivity.

I wouldn't have a clue where to start with that particular kit combination. Modems, modems feeding routers, modem/routers bridging to routers I can often handle, but you have two high-end routers and a fancy switch there. One of the routers presumably containing the modem.

What I expect you should have on your LAN is roughly what I previously described. Each device should receive its own public IPv6 address on your 2001:xxx:xxx:2300::/56. IIRC from the past, your 2301 config picture is fine except for the 2301 should be 2300 and I'm unsure now about the final /56 or the /64 you had there. (I ditched my dual IPv4 and IPv6 AAISP connection at the end of November 2018 so can't easily looked up how I configured my /64s. Not /56s as I previously said when I did have 2 for a while inside the full /48 they provide).

Although in E300's first reply to me he says you could use anything including your 2301 on your LAN, I believe those would be sent via the net (and possibly fail), rather than through your LAN where your should have fc00 addresses just like you get 192.168.n.n ones on IPv4.

I of course, given my track record today, stand to be corrected on that! (Dammit !)

Your router controlling your LAN's connection to the net I would expect use its DHCP to provide the fc00 addresses and the 2300 ones. With two 2300 ones per device per device as I explained previously.

Useful stuff:
AAISP IPv6 knowledgebase, which although it describes how they handle it also contains a lot of explanation. Also related pages linked from there.

RIPE, which includes

A single network at a customer site will be a /64. At present, RIR policies permit assignment of a /48 per site, so the possible options when choosing a prefix size to delegate are /48, /52, /56, /60 and /64. However, /64 is not sustainable, it doesn't allow customer subnetting, and it doesn't follow IETF recommendations of “at least” multiple /64s per customer. Moreover, future work within the IETF and recommendations from RFC 7934 (section 6) allow the assignment of a /64 to a single interface (https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-07).

The following sections explain why /48 and /56 are the recommended prefix assignment sizes for end customers.

That quote comes from Section 4.2. I suggest you read on to the end of 4.2.3 .

In reply to a post by pluralist:

Another minor point is that on your lan you should no longer see fe80 addresses. These are now "deprecated", meaning they are being phased out and shouldn't be used. The correct equivalent is fc00.

Completely incorrect. There will always be an fe80::/10 address (so in the range fe80:: - fe80::ffff:ffff:ffff:ffff) present on an interface, regardless of any other addresses, it is required for some IPv6 mechanisms such as NDP (Neighbour Discovery Protocol) and DHCPv6. The closest IPv4 equivalent are the RFC3927 addresses (169.254.1.0 - 169.254.254.255).

The fc00::/7 ULA (Unique Local Address) range is split into two equal-sized blocks. The use of fc00::/8 is currently undefined, and fd00::/8 (so in the range fd00:: - fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff) is for private addressing within an administrative domain encompassing a site or organisation, the IPv4 equivalent are the RFC1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).

You may be thinking of the fec0::/10 site-local address range which was deprecated in 2004 as what comprised a "site" was open to interpretation causing confusion. These should not be used.

Hi, I hope this is useful.

Traceroute from https://network-tools.webwiz.net/traceroute.htm to Cisco
1 0 ms 2a00:85c0:1::2
2 6 ms 2001:1900:5:2:2:0:8:7d75
3 5 ms 2001:1900:2::3:159
4 5 ms 2001:1900:5:2:2::2a5e
5 8 ms 2001:xxx:1:1::ff3e:b0
6 12 ms 2001:xxx:xxx:2300::1

Traceroute from https://network-tools.webwiz.net/traceroute.htm to UDMP
1 0 ms 2a00:85c0:1::2
2 5 ms 2001:1900:5:2:2:0:8:7d75
3 5 ms 2001:1900:2::3:159
4 6 ms 2001:1900:5:2:2::2a5e
5 7 ms 2001:xxx:1:1::ff3e:b0
6 12 ms 2001:xxx:xxx:101::35:2
7 Timeout Unknown Host did not respond to ping

From UDMP SSH
traceroute to ipv6.google.com (2a00:1450:4009:815::200e), 30 hops max, 72 byte packets
1 2001:xxx:xxx:2300::1 0.722 ms 0.592 ms 0.461 ms
2 2001:xxx:300:101::35:1 5.748 ms 6.417 ms 6.109 ms
3 2001:xxx:1:1::ff40:dc 5.805 ms 5.860 ms 5.962 ms
4 2001:xxx:1:40:1525:3b41:1:2 6.587 ms 6.645 ms 6.561 ms
5 2a00:1450:8125::1 5.877 ms * *
6 * 2001:4860:0:1::5378 5.954 ms 2001:4860:0:1::248e 5.874 ms
7 * 2001:4860:0:1100::f 7.301 ms 2001:4860:0:1100::10 6.801 ms
8 lhr35s11-in-x0e.1e100.net (2a00:1450:4009:815::200e) 6.390 ms 5.881 ms *

I get no route from the LAN.

Thanks.

In reply to a post by tdw42:

In reply to a post by pluralist:

Another minor point is that on your lan you should no longer see fe80 addresses. These are now "deprecated", meaning they are being phased out and shouldn't be used. The correct equivalent is fc00.

Completely incorrect.
...
You may be thinking of the fec0::/10 site-local address range which was deprecated in 2004 as what comprised a "site" was open to interpretation causing confusion. These should not be used.

You are right, except I wasn't thinking about fec0::/10. don't recall ever seeing that. I may have simply mis(speed)read something where fe80 v fc00 was being discussed. In particular wrt the 192.168.n.n of IPv4.

Thanks for pointing it out. The OP does need to get the right information.

In reply to a post by tdw42:

The lowest address within each subnet prefix (the interface identifier set to all zeroes) is reserved as the "subnet-router" anycast address, try setting the LAN address to 2001:xxxx:xxxx:2301::1/64 instead of 2001:xxxx:xxxx:2301::/64

Unfortunately, this didn't work.

Thanks.

In reply to a post by pluralist:

In reply to a post by tdw42:

In reply to a post by pluralist:

Another minor point is that on your lan you should no longer see fe80 addresses. These are now "deprecated", meaning they are being phased out and shouldn't be used. The correct equivalent is fc00.

Completely incorrect.
...
You may be thinking of the fec0::/10 site-local address range which was deprecated in 2004 as what comprised a "site" was open to interpretation causing confusion. These should not be used.

You are right, except I wasn't thinking about fec0::/10. don't recall ever seeing that. I may have simply mis(speed)read something where fe80 v fc00 was being discussed. In particular wrt the 192.168.n.n of IPv4.

Thanks for pointing it out. The OP does need to get the right information.

Can you recap what info I need to get, please?

Thank you.

A lot has been said by many of us. So a recap is difficult.

All I can recommend at the moment is that you forget about the 2301. Just use the 2300, which should appear automatically in your LAN if things are set up correctly. As should one or other or several fe80s or fc00s.

It isn't impossible that the info you have from Daisy is slightly incorrect, possibly the person writing it making a mistake like I've made a few. Though most of what I've posted has not been challenged - as it's right .

I keep harking back to:

Provided to me by Daisy:

The IPv6 Range 2001:xxx:xxx:2300::/56 has been routed to port Gi0/1/0 (Vlan100, port currently in use by your IPv4 network) & Gi0/1/1 (Vlan100, port currently free) on the Cisco 1111-8P router. Please configure your network with the following details:

Gateway IP: 2001:xxx:xxx:2300::1/64

Usable IP's: 2001:xxx:xxx:2300::2 - 2001:xxx:xxx:2300:ffff:ffff:ffff:ffff

That quote has internal inconsistences. For the whole of the /56 to have been routed, i.e. available, the usable IP's would be "2001:xxx:xxx:2300::2 - 2001:xxx:xxx:23ff:ffff:ffff:ffff:ffff", so you could put anything you liked after the final "23". The "2300" at the end of the availables suggests to me a /64 has actually been routed. Not the /56 as stated.

Even if I'm wrong, the fact your using 2301 is not what they say is usable. So my recommendation throughout not just at the start of this post has been not to try 2301 until you get 2300 working. You definitely should not be specifying it within the 2300 LAN. The 2301 would be a different /64 subnet within the /56, though possibly with the same 2300 gateway.

PS: Let's see how wrong I'm shown to be with that little lot. Though I cannot be wrong in recommending to first get things working with no mention at all of 2301 in your setup .

Edit: The DHCP for your LAN in your router should be using the range Daisy specified as available, the full range of 2300 starting with "2". "1" being the external address of your router.

Edited by pluralist (Sat 24-Jul-21 16:02:18)

There is a difference between connecting an endpoint (the PC) and a router (the UDM Pro).

The WAN setup on the UDM Pro appears correct as the OP can successfully traceroute to an external site, the last hop of the traceroute to the UDM Pro likely fails due to the default firewall rules.

The UDM Pro will require a unique /64 on each interface, as would any router, it is not possible to use the same 2001:xxxx:xxxx:2300::/64 subnet on both WAN and LAN interfaces. Using 2001:xxxx:xxxx:2300::2/64 as the WAN address and 2001:xxxx:xxxx:2301::1/64 as the LAN address is perfectly valid.

As you say the Information from Daisy is contradictory, and I believe the issue is that they need to route the /56, or some subset thereof, to the UDM Pro WAN address. A traceroute to an address in any other subnet (so 2001:xxxx:xxxx:2301::1/64 to 2001:xxxx:xxxx:23ff::1/64) may or may not provide some information.

In reply to a post by jpm:

Have Daisy said what they are expecting the next-hop address to be for your /56 from the perspective of their router? Usually how I'd expect to see this configured is (ignoring VRRP to keep things simple):

ISP interface configured to 2300::1/64
Your firewall configured to 2300::2/64

The ISP then has a route in their network that the next-hop for 2300::/56 is 2300::2/64 so that traffic can actually get back to you.

If they've just stuck a /64 on an interface and given you a 'usable range' as if it's IPv4 networking then that won't work. I've had this discussion with ISPs a fair amount so it can get frustrating but normally someone who works there knows what you're after.

If the OP is able to raise a ticket to arrange a telecon with Daisy 2nd /3rd level support team responsible for configuring their customer addressing then that may be the most expedient way for both of them to walk through the config. Whilst both on the line, hopefully they can both cross check everything and get things moving.

You never know there may be an “ah ha” moment during which Daisy discover an error has been made on their side or some routing not been correctly configured….

Do you think I should ask for a /48 when I ask them to check their config (again)?

There’s no harm in it. It may be ‘force’ them to recheck the config. So from that perspective no bad thing.

In reply to a post by JESC77:

Hi, I hope this is useful.

Traceroute from https://network-tools.webwiz.net/traceroute.htm to Cisco
1 0 ms 2a00:85c0:1::2
2 6 ms 2001:1900:5:2:2:0:8:7d75
3 5 ms 2001:1900:2::3:159
4 5 ms 2001:1900:5:2:2::2a5e
5 8 ms 2001:xxx:1:1::ff3e:b0
6 12 ms 2001:xxx:xxx:2300::1

Traceroute from https://network-tools.webwiz.net/traceroute.htm to UDMP
1 0 ms 2a00:85c0:1::2
2 5 ms 2001:1900:5:2:2:0:8:7d75
3 5 ms 2001:1900:2::3:159
4 6 ms 2001:1900:5:2:2::2a5e
5 7 ms 2001:xxx:1:1::ff3e:b0
6 12 ms 2001:xxx:xxx:101::35:2
7 Timeout Unknown Host did not respond to ping

From UDMP SSH
traceroute to ipv6.google.com (2a00:1450:4009:815::200e), 30 hops max, 72 byte packets
1 2001:xxx:xxx:2300::1 0.722 ms 0.592 ms 0.461 ms
2 2001:xxx:300:101::35:1 5.748 ms 6.417 ms 6.109 ms
3 2001:xxx:1:1::ff40:dc 5.805 ms 5.860 ms 5.962 ms
4 2001:xxx:1:40:1525:3b41:1:2 6.587 ms 6.645 ms 6.561 ms
5 2a00:1450:8125::1 5.877 ms * *
6 * 2001:4860:0:1::5378 5.954 ms 2001:4860:0:1::248e 5.874 ms
7 * 2001:4860:0:1100::f 7.301 ms 2001:4860:0:1100::10 6.801 ms
8 lhr35s11-in-x0e.1e100.net (2a00:1450:4009:815::200e) 6.390 ms 5.881 ms *

I get no route from the LAN.

Thanks.

The last one I need is a traceroute from outside your network to an address inside the /48 or /56 - one that should be routing via your UDM. This will tell us if Daisy have configured the routing correctly.

He hasn't got a /48.

That's why I said /48 or /56

Traceroute from https://network-tools.webwiz.net/traceroute.htm to 2001:xxx:xxx:23aa::4fb automatically assigned to my laptop (tried configuring the LAN with 23aa for the hell of it).

1 1 ms 2a00:85c0:1::2
2 5 ms 2001:1900:5:2:2:0:8:7d75
3 5 ms 2001:1900:2::3:159
4 6 ms 2001:1900:5:2:2::2a5e
5 9 ms 2001:b98:1:1::ff3e:b0
6 12 ms 2001:b98:300:101::35:2
7 Timeout Unknown Host did not respond to ping

Cheers

What have you got against configuring the LAN as 2300? (2-ffff as the router has 1).

It's the one thing you you don't seem to have tried, and it is what Daisy said you should do!

It's so simple.

Edited by pluralist (Mon 26-Jul-21 21:25:58)

Have Daisy verified they have added the route on their side, pointing towards your firewall? It doesn't look like they have because the error response isn't coming back from the UDM (unless ICMP is disabled and making everything look like a timeout).

What is this firewall? The one in the router or something else? Since when did a (software/firmware) firewall have its own IP address?

If Daisy have only routed the 2300 (/64) in the /56, then pings to LAN 2301 will not get go anywhere.

Most here seem to me to be grossly over-complicating this. The OP is not setting up his LAN as specified by Daisy. Before trying the strange 2301, for heavens sake can't we get the Daisy-specified setup tried?

In reply to a post by pluralist:

What have you got against configuring the LAN as 2300? (2-ffff as the router has 1).

It's the one thing you you don't seem to have tried, and it is what Daisy said you should do!

It's so simple.

I have tried 2300, just tried again and performed a traceroute to 2001:xxx:xxx:2300::4fb assigned to my laptop and got the same results. IPv6 tests fail.

In reply to a post by jpm:

Have Daisy verified they have added the route on their side, pointing towards your firewall? It doesn't look like they have because the error response isn't coming back from the UDM (unless ICMP is disabled and making everything look like a timeout).

I've received a reply from my account manager who sent my request to the relevant team, awaiting next response.

In reply to a post by pluralist:

What is this firewall? The one in the router or something else? Since when did a (software/firmware) firewall have its own IP address?

If Daisy have only routed the 2300 (/64) in the /56, then pings to LAN 2301 will not get go anywhere.

Most here seem to me to be grossly over-complicating this. The OP is not setting up his LAN as specified by Daisy. Before trying the strange 2301, for heavens sake can't we get the Daisy-specified setup tried?

By firewall I mean UDM. The routing goes ISP -> Cisco router -> UDM -> LAN hosts, you can't put addresses from the same /64 on the WAN side of the UDM as well as on a LAN subnet.

Currently we know what /64 to use between the Cisco router and the WAN side of the UDM, because that works. We're just waiting for confirmation that the whole allocation has been routed correctly.

Edited by jpm (Tue 27-Jul-21 09:44:35)

In reply to a post by pluralist:

What is this firewall? The one in the router or something else? Since when did a (software/firmware) firewall have its own IP address?

If Daisy have only routed the 2300 (/64) in the /56, then pings to LAN 2301 will not get go anywhere.

Most here seem to me to be grossly over-complicating this. The OP is not setting up his LAN as specified by Daisy. Before trying the strange 2301, for heavens sake can't we get the Daisy-specified setup tried?

The firewall is built in the UDM Pro, I haven't added any rules for IPv6 yet.

What should I use for the LAN?

Here's how Ubiquiti say it should be setup:
WAN
IPv6 Connection Type: Static IP
IPv6 Address: 2001:db8::1
Prefix Length: 64
Router: 2001:db8::2
LAN
IPv6 Interface Type: Static
IPv6 Gateway Subnet: 2001:db8:1::1/64
IPv6 RA: Checked
IPv6 RA Priority: High
DHCPv6: Checked
DHCPv6 Range > Start: 2001:db8:1::2
DHCPv6 Range > Stop: 2001:db8:1::7d1
DHCPv6 Lease Time: 86400
DHCPv6/RDNSS DNS Control: Auto
DHCPv6/RDNSS Name Server > DNS Server 1: <customizable>
DHCPv6/RDNSS Name Server > DNS Server 2: <customizable>
DHCPv6/RDNSS Name Server > DNS Server 3: <customizable>
DHCPv6/RDNSS Name Server > DNS Server 4: <customizable>

https://help.ui.com/hc/en-us/articles/115005868927-U...

Oh heck!

I've just realised why nobody agrees with me. I think I have been barking up the wrong tree. I'd forgotten what I meant to query as soon as I read your OP. The fact that you have two routers. I know how to configure that with IPv4, as you obviously do as you have it working. But as I just said, I forgot .

Apologies to you and the rest.

But I don't think they have it right either.

You have things working fine on IPv4. But which is the WAN link, as they both seem to have internet connectivity, and which is allocating your LAN addresses by DHCP? Are they both in router mode, or is the WAN link bridged?

In reply to a post by pluralist:

Oh heck!

I've just realised why nobody agrees with me. I think I have been barking up the wrong tree. I'd forgotten what I meant to query as soon as I read your OP. The fact that you have two routers. I know how to configure that with IPv4, as you obviously do as you have it working. But as I just said, I forgot .

Apologies to you and the rest.

But I don't think they have it right either.

You have things working fine on IPv4. But which is the WAN link, as they both seem to have internet connectivity, and which is allocating your LAN addresses by DHCP? Are they both in router mode, or is the WAN link bridged?

No worries!

I'm only using Gi0/1/0 on the cisco, the port I've always used.

DHCP and DHCPv6 are provided by the UDMP, Daisy have been very closed about their setup but maybe the fact that they are unable to provide DHCPv6 shows it is in bridge mode, I'll find out.

So the incoming line is going to the Cisco? Which then feeds the UDMP which then feeds the switch? (Line <> Cisco <> UDMP)

Or is it the other way round, line <> UDMP <> Cisco <> switch?

In reply to a post by pluralist:

So the incoming line is going to the Cisco? Which then feeds the UDMP which then feeds the switch? (Line <> Cisco <> UDMP)

Or is it the other way round, line <> UDMP <> Cisco <> switch?

It a fully managed service rather than "wires only" leased line. So the former.

In reply to a post by Pheasant:

In reply to a post by pluralist:

So the incoming line is going to the Cisco? Which then feeds the UDMP which then feeds the switch? (Line <> Cisco <> UDMP)

Or is it the other way round, line <> UDMP <> Cisco <> switch?

It a fully managed service rather than "wires only" leased line. So the former.

This is correct.

(Also @Pheasant)
In which case surely Daisy are referring to the Cisco when they say how to configure the router? That will be the DHCP they are referring to, and the DHCP in the UDMP should be disabled?

In reply to a post by pluralist:

(Also @Pheasant)
In which case surely Daisy are referring to the Cisco when they say how to configure the router? That will be the DHCP they are referring to, and the DHCP in the UDMP should be disabled?

The Cisco wont be end user accessible/manageable. The Cisco effectively presents the service on the respective user ports. That's effectively the network demarcation point for the OP.

Any routing etc on "their" side would need to be checked and confirmed by Daisy.

You're saying the Cisco is bridged then? It did occur to me after posting that is what the OP is asking Daisy to confirm.

(Isn't that then a very expensive piece of kit for the purpose?)

Cisco or Juniper are pretty much the defacto standard fare for a managed leased line service here. Depending on what services are delivered, then it’s a little bit more than a bridge - typically the provider will use it to provision and manage VLAN(s) for the various service. Some customers may wish to have one or more VLANs presented on one or more particular physical ports. This enables the CP to be able to define these and check their operation on the fly. It gives them end to end management of the circuit and the services laid on top.

The difference between managed and unmanaged (or wires only) is that the latter simply present the “circuit” to the customer on one of the Adva ports. The customer must then configure the VLAN termination and any associated routing on their own kit (router) for onward connection to their network.

In reality the costs of providing the actual kit are minimal compared to the overall cost of the circuit and tails etc.

Thanks. That clarifies some thing I didn't know.

From what you say though, these settings:

Gateway IP: 2001:xxx:xxx:2300::1/64

Usable IP's: 2001:xxx:xxx:2300::2 - 2001:xxx:xxx:2300:ffff:ffff:ffff:ffff

Daisy's DNS Servers:

DNS Preferred: 2a04:b2c0:202:3501::35

DNS Alternate: 2001:b98:202:3502::35

Are for the UDMP? In which case this page should have 2300 not 2300, and this one have IPv6 Address also ending in ::1 not the ::2 in the screenshot.

Despite the /56 in this quote:

The IPv6 Range 2001:xxx:xxx:2300::/56 has been routed to port Gi0/1/0 (Vlan100, port currently in use by your IPv4 network) & Gi0/1/1 (Vlan100, port currently free) on the Cisco 1111-8P router

I think the intended meaning is "this specific /56".

Effectively a /64, although ::23ff may well be routed through it. Though we can't be sure 23ff is routed inwards.

I've received a reply from Daisy.
Note, all the x's represent the same numbers/letter as in the initial configuration sent to me (probably obvious to you).

"On 28/05 I added the IPv6 configuration, emailed yourself confirming the /64 assigned to the interface Gi0/1/1 (Vlan100), that we have routed a /56 through our core to site (the /64 is part of this), the gateway IP, the usable IPv6 addresses and our IPv6 DNS servers.

On the 09/06 you advised when you connect a laptop directly into the port and configure one of the available IPv6 addresses etc that you have Internet facing connectivity, so confirmed all is working and this confirms that there’s no issue with the IPv6 configuration/routing applied.

There’s been no contradictory information, we reserve/route a /56 on our core and configure a /64 on your LAN interface (this give you 18,446,744,073,709,551,614 usable IPv6 addresses so should be more than you would ever need). My colleague also advised that we don’t support DHCPv6 and this is down to yourself to manage on your LAN via a device that can act as the IPv6 DHCP server.

Why do you need the LAN changing to a /48, as long as you configure the gateway/subnet correctly etc then there should be no issue with the configuration we have added and provided details on?


If you want to see the config added to your CPE, then please see the below:

int Gi0/0/0
ipv6 address 2001:xxx:xxx:101::35:2/112
!
int Vlan100
ipv6 address 2001:xxx:xxx:2300::1/64
!
ipv6 route 2001:xxx:xxx:2300::/56 Vlan100
!
ipv6 route ::/0 GigabitEthernet0/0/0 2001:xxx:xxx:101::35:1


There’s nothing further we can advise on this, as there’s no issue with the solution we are providing."

Where do I go from here?

Think it would be useful to get an output from the UDM of the IPv6 routes and routing tables. Can you get that from the CLI/shell commands?

Can various devices connected the LAN ping6 each other and the UDM?

On 28/05 I added the IPv6 configuration, emailed yourself confirming the /64 assigned to the interface Gi0/1/1 ...

I believe that confirms that Daisy are in fact working the way AAISP did.

The writer specifically says the 2300 is a /64 within the the /56. In the same way as my /56s on AAISP were within my overall /48. At initial setup time they only "activated" the single subnet of my /48, and Daisy seem only to gave activated the 2300 /64.

However, the rest of the reply from them is just pathetic. Particularly "we reserve/route a /56 on our core and configure a /64 on your LAN interface". But that line also confirms they have only configured a /64, the 2300 one. The rest of your 23ff is "reserved" for if you require another subnet or subnets.

It may mean you can use the 2301 subnet if you wish, (as the other posters believe you can), and may work once you have the 2300 one working, but I reiterate that you need to get what they specify working before trying to go beyond it . A step at a time.

People already using IPv4 blocks will know why they want them, and the reasons they have those will be real. The only one I know of is having internet servers at home accessible from outside, but not wanting them on your own LAN.

There is also the Internet Of Things rapidly approaching, where segregating domestic devices on a different subnet isn't necessary for things to work, but could save a lot of time diagnosing local faults without needing to disable access on other subnets.

Re your own setup, see what I said about your two screenshots in the post you replied to. Particularly the router IPv6 address.

What the two 2001:xxx:xxx:101::35: lines are about I have no idea unless they are to do with the leased line connection itself to their system, for any management they may need to do. (I expect you know your first "xxxx" after the 2001 identifies Daisy as the CP). Seeing as they haven't previously mentioned them as having anything to do with user-configuration I almost wonder if the writer is just trying to be rude "clever".

Just another thing that if you don't know about it can help a lot, and assuming you are using Windows. Click the Windows key and when the menu pops up type Command prompt. (It will come up offering the app you want after a few characters).

In the black window type
ipconfig /all
and press Return

This will not "do" or alter anything. It will list all the connections your computer is seeing, with their IPv4, IPv6 and Temp addresses. This sort of thing:

Wireless LAN adapter WiFi:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Realtek RTL8822BE 802.11ac PCIe Adapter
Physical Address. . . . . . . . . : 5C-BA-EF-B3-79-FF
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : fd24:fb65:5fe3:3300:68aa:1ef9:2660:c64(Preferred)
Temporary IPv6 Address. . . . . . : fd24:fb65:5fe3:3300:90f8:a8ee:44a9:7cc1(Preferred)
Link-local IPv6 Address . . . . . : fe80::68aa:1ef9:2660:c64%8(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.8.150(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 21 July 2021 18:45:00
Lease Expires . . . . . . . . . . : 28 July 2021 17:16:43
Default Gateway . . . . . . . . . : 192.168.8.1
DHCP Server . . . . . . . . . . . : 192.168.8.1
DHCPv6 IAID . . . . . . . . . . . : 89963247
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-27-13-4B-F4-F8-0D-AC-20-11-9B
DNS Servers . . . . . . . . . . . : fe80::26fb:65ff:fe5f:e333%8
192.168.8.1
NetBIOS over Tcpip. . . . . . . . : Enabled

The directly attached static route (ipv6 route 2001:xxx:xxx:2300::/56 Vlan100) is useless here, you need them to add a recursive static route.

Not being familiar with how Cisco routers handle overlapping addresses and subnets (as the 2001:xxx:xxx:2300::/64 subnet is part of the larger 2001:xxx:xxx:2300::/56) I'd suggest asking for just some of the /56 to be routed to the UDMP WAN address, e.g. ipv6 route 2001:xxx:xxx:2310::/60 2001:xxx:xxx:2300::2/64 which would route 16 of the subnets (2001:xxx:xxx:2310::/64 to 2001:xxx:xxx:231f::/64) to the UDMP.

In reply to a post by Pheasant:

Think it would be useful to get an output from the UDM of the IPv6 routes and routing tables. Can you get that from the CLI/shell commands?

Can various devices connected the LAN ping6 each other and the UDM?

I can only get the IPv4 routing table, will continue to look into it though.

I'll attempt to ping6 some other devices when on site tomorrow.

In reply to a post by pluralist:

On 28/05 I added the IPv6 configuration, emailed yourself confirming the /64 assigned to the interface Gi0/1/1 ...

I believe that confirms that Daisy are in fact working the way AAISP did.

The writer specifically says the 2300 is a /64 within the the /56. In the same way as my /56s on AAISP were within my overall /48. At initial setup time they only "activated" the single subnet of my /48, and Daisy seem only to gave activated the 2300 /64.

However, the rest of the reply from them is just pathetic. Particularly "we reserve/route a /56 on our core and configure a /64 on your LAN interface". But that line also confirms they have only configured a /64, the 2300 one. The rest of your 23ff is "reserved" for if you require another subnet or subnets.

It may mean you can use the 2301 subnet if you wish, (as the other posters believe you can), and may work once you have the 2300 one working, but I reiterate that you need to get what they specify working before trying to go beyond it . A step at a time. I believe I do have it working, when my laptop is plugged into the cisco with a static IPv6 address of 2001:xxx:xxx:2300::2

People already using IPv4 blocks will know why they want them, and the reasons they have those will be real. The only one I know of is having internet servers at home accessible from outside, but not wanting them on your own LAN.

There is also the Internet Of Things rapidly approaching, where segregating domestic devices on a different subnet isn't necessary for things to work, but could save a lot of time diagnosing local faults without needing to disable access on other subnets.

Re your own setup, see what I said about your two screenshots in the post you replied to. Particularly the router IPv6 address. I'm pretty sure that in. the UDMP WAN settings "Router" should be 2001:xxx:xxx:2300::1, if it's anything else, I cant ping out from the the UDMP.

What the two 2001:xxx:xxx:101::35: lines are about I have no idea unless they are to do with the leased line connection itself to their system, for any management they may need to do. (I expect you know your first "xxxx" after the 2001 identifies Daisy as the CP). Seeing as they haven't previously mentioned them as having anything to do with user-configuration I almost wonder if the writer is just trying to be rude "clever".

Just another thing that if you don't know about it can help a lot, and assuming you are using Windows. Click the Windows key and when the menu pops up type Command prompt. (It will come up offering the app you want after a few characters).

In the black window type
ipconfig /all
and press Return

This will not "do" or alter anything. It will list all the connections your computer is seeing, with their IPv4, IPv6 and Temp addresses. This sort of thing:

Wireless LAN adapter WiFi:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Realtek RTL8822BE 802.11ac PCIe Adapter
Physical Address. . . . . . . . . : 5C-BA-EF-B3-79-FF
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : fd24:fb65:5fe3:3300:68aa:1ef9:2660:c64(Preferred)
Temporary IPv6 Address. . . . . . : fd24:fb65:5fe3:3300:90f8:a8ee:44a9:7cc1(Preferred)
Link-local IPv6 Address . . . . . : fe80::68aa:1ef9:2660:c64%8(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.8.150(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 21 July 2021 18:45:00
Lease Expires . . . . . . . . . . : 28 July 2021 17:16:43
Default Gateway . . . . . . . . . : 192.168.8.1
DHCP Server . . . . . . . . . . . : 192.168.8.1
DHCPv6 IAID . . . . . . . . . . . : 89963247
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-27-13-4B-F4-F8-0D-AC-20-11-9B
DNS Servers . . . . . . . . . . . : fe80::26fb:65ff:fe5f:e333%8
192.168.8.1
NetBIOS over Tcpip. . . . . . . . : Enabled

I'm using a Mac but here's my ifconfig output if it's useful at all.

The default interactive shell is now zsh.
To update your account to use zsh, please run `chsh -s /bin/zsh`.
For more details, please visit https://support.apple.com/kb/HT208050.
Jays-MBP-3:~ jaycockerill$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
nd6 options=201<PERFORMNUD,DAD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8823<UP,BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500
options=400<CHANNEL_IO>
ether 8c:85:90:1b:32:7f
nd6 options=201<PERFORMNUD,DAD>
media: autoselect (<unknown type>)
status: inactive
en3: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
options=460<TSO4,TSO6,CHANNEL_IO>
ether 82:80:e9:45:20:01
media: autoselect <full-duplex>
status: inactive
en1: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
options=460<TSO4,TSO6,CHANNEL_IO>
ether 82:80:e9:45:20:00
media: autoselect <full-duplex>
status: inactive
en4: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
options=460<TSO4,TSO6,CHANNEL_IO>
ether 82:80:e9:45:20:05
media: autoselect <full-duplex>
status: inactive
en2: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
options=460<TSO4,TSO6,CHANNEL_IO>
ether 82:80:e9:45:20:04
media: autoselect <full-duplex>
status: inactive
bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=63<RXCSUM,TXCSUM,TSO4,TSO6>
ether 82:80:e9:45:20:00
Configuration:
id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
ipfilter disabled flags 0x0
member: en1 flags=3<LEARNING,DISCOVER>
ifmaxaddr 0 port 7 priority 0 path cost 0
member: en2 flags=3<LEARNING,DISCOVER>
ifmaxaddr 0 port 9 priority 0 path cost 0
member: en3 flags=3<LEARNING,DISCOVER>
ifmaxaddr 0 port 6 priority 0 path cost 0
member: en4 flags=3<LEARNING,DISCOVER>
ifmaxaddr 0 port 8 priority 0 path cost 0
nd6 options=201<PERFORMNUD,DAD>
media: <unknown type>
status: inactive
p2p0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 2304
options=400<CHANNEL_IO>
ether 0e:85:90:1b:32:7f
media: autoselect
status: inactive
awdl0: flags=8902<BROADCAST,PROMISC,SIMPLEX,MULTICAST> mtu 1484
options=400<CHANNEL_IO>
ether fa:03:e3:95:cd:68
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: inactive
llw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=400<CHANNEL_IO>
ether fa:03:e3:95:cd:68
nd6 options=201<PERFORMNUD,DAD>
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
inet6 fe80::db14:98c5:c453:721b%utun0 prefixlen 64 scopeid 0xe
nd6 options=201<PERFORMNUD,DAD>
utun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000
inet6 fe80::a8d5:ddbb:8ead:7282%utun1 prefixlen 64 scopeid 0xf
nd6 options=201<PERFORMNUD,DAD>
utun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
inet6 fe80::8b09:3921:9b3a:d7c3%utun2 prefixlen 64 scopeid 0x10
nd6 options=201<PERFORMNUD,DAD>
utun3: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
inet6 fe80::94fd:b39a:29a5:f512%utun3 prefixlen 64 scopeid 0x11
nd6 options=201<PERFORMNUD,DAD>
utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
inet6 fe80::895a:8e24:5b10:d0cc%utun4 prefixlen 64 scopeid 0x12
nd6 options=201<PERFORMNUD,DAD>
utun5: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
inet6 fe80::27ad:5962:7497:8600%utun5 prefixlen 64 scopeid 0x13
nd6 options=201<PERFORMNUD,DAD>
utun6: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
inet6 fe80::2868:3424:eb1:9d54%utun6 prefixlen 64 scopeid 0x14
nd6 options=201<PERFORMNUD,DAD>
utun7: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
inet6 fe80::ec0e:f6b6:c678:8a70%utun7 prefixlen 64 scopeid 0x15
nd6 options=201<PERFORMNUD,DAD>
utun8: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
inet6 fe80::22c2:5dd4:a19e:94b3%utun8 prefixlen 64 scopeid 0x18
nd6 options=201<PERFORMNUD,DAD>
utun9: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
inet6 fe80::e416:d0f0:269b:711a%utun9 prefixlen 64 scopeid 0x19
nd6 options=201<PERFORMNUD,DAD>
en5: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether ac:de:48:00:11:22
inet6 fe80::aede:48ff:fe00:1122%en5 prefixlen 64 scopeid 0x4
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
en8: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=6467<RXCSUM,TXCSUM,VLAN_MTU,TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
ether 00:e0:4c:68:05:b3
inet6 fe80::c3f:6e5a:3068:6ccb%en8 prefixlen 64 secured scopeid 0x1b
inet 10.10.1.201 netmask 0xfffffe00 broadcast 10.10.1.255
inet6 2001:xxx:xxx:2301::4fb prefixlen 64 dynamic
nd6 options=201<PERFORMNUD,DAD>
media: autoselect (1000baseT <full-duplex>)
status: active

In reply to a post by tdw42:

The directly attached static route (ipv6 route 2001:xxx:xxx:2300::/56 Vlan100) is useless here, you need them to add a recursive static route.

Not being familiar with how Cisco routers handle overlapping addresses and subnets (as the 2001:xxx:xxx:2300::/64 subnet is part of the larger 2001:xxx:xxx:2300::/56) I'd suggest asking for just some of the /56 to be routed to the UDMP WAN address, e.g. ipv6 route 2001:xxx:xxx:2310::/60 2001:xxx:xxx:2300::2/64 which would route 16 of the subnets (2001:xxx:xxx:2310::/64 to 2001:xxx:xxx:231f::/64) to the UDMP.

Thanks, I think I'll send this in reply to Daisy, can anyone think of anything else pertinent to add?

In reply to a post by JESC77:

int Vlan100
ipv6 address 2001:xxx:xxx:2300::1/64
!
ipv6 route 2001:xxx:xxx:2300::/56 Vlan100

It looks like for some reason they've configured the /56 route as a directly attached route. In everything I've set up the ipv6 route line would read:

ipv6 route 2001:xxx:xxx:2300::/56 2001:xxx:xxx:2300::2

As in, it's saying everything in the /56 is accessible via your UDM.

Can you packet capture the WAN side of your UDM? If you ping an address within the /56 but not inside the /64 assigned to the WAN interface itself then you should see those pings. If you don't then the route isn't configured correctly.

Edit: I see this is what tdw42 suggested already.

Edited by jpm (Tue 27-Jul-21 21:55:53)

In reply to a post by tdw42:

The directly attached static route (ipv6 route 2001:xxx:xxx:2300::/56 Vlan100) is useless here, you need them to add a recursive static route.

Not being familiar with how Cisco routers handle overlapping addresses and subnets (as the 2001:xxx:xxx:2300::/64 subnet is part of the larger 2001:xxx:xxx:2300::/56) I'd suggest asking for just some of the /56 to be routed to the UDMP WAN address, e.g. ipv6 route 2001:xxx:xxx:2310::/60 2001:xxx:xxx:2300::2/64 which would route 16 of the subnets (2001:xxx:xxx:2310::/64 to 2001:xxx:xxx:231f::/64) to the UDMP.

In other words, I think what you are saying is that the Cisco box is basically not able to determine the next hop simply using the Vlan100 interface as the destination. By adding the recursive route with the /60 you are effectively adding a proper next hop.

Why though only specify a subset of the /56 ?

Edit: I see that jpm has posted as I was scribing. oops 😂😀

Edited by Pheasant (Tue 27-Jul-21 22:10:48)

In reply to a post by jpm:

In reply to a post by JESC77:

int Vlan100
ipv6 address 2001:xxx:xxx:2300::1/64
!
ipv6 route 2001:xxx:xxx:2300::/56 Vlan100

It looks like for some reason they've configured the /56 route as a directly attached route. In everything I've set up the ipv6 route line would read:

ipv6 route 2001:xxx:xxx:2300::/56 2001:xxx:xxx:2300::2

As in, it's saying everything in the /56 is accessible via your UDM.

Can you packet capture the WAN side of your UDM? If you ping an address within the /56 but not inside the /64 assigned to the WAN interface itself then you should see those pings. If you don't then the route isn't configured correctly.

Edit: I see this is what tdw42 suggested already.

I can ping 2001:b98:301:2300:: from the UDMP.

I received a phone call from the same lead engineer that sent me the last email today, he insists that their configuration is correct as is proved by my laptop working when plugged into their cisco. They provide many customers with working IPv6 using the same setup as mine. He said that recursive routing is very specialised and unnecessary in my situation.
Then received the email below:

As suggested we allocate /56 for yourself on our core and route this to site. We understand you will not need that many IPv6’s addresses/subnet’s, so we allocate a /64 (1 IPv6 network) to your LAN and also still route the /56 to the back of this LAN so you are able to utilise any IPv6 addresses you wish within the /56 (even outside of the /64 configured). That is the reason for the route you questioned.

When you connect a laptop to the same part of your LAN as the Ubiquity controller and configure the laptop with the IPv6 configuration I provided you are able to gain external Internet facing IPv6 connectivity, however when you connect your Ubiquity to the same part of your LAN and configure it (as you’ve advised) to the same details you can’t gain external Internet facing IPv6 connectivity via the diagnostic console of the device and can’t hit or get past the gateway, meaning the issue is 100% the configuration on the Ubiquity or another factor on the Ubiquity.

Unfortunately we can’t support that. I would suggest to continue with Ubiquity support, advise them the exact scenario stated above, the exact configuration you’ve added at which point they can’t say it’s not an issue with their kit.

My reply:
To clarify my situation:
I can only get IPv6 connectivity when my laptop is plugged directly it Gi0/0/0 on your Cisco.
When my laptop is connected to the UDM Pro, with the UDM Pro plugged into Gi0/0/0, it doesn’t matter if I set a static IP on my laptop or it is assigned one with DHCPv6, it doesn’t work. The UDM Pro does has IPv6 connectivity as I can ping6 when logged in with SSH.

When you say the UDM Pro as IPv6 connectivity because you can ping6 when looged in with SSH, what exactly do you mean? IIRC you pinged it from the Cisco?

What is sending the ping to what address?

Is there a setting on the UDM Pro to respond or not to incoming IPv6 pings? If there is, have you allowed them?

For a further diagnostic, another thing that occurred to me about you getting IPv6 connectivity from your laptop when you plug it into the Cisco, instead of you pinging anything please go onto the tbb Main Site and set up a BQM with the IP address it detects. It should be the IP address of your laptop. (Remember it takes a few minutes for anything useful to show up on the graph).

Have you tried my suggested change to the IPv6 Address in that setup page where I recommended ::1 not ::2?

So yes, the /64 setup is correct and you can successfully connect a laptop. From you previous posts you indicated that from the UDMP console you do have internet access (ping, traceroute work), so why are they saying it doesn't?

They don't seem to understand how IPv6 works, the issue has nothing to do with the UDMP - any device of yours routing the other IPv6 subnets would face the same issue.

In reply to a post by pluralist:

When you say the UDM Pro as IPv6 connectivity because you can ping6 when looged in with SSH, what exactly do you mean? IIRC you pinged it from the Cisco?

What is sending the ping to what address? The UDMP is to ipv6.google.com, for example

Is there a setting on the UDM Pro to respond or not to incoming IPv6 pings? If there is, have you allowed them?
Not that I'm aware of, what would that be called on another vendors device?

For a further diagnostic, another thing that occurred to me about you getting IPv6 connectivity from your laptop when you plug it into the Cisco, instead of you pinging anything please go onto the tbb Main Site and set up a BQM with the IP address it detects. It should be the IP address of your laptop. (Remember it takes a few minutes for anything useful to show up on the graph).Ok will do, however, when I connect that way I have to set a static IP on my laptop and anything from 2001:xxx:xxx:2300::2 - 2001:xxx:xxx:2300::ffff works

Have you tried my suggested change to the IPv6 Address in that setup page where I recommended ::1 not ::2?
Yes, it didn't work, the Router (cisco) address has to be 2001:xxx:xxx:2300::1 and and UDMP address can't be the same.

In reply to a post by tdw42:

So yes, the /64 setup is correct and you can successfully connect a laptop. From you previous posts you indicated that from the UDMP console you do have internet access (ping, traceroute work), so why are they saying it doesn't? I'm not sure but think I've clarified my situation in my email reply.

They don't seem to understand how IPv6 works, the issue has nothing to do with the UDMP - any device of yours routing the other IPv6 subnets would face the same issue. My problem is that they understand it more than I do, so when I get a phone call, I can't argue my case.

Have you told them that the UDMP is a router, and so requires the recursive static route.

The UniFi UDM/USG block ICMP/ICMPv6 from WAN by default which is discouraged as it breaks things such as path MTU discovery. Under Settings, Routing & Firewall on the Firewall, Rules IPv6 tab for the WAN LOCAL interface create a rule with Rule Applied = After predefined rules, Action = Accept, IPv6 Protocol = ICMPv6, IPv6 ICMP Type Name = Echo Request (Classic UI, it may be different in the new UI). This can be repeated for other ICMP types e.g. Destination Unreachable, Packet Too Big

In reply to a post by JESC77:

Traceroute from https://network-tools.webwiz.net/traceroute.htm to 2001:xxx:xxx:23aa::4fb automatically assigned to my laptop (tried configuring the LAN with 23aa for the hell of it).

1 1 ms 2a00:85c0:1::2
2 5 ms 2001:1900:5:2:2:0:8:7d75
3 5 ms 2001:1900:2::3:159
4 6 ms 2001:1900:5:2:2::2a5e
5 9 ms 2001:b98:1:1::ff3e:b0
6 12 ms 2001:b98:300:101::35:2
7 Timeout Unknown Host did not respond to ping

Cheers

When you were speaking to their engineer. Did you mention the above?

Seem to me they think if your laptop is directly connected to the Cisco all is hunky dory but it isn't is it. Therein lies your line of questioning to them that proves that their routing in is broken.

In reply to a post by tdw42:

Have you told them that the UDMP is a router, and so requires the recursive static route. I assumed he did but will double check.

The UniFi UDM/USG block ICMP/ICMPv6 from WAN by default which is discouraged as it breaks things such as path MTU discovery. Under Settings, Routing & Firewall on the Firewall, Rules IPv6 tab for the WAN LOCAL interface create a rule with Rule Applied = After predefined rules, Action = Accept, IPv6 Protocol = ICMPv6, IPv6 ICMP Type Name = Echo Request (Classic UI, it may be different in the new UI). This can be repeated for other ICMP types e.g. Destination Unreachable, Packet Too Big I've created those rules but still can't ping the UDMP.

In reply to a post by Pheasant:

In reply to a post by JESC77:

Traceroute from https://network-tools.webwiz.net/traceroute.htm to 2001:xxx:xxx:23aa::4fb automatically assigned to my laptop (tried configuring the LAN with 23aa for the hell of it).

1 1 ms 2a00:85c0:1::2
2 5 ms 2001:1900:5:2:2:0:8:7d75
3 5 ms 2001:1900:2::3:159
4 6 ms 2001:1900:5:2:2::2a5e
5 9 ms 2001:b98:1:1::ff3e:b0
6 12 ms 2001:b98:300:101::35:2
7 Timeout Unknown Host did not respond to ping

Cheers

When you were speaking to their engineer. Did you mention the above? I emailed him all the traceroutes I've done when on the call.

Seem to me they think if your laptop is directly connected to the Cisco all is hunky dory but it isn't is it. Therein lies your line of questioning to them that proves that their routing in is broken. They do know that I can't make it work through the UDMP.

Are you unequivocally saying that because my laptop works when connected to the cisco, it is not proof of correct configuration on Daisys network?

Edited by JESC77 (Thu 29-Jul-21 09:35:06)

I just created a new firewall rule, ICMPv6 on WAN Local and can now traceroute to my UDMP. Could that mean that their config is correct?


Hop Time IP Address Hostname Country
1 0 ms 2a00:85c0:1::2
2 5 ms 2001:1900:5:2:2:0:8:7d75
3 13 ms 2001:1900:2::3:159 l
4 5 ms 2001:1900:5:2:2::2a5e
5 8 ms 2001:b98:1:1::ff3e:b0
6 12 ms 2001:b98:xxx:101::35:2
7 12 ms 2001:b98:xxx:2300::2

This person had a similar problem to me and was able to resolve it by using the link local address of the router in front of his UDMP, could that be my solution?
https://community.ui.com/questions/UDM-Pro-with-Stat...

Well done. It's a step a right direction. At least now the WAN side of the UDM Pro is responding to external ping and traceroute.

Not sure that Ubiquity Community posting is going to help - Daisy have said they don't support DHCPv6 / Prefix Delegation from their network/gear so its down to ensuring that static routing for your subnets have been correctly setup on the Cisco WAN interface to your box - which from what I have read they claim they have been.

Have you tested now to see if you can get a route out from the LAN, laptop etc connected behind the UDM Pro can you ping6 out?

In reply to a post by JESC77:

I just created a new firewall rule, ICMPv6 on WAN Local and can now traceroute to my UDMP. Could that mean that their config is correct?


Hop Time IP Address Hostname Country
1 0 ms 2a00:85c0:1::2
2 5 ms 2001:1900:5:2:2:0:8:7d75
3 13 ms 2001:1900:2::3:159 l
4 5 ms 2001:1900:5:2:2::2a5e
5 8 ms 2001:b98:1:1::ff3e:b0
6 12 ms 2001:b98:xxx:101::35:2
7 12 ms 2001:b98:xxx:2300::2

This person had a similar problem to me and was able to resolve it by using the link local address of the router in front of his UDMP, could that be my solution?
https://community.ui.com/questions/UDM-Pro-with-Stat...

I don't think the UDM IPv6 accessibility has ever been an issue.

Can you please get a packet capture of the WAN side of the UDMP and then generate traffic (from outside your network, a ping would do) to any address in the /56 that isn't the /64 configured between the UDMP and the LAN side of the Cisco managed router? If you don't see those packets arriving at your UDMP then the route isn't configured properly on the Cisco router, and Daisy need to resolve that.

I had this exact same issue less than a week ago with a Meraki device and a leased line with a static IPv6 allocation, and the problem was the route had been removed by the ISP in error, but they fixed it by adding a route to point towards my firewall.

If you can't get a packet capture then do a traceroute to any other destination within the /56 - if you don't see the UDMP in the traceroute then it would suggest the route isn't in place.

Edited by jpm (Thu 29-Jul-21 12:22:30)

Have you tried the IPv6 connection via the second physical port on the Cisco, Gi0/1/1 to the UDM ?

In reply to a post by Pheasant:

Well done. It's a step a right direction. At least now the WAN side of the UDM Pro is responding to external ping and traceroute.

Not sure that Ubiquity Community posting is going to help - Daisy have said they don't support DHCPv6 / Prefix Delegation from their network/gear so its down to ensuring that static routing for your subnets have been correctly setup on the Cisco WAN interface to your box - which from what I have read they claim they have been.

Have you tested now to see if you can get a route out from the LAN, laptop etc connected behind the UDM Pro can you ping6 out? I can only up to the UDMP, I can ping across the LAN from laptop to laptop, it's just that no IPv6 can get from LAN to WAN.

In reply to a post by jpm:

In reply to a post by JESC77:

I just created a new firewall rule, ICMPv6 on WAN Local and can now traceroute to my UDMP. Could that mean that their config is correct?


Hop Time IP Address Hostname Country
1 0 ms 2a00:85c0:1::2
2 5 ms 2001:1900:5:2:2:0:8:7d75
3 13 ms 2001:1900:2::3:159 l
4 5 ms 2001:1900:5:2:2::2a5e
5 8 ms 2001:b98:1:1::ff3e:b0
6 12 ms 2001:b98:xxx:101::35:2
7 12 ms 2001:b98:xxx:2300::2

This person had a similar problem to me and was able to resolve it by using the link local address of the router in front of his UDMP, could that be my solution?
https://community.ui.com/questions/UDM-Pro-with-Stat...

I don't think the UDM IPv6 accessibility has ever been an issue.

Can you please get a packet capture of the WAN side of the UDMP and then generate traffic (from outside your network, a ping would do) to any address in the /56 that isn't the /64 configured between the UDMP and the LAN side of the Cisco managed router? If you don't see those packets arriving at your UDMP then the route isn't configured properly on the Cisco router, and Daisy need to resolve that.

I had this exact same issue less than a week ago with a Meraki device and a leased line with a static IPv6 allocation, and the problem was the route had been removed by the ISP in error, but they fixed it by adding a route to point towards my firewall.

If you can't get a packet capture then do a traceroute to any other destination within the /56 - if you don't see the UDMP in the traceroute then it would suggest the route isn't in place.

Here's a Wireshark capture of the UDMP ssh interface when preforming a traceroute from https://network-tools.webwiz.net/traceroute.htm to UDMP 2001:b98:xxx:2300::2
121423 206.025941 2a00:85c0:1::240:230 2001:b98:xxx:2300::2 ICMPv6 78 Echo (ping) request id=0x0687, seq=60101, hop limit=1 (reply in 121424)
121424 206.026017 2001:b98:xxx:2300::2 2a00:85c0:1::240:230 ICMPv6 78 Echo (ping) reply id=0x0687, seq=60101, hop limit=64 (request in 121423)
123528 211.236402 fe80::f692:bfff:fe78:b3d 2001:b98:xxx:2300::1 ICMPv6 86 Neighbor Solicitation for 2001:b98:xxx:2300::1 from f4:92:bf:78:0b:3d
123529 211.240404 2001:b98:xxx:2300::1 fe80::f692:bfff:fe78:b3d ICMPv6 78 Neighbor Advertisement 2001:b98:xxx:2300::1 (rtr, sol)
125544 216.304566 fe80::c6f7:d5ff:fe20:acf4 fe80::f692:bfff:fe78:b3d ICMPv6 86 Neighbor Solicitation for fe80::f692:bfff:fe78:b3d from c4:f7:d5:20:ac:f4
125545 216.304611 fe80::f692:bfff:fe78:b3d fe80::c6f7:d5ff:fe20:acf4 ICMPv6 78 Neighbor Advertisement fe80::f692:bfff:fe78:b3d (rtr, sol)
125835 217.079963 fe80::c6f7:d5ff:fe20:acf4 2001:b98:xxx:2300::2 ICMPv6 86 Neighbor Solicitation for 2001:b98:xxx:2300::2 from c4:f7:d5:20:ac:f4
125836 217.080013 2001:b98:xxx:2300::2 fe80::c6f7:d5ff:fe20:acf4 ICMPv6 78 Neighbor Advertisement 2001:b98:xxx:2300::2 (rtr, sol)
127607 221.476386 fe80::f692:bfff:fe78:b3d fe80::c6f7:d5ff:fe20:acf4 ICMPv6 86 Neighbor Solicitation for fe80::c6f7:d5ff:fe20:acf4 from f4:92:bf:78:0b:3d
127608 221.480322 fe80::c6f7:d5ff:fe20:acf4 fe80::f692:bfff:fe78:b3d ICMPv6 78 Neighbor Advertisement fe80::c6f7:d5ff:fe20:acf4 (rtr, sol)

I hope you can make some sense of it!
Thanks everyone for your continued support, I really do appreciate everthing.

I need you to ping an address in the /56 that isn't also in the /64 configured on your UDMP - we know that traffic is getting to your UDMP. My suspicion is that when you ping to an address beyond the UDMP you won't see those packets arriving, which diagnoses a routing issue with the Daisy-managed Cisco router.

Post deleted by JESC77

In reply to a post by JESC77:

In reply to a post by jpm:

I need you to ping an address in the /56 that isn't also in the /64 configured on your UDMP - we know that traffic is getting to your UDMP. My suspicion is that when you ping to an address beyond the UDMP you won't see those packets arriving, which diagnoses a routing issue with the Daisy-managed Cisco router.

Sorry, can give me an example?

I mean an example address, please.

It's tricky because you've obfuscated your range.

If we say your allocation is 2001:b98:1234:2300::/56 and 2001:b98:1234:2300::2/64 is your UDMP, then 2001:b98:1234:2301::1 is the next /64 along.

If you have an external party ping that address and don't see packets on the WAN of your UDMP then you need Daisy to fix their routing before going further.

So I pinged 2001:b98:xxx:2301::1 from a network tools website and captured the following:

4094 14.428504 fe80::c6f7:d5ff:fe20:acf4 ff02::1:ff00:1 ICMPv6 86 Neighbor Solicitation for 2001:b98:xxx:2301::1 from c4:f7:d5:20:ac:f4
4487 15.519004 fe80::c6f7:d5ff:fe20:acf4 ff02::1:ff00:1 ICMPv6 86 Neighbor Solicitation for 2001:b98:xxx:2301::1 from c4:f7:d5:20:ac:f4
5016 16.608279 fe80::c6f7:d5ff:fe20:acf4 ff02::1:ff00:1 ICMPv6 86 Neighbor Solicitation for 2001:b98:xxx:2301::1 from c4:f7:d5:20:ac:f4
5573 18.485024 fe80::c6f7:d5ff:fe20:acf4 ff02::1:ff00:1 ICMPv6 86 Neighbor Solicitation for 2001:b98:xxx:2301::1 from c4:f7:d5:20:ac:f4
5828 19.576344 fe80::c6f7:d5ff:fe20:acf4 ff02::1:ff00:1 ICMPv6 86 Neighbor Solicitation for 2001:b98:xxx:2301::1 from c4:f7:d5:20:ac:f4
6052 20.601533 fe80::c6f7:d5ff:fe20:acf4 ff02::1:ff00:1 ICMPv6 86 Neighbor Solicitation for 2001:b98:xxx:2301::1 from c4:f7:d5:20:ac:f4

That’s the Cisco router on MAC c4:f7:d5:20:ac:f4 asking which host has that 2301::1 address, and broadcasting it out the connected interface. This is sort of the IPv6 equivalent to ARP.

What should be happening is that it knows that address is behind your UDMP on 2300::2, and you should be receiving ICMP packets on the UDMP WAN interface.

Daisy have configured their managed router incorrectly and will need to add the route. There might be some awful IPv6 equivalent of proxy ARP or you could NAT it all but honestly those are terrible options and the actual fix is one line of config.

I've sent this info the Daisy and have just had a reply:

"Going off the below you’re UDM Pro device doesn’t seem to be allowing IPv6 traffic to traverse from it’s LAN downlink to WAN uplink. This is where you’re issue, or at least part of you issue seems to be stemming from.

As stated this is unfortunately not a managed device and you will need to progress this with Ubiquity directly."

In reply to a post by jpm:

I need you to ping an address in the /56 that isn't also in the /64 configured on your UDMP - we know that traffic is getting to your UDMP. My suspicion is that when you ping to an address beyond the UDMP you won't see those packets arriving, which diagnoses a routing issue with the Daisy-managed Cisco router.

jpm why do you think the OP is unable to ping6 out to the internet from a machine connected behind the UDM? Yet if he tries directly with the laptop into the back of the Cisco it works? Unless I’ve got it completely wrong (not the first or last time) - smack of a routing issue on the UDM no?

Also from what’s written I don’t think there is any /56 routed by Daisy it’s simply a /64. That goes back to what we are told in post #3

In reply to a post by jpm:

There might be some awful IPv6 equivalent of proxy ARP

That would be a "Neighbour Discovery Proxy" (ND Proxy) but as you've pointed out you shouldn't need that if everything is routed correctly.

I'm doing one step at a time - we need to verify the Cisco router configuration is correct before trying to get the UDMP working. From what Daisy have provided as the config lines and how the service is working it appears that it's configured wrong.

I can't see how this is going to work without routing the /56 to the UDMP but Daisy don't seem too interested as long as a device directly connected to their router has IPv6 connectivity.

Yes I understand your logic. My suspicion is that there are indeed multiple issues at play here:

1. There is a either a misunderstanding, miscommunication or misconfiguration (or a little of all of them!) of the /56 (or as it seems only a /64) subnet routing of the service from Daisy

2. There is a routing issue present on the UDM Pro which is not allowing outbound routing of IPv6 from LAN to WAN

3. Daisy are insisting that all issue are related solely related to item (2) and are under the control of the OP. They are refusing to budge and the OP has neither the experience or knowledge (no offence OP) to adequately back up his position.

Whilst I understand that /56 routing needs to be investigated and/or altered by Daisy I don’t get the feeling that they will budge until they have ‘evidence’ that the UDM Pro configuration is in the clear so to speak. Hence why I’m asking why for equivalence purposes the OP can route out - so that at least they can say to Daisy “hey look I can connect out via laptop and can also connect out via my router, but there is a problem with my /56 allocation routing.

In reply to a post by JESC77:

I've sent this info the Daisy and have just had a reply:

"Going off the below you’re UDM Pro device doesn’t seem to be allowing IPv6 traffic to traverse from it’s LAN downlink to WAN uplink. This is where you’re issue, or at least part of you issue seems to be stemming from.

They are confusing traffic direction. with the UDMP configured as before (WAN IP ...:2300::2/64 gw ...:2300::1/64, LAN IP ...:2301::1/64) get a traffic dump whist trying to ping 2a00:1450:4009:81e::2003 (google.co.uk) - it should show packets leaving the UDMP WAN port for the Cisco.

I've found this in a Cisco manual:

ipv6 route ipv6-prefix/prefix length {ipv6-address | interface-id [ipv6-address]} [administrative distance]

ipv6-address—The IPv6 address of the next hop that can be used to reach the specified network. The IPv6 address of the next hop need not be directly connected; recursion is done to find the IPv6 address of the directly connected next hop. The address must be in the form documented in RFC 2373, specified in hexadecimal using 16-bit values between colons.

interface-id—Specifies direct static routes from point-to-point and broadcast interfaces. With point-to-point interfaces, there is no need to specify the IPv6 address of the next hop. With broadcast interfaces, you should always specify the IPv6 address of the next hop, or ensure that the specified prefix is assigned to the link, specifying a link-local address as the next hop. You can optionally specify the IPv6 address of the next hop to which packets are sent.

I've emboldened the key part - with a broadcast interface such as a physical ethernet port or VLAN the prefix including the prefix length must be assigned to the interface OR you have to specify the next hop address.

So, with Cisco terminology italicised, instead of the directly attached static route which will never work, and if they don't like recursive static routes for whatever reasons they should use a fully specified static route e.g. ipv6 route 2001:xxx:xxx:2310::/60 Vlan100 2001:xxx:xxx:2300::2 to route 16 of the subnets to the UDMP (to route all would likely be ipv6 route 2001:xxx:xxx:2300::/56 Vlan100 2001:xxx:xxx:2300::2 but I don't know how Cisco cope with overlapping network ranges).

Wireshark capture of UDMP WAN interface, ping from my laptop 2001:b98:xxx:2301::4fb to 2a00:1450:4009:81e::2003.

66 0.151460 2001:b98:xxx:2301::4fb 2a00:1450:4009:81e::2003 ICMPv6 70 Echo (ping) request id=0xed8b, seq=100, hop limit=63 (no response found!)
67 0.162784 fe80::c6f7:d5ff:fe20:acf4 ff02::1:ff00:4fb ICMPv6 86 Neighbor Solicitation for 2001:b98:xxx:2301::4fb from c4:f7:d5:20:ac:f4
435 1.153909 2001:b98:xxx:2301::4fb 2a00:1450:4009:81e::2003 ICMPv6 70 Echo (ping) request id=0xed8b, seq=101, hop limit=63 (no response found!)
445 1.186887 fe80::c6f7:d5ff:fe20:acf4 ff02::1:ff00:4fb ICMPv6 86 Neighbor Solicitation for 2001:b98:xxx:2301::4fb from c4:f7:d5:20:ac:f4
792 2.159113 2001:b98:xxx:2301::4fb 2a00:1450:4009:81e::2003 ICMPv6 70 Echo (ping) request id=0xed8b, seq=102, hop limit=63 (no response found!)
804 2.211257 fe80::c6f7:d5ff:fe20:acf4 ff02::1:ff00:4fb ICMPv6 86 Neighbor Solicitation for 2001:b98:xxx:2301::4fb from c4:f7:d5:20:ac:f4
1137 3.162289 2001:b98:xxx:2301::4fb 2a00:1450:4009:81e::2003 ICMPv6 70 Echo (ping) request id=0xed8b, seq=103, hop limit=63 (no response found!)
1163 3.240378 fe80::f692:bfff:fe78:b3d 2001:b98:xxx:2300::1 ICMPv6 86 Neighbor Solicitation for 2001:b98:xxx:2300::1 from f4:92:bf:78:0b:3d
1164 3.242451 2001:b98:xxx:2300::1 fe80::f692:bfff:fe78:b3d ICMPv6 78 Neighbor Advertisement 2001:b98:xxx:2300::1 (rtr, sol)

So it looks like my ping is hitting the cisco but is going no further?

To me it looks like it's going out but the reply can't get back to you as the Cisco router is looking for that IPv6 address on an interface where it doesn't exist.

In reply to a post by jpm:

To me it looks like it's going out but the reply can't get back to you as the Cisco router is looking for that IPv6 address on an interface where it doesn't exist.

But I can ping the UDM from outside.

In reply to a post by JESC77:

I've had had extensive support from Ubiquiti and Daisy, Ubiquiti say that my ISP must support prefix delegation and Daisy are unable to provide it.

https://help.ui.com/hc/en-us/articles/115005868927-U...
I find it hard to believe that the UDMP has this limitation when the help article above says:

"Depending on the configuration of the ISP, the UDM/USG can either use DHCPv6-PD (Prefix Delegation) or Static IPv6 addresses to provide IPv6 connectivity to the clients on the LAN. In both setups, the information regarding the connection type and its values is provided by the ISP."

Has anyone managed to get this to work?

I do have an Edgerouter 12P and a Mikotik Hex S I can use but are no expert at setting those up.

Thanks for any help!

Just circling back to your opening post here, and highlighting what you were told above by Ubiquiti. This is rather concerning that they insist you must use PD. There are other reports online (though admittedly now about 6 months old, perhaps fixed in most recent firmware...??) that complain about the 'flakiness' of parts of the IPv6 implementation in the UDM Pro's. Like this blog post.

From some other articles I've now read, most folks that have gotten IPv6 working with a UDMP have done so using Prefix Delegation, not using static routing as you must do with Daisy.

Therefore there may be some merit in attempting to get IPv6 working using the second port on the Cisco to another of the routers that you have available above. I believe Daisy have said they mapped your IPv6 allocation to use both of the Cisco user ports?

In this way you should be able to keep the rest of your existing network running on the first Cisco port via your UDM and create a test IPv6 network using the second Cisco port and test using either the EdgeRouter or the MikroTik.

Edit:
Links to further articles complaining about broken IPv6 routing on the UDM Pro. Where there's smoke and all that...

https://www.reddit.com/r/UNIFI/comments/hbf49z/love_...

https://www.sysadmins.lv/blog-en/ubiquiti-udm-pro-an...

Edited by Pheasant (Sat 31-Jul-21 14:09:08)

In reply to a post by Pheasant:

In reply to a post by JESC77:

I've had had extensive support from Ubiquiti and Daisy, Ubiquiti say that my ISP must support prefix delegation and Daisy are unable to provide it.

https://help.ui.com/hc/en-us/articles/115005868927-U...
I find it hard to believe that the UDMP has this limitation when the help article above says:

"Depending on the configuration of the ISP, the UDM/USG can either use DHCPv6-PD (Prefix Delegation) or Static IPv6 addresses to provide IPv6 connectivity to the clients on the LAN. In both setups, the information regarding the connection type and its values is provided by the ISP."

Has anyone managed to get this to work?

I do have an Edgerouter 12P and a Mikotik Hex S I can use but are no expert at setting those up.

Thanks for any help!

Just circling back to your opening post here, and highlighting what you were told above by Ubiquiti. This is rather concerning that they insist you must use PD. There are other reports online (though admittedly now about 6 months old, perhaps fixed in most recent firmware...??) that complain about the 'flakiness' of parts of the IPv6 implementation in the UDM Pro's. Like this blog post. I find it hard to believe thet the UDMP doesn't support static IPv6, I've read about it working with PPPoE but I assume that is different to my leased line.

From some other articles I've now read, most folks that have gotten IPv6 working with a UDMP have done so using Prefix Delegation, not using static routing as you must do with Daisy.

Therefore there may be some merit in attempting to get IPv6 working using the second port on the Cisco to another of the routers that you have available above. I believe Daisy have said they mapped your IPv6 allocation to use both of the Cisco user ports? I have attempted with both ports with the same results.

In this way you should be able to keep the rest of your existing network running on the first Cisco port via your UDM and create a test IPv6 network using the second Cisco port and test using either the EdgeRouter or the MikroTik. I'm willing to use a different router, I'll buy another if it means it works properly, but the UDMP needs to be in the mix as it's the controller for nearly 80 switches and APs that I've adopted to it.

Edit:
Links to further articles complaining about broken IPv6 routing on the UDM Pro. Where there's smoke and all that...

https://www.reddit.com/r/UNIFI/comments/hbf49z/love_...

https://www.sysadmins.lv/blog-en/ubiquiti-udm-pro-an...

So I've bought a cheapish TP-Link router that supports static IPv6 and I still have the same problem. With my laptop connected to the new router, it gets an IPv6 address and I can ping the router from the LAN (and from the web) but I can't ping past the TP-link router, in either direction.

Surely this proves that Daisy has messed up?

Although I think I probably won't need this, can anyone advise which of the below would best suit my requirements on the TP-link router? Considering I intend to plug my UDMP into it if I do get it working. I've tried all without success with just my laptop connected.

ND Proxy
DHCPv6
SLAAC+Stateless DHCP
SLAAC+RDNSS

Just to be sure my config is correct, is the following LAN ok?

Daisy's Cisco router 2001:b98:xxx:2300::1
My router 2001:b98:xxx:2300::2
LAN 2001:b98:xxx:2301::/64

The Daisy engineer phoned me again still insisting their config is correct. He thinks my LAN is wrong and should be 2001:b98:xxx:2300::/64 on the same network as the WAN, I tried this initially and again today turning DHCP off and set a static address on my laptop as advised it still didn't work. I couldn't even ping the UDMP. Strangely, I could with these settings on the TP-link (ping the TP-link). I couldn't ping the cisco with any setup.

If the WAN is 2001:b98:xxx:2300::1 and the LAN 2001:b98:xxx:2301::/64, does a static route need to be added? There only seems to be the option of adding IPv4 static routes on the UDMP.

He is now willing to add some config to theirs if anyone knows it should be?

Thanks.

Delete

ipv6 route 2001:xxx:xxx:2300::/56 Vlan100

Add

ipv6 route 2001:xxx:xxx:2300::/56 2001:xxx:xxx:2300::2

Thanks jpm,

That's been actioned by Daisy. I'm unable to test until tomorrow.

FWIW this is all pretty much the same as IPv4 routing, but there's huge chunks of people's knowledge missing in that area because NAT has ruined everything.

If your IPv4 allocation from your ISP was 167.98.0.0/16 then it would be immediately obvious that the WAN side of your UDM couldn't be 167.98.0.2/24 and then LAN 167.98.0.1/24 - you'd have to go for 167.98.1.1/24 - but IPv6 is just making this seem a lot more complicated than it really is.

Edited by jpm (Mon 02-Aug-21 23:39:53)

It worked!!!

jpm, you are a legend!

I'm so thankful to everyone who's contributed to this thread.

Thanks again,
Jay.

Good to hear. Since you now don't have the 'security' of NAT it's vital that you have IPv6 firewall rules. I'd allow unsolicited inbound ICMP but make sure everything else is blocked unless you have a good reason for it.

Result .

So the Daisy people were wrong. Which is a bit scary.

In reply to a post by JESC77:

It worked!!!

jpm, you are a legend!

I'm so thankful to everyone who's contributed to this thread.

Thanks again,
Jay.

Hey do a little dance, your perseverance paid off and you’ve no doubt learnt a thing or two about IPv6 networking and perhaps even with jpm’s help taught the Daisy chap a thing or two!!

So have you got I all working with the UDMP as well as your ‘test bed’ TP link router? Presume the full /56 is working now and they updated all the details above which were clearly in error.

[I’d love to know what he said when you got it working - he was insistent their config was correct!!] As pluralist said, kind of worrying that they stuffed up something so very basic.

Here's a screenshot of my firewall rules.

https://drive.google.com/file/d/1MKatvPE98d8IXFqo4CB...

Here's what was said between Daisy and I:

Hi Dario,

That's fixed it!

Thanks
Jay.

Hi Jay,

Glad it’s all now working. Like I stated on the call yesterday the change I made limits you using any network outside the /64 configured unless the next hop is the address 2001:B98:301:2300::2.

This means if you were ever to change the next hop device IP on site or add another network etc and have a different next hop for this we would have to amend/add a new route, however the same routing could have been added on your device (I know you did try though).

If you need anything else then let us know.

Thanks

It didn't work with with 2001:b98:301:2300::/64 as my LAN, I can however use 2001:b98:301:2301:: to 2001:b98:301:23ff:: so believe I have the potential for plenty of networks. I wish we'd found this solution 7 weeks ago!

Cheers
Jay.

Hi Jay,

As long as the WAN uplink of the device connecting directly to the Daisy CPE remains as the one stated then all will be fine. If you add new networks you will just need to add a new LAN on this device.

Looks like there is some default routing between directly connected interfaces on your UDMD (that’s what I would 100% expect anyway).

Glad it’s all working!

Thanks

In reply to a post by Pheasant:

In reply to a post by JESC77:

It worked!!!

jpm, you are a legend!

I'm so thankful to everyone who's contributed to this thread.

Thanks again,
Jay.

Hey do a little dance, your perseverance paid off and you’ve no doubt learnt a thing or two about IPv6 networking and perhaps even with jpm’s help taught the Daisy chap a thing or two!!

So have you got I all working with the UDMP as well as your ‘test bed’ TP link router? Presume the full /56 is working now and they updated all the details above which were clearly in error.

[I’d love to know what he said when you got it working - he was insistent their config was correct!!] As pluralist said, kind of worrying that they stuffed up something so very basic.

Once I found the UDMP was working I put the TP-link back in the box, hoping to return it.

The reason for needing IPv6 is my Terragraph equipment which is for the mesh network for a large music festival happening at the end of this month. I'm providing wifi for the ticket scanners and everyone else except the public, the IP CCTV and connectivity for the bars EPOS. The whole festivals success kind of relies on each element working so I'm working relentlessly to get everything together.

The Edge-Core Terragraph kit hasn't been out long so their still ironing out some bugs which is worrying, they didn't mention that when I bought it. I'm receiving support from Edge-core for the Terragraph setup which I've had to put on hold until IPv6 was sorted. It works fine in bridge mode but that's basic PTMP so doesn't give any link redundancy. If any of you know about Terragraph, I'm all ears!

In reply to a post by JESC77:

Once I found the UDMP was working I put the TP-link back in the box, hoping to return it.

The reason for needing IPv6 is my Terragraph equipment which is for the mesh network for a large music festival happening at the end of this month. I'm providing wifi for the ticket scanners and everyone else except the public, the IP CCTV and connectivity for the bars EPOS. The whole festivals success kind of relies on each element working so I'm working relentlessly to get everything together.

The Edge-Core Terragraph kit hasn't been out long so their still ironing out some bugs which is worrying, they didn't mention that when I bought it. I'm receiving support from Edge-core for the Terragraph setup which I've had to put on hold until IPv6 was sorted. It works fine in bridge mode but that's basic PTMP so doesn't give any link redundancy. If any of you know about Terragraph, I'm all ears!

Cool. Can we ask what music festival?

What made you choose the Edgecore Terragraph kit, if indeed you had a hand in its choice?

In reply to a post by JESC77:

Here's what was said between Daisy and I:

Hi Dario,

That's fixed it!

Thanks
Jay.

Hi Jay,

Glad it’s all now working. Like I stated on the call yesterday the change I made limits you using any network outside the /64 configured unless the next hop is the address 2001:B98:301:2300::2.

This means if you were ever to change the next hop device IP on site or add another network etc and have a different next hop for this we would have to amend/add a new route, however the same routing could have been added on your device (I know you did try though).

If you need anything else then let us know.

Thanks

It didn't work with with 2001:b98:301:2300::/64 as my LAN, I can however use 2001:b98:301:2301:: to 2001:b98:301:23ff:: so believe I have the potential for plenty of networks. I wish we'd found this solution 7 weeks ago!

Cheers
Jay.

Hi Jay,

As long as the WAN uplink of the device connecting directly to the Daisy CPE remains as the one stated then all will be fine. If you add new networks you will just need to add a new LAN on this device.

Looks like there is some default routing between directly connected interfaces on your UDMD (that’s what I would 100% expect anyway).

Glad it’s all working!

Thanks

Is it just me or does that Dario guy sound like someone who doesn't really know what they're talking about, hurriedly backpedaling when presented with evidence that directly contradicts their opening statement,

If that's Daisy business grade tech support - I'm steering wheel clear off them!!

Sorry, I didn't receive a notification about your post. Been super busy since the festival.

It's Victorious Festival.

I own some Ignitenet kit and found the cloud interface pretty good, they were taken over by Edge-Core and I was told that the new Terragraph kit would use the same EC cloud, it doesn't yet and is still quite buggy so I'm regretting the purchase. I'm now told that Terragraph will use EC Cloud by the end of the year, I won't hold my breath.

I'm into Peplink now and have deployed a Balance 310 5G router on a small job, going well so far but the speedfusion speeds aren't as fast as expected. I'm bonding Starlink, Vodafone 5G and LTE-A connections, but that's for anouther post.

Jay.

Edited by JESC77 (Wed 17-Nov-21 19:17:09)