dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
2389
share rss forum feed

34764170

join:2007-09-06
Etobicoke, ON

1 edit
reply to Ternerito

Re: IPv6 Vancouver

said by Ternerito:

What option should I pick for ipv6 on the router (RT-N66U)?
these are the options I have available:

»img827.imageshack.us/img827/8789/5by7.jpg

Native with DHCP-PD or Static? I tried DHCP-PD, and the only field that gets populated is the prefix lenght.

Make sure you're using a login name from the @hsiservice.net login realm; which you have to request from TSI. Use native with DHCP-PD and in screenshots I saw for that router elsewhere via Google there was another page that I saw an option to indicate PPP (for PPPoE) vs a straight Ethernet connection without PPPoE as in cable for example.


spock

join:2012-07-08
Out west we just use our regular teksavvy pppoe login

34764170

join:2007-09-06
Etobicoke, ON
said by spock:

Out west we just use our regular teksavvy pppoe login

That is the ideal situation. I would expect that to be the case with the Toronto POP by now too, but it sounds as if that is not the case yet. Can anyone confirm otherwise?

InvalidError

join:2008-02-03
kudos:5
said by 34764170:

said by spock:

Out west we just use our regular teksavvy pppoe login

That is the ideal situation. I would expect that to be the case with the Toronto POP by now too, but it sounds as if that is not the case yet. Can anyone confirm otherwise?

Wasn't that exactly what I confirmed a few days ago?

I tried DHCPv6-PD on regular TSI login for QC/ON, didn't work (no IPv6) so I requested an IPv6 login, got a response with a new login on TSI's hsiservice.net which is their IPv6 test-realm and DHCPv6-PD worked on that - using it right now.

34764170

join:2007-09-06
Etobicoke, ON
said by InvalidError:

Wasn't that exactly what I confirmed a few days ago?

I tried DHCPv6-PD on regular TSI login for QC/ON, didn't work (no IPv6) so I requested an IPv6 login, got a response with a new login on TSI's hsiservice.net which is their IPv6 test-realm and DHCPv6-PD worked on that - using it right now.

From your other response I had no idea how much testing you had done or not. Thank you for clarifying this.


TSI Marc
Premium,VIP
join:2006-06-23
Chatham, ON
kudos:28
In Toronto you still have to request a special login.. In Vancouver it will work with your regular login.
--
Marc - CEO/TekSavvy

notfred

join:2012-09-15
reply to InvalidError
said by InvalidError:

In QC/ON, DHCP-PD appears to be working fine - using that right now.

How is the throughput at peak hours? The hsiservice login used to show horrible congestion whilst the teksavvy login was fine.

InvalidError

join:2008-02-03
kudos:5
said by notfred:

How is the throughput at peak hours? The hsiservice login used to show horrible congestion whilst the teksavvy login was fine.

I remember that. Had to quit using my old hsiservice.net because of it and did not bother trying it again until I got my N66U since my WRT54GS was not quite stable with Toastman's IPv6 build.

I haven't tried speedtest during peak hours on hsiservice since getting the N66U yet but I did download a few things at 800+KB/s (I'm on 7/1) and watched a few 720p/1080p videos on Youtube; neither of which would have been possible back when the hsiservice.net speed problems were in full force.

I'll try to remember to test tonight.


TSI Marc
Premium,VIP
join:2006-06-23
Chatham, ON
kudos:28
We recently found an obscure problem on those ERX's. Phibian helped us find it... that may have been related to a similar issue..

We're not aware of any other problem though.. if you see problems, please let us know.
--
Marc - CEO/TekSavvy


clarknova

join:2010-02-23
Grande Prairie, AB
kudos:7
Reviews:
·TekSavvy DSL
reply to spock
said by spock:

All I am able to do is get a /64 ip address on my WAN connection on my router.

Same result here using shibby.
--
db


spock

join:2012-07-08
Reviews:
·TekSavvy DSL

