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 
497 posts

Ultimate Geek


  # 1941770 18-Jan-2018 02:20
One person supports this post
Send private message

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.




561 posts

Ultimate Geek


  # 1944139 20-Jan-2018 19:10
Send private message

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
}
}
}


 
 
 
 


497 posts

Ultimate Geek


  # 1944249 21-Jan-2018 03:36
Send private message

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 
View this topic in a long page with up to 500 replies per page Create new topic



Switch your broadband provider now - compare prices


Twitter and LinkedIn »



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:





News »

Ring launches indoor-only security camera
Posted 23-Jan-2020 17:26


New report findings will help schools implement the digital technologies curriculum content
Posted 23-Jan-2020 17:25


N4L to upgrade & support wireless internet inside schools
Posted 23-Jan-2020 17:22


Netflix releases 21 Studio Ghibli works
Posted 22-Jan-2020 11:42


Vodafone integrates eSIM into device and wearable roadmap
Posted 17-Jan-2020 09:45


Do you need this camera app? Group investigates privacy implications
Posted 16-Jan-2020 03:30


JBL launches headphones range designed for gaming
Posted 13-Jan-2020 09:59


Withings introduces ScanWatch wearable combining ECG and sleep apnea detection
Posted 9-Jan-2020 18:34


NZ Police releases public app
Posted 8-Jan-2020 11:43


Suunto 7 combine sports and smart features on new smartwatch generation
Posted 7-Jan-2020 16:06


Intel brings innovation with technology spanning the cloud, network, edge and PC
Posted 7-Jan-2020 15:54


AMD announces high performance desktop and ultrathin laptop processors
Posted 7-Jan-2020 15:42


AMD unveils four new desktop and mobile GPUs including AMD Radeon RX 5600
Posted 7-Jan-2020 15:32


Consolidation in video streaming market with Spark selling Lightbox to Sky
Posted 19-Dec-2019 09:09


Intel introduces cryogenic control chip to enable quantum computers
Posted 10-Dec-2019 21:32



Geekzone Live »

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


Support Geekzone »

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.