June 2016 - Test - lists.nanog.org

Extra Fairmont Rooms
by Brandon Ross 09 Jun '16

09 Jun '16

I've ended up with some extra room reservations at the Fairmont Chicago. If you can make use of any of these reservations, send me a direct email with the name you'd like me to put on the room. First come, first served, so if your primary choice(s) aren't available, let me know if you have a second choice. I'll reply with the confirmation number so you can call the hotel and guarantee the room with your credit card. 6/16-17 $242 Fairmont Room with King Bed 6/11-17 $299 Deluxe Room with King Bed 6/15-16 $278 Fairmont PURE Room King NS 6/15-16 $260 Fairmont Double/Double NS -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross

1 0

Monitoring system recommendation
by Manuel Marín 09 Jun '16

09 Jun '16

Dear Nanog community We are currently planning to upgrade our monitoring system (Opsview) due to scalability issues and I was wondering what do you recommend for monitoring 5000 hosts and 35000 services. We would like to use a monitoring system that is compatible with the nagios plugin format, however we are not sure if systems like Icinga/Shinken/Op5 are the way to go. Is someone using systems like Op5 or Icinga2 for monitoring > 5000 hosts? Would you recommend commercial systems like Sevone, Zabbix, etc instead of open source ones? Your input is really appreciated it Thank you and have a great day Regards

12 11

RE: Webmail / IMAPS software for end-user clients in 2016
by Coy Hile 08 Jun '16

08 Jun '16

I like horde (with dove cot doing imaps) because it speaks ActiveSync natively. Sent via the Samsung GALAXY S® 5, an AT&T 4G LTE smartphone -------- Original message -------- From: alvin nanog <nanogml(a)mail.ddos-mitigator.net> Date: 6/8/2016 21:37 (GMT-05:00) To: eric.kuhnke(a)gmail.com Cc: nanog(a)nanog.org Subject: Re: Webmail / IMAPS software for end-user clients in 2016 > > hi ya > > On 06/08/16 at 06:06pm, Eric Kuhnke wrote: >> If you had to put up a public facing webmail interface for people to use, >> and maintain it for the foreseeable future (5-6 years), what would you use? >> >> Roundcube? >> https://roundcube.net/ > - good > >> Rainloop? >> http://www.rainloop.net/ > - never used > - w/o db support, how you maintain a (real) list of x,000 users and pwd > >> Something else? > > http://squirrlemail.org > - good > > http://openwebmail.org/ > - least effort to get webmail running ( esp if time is limited ) > > http://horde.org > - possibly confusing install process > > --------- > imaps from doveocot.org > ( note differences between dovecot-1.x vs dovecot-2.x ) > >> Requirements: >> Needs to be open souce and GPL, BSD or Apache licensed >> >> Email storage will be accessed via IMAP/TLS1.2 >> >> Runs on a Debian based platform with apache2 or nginx >> >> Desktop browser CSS and mobile device CSS/HTML functionality on 4" to 7" >> size screens with Chrome and Safari > > - you probably want support for your favorite sql app > - you probably want support for your favorite anti-virus app > - you probably want support for your favorite anti-spam app > > http://networknightmare.net/WebMail/ > > magic pixie dust > alvin > # DDoS-Mitigator.net > # >

1 0

Bogon ASN Filter Policy
by Job Snijders 08 Jun '16

08 Jun '16

Dear fellow network operators, In July 2016, NTT Communications' Global IP Network AS2914 will deploy a new routing policy to block Bogon ASNs from its view of the default-free zone. This notification is provided as a courtesy to the network community at large. After the Bogon ASN filter policy has been deployed, AS 2914 will not accept route announcements from any eBGP neighbor which contains a Bogon ASN anywhere in the AS_PATH or its atomic aggregate attribute. The reasoning behind this policy is twofold: - Private or Reserved ASNs have no place in the public DFZ. Barring these from the DFZ helps improve accountability and dampen accidental exposure of internal routing artifacts. - All AS2914 devices support 4-byte ASNs. Any occurrence of "23456" in the DFZ is a either a misconfiguration or software issue. We are undertaking this effort to improve the quality of routing data as part of the global ecosystem. This should improve the security posture and provide additional certainty [1] to those undertaking network troubleshooting. Bogon ASNs are currently defined as following: 0 # Reserved RFC7607 23456 # AS_TRANS RFC6793 64496-64511 # Reserved for use in docs and code RFC5398 64512-65534 # Reserved for Private Use RFC6996 65535 # Reserved RFC7300 65536-65551 # Reserved for use in docs and code RFC5398 65552-131071 # Reserved 4200000000-4294967294 # Reserved for Private Use RFC6996 4294967295 # Reserved RFC7300 A current overview of what are considered Bogon ASNs is maintained at NTT's Routing Policies page [2]. The IANA Autonomous System Number Registry [3] is closely tracked and the NTT Bogon ASN definitions are updated accordingly. We encourage network operators to consider deploying similar policies. Configuration examples for various platforms can be found here [4]. NTT staff is monitoring current occurrences of Bogon ASNs in the routing system and reaching out to impacted parties on a weekly basis. Kind regards, Job Contact persons: Job Snijders <job(a)ntt.net>, Jared Mauch <jmauch(a)us.ntt.net>, NTT Communications NOC <noc(a)ntt.net> References: [1]: https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 [2]: http://www.us.ntt.net/support/policy/routing.cfm#bogon [3]: https://www.iana.org/assignments/as-numbers/as-numbers.xhtml [4]: http://as2914.net/bogon_asns/configuration_examples.txt