1 edit
reply to TSI Gabe
Could we get some official word if dhcpv6-pd is working for TSI West customers or what configuration we should be using?

Here is my dhcpv6.conf. Does the PD id matter?

I have run wireshark while trying Native ipv6 and dhcpv6-pd. I do not see any some of icmpv6 message coming from outside my network. Am I wrong to think that I should be seeing an router advertisement coming from the ERX?

interface ppp0 {
send ia-pd 0;
send rapid-commit;
request domain-name-servers;
script "/sbin/dhcp6c-state";
};
id-assoc pd 0 {
prefix-interface br0 {
sla-id 0;

Ternerito

join:2002-08-31
GVA
Reviews:
·TekSavvy DSL
quote:
Could we get some official word if dhcpv6-pd is working for TSI West customers or what configuration we should be using?
I agree. Just tested again. Here's the relevant bit from my router's log:

Aug 13 09:23:03 pppd[1758]: PAP authentication succeeded
Aug 13 09:23:03 pppd[1758]: peer from calling number 00:90:1A:A0:xx:xx authorized
Aug 13 09:23:03 pppd[1758]: local  LL address fe80::b827:91f0:xxxx:dd43
Aug 13 09:23:03 pppd[1758]: remote LL address fe80::0090:1a00:xxxx:14ab
Aug 13 09:23:03 pppd[1758]: local  IP address 76.10.x.x
Aug 13 09:23:03 pppd[1758]: remote IP address 76.10.191.6
 

»test-ipv6.com/ tells me no IPv6 addresses were detected. Some guidance from TSI would be appreciated.

notfred

join:2012-09-15
That's ppp with ipv6cp working, now fire up wireshark on the pppd and see what Router Advertisments there are and also see if anything responds to DHCPv6.

Ternerito

join:2002-08-31
GVA
OK, done that. There's exactly zero packets found, if filtered with icmpv6.type == 134 (hope that's the right filter).

InvalidError

join:2008-02-03
kudos:5
reply to notfred
said by notfred:

How is the throughput at peak hours? The hsiservice login used to show horrible congestion whilst the teksavvy login was fine.





Throughput looks fine but latency is more jittery than the 0-2ms I usually get during the day.

notfred

join:2012-09-15
reply to TSI Marc
said by TSI Marc:

We recently found an obscure problem on those ERX's. Phibian helped us find it... that may have been related to a similar issue..

We're not aware of any other problem though.. if you see problems, please let us know.

The @hsiservice login is way better than it was but not quite (although very close) to what the @teksavvy login is at.

I'm on 25/10 and with the teksavvy login a speedtest.net to the TekSavvy server in Toronto is 24+ and rock solid. Switching to the hsiservice login and it reports 22.67 and it wavers up and down quite a bit during the test, so it is close but not quite the same.

Let me know if you want packet captures or tcptrace analysis or any other help troubleshooting this.


spock

join:2012-07-08
Any chance we can keep this on topic "IPv6 Vancouver" ?


spock

join:2012-07-08
Reviews:
·TekSavvy DSL

1 edit
I tried plugging my computer directly into my modem to see what wireshark would give me. Should have done that earlier sorry.

Here is the result. I did notice the MTU was 1452

No. Time Source Destination Protocol Length Info
13 25.103588000 fe80::90:1a00:343:14ab ff02::1 ICMPv6 112 Router Advertisement

Frame 13: 112 bytes on wire (896 bits), 112 bytes captured (896 bits) on interface 0
Interface id: 0
WTAP_ENCAP: 25
Arrival Time: Aug 13, 2013 19:29:42.242861000 PDT
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1376447382.242861000 seconds
[Time delta from previous captured frame: 1.438332000 seconds]
[Time delta from previous displayed frame: 1.438332000 seconds]
[Time since reference or first frame: 25.103588000 seconds]
Frame Number: 13
Frame Length: 112 bytes (896 bits)
Capture Length: 112 bytes (896 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: sll:ipv6:icmpv6]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp || icmpv6]
Linux cooked capture
Packet type: Unicast to us (0)
Link-layer address type: 512
Link-layer address length: 0
Protocol: IPv6 (0x86dd)
Internet Protocol Version 6, Src: fe80::90:1a00:343:14ab (fe80::90:1a00:343:14ab), Dst: ff02::1 (ff02::1)
0110 .... = Version: 6
[0110 .... = This field makes the filter "ip.version == 6" possible: 6]
.... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
.... 0000 00.. .... .... .... .... .... = Differentiated Services Field: Default (0x00000000)
.... .... ..0. .... .... .... .... .... = ECN-Capable Transport (ECT): Not set
.... .... ...0 .... .... .... .... .... = ECN-CE: Not set
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 56
Next header: ICMPv6 (58)
Hop limit: 255
Source: fe80::90:1a00:343:14ab (fe80::90:1a00:343:14ab)
Destination: ff02::1 (ff02::1)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Internet Control Message Protocol v6
Type: Router Advertisement (134)
Code: 0
Checksum: 0x9c12 [correct]
Cur hop limit: 0
Flags: 0xc0
1... .... = Managed address configuration: Set
.1.. .... = Other configuration: Set
..0. .... = Home Agent: Not set
...0 0... = Prf (Default Router Preference): Medium (0)
.... .0.. = Proxy: Not set
.... ..0. = Reserved: 0
Router lifetime (s): 1800
Reachable time (ms): 0
Retrans timer (ms): 0
ICMPv6 Option (MTU : 1452)
Type: MTU (5)
Length: 1 (8 bytes)
Reserved
MTU: 1452
ICMPv6 Option (Prefix information : 2607:c000:100:FFUU::/64)
Type: Prefix information (3)
Length: 4 (32 bytes)
Prefix Length: 64
Flag: 0xc0
1... .... = On-link flag(L): Set
.1.. .... = Autonomous address-configuration flag(A): Set
..0. .... = Router address flag(R): Not set
...0 0000 = Reserved: 0
Valid Lifetime: 3600
Preferred Lifetime: 3000
Reserved
Prefix: 2607:c000:100:5XXX:: (2607:c000:100:5XXX::)

