- Test - lists.nanog.org

Re: Companies using public IP space owned by others for internal routing
by Scott Weeks 21 Dec '17

21 Dec '17

--- owen(a)delong.com wrote: From: Owen DeLong <owen(a)delong.com> > But I'd argue that if I have personal nanotech, I *really* want > to use ULA addresses. They're *my* nanotech. :) Feel free. Personally, I still see ULA as an absurdity. ------------------------------------------------------------ Why? More tools to solve more problems. scott

1 0

Re: Bandwidth distribution per ip
by Blake Hudson 20 Dec '17

20 Dec '17

Denys Fedoryshchenko wrote on 12/20/2017 11:38 AM: > On 2017-12-20 19:16, Blake Hudson wrote: >> Denys Fedoryshchenko wrote on 12/20/2017 8:55 AM: >>> National operator here ask customers to distribute bandwidth between >>> all ip's equally, e.g. if i have /22, and i have in it CDN from one >>> of the big content providers, this CDN use only 3 ips for ingress >>> bandwidth, so bandwidth distribution is not equal between ips and i >>> am not able to use all my bandwidth. >>> >>> And for me, it sounds like faulty aggregation + shaping setup, for >>> example, i heard once if i do policing on some models of Cisco >>> switch, on an aggregated interface, if it has 4 interfaces it will >>> install 25% policer on each interface and if hashing is done by dst >>> ip only, i will face such issue, but that is old and cheap model, as >>> i recall. >>> >>> Did anybody in the world face such requirements? >>> Is such requirements can be considered as legit? >> >> Not being able to use all of your bandwidth is a common issue if you >> are provided a bonded connection (aka Link Aggregation Group). For >> example, you are provided a 4Gbps service over 4x1Gbps ethernet links. >> Ethernet traffic is not typically balanced across links per frame, >> because this could lead to out of order delivery or jitter, especially >> in cases where the links have different physical characteristics. >> Instead, a hashing algorithm is typically used to distribute traffic >> based on flows. This results in each flow having consistent packet >> order and latency characteristics, but does force a flow over a single >> link, resulting in the flow being limited to the performance of that >> link. In this context, flows can be based on src/dst MAC address, IP >> address, or TCP/UDP port information, depending on the traffic type >> (some IP traffic is not TCP/UDP and won't have a port) and equipment >> type (layer 3 devices typically hash by layer 3 or 4 info). >> >> Your operator may be able to choose an alternative hashing algorithm >> that could work better for you (hashing based on layer 4 information >> instead of layer 3 or 2, for example). This is highly dependent on >> your provider's equipment and configuration - it may be a global >> option on the equipment or may not be an option at all. Bottom line, >> if you expected 4Gbps performance for each host on your network, >> you're unlikely to get it on service delivered through 4x 1Gbps links. >> 10Gbps+ links between you and your ISP's peers would better serve >> those needs (any 1Gbps bonds in the path between you and your >> provider's edge are likely to exhibit the same characteristics). >> >> --Blake > > No bonding to me, usually it is dedicated 1G/10G/etc link. > Also i simulated this bandwidth for "hashability", and any layer4 > aware hashing > on cisco/juniper provided perfectly balanced bandwidth distribution. > On my tests i can see that they have some balancing clearly by dst ip > only. > Are you claiming that your bandwidth is being equally divided 1024 ways (you mentioned a /22) or just that each host (IP) is not receiving the full bandwidth? What is the bandwidth ordered and what is the bandwidth you're seeing per host(IP)?

3 2

IPSec SPI
by Mike Hammett 20 Dec '17

20 Dec '17

Is it possible for light packet loss (0.1% - 0.3%) to cause these errors: Dec 18 00:12:07.098: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=Z.Z.Z.Z, prot=50, spi=0x9E6D41B7(2657960375), srcaddr=B.B.B.B, input interface=GigabitEthernet0/2 Dec 18 00:20:47.848: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= Z.Z.Z.Z , prot=50, spi=0x430A8C9C(1124764828), srcaddr=A.A.A.A, input interface=GigabitEthernet0/2 Dec 18 00:28:39.781: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= Z.Z.Z.Z , prot=50, spi=0x8716502A(2266386474), srcaddr=A.A.A.A, input interface=GigabitEthernet0/2 I look it up and none of the pages I find say anything about connection quality and everything about configuration and timing. My client is insisting that it can't possibly be their problem and that it's entirely because of the packet loss. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com

