- NANOG - lists.nanog.org

Americas II Landing Station (Hollywood, Florida).
by Faisal Imtiaz 22 Mar '17

22 Mar '17

Hello, I am looking for a contact who may be able to help us with getting more info (on getting space/power) so that we can terminate our Dark Fiber transport there. Not sure who is responsible for this facility, most of the Tel# I am finding are disconnected. Many Thanks in advance. Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support(a)Snappytelecom.net

2 1

Re: Facebook more specific via Level3 ?
by Jürgen Jaritsch 22 Mar '17

22 Mar '17

Hi Mike, Im running some DNS on my own for a few hundred users from an private community project. But this issue is also affecting DNS from smaller/other ISPs which do NOT use any forwarder but the root DNS. Best regards Jürgen

1 0

Re: Facebook more specific via Level3 ?
by Jürgen Jaritsch 21 Mar '17

21 Mar '17

Hi, > This specific, and many others, are only announced to peers in the > metro they originate in. To receive this prefix directly you'll > need to peer with us in Los Angeles. the point is: Level3 is exporting this prefix to the EU since ~1 week Telia is learning it from Level3 and they also started to re-export it: Telia Looking Glass (http://lg.telia.net/?query=bgp&protocol=IPv4&addr=31.13.71.0/24+exact&route r=Vienna) Command: show route protocol bgp 31.13.71.36 table inet.0 31.13.71.0/24 *[BGP/170] 18w5d 16:40:16, MED 0, localpref 150 AS path: 3356 32934 I, validation-state: unverified > to 80.239.128.178 via ae9.0 This is causing >120ms latency to Austrian (and some German ...) networks towards Facebook - current traceroute from source network 188.172.239.0/24: Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. router 0.0% 4 0.5 0.5 0.5 0.6 0.0 2. 192.168.8.3 0.0% 4 0.6 0.7 0.6 0.8 0.1 3. 37.252.236.88 0.0% 4 37.3 34.2 30.6 37.3 2.9 4. er-03.00-09-23.anx04.vie.at.anexia-it.com 0.0% 4 21.1 31.9 21.1 50.9 13.3 5. cr-02.0v-08-72.anx03.vie.at.anexia-it.com 0.0% 4 23.2 25.9 20.4 31.6 5.1 6. win-b4-link.telia.net 0.0% 4 22.1 25.0 22.1 30.1 3.5 7. level-ic-1573273-wien-b4.c.telia.net 0.0% 3 22.4 22.3 21.1 23.3 1.1 8. ae-3-3611.edge2.dallas1.level3.net 0.0% 3 150.5 150.6 150.4 150.8 0.2 9. facebook-in.edge2.dallas1.level3.net 0.0% 3 156.6 152.9 151.0 156.6 3.2 10. po102.psw02.dft4.tfbnw.net 0.0% 3 151.4 151.6 151.4 152.0 0.4 11. 173.252.67.57 0.0% 3 151.6 152.3 151.6 153.4 0.9 12. edge-star-mini-shv-01-dft4.facebook.com 0.0% 3 159.3 158.4 152.5 163.6 5.6 The admins of AS42473 started to drop the more specific from Level3 and now they get it from Telia (which is the Level3 re-export they learned). I guess you guys should talk to Level3 and ask them what the hell they are doing? :). Thanks & best regards Jürgen

2 2

Google G Suite Email Contact
by Jason Canady 20 Mar '17

20 Mar '17

Is anyone here from Google's G Suite or email department? I recently acquired a brand who's domain is being blocked by Google Mail ("G Suite"). I have followed all of the steps to be compliant (SPF and DKIM), but email is still going into customer's Spam folder at Google. There is not a massive amount of emails sent, just basic communication such as monthly invoices, support tickets, etc. If anyone has a contact, please share it with me on or off list. I would greatly appreciate it. Thank you! Jason Canady Unlimited Net, LLC

2 1

BGP Route Reflector - Route Server, Router, etc
by Justin Krejci 20 Mar '17

20 Mar '17

