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.




2413 posts

Uber Geek
+1 received by user: 133


Topic # 86416 6-Jul-2011 12:37
Send private message

Anyone (I guess the Snap guys would know this. ;) know if Snap is looking at offering native IPv6 on their DSL plans any time soon?

I'm currently running a Cisco 877 on Xnet with their v6 trial. Looking at Snaps Naked DSL plan, it's $15 cheaper and includes 5GB of data. 

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


2413 posts

Uber Geek
+1 received by user: 133


  Reply # 491416 9-Jul-2011 14:16
Send private message

Ah, this is the reply I got from SNAP support:

"Thanks for your query,

Unfortunatly, we are currently not trialing IPV6 as it doesn't work over ATM which the majority of Telecom's equipment uses. I also have no idea when Telecom will be updating to allow this, so no dates on when and if we will be trialing it in the future unfortunately. "

Uhm what. IPv6 is a few layers above ATM. You can do v6 over BUBA and EUBA (inside PPP) and most ISPs should be moving people to EUBA anyway. So it's unfair for SNAP to pass the buck to Telecom on this one.

I think they're just being lazy/not wanting to spend money or time (or trying to find an engineer who can do it) to upgrade their hardware/support/billing/etc. Seems like this is the case with most ISPs.

(For the record, XNet can do v6 over EUBA just fine.)

8020 posts

Uber Geek
+1 received by user: 387

Trusted
Subscriber

  Reply # 491436 9-Jul-2011 15:54
Send private message

Blame Telecom is the go to standard response from every ISP when they haven't bothered to implement something new yet.

The real reason of course is an obvious business reason, lack of demand for it.

 
 
 
 


Try Wrike: fast, easy, and efficient project collaboration software


2413 posts

Uber Geek
+1 received by user: 133


  Reply # 491440 9-Jul-2011 16:03
Send private message

Ragnor: Blame Telecom is the go to standard response from every ISP when they haven't bothered to implement something new yet.

The real reason of course is an obvious business reason, lack of demand for it.


Well, they'll be deploying CGNAT soon and then everyone on snap is screwed if they want a public IP (which they won't get, since they don't even have v6!)


26 posts

Geek


  Reply # 491614 10-Jul-2011 12:10
Send private message

The issue is not directly with telecom's network being ATM based for a large chunk of legacy broadband connection - it lies more around the lack of support in 95% of the CPE's - specifically the ones which dont' support native ethernet over the DSL.

We are working on a V6 DSL offering and hopefully we should be able to begin trialling publicly within 6 - 8 weeks, but I don't expect the uptake to be significant because most users modems wont support it.




2413 posts

Uber Geek
+1 received by user: 133


  Reply # 491636 10-Jul-2011 13:14
Send private message

jbergler: The issue is not directly with telecom's network being ATM based for a large chunk of legacy broadband connection - it lies more around the lack of support in 95% of the CPE's - specifically the ones which dont' support native ethernet over the DSL.

We are working on a V6 DSL offering and hopefully we should be able to begin trialling publicly within 6 - 8 weeks, but I don't expect the uptake to be significant because most users modems wont support it.



True, but ISPs are going to have to switch on IPv6 sooner or later, once CPE's start rolling out with support for it. You'd think they'd do this well _before_ they run out of V4, in order to get it tested before they completely run out.




2413 posts

Uber Geek
+1 received by user: 133


  Reply # 491637 10-Jul-2011 13:14
Send private message

@jbergler: Also, are you from SNAP or some other ISP?

26 posts

Geek


  Reply # 491640 10-Jul-2011 13:18
Send private message

kyhwana2: @jbergler: Also, are you from SNAP or some other ISP?


Snap. http://www.snap.net.nz/snap/ourteam



kyhwana2:

True, but ISPs are going to have to switch on IPv6 sooner or later, once CPE's start rolling out with support for it. You'd think they'd do this well _before_ they run out of V4, in order to get it tested before they completely run out.



True - but we've been running IPv6 Natively for over 2 years. A large portion of our ethernet customers have had the option for IPv6 for over a year.




2413 posts

Uber Geek
+1 received by user: 133


  Reply # 491642 10-Jul-2011 13:26
