- NANOG - lists.nanog.org

RE: Need BGP route check (UPDATE)
by Matthew Huff 20 May '16

20 May '16

>From responses I received, I have gotten a number of different answers. Some are seeing our routes from 6128, some from 46887 and a few from both. The response from Eric though was typical. Showing the IPv4 prefix only from AS6128, but the IPv6 from both 6128 & 46887. I am guessing that 46887 might be set with a community to not export our IPv4 prefixes except to direct peers? Anyone directly peered with 46887 that could see the community for 129.77.0.0/16 and verify? ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 > -----Original Message----- > From: Eric Tykwinski [mailto:eric-list@truenet.com] > Sent: Friday, May 20, 2016 11:48 AM > To: Matthew Huff <mhuff(a)ox.com> > Subject: RE: Need BGP route check > > Matt, > > show ip bgp 129.77.0.0/16 > BGP routing table entry for 129.77.0.0/16, version 161696687 > Paths: (2 available, best #2, table Default-IP-Routing-Table) > Advertised to update-groups: > 1 > 3356 6128 14607 > 4.59.140.65 from 4.59.140.65 (4.69.183.7) > Origin IGP, metric 0, localpref 100, valid, external > 174 6128 14607 > 38.104.114.73 from 38.104.114.73 (154.26.5.244) > Origin IGP, metric 105030, localpref 100, valid, external, best > Community: 174:21000 174:22013 > > show bgp ipv6 unicast 2620:0:2810::/48 > BGP routing table entry for 2620:0:2810::/48, version 18004880 > Paths: (2 available, best #1, table Global-IPv6-Table) > Advertised to update-groups: > 2 > 3356 6128 14607 > 2001:1900:2100::A2D (FE80::219:7FF:FEDD:2800) from > 2001:1900:2100::A2D > (4.69.183.7) > Origin IGP, metric 0, localpref 100, valid, external, best > Community: 3356:3 3356:22 3356:100 3356:123 3356:575 3356:2039 > 6128:3000 6128:3091 6128:4000 6128:5003 6128:5046 64600:4000 > 64600:65002 > 174 46887 14607 14607 > 2001:550:2:4::B:1 (FE80::D66D:50FF:FE5E:1D3) from 2001:550:2:4::B:1 > (154.26.5.244) > Origin IGP, metric 105030, localpref 100, valid, external > Community: 174:21001 174:22013 > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Matthew Huff > Sent: Friday, May 20, 2016 11:32 AM > To: nanog(a)nanog.org > Subject: Need BGP route check > > One of our upstreams is apparently having problems, although they don't > appear to know about it. I've seen an alert at BGPmon.net about our > prefixes > being withdrawn, and I can't locate our prefixes through that provider > on > any routeviews. Can someone check to see what ASPATHS you are seeing > for our > prefixes? > > 129.77.0.0/16 > 2620:0:2810::/48 > > We should be advertised via AS6128 and AS46887 > > ---- > Matthew Huff | 1 Manhattanville Rd Director of > Operations | > Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-694-5669 > > >

2 1

Need BGP route check
by Matthew Huff 20 May '16

20 May '16

One of our upstreams is apparently having problems, although they don't appear to know about it. I've seen an alert at BGPmon.net about our prefixes being withdrawn, and I can't locate our prefixes through that provider on any routeviews. Can someone check to see what ASPATHS you are seeing for our prefixes? 129.77.0.0/16 2620:0:2810::/48 We should be advertised via AS6128 and AS46887 ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669

4 3

Re: NANOG Digest, Vol 100, Issue 19
by Arthur Liew 20 May '16

20 May '16

Hi Guys, Just wondering if anyone knows equivalent of bgp.he.net for GRX/IPX world? Any good mailing list around targeting GRX/IPX? Thanks ! Rgds Arthur

1 0

Frontier Rep
by Chris McDonald 19 May '16

19 May '16

Could a frontier rep hit me up offlist for an on-net check? thanks chris

1 0

mail delivery delayed to gmail/gmail hosted domains
by Mathias Zimmermann 18 May '16

18 May '16

Dear Nanog'er, Since about 4 weeks or more we experience a mail delivery delay (always between 03:09 and 03:10) to gmail.com and gmail hosted domains. We already filled out the "delivery problem report" but never heard something from them. Are there any specs from google which explains when they delay mail acceptance? We are not listed in any blocklists and the SPF, PTR record is correctly set. Any ideas? Regards, Mathias

1 0

B5-Lite
by Jared Mauch 17 May '16

17 May '16

Anyone deployed this radio in production in the US? I’m curious to hear from people who are using it, looking at replacing some UBNT hardware with it on some PTP links, going from the M-series class devices to something more modern. Thanks, - Jared

10 17

Comcast DNS Contact
by rwebb＠ropeguru.com 17 May '16

17 May '16

Can one of the Comcast DNS guru's contact me reference an issue with a .gov resolution? Robert

2 3

Perspectives about customer M/A/C in triple play environments
by Jason Lixfeld 17 May '16

17 May '16

Hello, I think it’s fair to say that most broadband/FTTx customers don’t have to think very much or need to have a very high degree of understanding if they want to move their wired Internet device from one room or another in their house. Maybe to keep things simple, let’s assume that we’re talking about a relatively modern MDU unit where a customer has some sort of provider CPE in their in-suite telecom demark closet/box/what have you with some number of switched 'LAN’ ports on it, and each of those LAN ports would be wired to a wall jack somewhere. Mr. or Ms. User can move their Internet device anywhere there is a wall jack and Bob’s your uncle. My question is around how this landscape changes in triple play environments. As I understand it, most triple play deployments separate (in some cases VoIP,) TV and Internet traffic onto VLANs (Internet would be presented to the customer untagged). The CPE would then allow the ISP to switch the video traffic onto a coax port, or maybe onto the CPE’s embedded switch, or maybe both. For the sake of argument, let’s assume the provider is supplying an Ethernet based set-top-box, so customer should be able to connect the STB to any wall jack and it should just work. And they should be able to connect their provider supplied ATA to any wall jack, and it should just work. And they should be able to connect their Internet device to any wall jack and it should just work. Or should it? Are most CPEs that are provided by ISPs sophisticated enough to be able to put all service tags on all ports, and have those same ports act as untagged LAN ports as well? If not, how do providers deal with this? Do they dedicate one port for an IPTV STB? One port for an ATA (assuming no built-in POTS on the CPE)? And the rest of the ports for untagged Internet? What if the customer has 2+ TVs? Do they need to call in and have the provider remote in and provision another port for TV at the expense of some other service that might be running on that port already? Do they need to install a switch that does IGMP snooping? I feel like this all has the potential to become very complicated for the customer, and maybe the provider and their installers. To me, the customer should continue to be dumb and unassuming. They should be able to put whatever they want wherever they want and have it just work. Is that how things actually are in the real world or are customers and providers making silent sacrifices for the sake of all this new fangled technology?

4 3

Level 3 issues?
by David Hubbard 16 May '16

16 May '16

Anyone seeing issues with Level 3 networking right now? We’re seeing huge latency and loss on traffic coming inbound (to us, AS33260) but it seems to be at the peering points with other major ISP’s and Level 3. Comcast for example: 3 33 ms 21 ms 70 ms te-3-5-ur01.hershey.pa.pitt.comcast.net [68.85.42.29] 4 * 33 ms 106 ms 162.151.48.173 5 214 ms 54 ms 41 ms 162.151.21.229 6 561 ms 764 ms 459 ms 4.68.71.133 Thanks, David

6 6

Cost-effectivenesss of highly-accurate clocks for NTP
by esr＠thyrsus.com 16 May '16

16 May '16

Mel Beckman <mel(a)beckman.org>: >Finally, do you want to weigh in on the necessity for highly accurate local RT >clocks in NTP servers? That seems to be the big bugaboo in cost limiting right >now. Yes, this is a topic on which I have some well-developed judgments due to having collected (and, where practical, tested) a pretty comprehensive set of figures on components of the NTP error budget. I've even invented some hardware that simplifies the problem. The background to my findings is laid out in my "Introduction to Time Service" HOWTO: http://www.catb.org/gpsd/time-service-intro.html I find that an effective way to learn my way into a new application domain is to first do knowledge capture on the assumptions its experts are using and then document those. "Introduction to Time Service" was written to do that and as a white paper for my project management. Criticism and corrections are, of course, welcome. In order to discuss the value of accurate clocks intelligently, we need to split apart two issues: accuracy and availability. Of course we want the most accurate time our networks can deliver; we also want to hedge against sporadic or systemic failure of single time sources. The most important simplification of either issue is that clock accuracy worth paying for is bounded both by user expectations and the noise floor defined by our network jitter. According to RFC 5095 expected accuracy of NTP time is "several tens of milliseconds." User expectations seem to evolved to on the close order of 10ms. I think it's not by coincidence this is pretty close to the jitter in ping times I see when I bounce ICMP off a well-provisioned site like (say) google.com through my Verizon FIOS connection. It's good rule-of-thumb engineering that if you want to be metrologically accurate you should pay for precision an order of magnitude below your feature size *and not more than that*. Thus, with a feature size of 10ms the economic sweet spot is a clock with accuracy about 1ms. One reason discussions of how to budget for WAN timeservice clocks has tended to become heated in the past is that nothing inexpensive hit this sweet spot. The world was largely divided between cheap time sources with too much jitter (e.g. GPS in-band data with a wander of 100ms or worse) and expensive high-precision clocks designed for PTP over Ethernet that deliver three or more orders of magnitude than WAN time service can actually use. However...also use the 1PPS signal your GPS engine ships (top of UTC second accurate to about 50ns) and the picture changes completely. With that over RS232 your delivered accuracy rises to single-digit numbers of microseconds, which is two orders of magnitude below what you need for your 1ms goal. Now we have a historical problem, though: RS232 and the handshake lines you could use to signal 1PPS are dying, being replaced by USB. which doesn't normally bring 1PPS out to where the timeserver OS can see it. In 2012, nearly three years before being recruited for NTPsec, I solved this problem as part of my work on GPSD. The key to this solution is an obscure feature of USB, and a one-wire patch to the bog-standard design for generic USB that exploits it. Technical details on request, but what it comes down to is that with this one weird trick(!) you can mass-produce primary time sources with a jitter bounded by the USB polling interval for about $20 a pop. The USB 1 polling interval is 1ms. Bingo. We're done. If we're only weighting accuracy and not availability, a USB GPS is as much clock as you need for WAN timeservice *provided it exposes 1PPS*. These devices exist, because I designed them and found a shop in Shenzhen to build them. They're called the Navisys GR-601W, GR-701W, and GR-801W. (A viable, only skightly more expensive alternative is to mate a GPS daughterboard to a hackerboard like the Raspberry Pi and run NTP service on that. I'll have much, much more to say about that in a future post.) Of course, now we have to talk about availability. GPS sometimes loses lock. There are sporadic and systemic availability risks due to jamming and system failures like the 2012 hiccup, and extreme scenarios like a giant meteorite hitting GPSS ground control in Colorado. What you should be willing to pay for a hedge against this is proportional to your 95% confidence estimate of the maximum outage interval. At the low end, this is simple; put your antenna on a mast that guarantees unobstructed skyview. At the high end it's effectively impossible, in that anything that takes down GNSS and Galileo permanently (giant meteor impact, war in space, collapse of the U.S. and Europe) is likely to be in the you-have-much-bigger- problems than-inaccurate-time department. Traditionally dedicated time-source hardware like rubidium-oscillator GPSDOs is sold on accuracy, but for WAN time service their real draw is long holdover time with lower frequency drift that you get from the cheap, non-temperature-compensated quartz crystals in your PC. There is room for debate about how much holdover you should pay for, but you'll at least be thinking more clearly about the problem if you recognize that you *should not* buy expensive hardware for accuracy. For WAN time service, in that price range, you're wither buying holdover and knowing you're doing so or wasting your money. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> Everything you know is wrong. But some of it is a useful first approximation.

13 20