notfred

join:2012-09-15
reply to TSI Gabe
FYI You probably want to blank out the line beginning "ICMPv6 Option (Prefix information : " as well.

OK so that's the RA for the IPv6 for the link, giving you the IPv6 global address range to be used on your end of the PPP link and the default router. You'll have to try DHCPv6 to see if there is a prefix delegation as well.

mactalla

join:2008-02-19
kudos:1
reply to TSI Gabe
I tried DHCPv6 but to no avail. Given that ff02::1:2 out the wan port doesn't respond to pings I'm working with the assumption that there is no DHCPv6 server on the other end.

Looking at the output from rdisc6
# rdisc6 pppoe-wan
Soliciting ff02::2 (ff02::2) on pppoe-wan...
 
Hop limit                 :    undefined (      0x00)
Stateful address conf.    :          Yes
Stateful other conf.      :          Yes
Mobile home agent         :           No
Router preference         :       medium
Neighbor discovery proxy  :           No
Router lifetime           :         1800 (0x00000708) seconds
Reachable time            :  unspecified (0x00000000)
Retransmit time           :  unspecified (0x00000000)
 MTU                      :         1452 bytes (valid)
 Prefix                   : 2607:c000:100:me::/64
  On-link                 :          Yes
  Autonomous address conf.:          Yes
  Valid time              :         3600 (0x00000e10) seconds
  Pref. time              :         3000 (0x00000bb8) seconds
 from fe80::90:1a00:343:14ab
 

I see the prefix there, and can confirm Gabe's statement that the entire prefix is routed to me. As a temporary test I can assign an arbitrary address (in that prefix) to my router and have radvd dish out that prefix to machines on the network. They can all access the IPv6 'net. That's a great improvement over what we had before.

