Geekzone: technology news, blogs, forums
Guest
Welcome Guest.
You haven't logged in yet. If you don't have an account you can register now.


View this topic in a long page with up to 500 replies per page Create new topic
1 | 2 | 3 | 4

IcI

824 posts

Ultimate Geek
+1 received by user: 174

Trusted

  Reply # 1972788 11-Mar-2018 19:31
Send private message quote this post

matisyahu: michaelmurfy Where do you put the config.gateway.json file? ...

Did you see and follow this document? https://help.ubnt.com/hc/en-us/articles/215458888-UniFi-How-to-further-customize-USG-configuration-with-config-gateway-json


Mr Snotty
8089 posts

Uber Geek
+1 received by user: 4057

Moderator
Trusted
Lifetime subscriber

  Reply # 1972805 11-Mar-2018 19:39
Send private message quote this post

@IcI Strange. Of the USG's I've configured I have not noticed any high CPU or performance loss.





 
 
 
 




1419 posts

Uber Geek
+1 received by user: 269

Subscriber

  Reply # 1972874 11-Mar-2018 22:23
Send private message quote this post

IcI:

 

matisyahu: michaelmurfy Where do you put the config.gateway.json file? ...

Did you see and follow this document? https://help.ubnt.com/hc/en-us/articles/215458888-UniFi-How-to-further-customize-USG-configuration-with-config-gateway-json

 

Yes, I followed the instructions and it still didn't work so I assumed I must have done something wrong by not putting in the correct directory. I've sent an email off to the 2 Degrees help to see whether there is something stopping me from acquiring an ipv6 address. It is rather strange because I never had an issue when I was with BigPipe with the ipv6 working without any issues. With that all being said, it appears that the ipv6 support in USG is immature at this stage so I'l probably better off waiting till it comes out in a stable form to avoid dramas.





Laptop: MacBook Pro (15-inch, 2017)
Desktop: iMac (27-inch, 2017)
Smartphone: iPhone Xs Max 256GB 'Space Grey'
Additional devices: Unifi Security Gateway, Unifi Switch, Unifi AP AC HD, Unifi Cloud Key, Apple TV 4K 64GB
Services: iCloud, YouTube Premium, Wordpress, Skinny

 


388 posts

Ultimate Geek
+1 received by user: 79


  Reply # 1972906 11-Mar-2018 23:44
Send private message quote this post

In the above USG IPv6 setups I have not seen any settings that fix the MTU problem with PPPoE.  So, while IPv6 may appear to be working, it may well be broken.

 

The overhead of the PPPoE protocol is 8 bytes on each packet, so if you connect using PPPoE, your maximum MTU is 1492, not 1500.  Internally, your network is almost certainly using MTU 1500 packets, which is the standard setting for Ethernet and WiFi.  When a packet in the range 1493-1500 bytes hits the PPPoE interface, it will not be able to pass through it.  With IPv4, that is fine, the packet being bigger than the available PPPoE interface MTU will just cause it to be fragmented into two smaller packets.  This slightly reduces the throughput of your Internet connection, but most people will not notice anything at all.  But with IPv6, packets can not be fragmented - IPv6 does not support that.  What should happen is that the overlong IPv6 packet gets dropped, and an ICMPv6 "Packet too big" message should be sent back to the address the overlong packet was sent from.  It is a requirement of IPv6 that any overlong packets that get dropped send back that message.  But all the PPPoE implementations (server and client) that I have met are broken and do not send that ICMPv6 packet.  This bug has been around for quite a while and there has been no sign that anyone is ever going to fix it.  The result is that you think you have IPv6 working, but it is actually broken and will not work whenever full length packets get sent, in either direction.  The usual complaint that comes back as a result of this is "Facebook has stopped working".  That is because facebook.com is IPv6 enabled and the front page of facebook.com sends full length packets.  So as soon as IPv6 is enabled on a network, it gets used in preference to IPv4, and connections to facebook.com to log in fail due to the long packets being dropped.

 

So if you are connected to your ISP using PPPoE, you need to do one of two things to fix this:

 