2 2

a new source for authoritative routing data: ARIN WHOIS
by Job Snijders 20 Dec '17

20 Dec '17

Dear NANOG, I'd like to share an update on some routing security activities that ARIN, NTT Communications, YYCIX (Calgary Internet Exchange), the NLNOG Foundation, and the arouteserver project have been collaborating on. Quite some puzzles pieces were brought together! :) Traditionally, there are two commonly-used methods to signal to your peers or upstream providers what Origin ASN(s) are allowed to originate a given IP prefix. As an operator, you can either create a "route object" in the IRR, or you can compose a Letter Of Agency (LOA) and send that to your upstream providerfor manual verification. When it comes to manual verification of routing data (such a LOA), one of the big questions is "what data source is actually authoritative for the verification?". In the ARIN registry the so-called "OriginAS" attribute can be used for this purpose. The OriginAS attribute can only be set or modified by authorized accounts (such as the holder of the IP space). This makes the OriginAS attribute a very reliable source of truth! ARIN shared some notes on LOAs & OriginAS in the following article: https://teamarin.net/2016/07/07/origin-as-an-easier-way-to-validate-letters… That teamarin posting got me thinking: clearly there is a lot of valuable routing information in the ARIN WHOIS registry. What if we make the process such that you don't have to email in a LOA, and, have the recipient verify it against against the web interface output (which you updated before sending in the LOA). What if the prefix-filter generation software could just programmatically fetch all (CIDR, OriginAS) tuples from the ARIN WHOIS registry and load that into the list of prefixes a customer is allowed to announce. Just like we do with IRR objects! A few weeks ago I approached John Curran from ARIN asking whether we could work out a mechanism to somehow obtain a computer parsable rendering of the CIDR/OriginAS data in the ARIN WHOIS registry. The path forward turned out to be an agreement between the NLNOG Foundation and ARIN, which authorises NLNOG to publish a subset of the bulk whois data in the convenient format (JSON) for operational purposes. The ARIN WHOIS (CIDR, OriginAS) tuples can be downloaded in JSON format here: http://irrexplorer.nlnog.net/static/dumps/arin-whois-originas.json.bz2 Because of the JSON dump, the ARIN WHOIS data can now be easily consumed by software programs. For example, the JSON file is now loaded into IRR Explorer as can be seen here: http://irrexplorer.nlnog.net/search/AS22512 You can see the 'arin-whois' column which lists what ASN(s) are authorized to announce the blocks (this, in addition to what is signaled in IRR or RPKI). The novel thing here is that JSON file not only allows you to look up an OriginAS using the IP prefix as a lookup key, but the reverse can now also be done: lookup what IP prefixes an ASN is allowed to originate (based on ARIN WHOIS data). Deployment Experience YYCIX: At this point you may be wondering - what does any of the above have to do with an Internet Exchange in Alberta, Canada (https://www.yycix.ca/) or a python-based IXP Route Server management software from Italian origins (http://arouteserver.readthedocs.io/en/latest/) ? :-) As an experiment to explore real world use of the ARIN WHOIS data and prove its value, I worked with Pier Carlo Chiodi (arouteserver) and Theo de Raadt (YYCIX) to consume the ARIN WHOIS data as an additional source in the prefix filter generation process governing the YYCIX route servers. The YYCIX route servers see roughly 80,000 prefixes. The results are fantastic: ~ 1,700 IPv4 prefixes that were previously rejected by the YYCIX route servers (because no IRR route object exists), are now accepted because those announcements can be verified against data from ARIN's WHOIS registry. This resolved roughly 23% of invalid path announcements sent to the YYCIX route servers. Deployment Experience NTT: Based on the above positive results, starting today, NTT is also accepting ARIN WHOIS OriginAS information in conjunction with IRR route objects. Our implementation fetches the ARIN WHOIS data, transforms it into RPSL format, and imports it into our IRRd instance at rr.ntt.net as IRR objects. This way we don't need to update our toolchain to make use of this new data source. An example is here: job@vurt:~$ whois -h rr.ntt.net -- "-sARIN-WHOIS 204.209.252.0/23" route: 204.209.252.0/23 descr: NET-204-209-252-0-1 origin: AS22512 remarks: This route object represents authoritative data retrieved from ARIN's WHOIS service. remarks: The original data can be found here: https://whois.arin.net/rest/net/NET-204-209-252-0-1 remarks: This route object is the result of an automated WHOIS-to-IRR conversion process. mnt-by: MAINT-JOB changed: job(a)ntt.net 20090220 source: ARIN-WHOIS NTT also observed a substantial number (similar to YYCIX) of BGP announcements from its customers that were previously rejected because of the lack of an IRR object, but now are validated via ARIN WHOIS. Conclusion: It is great to be able to offer network operators a choice: either register your BGP announcements as route objects in RPSL format in IRR, or use the ARIN WHOIS web interface, (or both) - either way, as IP transit carrier, we can now pick up your attestations in an automated fashion. This which improves accuracy and reduces red tape! :) Hopefully more carriers and IXPs will embrace the ARIN WHOIS data source in their automation toolchain. The code & procedures to make use of this source are open. I'm happy to help you both on-list and off-list. Kind regards, Job