8 7

Re: Netflix VPN detection - actual engineer needed
by Baldur Norddahl 08 Jun '16

08 Jun '16

On 2016-06-08 17:20, Javier J wrote: > > Maybe I missed the start of this conversation but why are we talking > about blocking Netflix? > By blocking the netflix.com IPv6 prefix your browser will automatically fall back to IPv4 because it is using the Happy Eyeballs algorithm.

1 0

Traffic engineering and peering for CDNs
by Graham Johnston 08 Jun '16

08 Jun '16

Lately I have been putting in some effort to maximize our IX connections by trying to work with the top 5-ish list of ASNs that still send us traffic via a paid transit connection despite the fact that we are both present on the same IX(s). In one case I missed the fact that one ASN wasn't using the IXs route-servers, that's on me for not spotting that one. Even with proper IX peering in place though it seems like some CDNs are better at using the IX connections than others. ASN 15169 for instance does an excellent job sending more than 99.99% of traffic via the IX connection; thank you. While others only seem to manage to send 60 - 80% of traffic via the IX. What I am not understanding about the respective CDN's network wherein they don't send traffic to me through a consistent path? Is the content coming from widely different places and rather than transport it across their own network from a remote site they would rather hot-potato it out a local transit connection? Are their transit costs so low that they don't care about using an IX connection over transit unlike a small operator like me? Is this just a non-obvious issue wherein they maybe just can't originate enough of the traffic near the IX and therefore don't make use of the IX connection, again a hot-potato phenomenon? Secondly can someone explain to me why some CDNs want a gigabit or two of traffic to be exchanged between our respective networks before they would peer with me via a public IX? I totally get those kinds of thresholds before engaging in a private interconnect but I don't understand the reluctance with regard to a public IX, that they are already established at. Is it again just a simple case of bandwidth economics that operate at a different scale than I can comprehend? I'm hoping the community can shed some light on this for me as I'm trying to avoid grilling the operators that are working with me as I don't expect those front line individuals to necessarily have a full view of the factors at play. Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong(a)westmancom.com<mailto:johnstong@westmancom.com> P think green; don't print this email.

8 7

IPv6 is better than ipv4
by Ca By 07 Jun '16

07 Jun '16

https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-wh… Wherein akamai explains a detailed study showing ipv6 is "well over 10%" faster than ipv4 on mobile, and they reference corroborating studies from Linkedin and Facebook. Fair to ask your business 1) does mobile performance matter 2) are you taking advantage of this 10% page load speedup that ipv6 provides?

17 28

Re: Netflix VPN detection - actual engineer needed
by Baldur Norddahl 07 Jun '16

07 Jun '16

> And they could easily redirect HE IPv6 addresses to a IPv4 only > service. This would satify both the content providers and the > customers. It's not like there tunneled traffic is IPv6 only as > there has to be a IPv4 endpoint for the tunnel. > > You can't argue that HE is too small to do this for as they are > targeting HE tunnels. > > Mark And while we wait for Netflix to do that, you could also turn off ipv6 on your Netflix watching device as a quick fix. Most smart tv do not support it to start with. It is a bit surprising that your browser would choose the ipv6 path via tunnel over the more direct ipv4 path. Anyway, you could blackhole the Netflix ipv6 prefix to force the situation. Or you could get your own /48 prefix and announce via BGP. Might not be free but comes with other advantages and has some coolness factor. Or turn off the tunnel while you watch Netflix. Lots of options for "can do" people. Yes we all hate geo ip solutions but this particular Netflix issue is not a big thing in the grand scheme of things. Regards Baldur

2 1

Re: Netflix VPN detection - actual engineer needed
by Mark Felder 07 Jun '16

07 Jun '16

On Mon, Jun 6, 2016, at 13:09, Brandon Jackson wrote: > Looking up your tunnels block in ARIN will only show HE's Info. > > Using HE's rwhois http://rwhois.he.net/whois.php > > Shows the information provided by the tunnel user at time of signup or as > modified in account settings. > Ahh, correct. This way is showing it for me. I should have known to use their rwhois. -- Mark Felder feld(a)feld.me

11 11

any way to deal with google's captcha for whole /21 v4?
by Dmitry Sherman 06 Jun '16

06 Jun '16

Hello dear Nanog group, Any suggestions how to deal with Google captcha for whole /21 ipv4 newly acquired block? Every IP from the prefix getting blocked by Captcha which never resolves. Thanks in advance. — Dmitry Sherman Interhost Networks Ltd dmitry(a)interhost.net office: 972-74-7029881 mobile: 972-54-3181182 http://www.interhost.co.il

2 1