1) If your Internet connection is appropriately overprovisioned as fibre connections via Chorus are, then there is bandwidth available so that you can connect the Ethernet and VLAN 10 connections to the ONT using an MTU setting of 1508 bytes, and the PPPoE connection with an MTU of 1500 bytes.  This requires also that the ISP router you are connecting to has up-to-date PPPoE server software that supports PPPoE connections with MTU 1500.  As far as I know, all the 2degrees border routers will do this now.  It also requires that your router has an up-to-date PPPoE client that supports MTU 1500 connections.  Quite a lot of routers do support this, including Edgerouters, and almost certainly all other Ubiquiti routers.  However, you have to manually set up the MTU settings to make it happen.  To see if the connection is overprovisioned and has the later version of PPPoE software, the only way I know to find out for sure is try it out using the MTU 1508/MTU 1500 settings.  If the PPPoE fails to connect after that, or no traffic (even IPv4) passes through it, then the connection in not capable of doing MTU 1508 and you will need to use the other solution below.  Do not forget to add an MTU 1500 setting to the PPPoE settings - PPPoE connections default to MTU 1492, and will not be set to MTU 1500 simply because you have set the Ethernet port and VLAN 10 to use MTU 1508.

 

The FritzBox routers provided by 2degrees, with the 2degrees version of the FritzOS software installed, go one step further and will automatically try to connect a PPPoE connection at MTU 1500, and fall back to MTU 1492 only if that does not work.  So there is nothing you need to do with such a FritzBox to make IPv6 work correctly.  Other routers may do this as well, if you are lucky.  But there is nothing about the Ubiquiti USG routers that leads me to believe that they will do this automatic fix - my bet is that they will need manual configuration.

 

2) If you do not have the option of using overprovisioning and MTU 1508, then the other way of solving this problem is to make sure you never send IPv6 packets that are larger than 1492 bytes to the PPPoE connection.  The straightforward way of doing this is to tell your router to send an option in its IPv6 Router Advertisement (RA) packets that says the IPv6 MTU is 1492.  This will cause all the IPv6 packets internally on your network to also be limited to 1492, when they could safely be 1500 bytes, but it solves the problem.

 

I have used option 2) previously with my Edgerouter Lite, before 2degrees updated their border routers to do MTU 1508.  The way you do it on an ERL is to add a line like this to the interface setup for each of the interfaces from the ERL to your internal network (Ethernet, VLAN, any other strange ones such as tunnels):

 

set interface ethernet eth1 ipv6 router-advert link-mtu 1492

 

If the USG has GUI to set up the RA settings for its interfaces, you should be able to use that to set the RA packets to advertise MTU 1492 on each internal interface.




1419 posts

Uber Geek
+1 received by user: 269

Subscriber

  Reply # 1973096 12-Mar-2018 11:42
Send private message quote this post

fe31nz:

 

In the above USG IPv6 setups I have not seen any settings that fix the MTU problem with PPPoE.  So, while IPv6 may appear to be working, it may well be broken.

 

The overhead of the PPPoE protocol is 8 bytes on each packet, so if you connect using PPPoE, your maximum MTU is 1492, not 1500.  Internally, your network is almost certainly using MTU 1500 packets, which is the standard setting for Ethernet and WiFi.  When a packet in the range 1493-1500 bytes hits the PPPoE interface, it will not be able to pass through it.  With IPv4, that is fine, the packet being bigger than the available PPPoE interface MTU will just cause it to be fragmented into two smaller packets.  This slightly reduces the throughput of your Internet connection, but most people will not notice anything at all.  But with IPv6, packets can not be fragmented - IPv6 does not support that.  What should happen is that the overlong IPv6 packet gets dropped, and an ICMPv6 "Packet too big" message should be sent back to the address the overlong packet was sent from.  It is a requirement of IPv6 that any overlong packets that get dropped send back that message.  But all the PPPoE implementations (server and client) that I have met are broken and do not send that ICMPv6 packet.  This bug has been around for quite a while and there has been no sign that anyone is ever going to fix it.  The result is that you think you have IPv6 working, but it is actually broken and will not work whenever full length packets get sent, in either direction.  The usual complaint that comes back as a result of this is "Facebook has stopped working".  That is because facebook.com is IPv6 enabled and the front page of facebook.com sends full length packets.  So as soon as IPv6 is enabled on a network, it gets used in preference to IPv4, and connections to facebook.com to log in fail due to the long packets being dropped.

 

So if you are connected to your ISP using PPPoE, you need to do one of two things to fix this:

 