Send private message

jbergler:

True - but we've been running IPv6 Natively for over 2 years. A large portion of our ethernet customers have had the option for IPv6 for over a year.



Nice. So you need to sort out billing/support then? (Like most ISPs)
I see you just got EUBA at your auckland handover point up and running?

Is there any timeline for trialling v6 on your DSL customers? Maybe SNAP staff at home? ;)



26 posts

Geek


  Reply # 491644 10-Jul-2011 13:43
Send private message

kyhwana2:
Nice. So you need to sort out billing/support then? (Like most ISPs)
I see you just got EUBA at your auckland handover point up and running?

Is there any timeline for trialling v6 on your DSL customers? Maybe SNAP staff at home? ;)



jbergler: 

We are working on a V6 DSL offering and hopefully we should be able to begin trialling publicly within 6 - 8 weeks, but I don't expect the uptake to be significant because most users modems wont support it.


 
Short answer - sooner rather than later. 

19 posts

Geek


  Reply # 491754 10-Jul-2011 20:30
Send private message

I've been asking Snap regularly for IPv6 over residential DSL. I tend to ring them every month or two and ask similar questions. I don't always get the same answer but I sometimes get new information (some of it being true).  One thing that has come up is the lack of a IPv6 address/prefix management database.

In lieu of native IPv6 I have setup a 6in4 tunnel to Sixxs which is provided by ACSdata in Wellington. This provides reasonably latency (way way better than a HE tunnel to the US).  It is unfortunate that Snap peer with ACSData at APE even though the tunnel traffic goes to Wellington (WIX). The MTU on this is way less than 1500.

If you want to just setup a simple 6to4 tunnel, then there is a 6to4 anycast server close to Snap (which appears to be run by FX Networks).

My usual set of questions for Snap include, can I please have:


  • native IPv6

  • QOS over EUBA

  • VoIP


What size prefix are Snap looking to give out to customers? What MTU are Snap looking to offer for native IPv6? How are Snap looking to encapsulate IPv6? (PPPoA, PPPoE, IPoE or something else?)

In preparation for native IPv6 (and QoS) I moved to a EUBA configuration. Snap were helpful in getting me moved to a EUBA service. I was disappointed that IPv4 over PPPoE MTU went down below 1500 (Snap said they wanted 8 bytes for QinQ).

The other thing I have noticed is that the Cisco 877 is hitting a CPU limitation of around 11Mbps for IPv4 and I think it is worse for IPv6 (IOS 15.1, ZBFW, PPPoE, NAT). What happens for people that want full ADSL2+ speeds? What Cisco router will handle VDSL2 speeds without breaking the bank?


--

68.16.69.111.static.snap.net.nz (111.69.16.68)  11.656 ms  12.785 ms  13.373 ms
168.19.69.111.static.snap.net.nz (111.69.19.168)  15.312 ms  16.496 ms  17.683 ms
fx.chix.nzix.net (218.100.24.18)  26.018 ms  27.248 ms  28.486 ms
GigabitEthernet0-0-918.wnmur-rt1.fx.net.nz (202.53.187.69)  53.457 ms  259.887 ms  260.388 ms
192.88.99.1 (192.88.99.1)  20.603 ms  20.869 ms  23.281 ms



2413 posts

Uber Geek
+1 received by user: 133


  Reply # 491758 10-Jul-2011 20:40
Send private message

gregb:
The other thing I have noticed is that the Cisco 877 is hitting a CPU limitation of around 11Mbps for IPv4 and I think it is worse for IPv6 (IOS 15.1, ZBFW, PPPoE, NAT). What happens for people that want full ADSL2+ speeds? What Cisco router will handle VDSL2 speeds without breaking the bank?


Really? I can pull 14-15Mbit/s off my Cisco 877, i've got the RAM upgrade in it. ALthough i'm not using the IPSec/QOS stuff in it atm. Just NAT/firewall stuff. (Along with native v6 from xnet)


26 posts

Geek


  Reply # 491786 10-Jul-2011 22:15
Send private message

