Gfycat speeds on IPv6?

Forums › 2degrees (including Slingshot, Orcon, Flip, Stuff Fibre, MyRepublic, 2talk and Vocus) › Gfycat speeds on IPv6?

1 | 2

fe31nz

1232 posts

Uber Geek

#1941770 18-Jan-2018 02:20

Obraik: @2degreescare would your network engineers be willing to take a look at my EdgeRouter configuration to see if there's any IPv6 settings that need to be changed? As I mentioned it was working fine until suddenly it wasn't without any changes on my end so maybe 2degrees made changes to what is needed for IPv6 to work correctly?

I have had IPv6 disabled the last month or so to get around the issue and turned it back on yesterday to see of things were better but still the same issues are present.

To get IPv6 working properly, you need to have the PPPoE config set up to use the extra bandwidth made available by Chorus to compensate for the 8-byte PPPoE protocol overheads. Once you do that, the MTU is 1500 instead of 1492 and you stop having problems with long IPv6 packets getting dropped. Most PPPoE software I have met fails to send the required ICMPv6 "Packet too long" messages when it drops an overlong packet, and that breaks the path MTU discovery mechanism required for IPv6 to work. So you either have to set the MTU lower (1492) or get PPPoE to pass 1500 byte packets intact. The PPPoE software in the Edgerouter Lite and in the routers 2Degrees are using on their end of customer connections both seem to have this bug, so you can get overlong IPv6 packets silently dropped in either direction.

Here is what I have for my eth0 interface:

ethernet eth0 {
    description "Outside raw to ONT"
    duplex auto
    mac xx:xx:xx:xx:xx:xx
    mtu 1508
    speed auto
    vif 10 {
        description "Outside raw VLAN 10 to ONT"
        egress-qos "1:5 2:5 3:5 4:5 6:5 7:5"
        mtu 1508
        pppoe 0 {
            default-route auto
            description "Internet connection to ISP"
            ipv6 {
                address {
                    secondary 2406:xxxx:xxxx:xxxx::xxxx/128
                }
                dup-addr-detect-transmits 1
                enable {
                }
            }
            mtu 1500
            name-server none
            password xxxxxxxxxx
            user-id xxxxxxxxxx@snap.net.nz
        }
     }
}

Note the "mtu 1508" on the eth0 and vif10 interfaces, and "mtu 1500" on the pppoe interface.

Obraik

2123 posts

Uber Geek

#1944139 20-Jan-2018 19:10

I tried the 1508 MTU but that seemed to make things worse..

This is how I currently have my config when I have IPv6 enabled:

ethernet eth0 {
   duplex auto
   speed auto
   vif 10 {
     description "Internet (PPPoE)"
     pppoe 0 {
        default-route auto
        dhcpv6-pd {
         pd 0 {
            interface eth0 {
                prefix-id :6
            }
            interface eth1 {
                host-address ::1
                prefix-id 0
                service slaac
            }
            interface eth1.104 {
                host-address ::1
                prefix-id 1
                service slaac
            }
            interface eth2 {
                host-address ::1
                prefix-id :2
                service slaac
            }
            interface pppoe0 {
                host-address ::1
                prefix-id :5
            }
            prefix-length /56
         }
         rapid-commit disable
      }
      firewall {
         in {
           ipv6-name WANv6_IN
           name PPPOE
         }
        local {
           ipv6-name WANv6_LOCAL
         name WAN_LOCAL
      }
      }
      ipv6 {
          address {
             autoconf
          }

         enabled {
          }
          dup-addr-detect-transmits 1
          router-advert {
             cur-hop-limit 64
             link-mtu 1492
             managed-flag false
             max-interval 600
             name-server [internal ipv6 dns]
             name-server [internal ipv6 dns2]
             other-config-flag false
             reachable-time 0
             retrans-timer 0
             send-advert true
          }
}
mtu 1492
name-server auto
password pass
user-id user@snap.net.nz
}
}
}

Looking to buy a Tesla? Use my referral link and we both get credits

fe31nz

1232 posts

Uber Geek

#1944249 21-Jan-2018 03:36

What on earth are you doing router advertisments on the PPPoE interface for? RAs should only be configured on your internal network - the ISP network does not want or need them, and I would hope that their routers would be dropping those packets.

As I have static IP addresses, I have never done the PD delegation you are doing for your IPv6 addresses, but I think that delegating back to the eth0 interface (interface eth0 {prefix-id :6}) is probably a bad idea. Delegation of your IPv6 addresses should only be to your own network. Depending on how 2Ds routers are set up, and your firewall setup, having a routeable IPv6 on your eth0 interface may be opening up a security hole where people can try to connect to the ERL.

If you are configuring to use MTU 1492 for IPv6 on the PPPoE interface, then you will also need the same IPv6 MTU 1492 config on all the other IPv6 interfaces on the router, otherwise they will be defaulting to 1500. I know, path MTU discovery should be making all your packets going out the PPPoE interface match its MTU, but remember PPPoE has that bug - it does not send the ICMPv6 "Packet too long" messages. So you have reduce the MTU on all the internal interfaces also to fix that. And then you just have to live with 1492 for the MTU of the IPv6 packets that do not go outside your network. Which is another reason for configuring the PPPoE to use MTU 1500.

What happens when you set the the eth0 and vif10 MTUs to 1508 and PPPoE to 1500? That should fix the problem, unless you are connecting to an ISP router that does not do 1508 for the PPPoE interface, in which case you should get some errors about that - it may not connect, or it may connect with MTU 1500 instead of 1508. But as far as I know 2D's routers all do 1508 for PPPoE now.

What I had to do to figure out what was going on when I had IPv6 problems was to install the tshark package on the ERL and use that to capture the packets on the PPPoE interface. Once you have installed tshark, use "sudo su" to get a root prompt to run tshark from. When you run it make sure it only writes its capture file to the ERL's ramdisk, otherwise the large number of writes will wear out its USB stick and the ERL will crash and fail to boot. The /var/log directory is where I store them, but you can use the df command to see what directories are on ramdisk (tempfs). Then when the capture is done, I use sshfs (eg the scp command) to copy the files to my PC and display them with Wireshark.

It is a while since I did this, but I believe a command like this would be what you want for tshark:

tshark -tad -P -w /var/log/eth0.pcap -i eth0

The "-tad -P" makes tshark display the packets as well as storing them, and is optional. Capturing the eth0 interface means the captured packets will include the PPPoE and VLAN headers as well as the standard Ethernet packet data. It is best to do such captures when your network is not doing much traffic, or use filters to see only the traffic you want. You may also need to turn off the offloading options in order to be able to capture all the packets. That will, of course, dramatically slow down the ERL throughput. I would suggest setting up for using the 1508/1500 MTUs and then doing a capture of the traffic as the ERL connects to 2D's router, and see what the PPPoE negotiation is doing. If that is working and allowing 1508, then leave the settings on that and try capturing IPv6 traffic to problem sites. A good one to try first is facebook.com, as its front page produces full length IPv6 packets every time you load it. If facebook.com's opening pages load OK, then it is likely that the long packet problem is fixed.

I think that I had to use the ERL commands shut down and start up the PPPoE interface to capture it at connection time as unplugging the cable to the ONT causes the eth0 interface to go down and that stops tshark if it is capturing eth0.

1 | 2