Re: Residential GPON last mile for network engineers (Telus AS852 and others)
On 2020-10-13 6:38 p.m., Eric Kuhnke wrote: Any insights as to what the configuration of the Telus AS852 GPON network looks would be helpful. Or other observations in general on technically-oriented persons who are doing similar with other ILECs. I have heard rumors that Telus's GPON deployment is a little bit different depending on when the location was connected to GPON, although I think they've been working towards having a single unified provisioning system. I'm unclear if there are user-impacting differences, I haven't noticed any. I deal with several sites that are connected to Telus's consumer GPON network. Here are three samples: 1. Telus GPON is terminated to a Telus-provided media converter that provides a copper gigabit ethernet switch. The Telus-supported deployment involves some magic wifi gateway that speaks both DSL and Ethernet for WAN connectivity. Removing the magic box and using standard DHCP from my own networking equipment works fine. This site was amongst Telus's very first GPON deployments. 2. Telus GPON is terminated to a magic GPON SFP. The Telus-supported deployment involves an SFP being provided to CPE they deploy which has an SFP port (in addition to the DSL & Ethernet WAN uplink ports which are also present on that CPE). That SFP instead goes into my own equipment, and standard DHCP works fine. I specifically requested an SFP-based deployment when I ordered the service, and again from the technician that did the install. While the tech was confused why I would care, he was happy to oblige. 3. For a site that was deployed after I was familiar with how it went, I had my equipment at that site pre-configured to do DHCP on my SFP port prior to the technician arriving. The technician was quite happy to dash off to his next appointment when after plugging in the SFP I was able to confirm that everything was working. At that site I don't have any Telus-owned CPE other than their SFP, the technician had reason to provide any. I have heard rumours that if you want their "Optik TV" service that it simply requires standard-but-undocumented VLAN tagging, but I've never had reason to care to find out. Telus happily provides >1 IPv4 over DHCP to multiple devices on the interface, and their equipment also happily allocates a /56 in IPv6 land. While there's lot to be unhappy about with Telus, they do a very good job with some of the important basics. Regards, Daniel Dent https://www.danieldent.com/
Re: QUIC traffic throttled on AT&T residential
On 2020-02-18 4:25 p.m., Jared Mauch wrote: The members of the QUIC WG at IETF have not thought this was a problem as they don't observe it across the board. The cost for payloads with QUIC is much higher on the CPU side vs TCP as well - this is also not considered an issue either. There's plenty of room for system call/interface improvements and hardware acceleration in UDP stacks, both of which should help with CPU concerns. Now that UDP may represent a significant portion of internet traffic, it will be easier for the necessary engineering expense to be justified. The explanation I got (which seems fair) from someone was that they only way to roll a new transport was to squat on some existing stuff that would make it through firewalls. If there's clearly a two-way flow occurring, i.e. as is the case with a stream of QUIC traffic, that is a clearly distinguishable case from a DoS where the recipient is going to be dropping traffic. While this may be considerably harder to implement at scale than simply throttling UDP indiscriminately, hopefully there can be enough user suffering that AT&T feels compelled to do the right thing and allow the internet to continue to develop new protocols. Not everything fits neatly into a circuit-switched head-of-line-blocking request-response/HTTP paradigm. We have an internet that is largely fixed around running NATs and TCP and UDP only these days. I for one find this sad and don't see a good way forward on either side. Hopefully situations like this where Google swings their Chrome hammer for good instead of for evil can help get us there... now if we can just get those 100 gigabyte game downloads to get delivered over UDP too... --- Daniel Dent https://www.danieldent.com
Re: Cloudflare 1.1.1.1 public DNS broken w/ Xerox Phaser MFP
On a Xerox Phaser 3635MFP printer running the latest firmware, when attempting to configure it to use 1.1.1.1 for DNS, it throws the following error: "The following Alternate DNS Server 1 addresses are not permitted: 1.1.1.1 and 255.255.255.255". I suspect this was intended to prevent people from putting in an "invalid" placeholder, but the assumption that 1.1.1.1 would never be an actual DNS server that somebody might actually wish to use appears to have been unwise. Daniel Dent https://www.danieldent.com On 2018-04-02 12:32 PM, Marty Strong via NANOG wrote: Do you have one? Do you know what is causing it to fail? i.e. IP on internal interface etc. Regards, Marty Strong -- Cloudflare - AS13335 Network Engineer ma...@cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335 On 2 Apr 2018, at 19:24, Rubens Kuhl wrote: D-Link DMG-6661 as well. Rubens On Mon, Apr 2, 2018 at 12:26 PM, Marty Strong via NANOG wrote: So far we know about a few CPEs which answer for 1.1.1.1 themselves: - Pace 5268 - Calix GigaCenter - Various Cisco Wifi access points If you know of others please send them my way so we can investigate. Regards, Marty Strong -- Cloudflare - AS13335 Network Engineer ma...@cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335 On 2 Apr 2018, at 16:16, Jason Kuehl wrote: Just like "S3 dependency check day" Thus begins "National 1.1.1.1 change week" I've already around a few peaces of equipment sets with 1.1.1.1 On Mon, Apr 2, 2018 at 11:05 AM, Matt Hoppes < mattli...@rivervalleyinternet.net> wrote: Seeing as how 1.1.1.1 isn’t suppose to be routed I’m not surprised this is causing odd issues. On Apr 2, 2018, at 11:03, Darin Steffl wrote: I am behind a Calix router at home for my ISP and 1.1.1.1 goes to my router and not any further. When I enter the IP into my browser, it opens the login page for my router. So it appears 1.1.1.1 is used as a loopback in my Calix router. 1.0.0.1 goes to the proper place fine. On Sun, Apr 1, 2018 at 3:59 PM, Jeremy L. Gaddis wrote: Greetings, If anyone at 7018 wants to pass a message along to the correct folks, please let them know that Cloudflare's new public DNS service (1.1.1.1) is completely unusable for at least some of AT&T's customers. There is apparently a bug with some CPE (including the 5268AC). From behind such CPE, the services at 1.1.1.1 are completely unreachable, whether via (ICMP) ping, DNS, or HTTPS. Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns the following results: ping successful: icmp seq:0, time=2.364 ms ping successful: icmp seq:1, time=1.085 ms ping successful: icmp seq:2, time=1.160 ms ping successful: icmp seq:3, time=1.245 ms ping successful: icmp seq:4, time=0.739 ms RTTs to the CPE's default gateway are, at minimum, ~20 ms. A traceroute (using the same web-based diagnostic tool built-in to the CPE) reports, simply: traceroute 1.1.1.1 with: 64 bytes of data 1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms I haven't bothered to report this to AT&T through the standard customer support channels (for reasons that should be obvious to anyone who has ever called AT&T's consumer/residential technical support) but if anyone at AT&T wants to pass the info along to the appropriate group, it would certainly be appreciated. Thanks, -Jeremy -- Jeremy L. Gaddis "The total budget at all receivers for solving senders' problems is $0. If you want them to accept your mail and manage it the way you want, send it the way the spec says to." --John Levine -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi <http://www.facebook.com/minnesotawifi> Like us on Facebook <http://www.facebook.com/minnesotawifi> -- Sincerely, Jason W Kuehl Cell 920-419-8983 jason.w.ku...@gmail.com