1) If your Internet connection is appropriately overprovisioned as fibre connections via Chorus are, then there is bandwidth available so that you can connect the Ethernet and VLAN 10 connections to the ONT using an MTU setting of 1508 bytes, and the PPPoE connection with an MTU of 1500 bytes.  This requires also that the ISP router you are connecting to has up-to-date PPPoE server software that supports PPPoE connections with MTU 1500.  As far as I know, all the 2degrees border routers will do this now.  It also requires that your router has an up-to-date PPPoE client that supports MTU 1500 connections.  Quite a lot of routers do support this, including Edgerouters, and almost certainly all other Ubiquiti routers.  However, you have to manually set up the MTU settings to make it happen.  To see if the connection is overprovisioned and has the later version of PPPoE software, the only way I know to find out for sure is try it out using the MTU 1508/MTU 1500 settings.  If the PPPoE fails to connect after that, or no traffic (even IPv4) passes through it, then the connection in not capable of doing MTU 1508 and you will need to use the other solution below.  Do not forget to add an MTU 1500 setting to the PPPoE settings - PPPoE connections default to MTU 1492, and will not be set to MTU 1500 simply because you have set the Ethernet port and VLAN 10 to use MTU 1508.

 

The FritzBox routers provided by 2degrees, with the 2degrees version of the FritzOS software installed, go one step further and will automatically try to connect a PPPoE connection at MTU 1500, and fall back to MTU 1492 only if that does not work.  So there is nothing you need to do with such a FritzBox to make IPv6 work correctly.  Other routers may do this as well, if you are lucky.  But there is nothing about the Ubiquiti USG routers that leads me to believe that they will do this automatic fix - my bet is that they will need manual configuration.

 

2) If you do not have the option of using overprovisioning and MTU 1508, then the other way of solving this problem is to make sure you never send IPv6 packets that are larger than 1492 bytes to the PPPoE connection.  The straightforward way of doing this is to tell your router to send an option in its IPv6 Router Advertisement (RA) packets that says the IPv6 MTU is 1492.  This will cause all the IPv6 packets internally on your network to also be limited to 1492, when they could safely be 1500 bytes, but it solves the problem.

 

I have used option 2) previously with my Edgerouter Lite, before 2degrees updated their border routers to do MTU 1508.  The way you do it on an ERL is to add a line like this to the interface setup for each of the interfaces from the ERL to your internal network (Ethernet, VLAN, any other strange ones such as tunnels):

 

set interface ethernet eth1 ipv6 router-advert link-mtu 1492

 

If the USG has GUI to set up the RA settings for its interfaces, you should be able to use that to set the RA packets to advertise MTU 1492 on each internal interface.

 

Makes me wonder whether I would be better off getting a Fritz!box 7590 - is it only the 2 degrees build or is it Fritz!box in general? I'll try fiddling around with the MTU when I get home tonight to see what happens but as I noted, it appears that at the moment the ipv6 support in USG products is buggy at best.





Laptop: MacBook Pro (15-inch, 2017)
Desktop: iMac (27-inch, 2017)
Smartphone: iPhone Xs Max 256GB 'Space Grey'
Additional devices: Unifi Security Gateway, Unifi Switch, Unifi AP AC HD, Unifi Cloud Key, Apple TV 4K 64GB
Services: iCloud, YouTube Premium, Wordpress, Skinny

 


1781 posts

Uber Geek
+1 received by user: 408

Trusted
Subscriber

  Reply # 1973101 12-Mar-2018 11:54
Send private message quote this post

fe31nz:

 

In the above USG IPv6 setups I have not seen any settings that fix the MTU problem with PPPoE.  So, while IPv6 may appear to be working, it may well be broken.

 

The overhead of the PPPoE protocol is 8 bytes on each packet, so if you connect using PPPoE, your maximum MTU is 1492, not 1500. 

 

 

<snip>

 

So if your ISP doesnt use PPPoE?





________

 

Antonios K

 

 

 

Click to see full size


IcI

824 posts

Ultimate Geek
+1 received by user: 174

Trusted

  Reply # 1973148 12-Mar-2018 12:54
Send private message quote this post

matisyahu: ... but as I noted, it appears that at the moment the ipv6 support in USG products is buggy at best. 

 

As others have noted, IPv6 support on the USG is only in the beta / Release Candidate stage, not in stable.

 

If you buy a Fritzbox 7590 now, you will most certainly have 4+ years of use available. Thats a long time not to use the existing USG when IPv6 will be available in less than six months.




1419 posts

Uber Geek
+1 received by user: 269

Subscriber

  Reply # 1973496 12-Mar-2018 19:26
Send private message quote this post

IcI:

 

matisyahu: ... but as I noted, it appears that at the moment the ipv6 support in USG products is buggy at best. 

 

As others have noted, IPv6 support on the USG is only in the beta / Release Candidate stage, not in stable.

 

If you buy a Fritzbox 7590 now, you will most certainly have 4+ years of use available. Thats a long time not to use the existing USG when IPv6 will be available in less than six months.

 