I can't really comment about the voice side of things - its not something i'm involved in. V6 on DSL should be coming as per my earlier post. On the other points I'll respond without my Snap hat on and take a general approach. 

 
In lieu of native IPv6 I have setup a 6in4 tunnel to Sixxs which is provided by ACSdata in Wellington. This provides reasonably latency (way way better than a HE tunnel to the US).  It is unfortunate that Snap peer with ACSData at APE even though the tunnel traffic goes to Wellington (WIX). The MTU on this is way less than 1500.


The address for the ACS Sixxs tunnel box is advertised equally to APE, WIX & CHIX. A service provider has no way to tell what is better and from experience APE is the best choice out of the peering points. If ACS was to advertise the route at better at WIX than elsewhere this should solve your problem.

MTU will never be better because the tunnel has to traverse across a 1500 byte network.




If you want to just setup a simple 6to4 tunnel, then there is a 6to4 anycast server close to Snap (which appears to be run by FX Networks).



This could be one of Nathan Wards teredo boxes which alot of service providers are hosting. I believe he may have one in Snap's network but I think he manages these. Regardless teredo isn't a nice solution and probably shouldn't be relied upon.



QOS over EUBA


This point actually makes me curious. What are you expecting from this? Would you pay extra for it? 

QOS doesn't work across the internet. It works in the confines of a tightly managed and controlled network - which is internet is not. The very best you could expect is for us to obey your markings to our upstreams at which point they would be lost. Traffic coming back would not be marked. This is just on of the reasons why applications which require QOS are not designed to be run across the internet.

If a service provider was to provide QOS on a DSL internet the only service which could realistically be supported would be a service hosted on the service providers network - ie their own voice service or similar - which for me doesn't fall under the internet umbrella - it's a value add service not part of the internet - it just happens to be delivered using the same piece of string.




What size prefix are Snap looking to give out to customers? What MTU are Snap looking to offer for native IPv6? How are Snap looking to encapsulate IPv6? (PPPoA, PPPoE, IPoE or something else?)



PPPoA vs PPPoE has minimal differences - mostly CPE's that don't have support for Ethernet over EUBA wont support v6 anyway. Initially, I'd IP6oPPP will be the most likely as it simply involves sending a few additional attributes with the login - everything else keeps working (cough billing cough)

IPoE is the way forward and then it will be DHCP6.



In preparation for native IPv6 (and QoS) I moved to a EUBA configuration. Snap were helpful in getting me moved to a EUBA service. I was disappointed that IPv4 over PPPoE MTU went down below 1500 (Snap said they wanted 8 bytes for QinQ).


MTU could be a CPE issue - I'm running 1500 bytes on my EUBA tail - but I'm using a modem in bridge mode and a mikrotik behind it. The modem is a linksys AM300 which doesn't care about bridging more than 1500 (i think it will pass around 1518 - 1524 form memory and i think euba's max is 1528ish)

You'll have to be using ethernet mode though - PPPoA to PPPoE translation likes to mess things up a bit from experience.



The other thing I have noticed is that the Cisco 877 is hitting a CPU limitation of around 11Mbps for IPv4 and I think it is worse for IPv6 (IOS 15.1, ZBFW, PPPoE, NAT). What happens for people that want full ADSL2+ speeds? What Cisco router will handle VDSL2 speeds without breaking the bank?


Theres an 877 software bug (fixed by 12.24 i think) which limits dsl to about 16meg on PPPoA.
I've seen pretty poor performance on the 877's running PPPoE using the 0/110 pvc but its a new feature so I imagine this might get better with newer code / hardware. 

As with other cisco kit the more features you enable the slower it will perform.

We've played with the 887VA's a bit and they seem to fly.

19 posts

Geek


  Reply # 491787 10-Jul-2011 22:18
Send private message

What is the CPU load at 14-15Mbps? I'm doing an single ipv4 rsync at around 6Mbps and it is using around 50% CPU. Looking at the stats it's mostly interrupt time. Not sure of the RAM (236544K/25600K bytes of memory).


--
#show proc cpu his