Nanog, I am working on some network designs and am adding some additional routers to a BGP network. I'd like to build a plan of changing all of the existing routers over from full iBGP mesh to something more scalable (ie route reflection). Fortunately, I am also going to be able to decommission some older routers from the network and so shrinking the existing iBGP full mesh is something I am all too happy to spend time and energy on. For the purpose of this thread though, I am not really interested in the route reflector vs confederation discussion. In doing some research[1][2][3][4][5] I see a lot of discussions, config examples, etc on using route reflectors but most suggest picking a router, or more appropriately a set of routers, to become route reflectors within an ASN. I have not found many resources discussing using a non-router box as a route reflector (ie a device not necessarily in the forwarding path of the through traffic). I am thinking things like OpenBGPd and BIRD could make a good route reflector though they are most often discussed in the context of IXPs (ie eBGP sessions). I am wondering if people can point me in the direction to some good resource material on how to select a good BGP route reflector design. Should I just dust off some 7206VXR routers to act as route reflectors? Use a few existing live routers and just add the responsibility of being route reflectors, is there a performance hit? Install and run BIRD on new server hardware? Buy some newer purpose built routers (Cisco, Juniper, Brocade, etc) to act as route reflectors and add them to the iBGP topology? GNS3 running IOS on server hardware? Something else? How many reflectors should be implemented? Two? Four? What are the pros and cons of one design over another? On list or private off list replies would be great; I'd welcome real world experiences (especially any big gotchas or caveats people learned the hard way) as well as just links to previous discussions, PDFs, slideshows, etc. Heck even a good book suggestion that covers this topic would be appreciated. [1] - iBGP-to-RR migration slideshow: http://meetings.ripe.net/ripe-42/presentations/ripe42-eof-bgp/sld015.html [2] - General RR design issues: http://www.netcraftsmen.com/bgp-route-reflector-design-issues/ [3] - Video intro to RR from Cisco: http://www.cisco.com/c/dam/en_us/training-events/le31/le46/cln/qlm/CCIP/bgp… [4] - Quagga and BIRD as RR example: https://bsdrp.net/documentation/examples/bgp_route_reflector_and_confederat… [5] - Countless hours on youtube: https://www.youtube.com/results?search_query=bgp+route+reflector Lots more data is out there of course as that is part of my problem. Thanks! Justin

17 21

ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations
by Eygene Ryabinkin 20 Mar '17

20 Mar '17

