- Test - lists.nanog.org

Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
by Bjørn Mork 25 Oct '19

25 Oct '19

Julien Goodwin <jgoodwin(a)studio442.com.au> writes: > On 20/10/19 11:08 pm, Bjørn Mork wrote: >> Hank Nussbacher <hank(a)efes.iucc.ac.il> writes: >>> On 07/10/2019 17:42, Stephane Bortzmeyer wrote: >>>> On Fri, Oct 04, 2019 at 03:52:26PM -0400, >>>> Phil Pishioneri <pgp+nanog(a)psu.edu> wrote >>>> a message of 9 lines which said: >>>> >>>>> Using Cloud Resources to Dramatically Improve Internet Routing >>>>> UMass Amherst researchers to use cloud-based ‘logically centralized >>>>> control’ >>>> Executive summary: it's SDN for BGP. Centralizing Internet routing, >>>> what could go wrong? (As the authors say, "One reason is there is no >>>> single entity that has a big picture of what is going on, no >>>> manager". I wonder who will be Internet's manager.) >>>> >>> Centralized Internet routing - sounds like DoH for BGP. >> >> Great idea! Why don't we just run BGP over HTTPS? Everyone already has >> a browser, so we can get rid of all these expensive routers. > > IMO BGP over TLS actually makes a bunch of sense, Absolutely. And so does DNS over TLS. A lot of sense. But if you start encoding the BGP protocol data in the TLS session as HTTP so you can tunnel it over a shared 443 port to some distant endpoint, and even traverse HTTP proxies, then it would look like a joke. Or in the DoH case, would make you wish it was a joke. Bjørn

17 37

FCC: DIRS activation for California Public Safety Power Shutoffs
by Sean Donelan 24 Oct '19

24 Oct '19

Unlike the last California public safety power shut-offs (PG&E, SoCal Edison, SDG&E), the FCC has decided to activate its Disaster Information Reporting System this time. DIRS is a voluntary reporting method for wireline, wireless, broadcast, cable, and VOIP providers. https://docs.fcc.gov/public/attachments/DA-19-1073A1.pdf CALIFORNIA: Alpine, Amador, Butte, Calaveras, El Dorado, Napa, Nevada, Orange, Placer, San Diego, San Mateo, Sierra, Sonoma, and Tehama Reports from participating communications providers are requested at 10:00 a.m. on Friday, October 25, 2019, and every day after that by 10:00 a.m. until DIRS is deactivated.

1 0

MX10003 rack size
by Sander Steffann 24 Oct '19

24 Oct '19

Hi, Has anyone ever managed to fit a Juniper MX10003 in a 90cm deep rack? Without applying power tools to either the rack or the router ;) Cheers, Sander

4 4

Russian government’s disconnection test
by Scott Weeks 24 Oct '19

24 Oct '19

Anyone got any technical info on how Russia plans to execute a disconnection test of the internet? I am starting to see this on web sites again: https://slate.com/technology/2019/10/russia-runet-disconnection-domestic-in… and started wondering how they plan to do that? DNS? firewalls? Shut off optics on fiber? Stop satellite comms? What about microwave? https://aviatnetworks.com/solutions/ip-mpls-microwave "Russia plans to execute a so-called disconnection test of the internet sometime in October—right ahead of Nov. 1, when a new law about domestic internet kicks into gear. Russia plans to then repeat this test at least once a year." "For one, “equipment is being installed on the networks of major telecom operators,” Alexander Zharov, head of Roskomnadzor, told reporters." scott

1 0

Re: Geyserville fire
by Ben Cannon 24 Oct '19

24 Oct '19

Geyser Peak is on fire and will likely soon lose all mobile telecommunications. -Ben > On Oct 24, 2019, at 12:13 AM, Ben Cannon <ben(a)6by7.net> wrote: > > > <image.png> > > > -Ben

3 2

Contact at ESPN?
by Danny Meister 24 Oct '19

24 Oct '19

1 0

Re: IPv4 and Auctions
by Matt Hoppes 24 Oct '19

24 Oct '19

> You can hold onto resources you don't actively need, and nothing in any > RIR agreement I'm aware of (I'm only familiar with ARIN's) says > otherwise. There is no requirement to return resources under any > circumstances. So you're saying you can justify a large amount of IPs with ARIN, then suddenly not need them and just hold onto them? I was under the impression you had to need them in order to hold onto them?

1 0

A New Fiber Optic Network
by Rod Beck 24 Oct '19

24 Oct '19

https://www.telecomramblings.com/2019/10/crosslake-fibre-now-live/?utm_sour… [https://www.telecomramblings.com/files/2019/10/ScreenHunter-052-22-Oct-19-0…]<https://www.telecomramblings.com/2019/10/crosslake-fibre-now-live/?utm_sour…> Crosslake Fibre Now Live | Telecom Ramblings<https://www.telecomramblings.com/2019/10/crosslake-fibre-now-live/?utm_sour…> One of the more unique recent fiber buildouts is now complete. Crosslake Fibre announced this morning that its Toronto-New York cable is now live, adding diversity on a route that hasn't seen anything new in decades while cutting latency.. The nature of Crosslake's project is evident in the name of the company: a 'subsea' cable underneath Lake Ontario from Toronto over to New York State north ... www.telecomramblings.com Roderick Beck VP of Business Development United Cable Company www.unitedcablecompany.com<http://www.unitedcablecompany.com> New York City & Budapest rod.beck(a)unitedcablecompany.com 36-70-605-5144 [1467221477350_image005.png]

