Using My Own Router, Correct Way to Setup?

[noname123456]

Hi,

I have FTTP using a BT ONT and I have being using my own router Flint 2 (GL-MT6000) for the last 6+ months and in that time I have have two instances where the network just drops (no errors in the logs that I can see) and it will remain like this until I power-cycle my router.

I have set this up using DHCP 61 as per this post but I have also read that you shouldn't need to use this method here.

Can someone please tell me what is the current correct way to setup your own router when using FTTP using a BT ONT and have others experienced similar issue with their network dropping using their own router or same as mine?

Thanks

[noname123456]

Turns out this problem is quite common when people want to use their own routers with Sky FTTP as they use either CG-NAT or MAP-T systems.

If there's no work-around, then we will be leaving to either BT or Plusnet who don't use any of these daft systems.

[Chrisee]

@noname123456 no idea where you got that information but it is not correct. Sky can only use MAP-T on routers that advertise support for DHCPv6  Option 95 which their white Sky Max and Sky Gigafast+ hubs do but third party routers normally dont. 

It is therefore highly unlikely that is the cause of the issue but its worth checking the set up on the router. It sounds like occasionally the router is missing the hourly IP lease renewal. 

[GD1]

@noname123456  Using a Dryatek 3910 with DHCP Option 60/621 on FTTP the uptime is 24 days (did a firmware update) witoiut any drops, so I suspect as @Chrisee  states is a hourly IP release issue.

[noname123456]

Thanks for your reply.

I have followed this advice to set up my router on DHCP Option 61 (Client ID)

Like I said, it only drops when Sky change my public facing IP which is roughly every 56 days.

I have looked all over the web and have gathered lots of info for this issue and others have the same issue, as found here:

It does seem to be linked to how Sky uses the CG-NAT & MAP-T systems where other ISP don't and they don't have this problem.

This is exactly what I see on my routers 'Internet page' when I lose the connection after the 56 day period:

---

Sky's use of MAP-T (Mapping of Address and Port using Translation) on their FTTP network. When Sky rotates your public-facing IPv4 address, it shifts you into a shared 100.x.x.x (CGNAT-style) range. The GL.iNet Flint 2 (GL-MT6000) fails to handle the routing table refresh under MAP-T automatically, causing the internet handshake to break completely until the interface or router is manually restarted.

---

If you could suggest another way to get this working I'm happy to try it.

[Chrisee]

@noname123456 I repeat it can't be MAP-T unless your router is advertising support for DHCPv6 Option 95. 

[TimmyBGood]

---

@noname123456 wrote:

If you could suggest another way to get this working I'm happy to try it.

---

If the issue is an unfortunate interaction between GL.iNet hardware (and/or OpenWRT) and Sky network implementation then it's up to them to solve it, although given GL.iNet is an extremely minor vendor on the domestic broadband market this may just be unrealistic.

[Me134]

---

@noname123456 wrote:

Thanks for your reply.

I have followed this advice to set up my router on DHCP Option 61 (Client ID)

Like I said, it only drops when Sky change my public facing IP which is roughly every 56 days.

I have looked all over the web and have gathered lots of info for this issue and others have the same issue, as found here:

It does seem to be linked to how Sky uses the CG-NAT & MAP-T systems where other ISP don't and they don't have this problem.

This is exactly what I see on my routers 'Internet page' when I lose the connection after the 56 day period:

---

Sky's use of MAP-T (Mapping of Address and Port using Translation) on their FTTP network. When Sky rotates your public-facing IPv4 address, it shifts you into a shared 100.x.x.x (CGNAT-style) range. The GL.iNet Flint 2 (GL-MT6000) fails to handle the routing table refresh under MAP-T automatically, causing the internet handshake to break completely until the interface or router is manually restarted.

---

If you could suggest another way to get this working I'm happy to try it.

---

I thought using a 3rd party router takes you entirely out of Skys Map-T infrastructure so if I'm correct, then it's definitely nothing to do with that. Sky do rotate your public IP address around the 56 day marks by the looks (not checked it TBH)