We (at Kurchatov Insitute) still use 144.206.0.0/16, the legacy block, and seeing the breakage rooted at ARIN since this night, {{{ $ dig +trace -t soa 206.144.in-addr.arpa ; <<>> DiG 9.10.4-P6 <<>> +trace -t soa 206.144.in-addr.arpa ;; global options: +cmd . 206351 IN NS a.root-servers.net. . 206351 IN NS c.root-servers.net. . 206351 IN NS d.root-servers.net. . 206351 IN NS e.root-servers.net. . 206351 IN NS l.root-servers.net. . 206351 IN NS f.root-servers.net. . 206351 IN NS g.root-servers.net. . 206351 IN NS h.root-servers.net. . 206351 IN NS j.root-servers.net. . 206351 IN NS m.root-servers.net. . 206351 IN NS k.root-servers.net. . 206351 IN NS i.root-servers.net. . 206351 IN NS b.root-servers.net. . 514733 IN RRSIG NS 8 0 518400 20170329170000 20170316160000 61045 . OjsjoA6WCcThV3BqhAyMaXI3bU1m228Gl8nvaR074qBtem/RjaFJh1Oe r7LPI6W15jgbRGuCY7/GUNgDex4ZM43yvx2iY+2GpSk9b2/pKGbDaDIp X1Hd8418206eow1P/SgPqtT+2LzjM+lz/HKUvCyPoN4uX5/7GDExn8ir 2Q/vw81Za2nJ4Ji6oeGAmE8g6V3RJfTI0El/CP9Vl2/r0jWDZZ+wtYRA uwqvQYj+7VZc5+UJDJ3/Gne1LBnzXKnZRwnfJtZenhfZ7X20D9PiXvfJ M2s1ryqZvg8K5RqYt/r8pIiq1Udd1KWQBgdN7Q629+jNSngZQtH19R9H fM7h1w== ;; Received 1097 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms in-addr.arpa. 172800 IN NS e.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS f.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS d.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS c.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS b.in-addr-servers.arpa. in-addr.arpa. 172800 IN NS a.in-addr-servers.arpa. in-addr.arpa. 86400 IN DS 53696 8 2 13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF in-addr.arpa. 86400 IN DS 63982 8 2 AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73 in-addr.arpa. 86400 IN DS 47054 8 2 5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2 in-addr.arpa. 86400 IN RRSIG DS 8 2 86400 20170330000000 20170316230000 33786 arpa. gqNN6MmLVxFtSG0oxdyoYVSXZlp6vY9yxpnJW89TYCHfTkv+ZmklM76O IHdTznEhLHXbyr4BaxjFCshsC3WacdH/YZYa/SZynJ9Q1N6/bogrIUTn qs61Y/YD4Sk5lI7YvUxVnPrF3lk1pY8dpoTkprTLZngoeQEsm552inqG ypU= ;; Received 733 bytes from 198.41.0.4#53(a.root-servers.net) in 64 ms 144.in-addr.arpa. 86400 IN NS r.arin.net. 144.in-addr.arpa. 86400 IN NS u.arin.net. 144.in-addr.arpa. 86400 IN NS x.arin.net. 144.in-addr.arpa. 86400 IN NS y.arin.net. 144.in-addr.arpa. 86400 IN NS z.arin.net. 144.in-addr.arpa. 86400 IN NS arin.authdns.ripe.net. 144.in-addr.arpa. 86400 IN DS 62856 5 1 484154736CF9D4DC4F1C2B807BDC06E5B1645AFF 144.in-addr.arpa. 86400 IN RRSIG DS 8 3 86400 20170328085556 20170307105911 4341 in-addr.arpa. X3nPKgjQbRef6BxK3msEXi/IcfpG1rylY2xeWwfNO6fJB5x/QT38ZCA5 XMs6CBeXb59tpQFbgjwZX+prqSpjGFtZ+phFuzsaGmuPOF0FFypMHj7F swykEFvaPY5z4d8mo9FKFJetF2gZfzYthwJWW0x2oo2H2BG0lEedVUCb 1aGs/HE= ;; Received 380 bytes from 193.0.9.1#53(f.in-addr-servers.arpa) in 48 ms 144.in-addr.arpa. 0 IN SOA z.arin.net. dns-ops.arin.net. 2017022432 1800 900 691200 10800 144.in-addr.arpa. 0 IN RRSIG SOA 5 3 86400 20170331083220 20170317073220 33345 144.in-addr.arpa. k2sZXuQQR3MyyRiB9Wd7fw45yZTbNokjQtFFNY+aCEa/85AnSyuomLlZ jZs4A0bO376/Z1v+bTHoeFqsyHr/xuWHX74r0QC/TCeP0amc+w8RqCvw Yox1TfoJxwhblGNRCgyLw52WszMYyr49EfWPfpHAKFU+G94gdilf3C6x GOM= 144.in-addr.arpa. 10800 IN NSEC 0.144.in-addr.arpa. NS SOA RRSIG NSEC DNSKEY 144.in-addr.arpa. 10800 IN RRSIG NSEC 5 3 10800 20170331083220 20170317073220 33345 144.in-addr.arpa. opvG8SC7+UjHSTtBBtekWNkhLFMIxFxOdejJ7sM7t8lyGNzM6sOABeSI ADXfo8q3p4YFBHgBU5fRCAhBdiQ/AiZC0dLMnHb4WdKEv5bDsBbq5Pt6 vabJaIv7Gizw7kBy1JZ/ZrC4Jmp4EX0HiYA+Ak+aQggD7gdI/6tFDNpl N7M= 205.144.in-addr.arpa. 10800 IN NSEC 207.144.in-addr.arpa. NS RRSIG NSEC 205.144.in-addr.arpa. 10800 IN RRSIG NSEC 5 4 10800 20170331083220 20170317073220 33345 144.in-addr.arpa. F1e5mA7C3Mx10YSaNtshzfzfER8pudDOQkUoe+jeDhHeDZeR8FM1FoqW dqrNh5X6JVNlTdWGio6evnSkxnaoJFYyeYJtc+tJ8dTd5APJxJCSOfhH VfRNy7VHs2PdElRo1rRwMw+5Zncc0u8uPdmFDv2ZG8Vv3zj5C6l7rMla 3SA= ;; Received 718 bytes from 199.212.0.63#53(z.arin.net) in 128 ms }}} Seems like the other /16 from 144.in-addr.arpa are affected too (at least). ARIN tickets are engaged, but I am seeking some live person: having the whole reverse zone being unavailable isn't the stuff that is to be handled in 5x8 or alike. If anybody knows what happened, can point me to my errors in assertions or give an e-mail/phone of 24x7-like person or service at ARIN -- will be tremendous. Thanks! -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

15 31

AS 9583 (Sify Corp) contact required
by Scott Larson 20 Mar '17

20 Mar '17

Beginning at 10am UTC today, AS 9583 began announcing routes for our (AS 40041) IP space, the most significant damage of which has so far been caused in the UK. We're currently playing whack-a-mole on an ISP and exchange level, but having zero luck tracking down a contact capable of a proper resolution to this issue. Please contact me off list if you are that person or know who they are. *[image: userimage]Scott Larson[image: los angeles] <https://www.google.com/maps/place/4216+Glencoe+Ave,+Marina+Del+Rey,+CA+9029…>Lead Systems Administrator[image: wdlogo] <https://www.wiredrive.com/> [image: linkedin] <https://www.linkedin.com/company/wiredrive> [image: facebook] <https://www.twitter.com/wiredrive> [image: twitter] <https://www.facebook.com/wiredrive> [image: instagram] <https://www.instagram.com/wiredrive>T 310 823 8238 <310%20823%208238%20x1106> *

1 0

Purchased IPv4 Woes
by Pete Baldwin 20 Mar '17

20 Mar '17

Hi All, Hopefully this is not taken in bad taste. Our organization purchased some IP space last year (163.182.192.0/18 to be specific), and it appears that this block must have been used for less-than-admirable purposes in the past. We have been trying to clean up the reputation where possible, and we do not appear to be on any blacklists, but we do appear to be blocked from a lot of networks across the US/Canada. I am noticing a lot of name servers blocking our requests, many web servers, gaming servers, mail etc. This is a transition block for us to move towards v6 everywhere, but we have many systems that will need to rely on this block of space for some time to come. We are a small rural co-op ISP in Ontario, and I am just writing this email as an extra plea so that if you happen to run a network that has this entire range on your naughty list, we would appreciate you giving it another chance. I can be contacted on or off list, thanks. -- ----- Pete Baldwin Tuckersmith Communications (P) 519-565-2400 (C) 519-441-7383

24 46

IPv6 oddness in Comcast land...
by valdis.kletnieks＠vt.edu 20 Mar '17

20 Mar '17

Trying to figure out what the heck is going on here. Any good explanations cheerfully accepted. Background: Home internet router is a Linksys WRT1200AC that had been running OpenWRT 15.05.01. IPv6 worked just fine - Comcast handed me a /60 via DHCP-PD and no issues. I reflashed it to Lede 17.01, and after doing all the reconfig, I'm hitting a really strange IPv6 issue. Symptoms - IPv6 still configures correctly, but IPv6 packets appear to go out and disappear into the ether when they leave the Linksys. Doing a traceroute to any IPv6 destination makes things work again - for a while (from 15 minutes to an hour or two). As seen from my laptop (I have the matching tcpdump from the outbound interface on the Linksys): [~] ping -6 -c 3 listserv.vt.edu PING listserv.vt.edu(listserv.ipv6.vt.edu (2001:468:c80:2105:211:43ff:feda:d769)) 56 data bytes --- listserv.vt.edu ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2070ms [~] traceroute -6 listserv.vt.edu traceroute to listserv.vt.edu (2001:468:c80:2105:211:43ff:feda:d769), 30 hops max, 80 byte packets 1 2601:5c0:c001:69e2::1 (2601:5c0:c001:69e2::1) 2.417 ms 3.077 ms 5.358 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * hu-0-10-0-7-pe04.ashburn.va.ibone.comcast.net (2001:558:0:f5c1::2) 31.478 ms 31.975 ms 7 2001:559::d16 (2001:559::d16) 32.406 ms 17.102 ms 24.751 ms 8 2001:550:2:2f::a (2001:550:2:2f::a) 23.245 ms 23.519 ms 22.185 ms 9 2607:b400:f0:2003::f0 (2607:b400:f0:2003::f0) 29.782 ms 28.604 ms 29.891 ms 10 2607:b400:90:ff05::f1 (2607:b400:90:ff05::f1) 30.423 ms * 30.680 ms 11 * * * 12 listserv.ipv6.vt.edu (2001:468:c80:2105:211:43ff:feda:d769) 34.562 ms 39.072 ms 24.633 ms [~] ping -6 -c 3 listserv.vt.edu PING listserv.vt.edu(listserv.ipv6.vt.edu (2001:468:c80:2105:211:43ff:feda:d769)) 56 data bytes 64 bytes from listserv.ipv6.vt.edu (2001:468:c80:2105:211:43ff:feda:d769): icmp_seq=1 ttl=53 time=33.3 ms 64 bytes from listserv.ipv6.vt.edu (2001:468:c80:2105:211:43ff:feda:d769): icmp_seq=2 ttl=53 time=24.3 ms 64 bytes from listserv.ipv6.vt.edu (2001:468:c80:2105:211:43ff:feda:d769): icmp_seq=3 ttl=53 time=46.0 ms --- listserv.vt.edu ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 24.334/34.595/46.093/8.927 ms So it looks like something times out somewhere and fails to pass packets back. TCP connections don't keep IPv6 alive. I have a browser window that auto-updates every 5 minutes, and a SmokePing process on a Raspberri Pi uploads to a server at work every few minutes, and those eventually drop back to IPv4 when the IPv6 TCP fails to connect. And normal UDP doesn't seem to keep it alive - NTP pointing at IPv6 peers loses connectivity as well. But a traceroute wakes it up. It's almost like some router is losing the route to me out of the FIB, and fixes it when it has to handle a packet on the CPU slow path (like send back a 'time exceeded'). But I'm mystified why this started when I reflashed my router.

2 1

difference with caching when connected to telia internet
by Aaron Gould 18 Mar '17

18 Mar '17

Regarding, caching services like Netflix OCA and Google GGC, does anyone know if there is something strange that occurs when connected to Telia BGP AS1299 ? .meaning, if I have local Netflix/google caches, and then later I establish a BGP session for Internet with Telia/BGP 1299, would there be something that would make netflix and google caches reachable via Telia look better than my local ones ?! -Aaron

6 9