- Test - lists.nanog.org

route-views.chicago.routeviews.org
by John Kemp 30 Jun '16

30 Jun '16

As mentioned at the peering personals... route-views.chicago.routeviews.org is now up and running. New peers are welcomed. We request full tables if possible. We send zero back in your direction. Peers should minimally filter default/null/rfc1918 from their view. Our side is: AS6447 206.223.119.187 2001:504:0:4::6447:1 telnet://route-views.chicago.routeviews.org {http/ftp/rsync}://archive.routeviews.org/route-views.chicago A huge thanks to our host, CTS Telecom. Those guys really made it happen. And as always, a huge thanks to Equinix. We could not make this all happen without the help of our hosts and the exchanges, so thanks to all. -- John Kemp RouteViews Network Engineer help(a)routeviews.org

1 0

automated site to site vpn recommendations
by c b 30 Jun '16

30 Jun '16

Situation: We have salespeople/engineers holding temporary seminars/training/demonstrations in hotel meeting rooms. Requirements: field people need a very plug-n-play, simple, reliable vpn back to corporate offices to present videos/slides/demonstrations. The materials are not accessible via the internet directly, they are in a contained environment at corporate HQ locations but not necessarily on the corp network.the solution should be able to provide wireless to attendees. In some cases, guest login will be fine but in some cases the attendees will have registered and provided login creds prior to the event, and these creds will need to be checked before providing accessthe solution should have the option to split tunnel internet traffic out, but in some cases they need all traffic tunneled and internet will be via our corporate offices (NDA/legal, don't ask, it's just a requirement provided) Nice-to-have: field person should be able to not only access the presentation materials (in their contained network) but also the corporate network. Some early attempts required a user-vpn connection by the field person over the S2S VPN, but it made it clunky to switch back and forth. This isn't mandatory, but it would be nice to provide one solution providing dual-level access: restricted to attendees, less-restricted to field people Tried this in the past with basic router/switch/wireless and captive portals because we had some inventory available... it was workable but not quick or easy. We really could use a simple solution that you just flip on, it calls home, and works... or as close to that as possible. Have been looking at Meraki and a couple other low-touch solutions and they may do the trick, but we are hoping there are lower cost options that people have used successfully? We don't mind dealing with some off brands and even some custom coding (within reason) as long as the end result is a low-touch, reliable solution. Thanks in advance.

14 16

Malware/ransomware current live distribution points
by Ronald F. Guilmette 30 Jun '16

30 Jun '16

The various domains and IP address listed in the following file are, as we speak, acting as distribution/infection points for some sort of Javascript malware which is almost certainly a flavor of ransomware. ** FAIR WARNING *** Please use exceptional caution when browsing to any of the domains listed within the following file. Doing so with a vlunerable browser and/or from a vulnerable platform is likely to cause encryption of your entire harddrive. Such encryption may perhaps be irreversable without paying a ransom. ftp://ftp.tristatelogic.com/pub/cases/295165/20160629-0.txt I am including below the same information as is present within the above referenced file, but without the associated domain names. I do this in order to avoid having this message improperly filtered, as it might be, by some of the spam filters being used by some of the people who really should see this message. (But the domain names are all readily available in the above file.) Note that the domain names involved in this particular set of malware distributors are all third-level .COM domains, and that in all cases, the actual text of the first (leftmost) of the three domain name labels is irrelevant and can be replaced by any other valid domain name label because the second level domains have all been wildcarded in the DNS. The following list has been sorted numerically, based on the AS number. RIR ASN IP address -------------------------- RIPE 16276 188.165.62.14 RIPE 16276 5.196.36.42 ARIN 19531 155.94.69.167 ARIN 19757 107.155.188.126 ARIN 33182 184.171.243.123 ARIN 33182 184.171.243.81 ARIN 33182 198.136.53.210 ARIN 46562 107.181.174.10 RIPE 47583 195.110.58.82 RIPE 50673 217.12.208.160 RIPE 50979 195.123.209.55 RIPE 51852 141.255.161.67 RIPE 52048 46.183.216.167 RIPE 56322 91.219.237.211 RIPE 56577 31.41.44.155 RIPE 59432 5.134.117.190 RIPE 59729 185.82.216.204 RIPE 62240 185.120.20.107 APNIC 63912 111.221.44.152 RIPE 201133 82.118.226.13 If you are an administrator of one of the above listed ASNs, or if you know someone who is, please spend a few minutes and help get this hostile trash off the Internet. Thank you. Regards, rfg P.S. Those who do elect to browse to the domains listed in the file cited above, and so do so without getting infected, will notice that the underyling actual web sites are all identical, and are all selling a completely bogus diet supplement called "CLA Safflower Oil". It is unclear at this time whether the criminals behind these IPs and domains are making more money from their ransomware extortion racket, or from selling this bogus diet supplement to naive idiots.

1 0

Fwd: [v6ops] RFC 7872 on Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World
by Fernando Gont 28 Jun '16

28 Jun '16