Marathon   10:10:48 PM Sunday Jul 10 2011 NZST




      555555555566666555555555544444555555555544444555554444455555
      333335555511111222223333388888666663333399999000008888811111
  100
   90
   80
   70
   60      **********               *****
   50 ************************************************************
   40 ************************************************************
   30 ************************************************************
   20 ************************************************************
   10 ************************************************************
     0....5....1....1....2....2....3....3....4....4....5....5....6
               0    5    0    5    0    5    0    5    0    5    0
               CPU% per second (last 60 seconds)


#show proc cpu sorted
CPU utilization for five seconds: 46%/43%; one minute: 50%; five minutes: 52%
 PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process
  66    48032966    11777279       4078  1.99%  1.99%  1.97%   0 COLLECT STAT COU
 106     5168713     2922253       1768  0.55%  0.28%  0.34%   0 IP Input
 279       66653    73521918          0  0.07%  0.02%  0.01%   0 PPP Events
 269       13265     9418468          1  0.07%  0.00%  0.00%   0 MLD
  76       76318      236596        322  0.07%  0.00%  0.00%   0 ATM OAM Input
 273       10638     4595290          2  0.07%  0.01%  0.00%   0 IP NAT Ager
   7           0           1          0  0.00%  0.00%  0.00%   0 DiscardQ Backgro


Cisco 877-M (MPC8272) processor (revision 4.0) with 236544K/25600K bytes of memory.

19 posts

Geek


  Reply # 491810 10-Jul-2011 23:15
Send private message

jbergler: V6 on DSL should be coming as per my earlier post.


I'd be keen get a native prefix when you're ready please.

jbergler: The address for the ACS Sixxs tunnel box is advertised equally to APE, WIX & CHIX. A service provider has no way to tell what is better and from experience APE is the best choice out of the peering points. If ACS was to advertise the route at better at WIX than elsewhere this should solve your problem.

MTU will never be better because the tunnel has to traverse across a 1500 byte network.


From a technical POV I understand that (but don't claim to be a BGP and/or peering expert). From an IPv6 user running a tunnel POV it would seem better if the traffic could go a more direct path.

jbergler: This could be one of Nathan Wards teredo boxes which alot of service providers are hosting. I believe he may have one in Snap's network but I think he manages these. Regardless teredo isn't a nice solution and probably shouldn't be relied upon.


I would concur. However when I have asked for IPv6 from Snap this has been presented as an option.

jbergler:
This point actually makes me curious. What are you expecting from this? Would you pay extra for it?


An interesting question. I don't know how much more I would paid for some prioritised traffic. I can see that I would buy a VoIP offering from Snap over another provider if it came with some form of QoS (even if it was a few dollars more). I guess the counter question is do you think it would be a service that Snap could offer that would be a competitive advantage? Would selling it as a value add for VoIP not be an advantage? Can it be sold to gamers?

I'm mainly looking at it for VoIP (and specifically SIP). I can see how it would be straightforward to understand the QOS/COS in a service provider/custom scenario (I'm not sure what Xnet are doing but they seem to be leading this game). In my case I can see it working the same where my prioritised traffic is prioritised only up to the ISP's border (a trust boundary where the ISP's trusts the markings). Return traffic would need to use a scheme (say DSCP) to decide whether it's prioritised traffic. Given the tiny bandwidth available on the EUBA offerings the policing/dropping of all over allocation traffic means it won't tend to be abused for 'faster torrents'.


jbergler: I've seen pretty poor performance on the 877's running PPPoE using the 0/110 pvc but its a new feature so I imagine this might get better with newer code / hardware.


Although the EUBA offering is new-ish, PPPoE should be really well understood. Worldwide I would have thought that it was more widely used that PPPoA (e.g. BUBA & EUBA in compatibility mode).

26 posts

Geek


  Reply # 491818 10-Jul-2011 23:32
Send private message

jbergler: The address for the ACS Sixxs tunnel box is advertised equally to APE, WIX & CHIX. A service provider has no way to tell what is better and from experience APE is the best choice out of the peering points. If ACS was to advertise the route at better at WIX than elsewhere this should solve your problem.