3 2

historic SWIP (or rwhois) data?
by Neal Rauhauser 20 Dec '17

20 Dec '17

Hello, I'm working on a forensics problem rather than a network operations issue. I've got a /28 that I can see is currently assigned to a certain company via rwhois. What I want to do is see this block's history over the last five years. It was involved in some problematic behavior back in 2012, I'd really like to know whose name was on it then. It would be ideal if this data were available in some sort of flat file format, or if a sensible API to it exists. I've been searching a little bit, just found this, not really seeing any place to download any of this data though. https://gist.github.com/NetwarSystem/eed78b65d881d0d384664ab713cf5e1f

4 4

Final Reminder to Re-Register DMCA Agents in Electronic System
by Sean Donelan 19 Dec '17

19 Dec '17

The U.S. Copyright Office has been moving DMCA registration from paper forms to an online registration system. All previously filed paper DMCA agent registration forms expire on December 31, 2017. U.S. ISPs and non-US ISPs doing business in the United States should have re-registered using the online DMCA electronic registration. If you've neglected to register using the online system, you have until December 31, 2017. https://www.copyright.gov/newsnet/2017/694.html

1 0

MSN/Azure
by Joe Carroll 19 Dec '17

19 Dec '17

Anyone have a clueful contact at Azure/MSN? We have a block of recently acquired address space being filtered.

2 1

Geolocate data for allocated blocks
by JASON BOTHE 19 Dec '17

19 Dec '17

I am seeking assistance in getting nets I’ve allocated (several months ago) to an office in another RIR region to properly update its geolocate data. In this particular case, I have a net in use in India, but currently reflects Houston as its address although the allocation indicates otherwise. Any databases I should contact or other info is appreciated. Cheers! Jason

3 2

40G and 100G optics options
by Baldur Norddahl 19 Dec '17

19 Dec '17

Hi What options are available for 40G QSFP+ and 100G QSFP28 for 10+ km links? I see a lot of switches offered with QSFP+ and QSFP28. But I do not seem to find the necessary optics to build the links I want. For example, take a look at the options available at Fiberstore: https://www.fs.com/c/generic-40g-qsfp-891 Generic Compatible 40GBASE-LR4 and OTU3 QSFP+ 1310nm 10km LC Transceiver for SMF $340 Generic Compatible 40GBASE-ER4 and OTU3 QSFP+ 1310nm 40km LC Transceiver for SMF $1500 https://www.fs.com/c/generic-qsfp28-100g-transceivers-2858 Generic Compatible QSFP28 100GBASE-LR4 1310nm 10km Transceiver $1999 Generic Compatible QSFP28 100GBASE-ER4 1310nm 40km Transceiver $7000 That is it. Four modules and the 40km are prohibitive expensive. The situation at other vendors appears to be similar. I need stronger modules that can do more than 10 km without being extremely expensive. Or DWDM modules in the 1550 nm band so I can use external amplifiers. Am I looking in the wrong place? Is this expected to be available in the near future? Regards, Baldur

6 7

contact for WCGDB routing registry?
by Christopher Rogers 19 Dec '17

19 Dec '17

Does anyone have a contact for the WCGDB RR? They've got an invalid object registered that is being mirrored to other providers, but I am unable to find any working poc. Also why is wcg.com running an RR that's being mirrored by t1s to begin with? (changed had wcg.com email addr.) cheers -chris

1 0