See INC0164829 (for pinger and INC0176266 for www3), also INC0191881 for fixes following upgrading the border.
pinger.slac.stanford.edu and www3.slac.stanford.edu
...
- Had to get subnet enabled for IPv6 - Mark.
- To find subnet for the host (e.g. pinger) use NetDB (or ping, or ifconfig on actual host) to find IPv4 address
- Use http://network.slac.stanford.edu/subnets to find list of subnets
- Enter first 3 octets of the host (e.g. 134.79.197.) in the filter
- Taylor blocked ipv6 by default for security reasons, so had to request to enable IPv6 for pinger in Taylor (INC0175010) - Karl
for taylor.opts on a linux server, I believe would look something like ipv6addr=2620:114:d000:25a1::80/64,2620:114:d000:25a1::1
- Modifications to the PAN rules - Kent
- It needed an IPv6 address in NetDB
It may seem to have an IPv6 address by looking at ifconfig you may see
Code Block eth0 Link encap:Ethernet HWaddr 00:50:56:BE:3D:4C inet addr:134.79.197.214 Bcast:134.79.197.255 Mask:255.255.255.128 inet6 addr: 2620:114:d000:2716:250:56ff:febe:3d4c/64 Scope:Global inet6 addr: fe80::250:56ff:febe:3d4c/64 Scope:Link
The global ipv6 address which is currently configured on this host is probably the slaac (auto-configured) from the router.
If the last couple octets look like a MAC address (versus zero or a very small number), then the address was almost certainly auto-configured.The other way to convince yourself is to look at the DNS record for the given system (e.g. “host www3”). If there is no IPv6 address displayed, then the address got autoconfigured.
Code Block 447cottrell@rhel6-64f:~$host www3 www3.slac.stanford.edu has address 134.79.197.214
If it does not have an IPv6 address then we have to assign one from the relevant range (e.g. for www3)
Code Block ksa@cdlogin3 $ /afs/slac/g/scs/net/bin/subnet all | grep SERV01-DMZ-WEBSERV 134.79.197.128 SERV01-DMZ-WEBSERV 134.79.197.129 255.255.255.128 Serv01 Web Servers DMZ (vlan 1814) 2620:114:d000:2716:: SERV01-DMZ-WEBSERV 2620:114:d000:2716::1 ffff:ffff:ffff:ffff:: Serv01 Web Servers DMZ (vlan 1814)
To test:
Code Block ksa@www3 $ curl -I -v www3 * About to connect() to www3 port 80 (#0) * Trying 2620:114:d000:2716::8... connected * Connected to www3 (2620:114:d000:2716::8) port 80 (#0) [?]
Modifications Required
pinger2.pl
Modified to enable both the hostname and IPv6 address to be the same. It is integrated with the new xml files generated from NODEDETAILS. It is backward compatible. Version >= 3.0 is IPv6 version.
traceroute.pl
Modified to make work on Solaris and Linux:
my $version="7.3, 12/13/2017, Les Cottrell";
# Added \[\] to untainting of dig command. Appears to be needed for IPv6.
# Do not avoid testing internal domains if server is IPv6 host,
# Added avoid calling gethostbyname6 if hostname is already an ipv6 address
# Fixed how Solaris mis-interprets system(@args) sometimes (saw in IPv6)
create-scriptTable.pl
We added the option --inet4-only to the wget command, else the cromjob timed out after 8550 seconds . when the tokens ran out.
getdata.pl
Created nodes-ipv6.pl to add the PingER IPv6 MA 2001:da8:270:2018:f816:3eff:fef3:bd3. See here for addition.
Copied getdata.pl to getdata-ipv6.pl and modified to use the /afs/slac/package/pinger/nodes-ipv6.cf file and write to the /nfs/slac/g/net/pinger/pingerdata/ipv6/data/ directory (e.g. /nfs/slac/g/net/pinger/pingerdata/ipv6/data/2001:da8:270:2018:f816:3eff:fef3:bd3/ping-2017-12-19.txt.gz) when running getdata-ipv6.pl 2001:da8:270:2018:f816:3eff:fef3:bd3 2017-12-19 1. Also replaced IPv4 address checks with sub chck_ip{} to test for both IPv4 and IPv6 addresses.
...
We added the option -
...
-prefer-family=ipv4 to the wget options. This redcuced the time for /afs/slac/package/pinger/getdata_all.pl -h pinger.slac.stanford.edu -D 0 from 190 seconds to 10 10 seconds.
10 seconds.
wrap-analyze-hourly.pl
Call with:
wrap-analyze-hourly.pl --
Call with:
wrap-analyze-hourly.pl --usemetric --dataset ipv6 --by by-node --size 100 --set_metric 3 --date 2017-12-19
...
/nfs/slac/g/net/pinger/pingerreports/<dataset>/<metrics>/<metric>-<size>-<by-node>-<yyyy><mm><dd>.txt.gzor more specifically /nfs/slac/g/net/pinger/pingerreports/ipv6/minimum_rtt/minimum_rtt-100-by-node-2017-12-19.txt.gz
We decided, initially to stick with a single data set (hep) and wrap-analyze-hourly now allows both IPv4 and IPv6 addresses by using the valid_ip function. Later we may also support a seprate ipv6 dataset.
The other analyze scripts (daily, monthly and yearly) did not need modification.
APEX/Oracle user interface to PingER NODEDETAILS database
This did not accept IPv6 Addresses, see INC0176849 and INC0176966. The NODEDETAILS Oracle Apex database now accepts IPv6 addresses as the name (in case there is no name for the host) and as the IP address. It is backward compatible and also (as before) accepts IPv4 addresses in both fields.
...
- To access the SLACPROD production copy of the NODEDETAILS database go to:
- To access the SLACDEV2 test copy of the NODETATILS database go to:
write_offssitenodes.pl
The script write_offsitenodes.pl creates the configuration file /afs/slac.stanford.edu/package/pinger/pinger2/share/pinger/pinger.xml for the SLAC MA.
We modified NodeIPCheck-new.pl to add a subroutine to use dig to find the IPv6 address of a host and also to validate the hostname and Iv6 address. These were used in script write_offsitenodes.pl.
node.pl
There were no changes.
IPv6 Targets
See Validating ICMP ping measurements against TCP nping measurements
One can use https://network-tools.webwiz.net/ping.htm to check if a target responds to IPv6 pings. As part of this we discovered that the SLAC border was blocking IPv6 pings (see INC0178575). This was fixed.
We started by adding ipv6.google.com(2607:f8b0:4007:802::200e) to NODEDETAILS in the SLACPROD database. After running
/afs/slac/package/pinger/guthrie/node.pl -o > /afs/slac/package/pinger/nodes.cf, we got the following in nodes.cf.
ping_data_plot.pl
Need to add a colon (: ) to the list of characters allowed by cgi-wrap. This goes in the rules file.
Typical PingER Raw Data
ipv6.google.com 2607:f8b0:4007:802::200e 56 1524939147 10 10 9.632 9.690 9.860 1 2 3 4 5 6 7 8 9 10 9.63 9.63 9.74 9.86 9.66 9.65 9.70 9.67 9.64 9.67
IPv6 Targets
See Validating ICMP ping measurements against TCP nping measurements
One can use https://network-tools.webwiz.net/ping.htm to check if a target responds to IPv6 pings. As part of this we discovered that the SLAC border was blocking IPv6 pings (see INC0178575). This was fixed.
We started by adding ipv6.google.com(2607:f8b0:4007:802::200e) to NODEDETAILS in the SLACPROD database. After running
/afs/slac/package/pinger/guthrie/node.pl -o > /afs/slac/package/pinger/nodes.cf, we got the following in nodes.cf.
| Code Block |
|---|
"ipv6.google.com" => [
"2607:f8b0:4007:802::200e |
| Code Block |
"ipv6.google.com" => [ "2607:f8b0:4007:802::200e", "Google.com", "Google.com", "COM.GOOGLE.IPV6", "GooglePlex", "Mountain View, California", "United States", "North America", "37.4220 -122.0841", "NOT-SET", "NOT-SET", "NOT-SET", "NOT-SET", "http://www.google.com", "", "", "", "", "Testing IPv6 support, add by Cottrell 1/31/2018.", ], |
...
This resulted in PingER's raw data measurements reporting::
| Code Block |
|---|
pinger.slac.stanford.edu 2620:114:d000:25a1::80 ipv6.google.com 2607:f8b0:4007:802::200e 100 1517962635 10 10 9.617 9.704 9.780
|
| Code Block |
pinger.slac.stanford.edu 2620:114:d000:25a1::80 ipv6.google.com 2607:f8b0:4007:802::200e 100 1517962635 10 10 9.617 9.704 9.780 2607:f8b0:4007:802::200e 2607:f8b0:4007:802::200e 100 1517962640 10 10 9.594 9.648 9.705 |
and automated daily email warnings of the form:
| Code Block |
|---|
/afs/slac/package/pinger/smokeping/SelectConvSrcDest1.pl --mon pinger.slac.stanford.edu #takes 520 mins (10/10/2011) produced the following output: decide_Action: create_File: start_Converting(37): add_ToRrd: warning: only min/avg/max in pinger.slac.stanford.edu 2620:114:d000:25a1::80 2607:f8b0:4007:802::200e 2607:f8b0:4007:802::200e 100 1517788034 1517962640 10 10 9.594519 9.648574 9.705619 , skipping pair |
Thus I added perfsonar-lt.cern.ch to NODEDETAILS. and gotand automated daily email warnings of the form:
| Code Block |
|---|
pinger.slac.stanford.edu 2620:114:d000:25a1::80 perfsonar-lt.cern.ch 2001:1458:301:a7bc::100:15 100 1518025122 10 10 151.850 152.004 152.372 1 2 3 4 5 6 7 8 9 10 152 151 151 151 152 151 151 151 152 151 |
For testing I also added 128.142.223.247 (the IPv4 address for perfsonar-lt.cern.ch) to NODEDETAILS. Finally I set the ping packet length for ipv6.google.com to 56Bytes in NODEDETAILS and now get the individual sequence of ping RTTs.
| Code Block |
|---|
/afs/slac/package/pinger/smokeping/SelectConvSrcDest1.pl --mon pinger.slac.stanford.edu #takes 520 mins (10/10/2011) produced the following output: decide_Action: create_File: start_Converting(37): add_ToRrd: warning: only min/avg/max in pinger.slac.stanford.edu 2620:114:d000:25a1::80 ipv6.google.com 2607:f8b0:4007:802::200e 2607:f8b0:4007:802::200e 100 1517788034 10 10 9.519 9.574 9.619 , skipping pair |
...
| Code Block |
|---|
56 1518450162 10 10 9.643 9.673 9.692 1 2 3 4 5 6 7 8 9 10 9.66 9.69 9.64 9.68 9.66 9.67 9.69 9.64 9.68 9.68 pinger.slac.stanford.edu 2620:114:d000:25a1::80 perfsonar-lt.cern.ch 2001:1458:301:a7bc::100:15 100 15180251222607:f8b0:4007:802::200e 2607:f8b0:4007:802::200e 56 1518450162 10 10 1519.850586 1529.004674 1529.372755 1 2 3 4 5 6 7 8 9 10 152 151 151 151 152 151 151 151 152 151 |
...
9.58 9.68 9.70 9.66 9.64 9.71 9.72 9.75 9.62 9.65 |
XML file at Guangzhou
See here. Currently, it contains random pingable IPv6 addresses as Saqib took it from http://www.ipv6forum.com/ipv6%5fenabled/approval%5flist.php. He proceeded as follows:
...