FYI -------- Forwarded Message -------- Subject: [v6ops] RFC 7872 on Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World Date: Tue, 21 Jun 2016 16:57:35 -0700 (PDT) From: rfc-editor(a)rfc-editor.org To: ietf-announce(a)ietf.org, rfc-dist(a)rfc-editor.org CC: v6ops(a)ietf.org, rfc-editor(a)rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7872 Title: Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World Author: F. Gont, J. Linkova, T. Chown, W. Liu Status: Informational Stream: IETF Date: June 2016 Mailbox: fgont(a)si6networks.com, furry(a)google.com, tim.chown(a)jisc.ac.uk, liushucheng(a)huawei.com Pages: 15 Characters: 30924 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-ipv6-ehs-in-real-world-02.txt URL: https://www.rfc-editor.org/info/rfc7872 DOI: http://dx.doi.org/10.17487/RFC7872 This document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time. This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor(a)rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ v6ops mailing list v6ops(a)ietf.org https://www.ietf.org/mailman/listinfo/v6ops -- Fernando Gont e-mail: fernando(a)gont.com.ar || fgont(a)si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

1 0

Level 3 Technical Contact
by David Nelson 28 Jun '16

28 Jun '16

Please contact me off list if you have a contact at Level 3 that can help. I have performance issues coming out of Las Vegas and ditching routes to Level 3 seems to fix the problem. Has anyone else seen/heard about problems in US Southwest?

1 0

Real world power consumption of a 7604-S or 7606-S
by Eric Kuhnke 28 Jun '16

28 Jun '16

I'm finding that the spec sheet for an RSP720-3CXL says 310W for the supervisor itself. Assuming a dual supervisor configuration in a 7604 or 7606, has anyone put one on a watt meter and measured its actual power consumption? Example: 7604S chassis with dual 2700W DC power - chassis and fans use how much power? 2 x RSP720-3CXL at 310W each WS-X6704 with DFC4 - ???W each

4 4

Cisco 2 factor authentication
by Ray Ludendorff 27 Jun '16

27 Jun '16

Has anyone setup two factor VPN using a Cisco ASA VPN solution? What sort of soft client based dual factor authentication options were used for the Cisco VPNs (e.g. Symantec VIP, Google authenticator, Azure authenticator, RSA, etc.) I am trying to find what infrastructure is needed to come up with the solution. Please contact me of list Regards Ray Ludendorff

6 5

Quick question regarding: Problematic IPv6 Multicast traffic within an IX.
by Bob Evans 26 Jun '16

26 Jun '16

Is it true that managed Layer2 switches used by IX's can not block IPv6 multicast ingress port traffic from broadcasting to all ports ? ___Yes , seen many IXs with IPv6 multicast continuing yet IPv4 multicast is blocked. ___No , All should be able to bock IPv6 multicast. ___Only a few specific managed switch manufacturers have this issue with IPv6 multicast broadcasting. You're knowledge on this problem would be helpful. Thank You in advance. Bob Evans CTO

5 4

measuring effects of happy eyeballs
by Bajpai, Vaibhav 25 Jun '16

25 Jun '16

Dear NANOG, A paper on measuring the effects of happy eyeballs [RFC 6555] just got accepted last week. This uses a 3-years long ('13 - '16) dataset of TCP connect times towards ALEXA top 10K websites collected from 80 dual-stacked SamKnows probes. We just released [a] the paper. Thought to share it along: [a] http://goo.gl/JmKEax Feedback most welcome! You may recall preliminary versions of this work at RIPE 66 [b] and IETF 87 [c]. [b] https://ripe66.ripe.net/archives/video/1208 [c] https://vimeo.com/71407427 Measuring the Effects of Happy Eyeballs --------------------------------------- The IETF has developed protocols that promote a healthy IPv4 and IPv6 co-existence. The Happy Eyeballs (HE) algorithm, for instance, prevents bad user experience in situations where IPv6 connectivity is broken. Using an active test (happy) that measures TCP connection establishment times, we evaluate the effects of the HE algorithm. The happy test measures against ALEXA top 10K websites from 80 SamKnows probes connected to dual-stacked networks representing 58 different ASes. Using a 3-years long (2013 - 2016) dataset, we show that TCP connect times to popular websites over IPv6 have considerably improved over time. As of May 2016, 18% of these websites are faster over IPv6 with 91% of the rest at most 1 ms slower. The historical trend shows that only around 1% of the TCP connect times over IPv6 were ever above the HE timer value (300 ms), which leaves around 2% chance for IPv4 to win a HE race towards these websites. As such, 99% of these websites prefer IPv6 connections more than 98% of the time. We show that although absolute TCP connect times (in ms) are not that far apart in both address families, HE with a 300 ms timer value tends to prefer slower IPv6 connections in around 90% of the cases. We show that lowering the HE timer value to 150 ms gives us a margin benefit of 10% while retaining same preference levels over IPv6. Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany ===================================

1 0

colo at 111 8th ave NY?
by Sean Watkins 25 Jun '16

25 Jun '16

Hi, I'm looking for a rack or half rack at 111 8th ave NYC. I've tried going via sales at Equinix etc and few other carriers, it seems to never go anywhere... Can anyone who is there, and wants to sell some space contact me off list? thanks Sean -- -- Sean Watkins 403-629-6152

2 1