1 0

Anyone from NTT America here?
by Stephen Satchell 23 Oct '19

23 Oct '19

Routing loop > 11.|-- 129.250.24.196 0.0% 1 28.9 28.9 28.9 28.9 0.0 > 12.|-- 129.250.130.254 0.0% 1 29.0 29.0 29.0 29.0 0.0 > 13.|-- 129.250.130.253 0.0% 1 29.4 29.4 29.4 29.4 0.0 > 14.|-- 129.250.130.254 0.0% 1 29.6 29.6 29.6 29.6 0.0 > 15.|-- 129.250.130.253 0.0% 1 28.5 28.5 28.5 28.5 0.0 > 16.|-- 129.250.130.254 0.0% 1 29.0 29.0 29.0 29.0 0.0 > 17.|-- 129.250.130.253 0.0% 1 28.6 28.6 28.6 28.6 0.0 > 18.|-- 129.250.130.254 0.0% 1 27.9 27.9 27.9 27.9 0.0 > 19.|-- 129.250.130.253 0.0% 1 28.4 28.4 28.4 28.4 0.0 > 20.|-- 129.250.130.254 0.0% 1 27.9 27.9 27.9 27.9 0.0 > 21.|-- 129.250.130.253 0.0% 1 28.2 28.2 28.2 28.2 0.0 > 22.|-- 129.250.130.254 0.0% 1 29.0 29.0 29.0 29.0 0.0 > 23.|-- 129.250.130.253 0.0% 1 27.9 27.9 27.9 27.9 0.0 > 24.|-- 129.250.130.254 0.0% 1 28.6 28.6 28.6 28.6 0.0 > 25.|-- 129.250.130.253 0.0% 1 28.7 28.7 28.7 28.7 0.0

3 2

Request comment: list of IPs to block outbound
by Stephen Satchell 23 Oct '19

23 Oct '19

The following list is what I'm thinking of using for blocking traffic between an edge router acting as a firewall and an ISP/upstream. This table is limited to address blocks only; TCP/UDP port filtering, and IP protocol filtering, is a separate discussion. This is for an implementation of BCP-38 recommendations. I'm trying to decide whether the firewall should just blackhole these addresses in the routing table, or use rules in NFTABLES against source and destination addresses, or some combination. If NFTABLES, the best place to put the blocks (inbound and outbound) would be in the FORWARD chain, both inbound and outbound. (N.B. for endpoint boxes, they go into the OUTPUT chain.) In trying to research what would constitute "best practice", the papers I found were outdated, potentially incomplete (particularly with reference to IPv6), or geared toward other applications. This table currently does not have exceptions -- some may need to be added as a specific "allow" route or list. The Linux rp_filter knob is effective for endpoint servers and workstations, and I turn it on religiously (easy because it's the default). For a firewall router without blackhole routes, it's less effective because, for incoming packets, a source address matching one of your inside netblocks will pass. A subset of the list would be useful in endpoint boxes to relieve pressure on the upstream edge router -- particularly if a ne'er-do-well successfully hijacks the endpoint box to participate in a DDoS flood. IPv4 Address block Scope Description 0.0.0.0/8 Software Current network (only valid as source address). 10.0.0.0/8 Private network Used for local communications within a private network. 100.64.0.0/10 Private network Shared address space[3] for communications between a service provider and its subscribers when using a carrier-grade NAT. 127.0.0.0/8 Host Used for loopback addresses to the local host. 169.254.0.0/16 Subnet Used for link-local addresses between two hosts on a single link when no IP address is otherwise specified, such as would have normally been retrieved from a DHCP server. 172.16.0.0/12 Private network Used for local communications within a private network. 192.0.0.0/24 Private network IETF Protocol Assignments. 192.0.2.0/24 Documentation Assigned as TEST-NET-1, documentation and examples. 192.88.99.0/24 Internet Reserved. Formerly used for IPv6 to IPv4 relay 192.168.0.0/16 Private network Used for local communications within a private network. 198.18.0.0/15 Private network Used for benchmark testing of inter-network communications between two separate subnets. 198.51.100.0/24 Documentation Assigned as TEST-NET-2, documentation and examples. 203.0.113.0/24 Documentation Assigned as TEST-NET-3, documentation and examples. 224.0.0.0/4 Internet In use for IP multicast. 240.0.0.0/4 Internet Reserved for future use. 255.255.255.255/32 Subnet Reserved for the "limited broadcast" destination address. IPv6 Address block Usage Purpose ::/0 Routing Default route. ::/128 Software Unspecified address. ::1/128 Host Loopback address to local host. ::ffff:0:0/96 Software IPv4 mapped addresses. ::ffff:0:0:0/96 Software IPv4 translated addresses. 64:ff9b::/96 Global Internet IPv4/IPv6 translation. 100::/64 Routing Discard prefix. 2001::/32 Global Internet Teredo tunneling. 2001:20::/28 Software ORCHIDv2. 2001:db8::/32 Documentation Addresses used in documentation and example source code. 2002::/16 Global Internet The 6to4 addressing scheme fc00::/7 Private network Unique local address. fe80::/10 Link Link-local address. ff00::/8 Global Internet Multicast address.

15 30