Now, I've also found that the prefix is not static. Rebooting the router results in a different prefix dished out to me. So hardcoding the prefix is not a solution. Also, when the pppoe link gets an IP, it tries to assign the default route for that prefix out that link (running OpenWRT here). That screws with the routing since that prefix should be going out the lan side.

I don't know the correct component that should understand the prefix as announced in the router advertisement. DHCPv6 would understand it from a DHCPv6 server, but that doesn't seem to help us here.

I might try upgrading to the bleeding edge of OpenWRT; it looks like they've put some work in to IPv6, so if I'm lucky it might just magically work. Not sure when I want to destabilize my router with that, though.

Looks like there are some routers out there struggling with the IPv6 traffic. I can ping (v4) www.google.com in ~22ms, but a ping (v6) to ipv6.google.com has a couple of spikes that result in ~174ms.

$ traceroute6 ipv6.google.com
traceroute to ipv6.l.google.com (2607:f8b0:400e:c04::67) from 2607:c000:100:me:a:b:c:d, port 33434, from port 49434, 30 hops max, 60 bytes packets
 1  2607:c000:100:me::me (2607:c000:100:me::me)  0.397 ms  0.325 ms  0.381 ms 
 2  2607:c000:1::100 (2607:c000:1::100)  10.561 ms  9.861 ms  10.227 ms 
 3  2607:c000:1:1600::1 (2607:c000:1:1600::1)  9.721 ms  15.641 ms  9.355 ms 
 4  2001:1978:1100:1::1 (2001:1978:1100:1::1)  9.669 ms  9.708 ms  9.044 ms 
 5  2001:1978:2:5::51 (2001:1978:2:5::51)  10.222 ms  9.740 ms  9.149 ms 
 6  2001:1978:2:5::1 (2001:1978:2:5::1)  71.044 ms  70.225 ms  69.636 ms 
 7  2001:1978:2:5::5e (2001:1978:2:5::5e)  70.286 ms  92.576 ms  70.404 ms 
 8  2001:1978:2:5::d1 (2001:1978:2:5::d1)  79.602 ms  79.574 ms  80.193 ms 
 9  2001:1978:2:5::7e (2001:1978:2:5::7e)  85.041 ms  84.380 ms  84.535 ms 
10  2001:1978:2:5::96 (2001:1978:2:5::96)  185.543 ms  185.686 ms  184.963 ms 
11  amsix-router.google.com (2001:7f8:1::a501:5169:1)  170.991 ms  170.200 ms  170.233 ms 
12  2001:4860::1:0:4b3 (2001:4860::1:0:4b3)  185.795 ms  243.308 ms  186.869 ms 
13  2001:4860::1:0:8 (2001:4860::1:0:8)  237.576 ms  192.767 ms  195.312 ms 
14  2001:4860::8:0:2ddf (2001:4860::8:0:2ddf)  190.296 ms  228.786 ms  190.451 ms 
15  2001:4860::8:0:3cd9 (2001:4860::8:0:3cd9)  173.839 ms  172.428 ms  172.706 ms 
16  2001:4860::8:0:2fe9 (2001:4860::8:0:2fe9)  168.446 ms  210.968 ms  167.380 ms 
17  2001:4860::8:0:281e (2001:4860::8:0:281e)  178.913 ms  178.060 ms  177.906 ms 
18  2001:4860::8:0:281e (2001:4860::8:0:281e)  188.291 ms  187.821 ms  187.249 ms 
19  2001:4860::8:0:252c (2001:4860::8:0:252c)  165.146 ms  165.351 ms  165.147 ms 
20  2001:4860::8:0:2b60 (2001:4860::8:0:2b60)  185.776 ms  174.981 ms  171.763 ms 
21  2001:4860::2:0:ac (2001:4860::2:0:ac)  173.078 ms  229.502 ms  172.638 ms 
22  * * *         
23  * * *         
24  pc-in-x67.1e100.net (2607:f8b0:400e:c04::67)  174.026 ms  174.069 ms  173.363 ms 
 