Even so it is troubling that the settings in the config.gateway.json aren't being picked up and applied to my USG. I ssh into my USG, check out the settings via configure (show interfaces ethernet eth0) and none of the modifications from the config.gateway.json are being inherited by the USG (the file is on my cloud key and located in /usr/lib/unifi/data/sites/default I've renamed the site name to rachmaninov so I've also created a directory in the sites directory called rachmaninov with the file in and the settings still aren't inherited). I must be doing something wrong for those settings not to picked up. Btw, I had to edit the config.gateway.json because it left out the fact that vif 10 needed to go before the pppoe setting plus the pppoe 2 instead of 0.





Laptop: MacBook Pro (15-inch, 2017)
Desktop: iMac (27-inch, 2017)
Smartphone: iPhone Xs Max 256GB 'Space Grey'
Additional devices: Unifi Security Gateway, Unifi Switch, Unifi AP AC HD, Unifi Cloud Key, Apple TV 4K 64GB
Services: iCloud, YouTube Premium, Wordpress, Skinny

 


388 posts

Ultimate Geek
+1 received by user: 79


  Reply # 1973578 12-Mar-2018 21:20
Send private message quote this post

antoniosk:

 

fe31nz:

 

In the above USG IPv6 setups I have not seen any settings that fix the MTU problem with PPPoE.  So, while IPv6 may appear to be working, it may well be broken.

 

The overhead of the PPPoE protocol is 8 bytes on each packet, so if you connect using PPPoE, your maximum MTU is 1492, not 1500. 

 

 

<snip>

 

So if your ISP doesnt use PPPoE?

 

 

Then there should not be any problem - the default MTU of 1500 will work.  And without broken PPPoE software in your path to the Internet, even if the MTU is smaller, there should be ICMPv6 "Packet too big" messages to tell you about that, which would make IPv6 MTU path discovery work and correctly set the MTU on any IPv6 connections to match the smaller MTU that is available.


353 posts

Ultimate Geek
+1 received by user: 85


  Reply # 1979199 17-Mar-2018 21:27
Send private message quote this post

fe31nz:

 

antoniosk:

 

fe31nz:

 

In the above USG IPv6 setups I have not seen any settings that fix the MTU problem with PPPoE.  So, while IPv6 may appear to be working, it may well be broken.

 

The overhead of the PPPoE protocol is 8 bytes on each packet, so if you connect using PPPoE, your maximum MTU is 1492, not 1500. 

 

 

<snip>

 

So if your ISP doesnt use PPPoE?

 

 

Then there should not be any problem - the default MTU of 1500 will work.  And without broken PPPoE software in your path to the Internet, even if the MTU is smaller, there should be ICMPv6 "Packet too big" messages to tell you about that, which would make IPv6 MTU path discovery work and correctly set the MTU on any IPv6 connections to match the smaller MTU that is available.

 

 

 

 

Path MTU Discovery work? You must be new to the internet.


388 posts

Ultimate Geek
+1 received by user: 79


  Reply # 1979232 17-Mar-2018 23:40
Send private message quote this post

vulcannz:

 

fe31nz:

 

antoniosk:

 

fe31nz:

 

In the above USG IPv6 setups I have not seen any settings that fix the MTU problem with PPPoE.  So, while IPv6 may appear to be working, it may well be broken.

 

The overhead of the PPPoE protocol is 8 bytes on each packet, so if you connect using PPPoE, your maximum MTU is 1492, not 1500. 

 

 

<snip>

 

So if your ISP doesnt use PPPoE?

 

 

Then there should not be any problem - the default MTU of 1500 will work.  And without broken PPPoE software in your path to the Internet, even if the MTU is smaller, there should be ICMPv6 "Packet too big" messages to tell you about that, which would make IPv6 MTU path discovery work and correctly set the MTU on any IPv6 connections to match the smaller MTU that is available.

 

 

Path MTU Discovery work? You must be new to the internet.

 

 

IPv6 MTU Path Discovery does work, as it is a required part of the IPv6 specification.  Except when it meets broken PPPoE software.  Remember that IPv6 does not support fragmentation of packets, so it MTU path discovery did not work, IPv6 would not function very well.  IPv4 MTU Path Discovery is rather more hit and miss.  But it is not necessary for it to work as the packets will just get fragmented when it fails.




1419 posts

Uber Geek
+1 received by user: 269

Subscriber

  Reply # 1979396 18-Mar-2018 17:34
Send private message quote this post

fe31nz:

 