gregb: From a technical POV I understand that (but don't claim to be a BGP and/or peering expert). From an IPv6 user running a tunnel POV it would seem better if the traffic could go a more direct path.


My point here is that although a service provider could make this better for the user they shouldn't (and if they did it would probably break things long term). It's up to the content provider to make the decision on where their traffic comes from, not vice versa.

jbergler: This point actually makes me curious. What are you expecting from this? Would you pay extra for it?


gregb: An interesting question. I don't know how much more I would paid for some prioritised traffic. I can see that I would buy a VoIP offering from Snap over another provider if it came with some form of QoS (even if it was a few dollars more). I guess the counter question is do you think it would be a service that Snap could offer that would be a competitive advantage? Would selling it as a value add for VoIP not be an advantage? Can it be sold to gamers?


Sure it could - but it would cost a significant chunk of money. If an ISP is selling QOS they need to ensure it end to end which in this case would mean peering with the game servers you want an enhanced service to. It very quickly stops being an internet service and heads towards an transport service which costs lots of $.

I don't think QOS will ever be something you can buy on your internet connection - at least I hope not. This becomes a net neutrality argument very quickly. Why is X on the internet more important than Y etc.
The difference between QOS for voice from your isp is that its not an internet service. 



gregb: I'm mainly looking at it for VoIP (and specifically SIP). I can see how it would be straightforward to understand the QOS/COS in a service provider/custom scenario (I'm not sure what Xnet are doing but they seem to be leading this game). In my case I can see it working the same where my prioritised traffic is prioritised only up to the ISP's border (a trust boundary where the ISP's trusts the markings). Return traffic would need to use a scheme (say DSCP) to decide whether it's prioritised traffic. Given the tiny bandwidth available on the EUBA offerings the policing/dropping of all over allocation traffic means it won't tend to be abused for 'faster torrents'.


I'm not concerned with a user abusing the service - the potential for that is minimized because any traffic in excess of the traffic class's bandwidth is discarded, there is no borrowing or lending, its simply policed.
Which means if I want to be malicious I will send you 48kbps of cos marked UDP traffic and your phone will stop working. It's not actually the case because as you say qos only works to trust boundries - which means everything from the 'internet' is rewritten to best efforts and suddenly using QOS for games or voice outside your ISP's network isn't going to work.




jbergler: I've seen pretty poor performance on the 877's running PPPoE using the 0/110 pvc but its a new feature so I imagine this might get better with newer code / hardware.


gregb: Although the EUBA offering is new-ish, PPPoE should be really well understood. Worldwide I would have thought that it was more widely used that PPPoA (e.g. BUBA & EUBA in compatibility mode).


It's not the PPPoE support i'm worried about - it's the half complete implementation of the ethernet over dsl encapsulation in the 800 series. Which incidentally to my knowledge doesn't even support qos marking - last i looked you had to go back to PPPoA and the legacy PVC doesn't support QOS as its not ethernet the whole way.

 1 | 2 | 3
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:





News »

Amazon launches the International Shopping Experience in the Amazon Shopping App
Posted 19-Apr-2018 08:38


Spark New Zealand and TVNZ to bring coverage of Rugby World Cup 2019
Posted 16-Apr-2018 06:55


How Google can seize Microsoft Office crown
Posted 14-Apr-2018 11:08


How back office transformation drives IRD efficiency
Posted 12-Apr-2018 21:15


iPod laws in a smartphone world: will we ever get copyright right?
Posted 12-Apr-2018 21:13


Lightbox service using big data and analytics to learn more about customers
Posted 9-Apr-2018 12:11


111 mobile caller location extended to iOS
Posted 6-Apr-2018 13:50


Huawei announces the HUAWEI P20 series
Posted 29-Mar-2018 11:41


Symantec Internet Security Threat Report shows increased endpoint technology risks
Posted 26-Mar-2018 18:29


Spark switches on long-range IoT network across New Zealand
Posted 26-Mar-2018 18:22


Stuff Pix enters streaming video market
Posted 21-Mar-2018 09:18


Windows no longer Microsoft’s main focus
Posted 13-Mar-2018 07:47


Why phone makers are obsessed with cameras
Posted 11-Mar-2018 12:25


New Zealand Adopts International Open Data Charter
Posted 3-Mar-2018 12:48


Shipments tumble as NZ phone upgrades slow
Posted 2-Mar-2018 11:48



Geekzone Live »

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



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.