spock

join:2012-07-08
Reviews:
·TekSavvy DSL
I have tried a few different routers with different firmware and also tried the stock netgear firmware for my router which supports ipv6 and the lan still does not get an ipv6 ip. Could this be a MTU related issue? Going to pull out an old 2621xm router to see if it will work. The cisco has some nice debugging features. Wish someone from teksavvy would step in and comment on this so we don't waste anymore of our time.

mactalla

join:2008-02-19
kudos:1
I doubt it has anything to do with MTU. I think it's just a matter of using the correct mechanism to assign the prefix. I've only heard of PD (Prefix Delegation) in the context of DHCPv6, but it seems DHCPv6 is not in use for us here. But the RA (Router Advertisement) mentions a prefix, but I don't believe it's explicit that the prefix is actually delegated to us as opposed to simply being the prefix we live in (consider the router advertising to your LAN -- it's the same prefix for each machine downstream, but not delegated to them). So with a basic RA, do we actually have at the protocol level anything that's telling us (read: the router) that it has permission to use the entire prefix as it sees fit? So far I'm not seeing it.

The next thing I'll try playing with when I can is setting up a relay. Haven't ever looked in to that, but maybe that's what we need. I'll update what whatever results once I've tried it.

notfred

join:2012-09-15
If you get an RA then as far as the standards are concerned then you have the whole of that prefix. Whilst it is for the WAN link, you could cheat and advertise it out on the LAN, although then you have to play games with neighbour discovery and routing on your router.

mactalla

join:2008-02-19
kudos:1
reply to TSI Gabe
So I tried out 6relayd and it's working well. So now I have neither dhcpv6 (server or client) nor radvd running. Just 6relayd. The LAN interface and downstream machines are configuring appropriate addresses for themselves based on the prefix advertised by TSI's machines. My only problem is that the pppoe interface is still configuring itself a /64 address and creates a route for that entire prefix which conflicts with the same route for the LAN interface. So I still require manual intervention to remove that wrong route every time the link is restored (reboot or extended power outage).

But at least it's functional.

34764170

join:2007-09-06
Etobicoke, ON
reply to mactalla
said by mactalla:

Looks like there are some routers out there struggling with the IPv6 traffic. I can ping (v4) www.google.com in ~22ms, but a ping (v6) to ipv6.google.com has a couple of spikes that result in ~174ms.

TSI really needs to turn up v6 transit with Hurricane in Vancouver.


martyb

join:2013-05-18
Wemindji, QC
said by 34764170:

said by mactalla:

Looks like there are some routers out there struggling with the IPv6 traffic. I can ping (v4) www.google.com in ~22ms, but a ping (v6) to ipv6.google.com has a couple of spikes that result in ~174ms.

TSI really needs to turn up v6 transit with Hurricane in Vancouver.

I don't think thats it, the third hop of his traceroute is on Peer1 so its been handed off to transit relatively early on.

mactalla, what DNS servers are you using? Because you are resolving google somehow that is sending you over AMS-IX, the _amsterdam_ exchange....no wonder your latency is so damn high. Are you using open resolvers perhaps?

34764170

join:2007-09-06
Etobicoke, ON
said by martyb:

I don't think thats it, the third hop of his traceroute is on Peer1 so its been handed off to transit relatively early on.

That might be so but that does not always mean taking the best possible route for a particular destination. I understand where you're coming from with the DNS aspect and the IP address that is ultimately being resolved to; that is probably the bigger issue with this scenario. Having the additional routes provided by such a well connected IPv6 network like Hurricane doesn't exactly hurt. Via Hurricane from Vancouver it takes a route down to Seattle and through to Google, and is probably hitting some sort of Google cache cluster.

1 10 ms 21 ms 3 ms 10gigabitethernet12-3.core1.sea1.he.net (2001:470:0:231::1)
2 20 ms 3 ms 3 ms google-as15169.gigabitethernet2-8.core1.sea1.he.net (2001:470:0:130::2)
3 12 ms 20 ms 50 ms 2001:4860::1:0:610
4 33 ms 15 ms 12 ms 2001:4860::8:0:252c
5 12 ms 24 ms 25 ms 2001:4860::8:0:467d
6 28 ms 21 ms 25 ms 2001:4860::2:0:ac
7 * * * ?
8 16 ms 10 ms 14 ms pc-in-x67.1e100.net (2607:f8b0:400e:c04::67)
 
core1.yvr1.he.net> ping ipv6 2607:f8b0:400e:c04::67 numeric count 5
Sending 5, 16-byte ICMPv6 Echo to 2607:f8b0:400e:c04::67
timeout 5000 msec, Hop Limit 64
Reply from 2607:f8b0:400e:c04::67: bytes=16 time=18ms Hop Limit=57
Reply from 2607:f8b0:400e:c04::67: bytes=16 time=10ms Hop Limit=58
Reply from 2607:f8b0:400e:c04::67: bytes=16 time=14ms Hop Limit=58
Reply from 2607:f8b0:400e:c04::67: bytes=16 time=13ms Hop Limit=58
Reply from 2607:f8b0:400e:c04::67: bytes=16 time=13ms Hop Limit=58
Success rate is 100 percent (5/5), round-trip min/avg/max=10/13/18 ms.
 


martyb

join:2013-05-18
Wemindji, QC
said by 34764170:

said by martyb:

I don't think thats it, the third hop of his traceroute is on Peer1 so its been handed off to transit relatively early on.

That might be so but that does not always mean taking the best possible route for a particular destination. I understand where you're coming from with the DNS aspect and the IP address that is ultimately being resolved to; that is probably the bigger issue with this scenario. Having the additional routes provided by such a well connected IPv6 network like Hurricane doesn't exactly hurt. Via Hurricane from Vancouver it takes a route down to Seattle and through to Google, and is probably hitting some sort of Google cache cluster.

I won't argue that HE is well connected in the v6 world, however Peer1 is not so poorly connected that it must forward traffic to Europe. I would not assume however that HE == Best Route(tm) in all cases.

My DNS resolves google.com to 2607:f8b0:400c:c03::67 and over Peer1 I reach that destination in 25-30ms, which is identical to IPv4.

I don't know how TSI has designed their network between Vancouver and Toronto, however my view would be that it would be better to peer IPv6 at TorIX with Google and forward traffic over TSI's backbone instead of handing it off to transit and letting the "best route" decide. I would hope they have better capacity and manageability on their backbone west-east.


fluffybunny

@teksavvy.com
mine is fine :
traceroute to sea09s01-in-x11.1e100.net (2607:f8b0:400a:800::1011) from x:e7c9, port 33434, from port 44728, 30 hops max, 60 byte packets
1 x::1 (x::1) 2.564 ms 0.404 ms 0.319 ms
2 x (x::1) 17.748 ms 17.355 ms 26.857 ms
3 gige-g2-6.core1.sea1.he.net (2001:470:0:9b::1) 19.956 ms 31.653 ms 16.342 ms
4 google-as15169.gigabitethernet2-8.core1.sea1.he.net (2001:470:0:130::2) 26.887 ms 16.193 ms 15.927 ms
5 2001:4860::1:0:795 (2001:4860::1:0:795) 16.349 ms 15.977 ms 17.848 ms
6 2001:4860:0:1::44a (2001:4860:0:1::44a) 16.186 ms 18.199 ms 18.061 ms
7 2607:f8b0:400a:800::18 (2607:f8b0:400a:800::18) 17.883 ms 17.974 ms 25.298 ms


spock

join:2012-07-08
reply to 34764170
How does turning up v6 transit fix the problem we have out west with ipv6.