IPv6 MTU Path Discovery does work, as it is a required part of the IPv6 specification.  Except when it meets broken PPPoE software.  Remember that IPv6 does not support fragmentation of packets, so it MTU path discovery did not work, IPv6 would not function very well.  IPv4 MTU Path Discovery is rather more hit and miss.  But it is not necessary for it to work as the packets will just get fragmented when it fails.

 

 

Maybe all this is related to: https://www.geekzone.co.nz/forums.asp?forumid=85&topicid=230792&page_no=1#1976748 





Laptop: MacBook Pro (15-inch, 2017)
Desktop: iMac (27-inch, 2017)
Smartphone: iPhone Xs Max 256GB 'Space Grey'
Additional devices: Unifi Security Gateway, Unifi Switch, Unifi AP AC HD, Unifi Cloud Key, Apple TV 4K 64GB
Services: iCloud, YouTube Premium, Wordpress, Skinny

 


2028 posts

Uber Geek
+1 received by user: 794

Trusted

  Reply # 1979475 18-Mar-2018 21:12
Send private message quote this post

This is slightly offtopic, but PPPoE does not HAVE to be limited to 1492 (though yes, this is very common)

 

I'm on NowNZ in Napier on PPPoE and they set a MRU/MTU of 1500 (I've had to set the MTU of my physical port higher to 1508)

 

[2.4.2-RELEASE][admin@trogdor.muppetz.com]/root: ifconfig pppoe0 | grep mtu
pppoe0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
[2.4.2-RELEASE][admin@trogdor.muppetz.com]/root: ping -D -s 1472 -c 1 139.130.4.5
PING 139.130.4.5 (139.130.4.5): 1472 data bytes (1472 data bytes for ping will put 1500 on the wire, -D means do not fragment)
1480 bytes from 139.130.4.5: icmp_seq=0 ttl=108 time=46.288 ms

 

 


Mr Snotty
8089 posts

Uber Geek
+1 received by user: 4057

Moderator
Trusted
Lifetime subscriber

  Reply # 1979489 18-Mar-2018 23:14
Send private message quote this post

I, Too am running IPv6 at a MTU of 1500 and 1508 on the physical port.





353 posts

Ultimate Geek
+1 received by user: 85


  Reply # 1979578 19-Mar-2018 09:45
Send private message quote this post

fe31nz:

 

IPv6 MTU Path Discovery does work, as it is a required part of the IPv6 specification.  Except when it meets broken PPPoE software.  Remember that IPv6 does not support fragmentation of packets, so it MTU path discovery did not work, IPv6 would not function very well.  IPv4 MTU Path Discovery is rather more hit and miss.  But it is not necessary for it to work as the packets will just get fragmented when it fails.

 

 

 

 

PMTU needed to work on IPv4 as fragmentation breaks many protocols (especially proprietary encrypted stuff). Packets only get fragmented if they get a fragmentation required notification back, PMTU relied on that notification. So if PMTU failed then it's likely packets would not get fragmented and just flat out fail (aka a black hole router).

 

Large packets are not the be all and end all of life on the internet.  There are benefits to limiting the size of packets you send, routers under load will often drop larger packets first. Smaller packets will often transition through routing points quicker. Your packet size will increase (and decrease) as it transitions some providers who will add packets/encapsulation (MPLS can add up to 22 bytes for example but that is extreme), and this can also cause issues.

 

Because we are often routing to distant points over multiple hops little old NZ seems more susceptible to MTU challenges (it is common in Asia, less common in Europe, and even less likely in the USA). Signs you have MTU issues are pages with lots of images that don't load properly, especially HTTPS, VPNs don't work properly. Applications such as RDP and Skype have issues (proprietary encryption being fragmented). 

 

For home use a good MTU size is 1420 - that seems to be the minimum xbox live uses :) . If you can force packet fragmentation off (ie you router/firewall sends an ICMP frag required back to LAN hosts to make them send smaller packets) it helps a lot.

 

 

 

...and yes I run v6 on a 2Degrees UFB connection with non-2D hardware.


1 | 2 | 3 | 4
View this topic in a long page with up to 500 replies per page Create new topic



Twitter »

Follow us to receive Twitter updates when new discussions are posted in our forums:



Follow us to receive Twitter updates when news items and blogs are posted in our frontpage:



Follow us to receive Twitter updates when tech item prices are listed in our price comparison site:



Geekzone Live »

Try automatic live updates from Geekzone directly in your browser, without refreshing the page, with Geekzone Live now.


Geekzone Live »

Our community of supporters help make Geekzone possible. Click the button below to join them.

Support Geezone on PressPatron



Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly to your computer or smartphone by using a feed reader.

Alternatively, you can receive a daily email with Geekzone updates.