A quick look suggests it's entirely down to the router software. There is an automated solution I've seen that should help (I don't have one so you'll have to take AI at it's word).

Option 2: Set up a WAN Watchdog Script (Automated Fix)

Since OpenWRT doesn't realize it has lost internet access, you can use the built-in Network Watchdog (ping tool) to auto-restart the WAN interface whenever a drop occurs.

1. Go to the advanced LuCI interface (Advanced settings in your GL.iNet menu).
2. Navigate to Network > Interfaces.
3. Click Edit on your WAN interface.
4. Look for the Advanced Settings or Link Review/Watchdog tab.
5. Enable the watchdog to ping a public DNS server (like 8.8.8.8 or 1.1.1.1) every few minutes/hours. Configure it so that if 5 consecutive pings fail, it automatically restarts the WAN interface (not the whole router). This will force it to pull the new Sky IP immediately.

[Chrisee]

@Me134 you are correct third party routers are not offered a MAP-T connection unless they advertise support for DHCPv6 Option95 which a few years ago Ubquiti routers did by default but unfortunately actually could not support MAP-T. Apparently this went on for 8 years before Ubquiti corrected their mistake causing issues with Sky Italia customers who have been using MAP-T for around 8 years I believe..

Therefore it is a safe assumption that connection issues on any routers apart from the Sky's own hub6 and hub7 are nothing to do with MAP-T unless that is somebody has specifically enabled DHCPv6 Option95 themselves.

[Me134]

@Chrisee As a slight aside, I've just checked and I'm still on 1:1 since enabling UPnP (since re-enabled). It's been quite a while so far.

[noname123456]

I've recently enabled DHCPv6 PD using 'Native Mode' following advice found on GL-iNET forums for Sky FTTP users who also have similar issues that aftert 56 off days when my public ip is refreshed, my router fails to negotiate the address. The thought process was that by enabling DHCPv6 PD it may get around the IPV4 failure

[noname123456]

This thread also details other issues with IPV6: https://helpforum.sky.com/t5/Broadband/Not-Getting-IPv6-Address/m-p/5348275

Why I have to use this router in this way for Sky is crazy, I don't know any other ISP that requires DHCP 61 option, they just plug in & it works.

[noname123456]

Not sure why I can't edit my posts, but here is another user with their own router having similar issues: https://helpforum.sky.com/t5/Broadband/Connecting-to-Sky-Fibre-Broadband-using-my-own-router/m-p/487...

[noname123456]

I Googled my issue and it has said:

Sticking strictly to IPv4 on a GL.iNet Flint 2 (GL-MT6000) when using Sky FTTP comes with significant disadvantages. Sky UK heavily relies on an address-sharing mechanism called MAP-T (Mapping of Address and Port using Translation) on newer connections to combat the shortage of IPv4 addresses. [1, 2]

Because MAP-T is inherently built on an IPv6-first architecture, forcing your network to handle everything natively over IPv4 breaks or severely compromises your connection. The core drawbacks include: [1, 2]

1. Frequent Connection Drops and "Broken" Internet

If you attempt to bypass MAP-T configuration on your Flint 2 and force a standard IPv4 connection (e.g., using only traditional DHCPv4 Option 61), the router will often randomly lose its public route. [1]

• The Root Cause: The router will continuously loop, dropping its standard IP and pulling a non-routable carrier-grade address in the 100.x.x.x range. [1]
• The Result: When this loop happens, all IPv4 access completely drops. Devices in your home that do not support IPv6 will lose internet connectivity entirely until you reboot the router to force a brief IP lease renewal. [1]

This is exactly what is happening to me every 56 days! But you guys say this is incorrect? If so, why is it my router fails to negotiate the IP and remains on 100.x.x.x?

[noname123456]

I have just called Sky Tech support and asked them to tell me whether I have an IPV6 address for my connection and they said they don;t provide IPv6 addresses to my line, so I'll just disable this on my router as apparently this can also cause issue if left on but not getting an address.