- Test - lists.nanog.org

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

vz deep routing clue?
by Randy Bush 23 Oct '19

23 Oct '19

would appreciate unicast contact with someone withq 70x deep routing clue. researchers want to confirm possible causes of some phemnomona we think we see. thanks. randy

1 1

Fwd: SLAAC renum: Problem Statement & Operational workarounds
by Fernando Gont 23 Oct '19

23 Oct '19

Folks, Your input would be very welcome. Preferably on the v6ops wg mailing-list (https://www.ietf.org/mailman/listinfo/v6ops) but also on this list or multicast to us (authors). Thanks! -------- Forwarded Message -------- Subject: SLAAC renum: Problem Statement & Operational workarounds Date: Wed, 23 Oct 2019 03:51:32 -0500 From: Fernando Gont <fgont(a)si6networks.com> To: IPv6 Operations <v6ops(a)ietf.org> Folks, Earlier this year there was a lot of discussion about slaac renumbering problems. Our original I-D covered everything from the problem statement to proposed protocol updates and operational workarounds. Based on the comments received while discussing this topic on this list and other forums, and in order to keep the discussion better focused on specific aspects of the problem, we have posted a v6ops-targetted document that focuses on: * The problem statement * Discussion of operational workarounds, and associated constraints The document is available at: https://tools.ietf.org/html/draft-gont-v6ops-slaac-renum We'd like to hear from the wg whether we have missed anything, whether the document is useful to the community, etc. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

1 0