webex.com DNS Contact - Possibly Broken DNSSEC?
Does anyone know of a contact of someone (presumably at Webex/Cisco) who can take a look at the DNS for webex.com? It has been for some time now, logging a lot of DNSSEC warnings on my resolver: dnssec: validating external-media75.public.wnrtm-a-2.prod.infra.webex.com/NSEC: no valid signature found: 1 Time(s) dnssec: validating external-media75.public.wsinm-a-3.prod.infra.webex.com/NSEC: no valid signature found: 1 Time(s) dnssec: validating external-media78.public.wbomm-a-2.prod.infra.webex.com/NSEC: no valid signature found: 1 Time(s) dnssec: validating external-media8.public.wnrtm-a-2.prod.infra.webex.com/NSEC: no valid signature found: 1 Time(s) (and a whole lot more hostnames in the same domain). Some basic DNSSec analysis indicates something in the middle of the trust chain is broken: https://dnssec-analyzer.verisignlabs.com/external-media26.public.wjfkm-a-3.prod.infra.webex.com It looks to me like the subdomains have DS records but the other parts of the subdomain don't and I guess there's no point in having DS records on host records, if the parent domain doesn't have them too. I wouldn't bother if it was one or two entries, but it looks like the whole domain is affected and this probably is a fairly widely utilised domain. Thanks, Reuben
Carriage Burst Speeds [was Re: Proving Gig Speed]
On 17/07/2018 5:49 pm, James Bensley wrote: Also there are SO many variables when testing TCP you MUST test using UDP if you want to just test the network path. Every OS will behave differently with TCP, also with UDP but the variance is a lot lower. One of the issues I have repeatedly run into is an incorrect burst size set on shaped carriage circuits. In the specific case I have in mind now, I don't recall what the exact figures were - but the carrier side configuration was set by the carrier to be something like a 64k burst on a 20M L3 MPLS circuit. End to end speed testing results both with browsers and with iperf depended enormously on if the test was done with TCP or UDP. Consequently the end customer was unable to get more than 2-3MBit/sec of single stream TCP traffic through the link. The carrier insisted that because we could still get 19+ MBit/sec of UDP then there was no issue. This was the same for all operating systems. The end customer certainly didn't feel that they were getting the 20Mbit circuit they were sold. The carrier view was that as we were able to get 20 TCP streams running concurrently and max out the link that they were providing the service as ordered. After many months of testing and negotiating we were able to get the shaper burst increased temporarily, and the issue completely went away. The customer was able to get over 18MBit/sec of continuous TCP throughput on a single stream. I was told that despite this finding and admission that the burst was indeed way too small, the carrier was going to continue to provision circuits with almost no burst, because this was their "standard configuration". The common belief seemed to be that a burst was a free upgrade for the customer. I was of the alternate view that this parameter was required to be set correctly for TCP to function properly to get their quoted CIR. I'd be very interested in other's thoughts with regards to testing of this. It seems to me that measuring performance with UDP only means that this very critical real-world aspect of a circuit (burst size on a shaper) is not tested, and this seems to be a very common misconfiguration. In my case...seen across multiple carriers over many years and many dozens of hours spent on "faults" related to it. [NB: I've always used the rule of thumb that the L3 burst size should be about 1/8th the Contracted Line Rate, but there seems to be no consensus whatsoever about that...certainly no agreement whatsoever within the carrier world] Reuben
Microsoft Skype for Business Contact - Broken PMTUD
Hi, Can someone from Microsoft who manages the network for the Skype for Business please contact me to help resolve what I believe is a problem with the S4B network? I am experiencing PMTUD issues whereby connections with an IPv4 TCP MSS above 1492 and an IPv6 TCP MSS of above 1432 do not function. I can run a clean 1500 byte MTU on both IPv4 and IPv6 from the connection I am testing with. External validation (thus ruling out my own link) from https://wand.net.nz/pmtud/ reports that the following URLs used by Lync/S4B are failing PMTUD: meet.lync.com webdir0b.online.lync.com -- tbit from 2001:df0:4:4000::1:115 to 2603:1047:0:a::12 server-mss 1440, result: pmtud-fail app: http, url: https://meet.lync.com/ [ 0.010] TX SYN 64 seq = 0:0 [ 0.049] RX SYN/ACK 64 seq = 0:1 [ 0.049] TX 60 seq = 1:1 [ 0.049] TX373 seq = 1:1(313) [ 0.097] RX 1500 seq = 1:314(1440) [ 0.097] RX 1500 seq = 1441:314(1440) [ 0.097] RX868 seq = 2881:314(808) [ 0.097] TX PTB 1280 mtu = 1280 [ 0.097] TX 60 seq = 314:1 [ 0.399] RX 1500 seq = 1:314(1440) [ 0.399] TX PTB 1280 mtu = 1280 [ 0.994] RX 1500 seq = 1:314(1440) [ 0.994] TX PTB 1280 mtu = 1280 [ 2.197] RX 1500 seq = 1:314(1440) [ 2.197] TX PTB 1280 mtu = 1280 [ 4.603] RX 1500 seq = 1:314(1440) tbit from 130.217.250.115 to 52.113.65.78 server-mss 1460, result: pmtud-fail app: http, url: https://meet.lync.com/ [ 0.009] TX SYN 44 seq = 0:0 c5c9 [ 0.152] RX SYN/ACK 44 seq = 0:1 56ef [ 0.152] TX 40 seq = 1:1 c5ca [ 0.153] TX353 seq = 1:1(313) c5cb DF [ 0.299] RX808 seq = 2921:314(768)56f7 DF [ 0.299] RX 1500 seq = 1:314(1460) 56f5 DF [ 0.299] RX 1500 seq = 1461:314(1460) 56f6 DF [ 0.299] TX 40 seq = 314:1c5cc [ 0.299] TX PTB 56 mtu = 1280 [ 0.763] RX 1500 seq = 1:314(1460) 5720 DF [ 0.764] TX PTB 56 mtu = 1280 [ 1.592] RX 1500 seq = 1:314(1460) 5750 DF [ 1.592] TX PTB 56 mtu = 1280 [ 3.232] RX 1500 seq = 1:314(1460) 57dc DF [ 3.232] TX PTB 56 mtu = 1280 [ 6.514] RX 1500 seq = 1:314(1460) 5910 DF - This is in the Asia Pacific region. Thanks, Reuben Farrelly
5GHz Wifi [Was: Re: GPON vs. GEPON]
On 9/01/2016 2:48 PM, Baldur Norddahl wrote: But 5 GHz usage is still low because people have a ton of devices that are 2,4 GHz only. Even brand new laptops are sold without a 5 GHz radio. People don't know that they have to check - it is oh but it has wifi and it is brand new, therefore it must have support for the new standard you are talking about! Sometimes we have to send someone out to the customer to demonstrate how crappy his new purchase is. Unfortunately almost all of the Internet of Things (IoT) client devices I have come across or purchased lately are 2.4GHz only: - Belkin Wemo - Airconsole - Sense Sleep Tracker - LIFX - Ninjasphere (now defunct, but this was interesting because these appear to have a 5GHz radio in them but don't have the antenna to support it) The explanation I have been given a few times is that the antenna requirements for 5GHz are just too difficult to achieve in what are often small and low powered devices. We're mostly there with phones and PCs though. Reuben
