Re: Network chatter generator
The replies I've gotten have been somewhat useful, but I think the purpose of what I'm seeking may not have been apparent. I'm not looking to perform volumetric or even known-vulneribility tests. I have some decent ways to do both and even know that I can make the device in question unhappy by flooding it with large volumes of nonsense traffic so as to overwhelm its ability to process them as quickly as they come in. This isn't surprising given its limited resources and 100Mb connection, and the device recovers once it works through the backlog and has some free buffers again. Humongous IP datagrams broken into numerous small fragments is a great way to annoy almost anything, FWIW. What I'm really looking for is a somewhat pre-canned list of typical network chatter that embedded devices would have to copy due to being addressed to broadcast or large multicast groups but that said devices are likely to consider garbage and the ability to generate traffic from those lists with various timings and breadth of field values. There's a LOT of this type of traffic on typical consumer and enterprise networks, and the issue is that I'm constantly finding new examples of things I'd never dream exist that tickle corner cases in network stacks, drivers, or even sometimes hardware. As an example, Cisco Meraki devices send SNAP framed packets for some proprietary loop-avoidance protocol even on networks using Ethernet II framing and even if STP is enabled. I found out the hard way that the Ethernet MAC on some micros doesn't like these if you have certain receive accelerator functions enabled - it locks up and won't receive anything you perform a fairly hard reset on it. The volume of traffic here is tiny - just one packet every few seconds from the nearest Meraki switch you're on - but can tickle processing bugs. I can and have played back PCAPs from kind folks running Wireshark. Combined with playing with the packet timing, this is useful, but it limits me to things me and my kind friends have seen on their networks before. The same would be true if I tried to make my own chatter generator using something like scapy. -- Brandon Martin
Network chatter generator
Before I go to the trouble of making one myself, does anybody happen to know of a pre-canned program to generate realistic and scalable amounts of broadcast/broad-multicast network background "chatter" seen on typical consumer and business networks? This would be things like lots of ARP traffic to/from various sources/destinations within a subnet, SSDP, MDNS-SD, SMB browser traffic, DHCP requests, etc.? Ideally, said tool would have knobs to control the amount of traffic and whether a given type of traffic is present. This is mostly for torture testing "IoT" type devices by exposing them to lots of diverse, essentially nonsense traffic that they're likely to see in a real environment. -- Brandon Martin
Re: Outside plant - prewire customer demarc preference
On 12/2/23 15:09, Jay Hennigan wrote: Rigid conduit is essentially galvanized plumbing pipe. Very rare in new construction other than for overhead electrical service entrance. It's extremely heavy and difficult to work with. As its name suggests, it's quite rigid. Not easily bent or cut and needs to be threaded. I didn't mean strictly RMC but any form of generally rigid conduit to include rigid PVC. You're correct that RMC is rarely used for anything other than service masts at least as far as I've seen. The only other time I see it used is classified (explosive) environments. Innerduct or ENT is far less expensive and orders of magnitude easier to deal with for low voltage applications. That's pretty much my point. Even EMT (which can be bent with a bender or "hicky" but is otherwise rigid) and PVC are a pain to work with in comparison to something that's basically flexible tubing.
Re: Outside plant - prewire customer demarc preference
On 12/1/23 05:18, Josh Luthman wrote: Keep in mind new construction versus having to get around drywall. Rigid conduit is great if you can get it. If you can, by all means go for it! However, if the outside utility aggregation point is not pretty much on the other side of the wall from the inside media aggregation point, rigid conduit can be a pain even in new construction. Outside of a few select areas (Chicago, parts of NYC) where it's required even in stick-built residential construction for electrical wires (and then it's usually metal, not plastic), most residential electricians almost never use it aside from maybe a short run between the meter base and panel - generally right on the other side of the wall from each other. If the path is complicated, you end up having to piece together fittings to make the path up and keep proper sweep, and of course you can't feasibly get it horizontally into stud framed walls at all unless you can poke it in from the edge which involves an otherwise unnecessary hole in the corner board or you resort to cutting it into 16" pieces and putting it back together with couplers. You can surface mount it to the bottom of floor joists, for example, but then you can't drywall that ceiling without building out a chase. Corrugated plastic conduit like ENT or comm duct can be pulled in essentially like NM cable (Romex). It's easy, fast, and it's a process essentially all resi electricians are familiar and comfortable with. I'm thinking mostly SFU construction here, but a lot of the same concerns apply to MDUs as well. The 4-over style wood framed buildings that have become popular are generally wired in NM and SE cable. There's often no good path for a rigid conduit with proper sweep to every unit. Flexible/corrugated duct is just a lot more, well, flexible. 2" is beyond excessive. We use 1.25" duct for our 288ct *PLUS* up to 6 flat drop cables. I agree in principle, but it allows for plenty of room for multiple utilities to get in without worrying about tearing up the others' cables. If it's just poking through a wall, you're talking, what 8" of pipe? -- Brandon Martin Mothic Technologies 317-565-1357 x7000
Re: Outside plant - prewire customer demarc preference
On 11/30/23 20:55, o...@delong.com wrote: For the most part out here, if it’s going behind sheetrock, contractors/electricians just run Romex or whatever in bare stud holes without any form of conduit. The nice thing about ENT (or other corrugated plastic conduit) from a residential electrician's point of view is that it basically installs like Romex. -- Brandon Martin
Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds
On 12/1/23 16:45, Shane Ronan wrote: Unfortunately from my experience it's usually because the small local ISPs don't have the resources to understand IPv6, and may be using equipment generations old that may not support IPv6. It's the large ISPs that don't want to do it because it would increase their operational costs and require upgrades to operational systems and they see no new revenue associated. Honestly, how old is your equipment at this point to not support IPv6 at all or usably in the data plane and in-band parts of the control plane? I wouldn't think it's even commercially relevant anymore. Pretty much anything L3 with at least 10Gb ports probably has support for most things relevant to a small local ISP. You might be missing some niceties, but even some new stuff is missing those. The big one I've seen is a nice way to handle DHCPv6-PD delegations without having to resort to using BGP to inject the routes (looking at you, Extreme SLX). -- Brandon Martin
Re: Outside plant - prewire customer demarc preference
On 11/28/23 12:43, Owen DeLong wrote: I’ve never used ENT (never even seen that name, TBH). 1” EMT is readily available at Home Depot and Lowes out here as well as several reputable supply houses. ... Interesting… ENT is apparently plastic and has interesting snap fittings. Until this email, I’ve never even looked into it. Used plenty of the “ENT” boxes, but always just called them PVC (since that’s what the ENT stuff is apparently made of). EMT is way more common out here than ENT, and even where plastic is used, most seem to use straight electrical PVC (grey stuff usually) instead of of the ENT brand stuff. It really comes down to if the path is straight or complicated. If it's just poking straight through a wall to something adjacent on the inside or nearby, rigid pipe works fine, is easy enough to work with, and is readily available. However if the external "demarc area" and inside "media aggregation area" aren't nearby or are separated by a convoluted path once running inside walls and ceilings is taken into account, flexible conduit is obviously easier, and ENT is a readily available option most electricians are going to be familiar with for that. It's literally where the term "smurf tube" came from AFAIK. It's not itself a brand-specific thing (indeed multiple manufacturers make it) and is just yet another type of raceway defined by NEC, but the blue Carlon stuff is well known. -- Brandon Martin
Re: Outside plant - prewire customer demarc preference
On 11/28/23 10:42, Mike Hammett wrote: Why not just use SCH40 PVC sticks? Everywhere stocks that in copious levels. Ever tried to snake one of those through a wall? They're great for just pushing through a wall penetration to something directly adjacent on the inside, though. At that point you might as well for for 2", honestly. -- Brandon Martin
Re: Outside plant - prewire customer demarc preference
On 11/27/23 18:52, owen--- via NANOG wrote: Why would 1” be significantly harder to get than 3/4”? Both in EMT and PVC, it’s readily available to the best of my knowledge. Most residential electrical contractors are going to use rated ENT since it's what they can easily get at a normal supply house or even home center. This is the stuff made popular by Carlon in their trademark blue that makes people call it "smurf tube". It's readily available in 1/2" and 3/4" everywhere from home centers to basically any supply house. 1" is less common - most home centers don't have it, and since it isn't normally needed in residential nor is ENT basically ever used in commercial, neither do a lot of strictly electrical supply houses. You can of course get corrugated communication duct in that size, often with mule tape pre-installed as a bonus, but a lot of electrical supply houses that deal only in "electrical" and not "communications" don't have that and will send folks to a "low voltage communication supplier" or have to special order it. A lot of electrical contractors, especially residential, would rather not bother with a separate supply run, and having to wait is a pain if it wasn't planned early on and also often means you're paying freight separately. Even then, most of the folks going to a communications supplier are going to reach straight for 1.25" or larger in commercial since you don't have to worry about drilling studs. As I recall, my local communication cable house didn't even have 1" in stock, but they did have 1.25" in stock, and their price was basically the same as the 1" as a result. So it's not that it doesn't exist or anything, it's just that, at least as far as I've seen, there's not a ton of demand for it, so local stock is thin. All that said, I just checked Home Depot, and they are showing some stock on 1" ENT at my local store, so maybe that's changing. Used to be they only stocked 3/4" and 1/2". They still only have 25ft hanks of the 1" stuff (you can get 1/2" and 3/4" in 25 or 100-200ft), but at least they have it now. It is still about 4x the price of 3/4" per unit length, though. -- Brandon Martin
Re: Outside plant - prewire customer demarc preference
On 11/27/2023 09:12, Josh Luthman wrote: If I was building a house I'd just get some 1" conduit from the outside to the inside. Put it in a NEMA box. That solves the problem forever. 1" is great if you can get it, and I'd try to argue for it. I'd settle for 3/4" Builders and resi electricians are going to hate 1". It's not something they'll stock nor is it readily available at cheeeap prices that they seek. 3/4" ENT is available fairly cheap, and the electricians are going to have a hole hog big enough for it which they may not have for 1" if they're truly resi-only. I can see the adder for 1" being eye-rolling as a result. As a fiber ISP, and assuming you're doing your own WiFi in the house, you can do conduit inside or we can just run the fiber. We don't want to run up/down walls and such. 99% of our installs are through the exterior wall and then a u6x covers the house. We run fiber Same. I don't expect to find a house pre-wired with suitable fiber from the outside utility access area to the inside distribution point. I'll use it if it's there, but the only time I've ever had that happen is when I've managed to hand the builder (or, more likely, the electrical contractor themselves) a spool of fiber during construction. Usually this is only on custom and semi-custom homes. Tract home electricians aren't going to do ANYTHING outside their SOW. Most large fiber ISPs won't use existing fiber even if it's there and suitable. They don't trust it, and it's not "standard" for them. Occasionally the install techs may bend the rules. When I'm running fiber for a customer, anything more than "rise up from the ground and poke it through the wall" is getting into "premium installation with upcharge" territory. Nobody wants to pay for it. Most other fiber ISPs seem similar. If you're in a cableCo area just run coax to get to your modem/router situation. Agreed. In theory they could also use suitable fiber for RFoG if they've got such a deployment in the area. I'm not aware of any standards for such prewires, and like above I doubt they'd want to use it even if it were present. All of the MSOs I know of doing RFoG to the home put a micro-nid outdoors and reverse power it over coax from inside. Fiber doesn't enter the home itself. I'm not sure what the Cat5 is for outside. Ethernet isn't going to work and DSL is nearly dead already. I suspect the relevant ANSI standard is just old and dates back to POTS+DSL. CAT6 is great for VDSL and G.FAST, and a standard cable gives you 4 pairs to work with and is cheap and fairly tolerant of abuse during install. I would love to see the relevant standard updated to include e.g. a duplex or 6-count tight buffered or breakout single-mode fiber cable. -- Brandon Martin
Re: Outside plant - prewire customer demarc preference
On 11/22/23 12:35, Sean Donelan wrote: For *only* $1,000, the builder is willing to pre-install a smurf tube from the demarc to the central distribution point. But such a deal for 5G Yeah that's ridiculous. Running such a thing while the walls are still open is a piece of cake, and the material is maybe $50-100 depending on distance. Since most fiber installs seem to use pre-connectorized cable, without affecting building structure integrity (i.e. 2-inch is too big according to builder), how small is too small? Trade size 1/2-inch, 3/4-inch, 1-inch? Does the FTTH industry have any published standards? At least my experience has been that, where pre-connectorized drop cables are used, they're only pre-termed on the telco side (often, but by no means always in a hardened connector). The customer side is either unterminated or uses a small ferrule with a snap-on housing precisely so that it can be fished through small holes in walls/framing and small or crowded conduits. In practice, 1/2" trade size smurf tube is big enough if it's not too long and bendy especially if they're willing to get one with a pull-string already in it (and the guy before you is nice enough to pull another). If it's a long or bendy drop or you want a little extra piece of mind, 3/4" is readily available not too expensive. 1" starts to get a bit expensive and is usually unnecessary. I personally connectorize both sides in the field. Having the ability to do it is invaluable for repairs, and it's not that much harder to do two sides than one especially if you're already fishing wires and such. If you're using hardened connectors, the situation is different since they're not commonly available for field install, though it is a thing you can get. I'm not aware of any published standards focusing on FTTx in North America. All the standards I know of are datacenter/mid-size business oriented and are going to call for ridiculous (in FTTx) things like 2"+ rigid conduit on the assumption it'll have at least a 48F loose-tube in it and probably more than one. I would imagine some of the national ogre telcos who are still doing FTTx deployments will have a pre-build guide for at least MDUs that might be useful, though around here they often just show up when the first person orders service and treat the building as "existing" even if it was just built last week. I'm guessing they have so many existing buildings to deal with at least right now that this isn't a huge deal for them and may even be easier than having two classes of MDU installs (existing and pre-wire). AT and Centurylink/Lumen are the most likely to have them IMO, but checking Frontier/Verizon (do they still have ANY wireline territory?) may be useful, too, especially since they were the earliest ones to do it. -- Brandon Martin
Re: Outside plant - prewire customer demarc preference
On 11/19/23 16:54, Sean Donelan wrote: Of course, every local carrier will be different, what are the current preferences for pre-wiring a customer demarc (NID, the box that hangs on the outside of the house, whatever the service provider calls it now)? 1. Nothing - telco/cable will do whatever the heck they want and wreck the outside of the house anyway This is pretty much the norm around me. If I can get with a builder prior to the walls getting closed up, I will hand them a spool I/O fiber for them to run from whatever they call the inside service point to the outside demarc for me, and they usually don't screw it up. 2. Smurf tube from demarc to central distribution point with an interior power outlet near the demarc This certainly works well. 3. ANSI TIA-570 prewire (2 x CAT 6, 2 x RG 6) from demarc to central distribution point (low-voltage contractors don't use UV-rated cable for the demarc, and the jacket is trash in a few years) This is almost pointless in the world of FTTH with indoor ONTs being preferred and even basically required for XGSPON (outdoor ONTs for XGSPON are uncommon and expensive). It'll make the local cable MSO happy, though, since they have RF ready to go. It'll make the local fiber provider scratch their heads and try to decide if it's worth using an outdoor ONT or just ignoring the pre-wire and starting from scratch. This is doubly true of there's no outlet near the pre-wire outside the home. How the heck am I going to power my outdoor ONT to use that CAT6 without one? Reverse-power outdoor ONTs are even rarer and even more expensive. In the past, I found if I made the pre-wire look nice and easy for the field technician, they usually made the extra effort to keep their work clean and tidy. Most installations are contractors, and they get paid by the job with an add-on schedule that nobody's willing to pay for, so they're going to have a roughly set amount of effort they're willing to put into a job. If you've done 90% of the work for them, then that effort can be put into making it tidy. If they have to do everything from scratch, see your point (1). Due to the use of indoor ONTs, lack of fiber pre-wire, and combined with customers wanting hand-holding up to and including managing their "in home WiFi", the "point of demarcation" has become really nebulous. In practice, the real demarc for many resi customers is their 802.11 SSID.
Re: SMTP-friendly VPS provider where I can also get a BGP feed
On 9/26/23 06:09, Daniel Corbe wrote: I'm looking for a place that I can host a mailer. My primary use case is a Mailman-style technical discussion list; much like NANOG but software related instead of network related: READ: non-commercial in nature. I'm currently a vultr customer, but they're refusing to unblock port 25 on my account. I've tried explaining my use case but no matter who I talk to over there they just keep pointing me to their spam policy. I've been a happy customer of prgmr.com now TornadoVPS. They will definitely allow port 25 outbound. It was unblocked by default when I signed up years ago and I think still is even on new accounts. I don't know if they will do BGP. In the past, they had said they would by request provided you had your own AS and IP space. I think they also had offered to do one under a private ASN for route collection. -- Brandon Martin
Re: any dangers of filtering every /24 on full internet table to preserve FIB space ?
On 10/20/22 17:50, Adam Thompson wrote: Alternately, a valid technique is to have a default route AND a partial BGP feed (a filtered full feed is by definition a partial feed). That helps optimize outbound routing a little bit, you still get the advantage - mostly - of multiple inbound carriers; but you still have to pick one carrier to do the heavy lifting for you. And you are paying them to route for you, so that's not an unfair shifting of the routing burden, unlike relying on covering routes. Note that this approach does NOT provide any redundancy, unlike having full BGP feeds. As a note, you can get redundancy (but still none of the best-path advantages of having multiple transits) by asking your transits to originate default in their BGP feed and then selectively accepting it. You can either ECMP it or pick priority with localpref. You need multiple full-view transits for this to work, though. -- Brandon Martin
Re: Frontier Dark Fiber
On 8/3/22 11:16, Jay Ashworth wrote: I wouldn't have thought that Frontier was able to offer dark fiber, since air distribution fan out is all GPON, is it not? If their fanout was active ethernet it might be a different story but... They have access to/control of a large amount of mid-mile and long-haul fiber built by/as GTE and Verizon. Additionally, while their resi/soho distribution is all PON, they do have some excess fiber fairly deep into their network in most markets and actively offer active-E service on it for the right price (it can even occasionally be competitive). I imagine they'd sell dark for the right price as well, though you may not like that "right" price. -- Brandon Martin Mothic Technologies 317-565-1357 x7000
Re: FCC BDC engineer?
On 7/5/22 18:27, Glenn Kelley wrote: I fully expect this to come down to someone needing to be an "engineer." The term "Professional Engineer" is a protected term in all 50 US states to my knowledge. It requires the qualifications and licensure you'd expect with the typical path being ABET engineering curriculum, passing the FE, interning for some number of years, attribution of character from some existing PEs, then passing the PE exam and receiving the state-adorned license. The use of the term "engineer" is much more vauge and generally unprotected in the USA. Lots of people have job titles with the word in it that wouldn't even fall under typical professional engineering guidelines in the most aggressive interpretation. However, the PE board in some states can be pretty aggressive about the whole "practicing professional engineering without the proper license", and part of the guidelines they use to make that determination is if you use the term "engineer" to describe yourself. The feds have quality steered clear of the whole PE thing in codes/laws since it's essentially entirely state-run. The use of the term here might be an oversight that should be corrected as it doesn't seem that they intended to require a state-licensed "Professional Engineer", at least if the person doing the approval of the report is an agent of the company submitting it, nor did they define the term as such. A lot of "engineering" happens under the so-called "industrial exemption" where things are going to cross state lines and therefore aren't under the purview of the state licensing board, but infrastructure-based/wireline comm systems would likely not fall under that, so it comes down to if your state defines the operation of such systems (not necessarily the physical design and emplacement of them) as an engineering activity. Note that I am not a PE, though I have passed the FE. This shouldn't be construed as legal advice much less advice to your specific situation.
Re: Upstream bandwidth usage
On 6/10/22 20:17, Mark Tinka wrote: We've seen proposals from Huawei, for example, where OLT shelves can support both GPON and XG-PON line cards. Just not seeing our market going in that direction yet. This isn't just Huawei. I know at least Adtran can do GPON+XGS-PON in the same chassis, and I'm pretty sure I remember Nokia telling me the same. I'd imagine Calix can, too, if the other two big names in North America have it. I know at least Adtran even has a combo card where the same card can handle optics with all the filters built in to do XGS-PON+GPON on the same fiber without external muxes and only consuming one port. The pricing is even what I'd call not just reasonable but "compelling" for immediate deployment even if you don't plan to use the 10G function since it would of course drastically extend the useful lifespan of that card plus give you in-service upgrades to XGS-PON overlay if you equipped it with suitable optics from the get-go (which are also not overly expensive). Given that the parts clearly exist for combo cards with combo optics, I'd imagine all of the major players have it in their portfolio at this point. The XGS-PON ONTs are still about double the price of the GPON ONTs last I checked. -- Brandon Martin
Re: What do you think about this airline vs 5G brouhaha?
On 01/19/2022 03:47, Masataka Ohta wrote: That's not saturation. Saturation means a receiver does not have adequate dynamic range. With digital processing under saturation, effective number of bits is reduced. That is, some necessary bits are lost, which is not "everything that's there". I think we're saying the same thing, but with a different focus. Yeah, front-end overload will always be a problem if the overload is caused by an unwanted signal or if the overload is so severe that it causes distortion going into the next stage even if it's just from a desired signal. But even a moderately powerful signal that's outside your band of interest by as much as the entire width of the interested band shouldn't easily overload your frontend if you designed it reasonably, IMO. Obviously the separation at which point you say it's a receiver issue vs. a physics issue is something of a judgement call. Obviously it's my problem if my 2.4GHz Wi-Fi receiver is overloaded by the 500kHz 1MW AM transmitter next door, but who's fault is it if my low-band cell phone's 650MHz receiver is overloaded by the 50kW 400MHz UHF TV transmitter half a mile away? IF you had enough dynamic range to receive both your radar reflections and the 5G signal as attenuated by your front-end band-pass filter, you could use digital tricks (I would think, I Am Not A Radar Engineer, though do engineer RF comm systems from time to time) similar to spread spectrum to effectively get processing gain on your radar reflection vs. that "white noise" 5G signal, but of course none of these devices probably do that mostly because they're so old that they predate the concept or at least commercial deployment of such techniques which didn't become common until around the turn of the century. From the sound of it, at least some of these altimeters were designed around the (probably poor) assumption that there would be essentially no RF power within half a GHz of them, and that assumption is no longer going to be true. Was that a good design decision? Probably not, but we need to figure out what to do about it. This is more of an FAA problem than an FCC problem since it involves functional device performance rather than emissions. The FCC can (and should) attempt to balance the needs of existing users, including practical performance of their equipment as deployed, with the public good in terms of what has become spectrum that is very valuable (not just in $$$s but also practicality) bandwidth for wireless communications. That does, to some degree, involve nudging existing users to migrate to semi-modern best practices in order to more efficiently use their allocation. They've done this before with e.g. reducing bandwidth limits on FM voice in the VHF/UHF "business bands". -- Brandon Martin
Re: What do you think about this airline vs 5G brouhaha?
On 1/19/22 12:28 AM, Masataka Ohta wrote: Digital technology can not be useful when RF stage is saturated, which is why a patent to avoid saturation was essential for CDMA. Completely overloading the receiver frontend will of course render any kind of modulation or coding gain irrelevant, yes. However, as long as your receiver still has adequate dynamic range to receive "everything that's there", effective gain via spread spectrum, FEC, etc. can be on the order of 20-30dB compared to a naive narrowband system operating at similar power when faced with a "jammer" within your RF receive mask, which is what I was getting at. In this case, however, the system is basically a dumb radar, apparently, so none of that is going to be present. The fact that a signal 250MHz out of band can present meaningful issues is troubling nonetheless. -- Brandon Martin
Re: What do you think about this airline vs 5G brouhaha?
On 01/18/2022 20:08, Michael Loftis wrote: Remember that the RA is sub 1W looking for reflected emissions. It’s very possible the ground equipment for a cell base station to have spurious harmonics…where they land requires more RF engineering chops than I’ve got, and would obviously be very system dependent. So yes in my understanding due to the RF voodoo of how they transmit and receive This is run-of-the-mill testing for not just transmitters but anything that could possibly, maybe, emit RF energy in the USA. The out-of-band (spurious emission) limits are quite strenuous, and the test criteria are specifically designed to catch even fairly intermittent blips that might crop up just about anywhere let alone in a band of particular interest. There's a reason (just about) all FCC compliance houses have 70GHz spectrum analyzers even if they don't normally look at intentional emissions above 6 or so. One thing the FCC could potentially do to wipe some egg of their collective faces, here, is mandate that transmitters operating in this newly allocated wireless band face additional scrutiny for spurious emissions in the radio altimeter band as well as the guard band between the two services and a similar bandwidth above the radio altimeter band. If the quasi-peak detector runs across that swath for an hour while the operating conditions of the device being tested are continuously varied both within and somewhat outside its normal and even extraordinary (but functional) operating range and still doesn't see anything that isn't outside the femtowatt range, you're probably good. FAA and aviation industry can even advise on these standards. That's not unheard of and a good example of industry cooperation. Note that this would be above and beyond the existing general rules for spurious emissions that are already tested as part of pretty much any RF transmitter in the USA. I'm curious at what point the possibility of spurious emissions from an old-fashioned TVRO C-Band receiver becomes concerning. It would be very sporadic, but the gain off the ground station dish is rather non-trivial. AFAIK, the design of most receivers would mean it would have to be a modulation product of two LOs, but I suspect it's possible to have something come within 500MHz of this band just like this wireless allocation does. Those users have been around for 35+ years and are widespread and unlicensed (as they are receive only). -- Brandon Martin
Re: What do you think about this airline vs 5G brouhaha?
On 01/18/2022 19:48, Jay Hennigan wrote: Intentional broadband jamming isn't going to be very effective against an airplane as the jammer would need to be directly beneath a fast moving target and get the timing exactly right with microsecond accuracy. Just to clarify, I wasn't referring to intentional (and naive) "jammers" that simply attempt to disable a system, here, but rather using a more academic notion of the concept to refer to a 5G NR system acting in an unintentional context with the same outcome similar to how one might consider modern OFDM-based WiFi a "jammer" to a conventional narrowband communication system operating on the same or a nearby carrier frequency like the classic Bluetooth PHY. 5G NR is (or should be, from what I know of it and its relation to other OFDM systems) a pretty broad-band, flat-spectrum PHY operating at only moderate power and for essentially infinite duration in the scope of a radar receiver. It would by no means be an ideal means to disable such a system, but it does represent RF energy that the receiver needs to contend with. -- Brandon Martin
Re: What do you think about this airline vs 5G brouhaha?
On 01/18/2022 16:57, Mel Beckman wrote: Bo, it’s the radar altimeter, not the barometric altimeter. This is a radar distance measurement device for determine the precise height above the ground, critical for low-visibility approaches. Where frequency interference is concerned, under FCC rules the existing users have priority, and are entitled to interference-free operation. Hmm, I'm seeing that "radar altimeter" and "radio altimeter" can indeed refer to the same class of instrument, so perhaps there's confusion (perhaps including by myself). Nonetheless, while indeed existing users are granted some reprieve from interference by new users of other services, this is mostly in the planning stage of things and not the actual operations. The time to get this addressed would have been back when this portion of the band was re-allocated to wireless systems (from space-to-ground satellite systems) several years ago. Further, it seems that good engineering practice was not used in the design of these vulnerable systems and that they are subject to interference from broad-spectrum "jammers" (i.e. signals that, in terms of modulation and timing, don't necessarily correspond to what they're expecting to receive) transmitting well outside their allocated band (by separation comparable to the entire band in which they operate) let alone outside the expected, tuned frequency of signal reception. All of these are typically very high on the list of consideration when designing an RF receiver and seem to have been either ignored entirely or at least discounted in the design of these instruments from what I'm hearing. That is, I have yet to see any source (even from the aviation industry) claiming that there is in-band interference issues from the new wireless systems or that these radio altimeter systems somehow need such extreme receiver sensitivity that a several hundred-MHz guard band between services (with an existing service in between, albeit one with the transmitter usually in the other direction) is not sufficient to ensure proper receiver isolation from unwanted signals. -- Brandon Martin
Re: What do you think about this airline vs 5G brouhaha?
On 1/18/22 5:06 PM, Mel Beckman wrote: Incorrect. Owning spectrum also includes the right to interference-free operation. And you imply that the FAA and airline industry has done nothing, when in reality it’s the FCC who has done nothing. the FAA sponsored extensive engineering tests that demonstrate the interference is a concern, and they notified all the parties well in advance. The fCC et al chose to do no research of their own, and are basing all their assumptions on operation in other countries, which even you must admit can’t really be congruent with the US. Owning spectrum includes the right to interference-free operations from IN BAND interference (or not, depending on how you "own" it). The FAA and airlines are (presumably) correct that there is de-facto an interference issue. The FCC is also (presumably) correct that it's "not their problem" as the interference is due to grossly out-of-band signals, and the FCC has provided what they believe to be (and, according to most RF engineering practices I know of, is) a more than sufficient guard band between the two users. Interference from out-of-band sources is on the operator of the receiving equipment to correct EVEN IF they are a licensed, primary user of their spectrum since the interference is from outside their allocation. This is always true so long as the folks sourcing the interference are complying with the limits of their spectrum (there are some other wiggles for Part 15 unlicensed users) including power limits and applicable transmit spectrum masks. The FCC's job is to make sure that they set the rules such that folks with licensed spectrum do not experience practical problems when presented with out-of-band signals. When doing this, they attempt to use established guidelines of good engineering practice as well as reports from "the field", but they can't possibly account for users with what is arguably simply (very) faulty equipment. If my 1kW HAM FM radio transmitter on 145MHz causes receive problems on your aviation band AM receiver (108-137MHz), that is YOUR problem as long as I'm complying with all the rules and regs of part 97. That is, your receiver sucks, and you need to fix it - possibly by replacing it. Likewise, if I'm getting receiver desense issues on my 145MHz FM handheld near the airport because of ATC's AM transmitter a few dozen MHz down, it's on ME to fix it (or live with it). The issue that cropped up appears to be that, since the C-band spectrum under discussion went unused for so long, a LOT of sucky receivers got deployed, and nobody really noticed or cared. Now, it's a big deal to try to replace them all, and it's made even worse by how difficult changing anything in aviation is and how comparatively old and hence simple (perhaps too simple) the radio altimeter RF physical layer apparently is. -- Brandon Martin
Re: What do you think about this airline vs 5G brouhaha?
On 01/18/2022 16:34, Michael Thomas wrote: Is this the band that has really really short range for 5G? If so, it doesn't seem like a very big deal to give them the airspace on approaches. I mean, if you live under a flight path by the airport, not getting fast 5G is hardly your biggest problem. This is the C-band spectrum near 4GHz. The super short-range (or, rather, highly direction and subject to attenuation by almost anything) that you're probably thinking of is likely the UWB mmWave band up at ~30GHz. C-band has moderate structure penetration and limited foliage penetration. With line of sight and at the power levels the carriers would consider running, several miles of usable range would be unsurprising, though I suspect many typical deployments would have design cells smaller than that while using existing "4g" (and newly opened ex-TV broadcast space) low- and mid-band frequencies for wider area coverage at reduced speeds. Interference considerations, especially high above the horizon (planes...) would be present for potentially dozens of miles away. -- Brandon Martin
Re: What do you think about this airline vs 5G brouhaha?
On 01/18/2022 15:29, Michael Thomas wrote: I really don't know anything about it. It seems really late to be having this fight now, right? The issue seems to be old aviation equipment that has poor receiver selectivity on its radio (not radar) altimeter. This is, apparently, a secondary, but still very important, instrument for instrument approaches upon landing. This older equipment can be subject to meaningful interference by signals as much as 500MHz outside the actual assigned radio altimeter band limit. Note that the radio altimeter band is only about 500MHz wide itself, so even a naive single-conversion receiver could/should have better selectivity that this. The reason for this poor selectivity seems to simply be that, at the time, there was nothing else using the RF spectrum nearby, so they could get away with it, and it made the receiver somewhat simpler. The system apparently also responds poorly to both narrowband and wideband jammers i.e. it does not employ what we'd consider robust, modern error-correction or coding systems or even digital error checking techniques. Both of these are basically issues with how old the system is and how old a large amount of deployed equipment using it is. The former is probably hard to fix in a backwards compatible way, but the latter is mostly a matter of upgrading your instruments more than once every 25 years which, for planes that are actually routinely making use of this system (largely commercial and charter operators), doesn't really seem like that big of an ask. I think the issue is that the FCC did some rulemaking assuming that existing service users were being reasonable with their equipment design, then a giant game of chicken got started, and nobody blinked in time for anything to get done until a collision was imminent. The C-band spectrum at issue here has become very valuable, both economically and from a public usage perspective, for mid- and short-range wireless communications. The FCC allocated some of it based on "reasonable" expectations of existing users and provided an ample (arguably rather large) guard band between services. In the end, I'd say that aviation folks are in the wrong, here, but they also have a lot of history to contend with and a large install base of gear that, whether it "should" or not, apparently does need to be upgraded to prevent detrimental interference to an important flight safety and operations facility. A pause in deployment seems reasonable in that light, though it would have been nice if folks could have gotten this resolved sooner. -- Brandon Martin
Re: SOHO IPv6 switches
The Netgear GS108T is my typical go-to "not a dumb switch". 8 ports for about $80. Make sure you get the v3 if you want most of the modern IPv6 L2 features (you also get some very limited L3 capabilities). The v2 lacks most of them and is still readily available on the market. -- Brandon Martin
Re: ONTs
On 1/12/22 4:15 PM, Josh Luthman wrote: I would have to imagine any QOS/traffic shaping is done in the OMCI and hence would probably be in the GPON spec, g.984. I would look there. Just guessing it would hold true with XG/s/PON, NGPON, etc. The way at least my gear (Adtran) works is that you configure shaping/policing as part of the provisioned service. That information is communicated to the ONTs via the OMCI. AFAIK, the ONT enforces admission control on the upstream (and coordinates for timeslot assignments with the OLT since upstream oversubscription is supported and common), and the OLT enforces downstream egress control. You can configure whether you want rate control to be based on hard policers (instantaneous drop once CIR+CBS+EIR+EBS is exceeded) or whether you want it to "shape" the traffic by delaying things. The latter is usually more user-friendly and certainly easier to set up, but it can result in bufferbloat, and they don't provide very friendly knobs to tune the maximum queue length. I haven't heard any real complaints from folks. DSLReports gives me like a C for bufferbloat but doesn't really make it clear why. The queue is, at most, a few ms in depth. You can tell it to honor 802.1p CoS, IP ToS, or IP DSCP in various ways and map them to separate queues with separate policers/shapers and WRR priority. This is semi-automated if you are doing voice/video via their provisioning environment. YMMV on other vendors' gear.
Re: home router battery backup
On 1/12/22 9:35 PM, Jay Hennigan wrote:
From what I've seen on the market, home router or "residential gateway" devices with built-in battery backup typically only provide backup for FXS style analog POTS services, not for data, wireless, etc.
This was definitely the case for the Verizon FiOS I had about 14 years
ago. They're the only carrier I've ever used that provided regulated
("POTS replacement", at least) voice service by means other than POTS
and that automatically gave you a battery backup with their NID.
AT and Comcast don't seem to provide battery by default if you buy
voice service from them. Note that AT still offers POTS in my market
even where they've overlaid FTTC-based VDSL (U-Verse/Lightspeed) or
FTTH, which may be part of why. I assume they offer it as an option if
you inquire per the rules OP mentioned, but they don't seem to mention
it or do it by default even on their "business class" services.
Most of our customers don't back up their home network gear. If they do
it's most often an under-desk style UPS with 15-minute runtime that
hasn't been serviced in a decade. Its battery is very much dead and so
swollen that it can't be replaced without the use of some serious prying
tools.
This has been my experience as well. Even among customers with an
automatic standby generator, having a UPS for their "IT" gear seems
rare, and they're often uninterested. They just live with things
dropping for a minute or two while everything reboots/reconnects if the
power glitches.
The networks I operate (some of which I own and some of which I operate
on a contract-for-services basis) tend to only automatically provide
batteries in MDU/MBU settings where one ONT or other NID serves multiple
subscribers and is powered from house/common power. We do that because
power to the ONT/NID is then out of the hands of the subscriber, and
they wouldn't be able to put it on a battery if they wanted to as they
often don't even have physical access to it.
For SFU/SBU subscribers who inquire, we offer to provide and set up a
typical "desktop" style UPS like you mention or of course try to plug
the gear into one if they already have one. It doesn't take a big
battery to keep a single-port ONT and Wi-Fi router up for several hours
which is all most customers seem to hope for if they don't have a
generator. Obviously we charge for the UPS, though even with a modest
mark-up it ends up being comparable to retail pricing. We don't really
charge to set it up (how much set up is there?), but we also don't
attempt to monitor or maintain them; we treat it as a one-time purchase
and just do it to try to keep customers happy.
Based on seeing ONTs drop when I know there's a power outage in an area,
I'd say maybe 10% of the customers I manage operations for have their
ONT on a UPS tops. That's including the MDU/MBUs where we've provided
it (which accounts for maybe half or more of that 10%).
Note that none of the networks I operate offer voice service at all.
There hasn't been enough of a demand for it to deal with the regulatory
hassles. I'm mostly in residential and very small business, so they
either just use their mobiles or usually have some setup they're happy
with. I try to keep an ITSP with local service/support on-call to hand
referrals in case someone asks, and usually I can get them to do me the
same if they're working with one of their customers who are in the
market for better IP connectivity. It works out well enough.
Re: 100GbE beyond 40km
On 9/27/21 1:47 PM, Brandon Butterworth wrote: You're looking for SOA at 1300nm, like https://www.fs.com/uk/products/69350.html Getting much more power out of a SOA than a -ZR QSFP28 is pretty hard, though they could be used for non-OEO re-generation in the middle if practical in your topology. There does also exist a PDFA. Same concept, different dopant in the fiber. They are...expensive. However, you can get a crazy amount of power out of them, and they're available with a lower noise floor than SOAs seem to be, as well. If you really want to make that 80-100km link at 1310nm and without going coherent, they are a potential option. When I inquired with a manufacturer/rep (what appears to be the only one in the world), it was almost as expensive as a coherent transponder on both ends. -- Brandon Martin
Re: Squat space is now being advertised by AS 749 (DoD Network Information Center)
On 9/11/21 8:36 AM, David Bass wrote: When can we reclaim all this unused space from the US DoD? Serious question. I’ve never understood how they can just sit on this without having to do something with it. Remember, just because a prefix isn't in your routing table doesn't mean the address space isn't in use. The DoD uses a fair bit of the address space allocated to them on networks that are not visible from the public Internet. Whether they use it efficiently is, perhaps, another matter. -- Brandon Martin
AT Ethernet sales contact
Can anyone provide a sales contact at AT for Ehhernet transport in Indiana/Illinois/Ohio? Unicast replies welcome. -- Brandon Martin
Re: 1G/10G BaseT switch recommendation
On 7/22/21 2:46 PM, Drew Weaver wrote: Hello everyone, I’m looking for recommendations from the community on 48x10G RJ45/4-6 SFP28 (uplink ports) switches that people actually like working with. Features are VPC or non-vendor specific equivalent, L2/L3 BGP/OSPFv3, ACLs, functional CoPP and some sort of API to manage them. [the CLI would work, my lib can handle most Networking OS CLIs anyway] My problem point is coming from the RJ45 requirement, most vendors have one switch that they sell that is RJ45 at 10G or at the most one in each line (enterprise/datacenter) and they seem to be almost an afterthought. [probably because SFP28 is better in every way if you are already using fiber at the endpoint] sadly, we are not. I just want to make sure I am not excluding any vendors from my research. I appreciate any suggestions or recommendations. Can even keep it off-list if you want. Arista 7160-48TC6 gets pretty close to your requirements, I think. It has 48x10GBASE-T ports + 6xQSFP28 100GBASE-R. The QSFP28 support breakout with SR4 or PLR4 optics AFAIK , so you can use them for 25GbE if you prefer. You'll need the FLX-LITE license to officially get access to the layer 3 features IIRC. -- Brandon Martin
Re: Alien waves
On 7/20/21 4:44 PM, Saku Ytti wrote: I'm going to hazard a guess that the exhaustive list is empty. Allowing 3rd parties to launch alien waves to your system puts your existing waves at the mercy of the 3rd party, power or lack thereof from the alien wave may impact operation of other waves. While it might be different for subsea, especially transoceanic, simply due to market factors, I suspect this is the case on most long-haul routes of consequence. Even the carriers I've talked to who have it productized in their sales catalog with documentation as to the responsibilities of all parties essentially refuse to sell it in practice. The only traction I've gotten was if I wanted to buy half the C-band spectrum on a new route not yet lit and was willing to sign a very long-term (20 year-ish) contract for it. Essentially it was treated similar to an IRU on half the bandwidth on the route and came lit end-to-end. They were willing/able to do this since they could use red/blue filters and separate VOAs and OPMs to keep things in check at the entry/exit points of the line system. This isn't really practical if you're dealing with just a couple hundred GHz or have frequent need to add/drop it. -- Brandon Martin
Re: Technical resources for Open Access Fiber Networks?
On 6/9/21 8:16 PM, Mark Leonard wrote: Not so long ago I learned about Open Access Fiber Networks. I'm quite curious about how these are actually implemented. I'm able to find boatloads of marketing material and management-targeted boilerplate, but I've not yet been able to find any technical resources. My first thoughts were: * Are these just massive VPLS networks? * Are they just giant L2 networks? I can't imagine that either of the above would scale particularly well. I'm looking for any books / papers / config guides / magic tomes / etc on the subject. Can anyone point me in the right direction? I think part of why you're not finding a lot of technical information is that things built under the name "open access network" come in all shapes, colors, and sizes. Things I've seen: * Fully open glass: Point-to-point fiber from central location(s) to each individual service point. Providers co-lo at the central location(s) and bring their own backhaul to them (which the open network operator may offer turnkey separately) and buy usage of the fiber from the open network operator. They can run whatever they want on it. CPE is provided by the service provider. Multiple strands can enable multiple service providers simultaneously at the same customer prem, but the number of fibers grows reeeally fast. * Central split open PON: Each service point has one or two fibers to central split cabinets in the field, and service providers buy customer glass to the splitter cabinet, space in the splitter cabinet for passives, and backhaul glass to each cabinet in areas they want to serve. They run whatever they want on it via co-location in central PoPs which need not be active for everyone in the facility (could be another layer of a hierarchical split), but the cost/availability of the baukhaul glass generally implies a PON architecture (but it could be e.g. WDM-PON since you can put whatever you want at the field split locations). CPE is provided by the service provider. Multiple strands between the field split and customer prem, if available, enables the customer to buy service from multiple providers with each provider having their own glass path and CPE. * Open L2 access: Could be active-E, xPON, or some mix. The open network operator hands off customer services on either a VLAN/VLL-per-customer basis or just adds customers to your VLAN/VPLS(s) on demand. Service providers establish either a central NNI (open network operator handles regional backhaul) or co-locates with their own backhaul as above. This architecture favors customers being able to buy service from multiple provides at once via a multi-port CPE ONT handled by the open network operator, but sometimes that responsibility gets delegated out to the service provider. The open network operator is responsible for bandwidth management, etc. * Private label of central services: There's fundamentally just one network (per type of service, e.g. IP, linear video, voice, etc.), and service providers just private label it. They may or may not even get separate blocks of number resources. The open network operator is really responsible for everything except maybe end-user billing. Most people seem to be focusing on open L2 type systems as it provides the most rapid deployment of service with lots of "providers", but it requires you have a competent administrator of the open-access network which is often not the case. I've also seen open glass (of both forms) especially with geographically larger deployments. I've had munis and HOAs inquire about all types. I'm not sure I've ever seen anyone actually deploy the private label only variety since it doesn't actually provide much beyond just directly selling the whole-stack service yourself, but it's been talked about. A lot of DSL got deployed back in the day on a similar basis with service providers either co-locating in COs and buying dry pairs or re-selling someone else's DSL product (could be the ILEC or someone who already co-lo'd DSLAMs) with backhaul over ATM on a VPI-per-customer basis to a central NNI. Linear video has proven to be problematic on them since it's difficult/expensive to get retrans rights for small geographic areas which can make it tough to get providers willing to come in and offer it without some exclusivity arrangements. Thankfully, demand for linear video is rapidly dropping as people abandon it entirely or switch to over-the-top alternatives. My general "favorite" where someone does want to do open access is the central split open PON model with ample excess fiber on both the backhaul and customer legs, but it is situational of course. -- Brandon Martin
Re: MPLS/MEF Switches and NIDs
On 5/26/21 12:39 PM, Colton Conor wrote: Ciena seems to have multiple options available with Segment Routing, MPLS, and streaming telemetry support. I am probably most interested in what Ciena has to offer. Has anyone deployed the 3000 or 5000 product line of Ciena? How does it compare to Juniper? The Ciena 3924 is sub $1000 for example, and has 4 10G ports on it. I've used the Ciena 3000 series switches as NIDs a fair bit and have no real complaints about them aside from TAC being a bit loathe to give out new versions of SAOS even when the version you've got deployed is going EOL. I've not used the MPLS functionality mostly because it's a pricey software license add-on and I can get by without, but the MEF and associated carrier-oriented Ethernet functionality seems to be pretty much top notch in terms of feature set, stability, and configurability. I mostly use the 3928 though partially because the 3924 is new enough it didn't make it into my standard build-out BOM. The 3928 does also have redundant PSU (fixed, but there are two) if that matters to you. At sub-$1000, the 3924 is a good deal in comparison if it'll do what you need. If you've never used them, you might find the config language a bit annoying in that it's more Yoda syntax than Cisco, but it's also more consistent than Cisco (what isn't?), so it's got that going for it. Documentation is alright. TAC is responsive to inquiries. -- Brandon Martin
Re: DoD IP Space
On 1/20/21 1:48 PM, Owen DeLong wrote: Do you think this still holds true if DoD were to (e.g.) sell that space to $CLOUD_PROVIDER or $ISP or $SUPPLIER or…? I don’t have any knowledge of any events surrounding this space currently, but I do know that press releases and congress have discussed that possibility, so it cannot be ruled out. This is a risk you take when using squad space of any form. DoD space is somewhat uniquely "safe" in this regard but not immune to such things. Honestly I'd be just about as worried as a potential legitimate non-DoD public Internet user of that space about reachability issues as I would as someone squatting on it internally within my network about it becoming a part of the common global routing table. I also suspect your typical large corporate environment cares less about broad, global reachability than other Internet users in many cases. -- Brandon Martin
Re: DoD IP Space
On 1/20/21 12:52 PM, John Curran wrote: > > While route hijacking isn't necessarily an ARIN issue, I will note > that several US law enforcement agencies (FBI & NCIS Cybercrime units) are > quite interested in such events and do investigate them looking for criminal > activity. > > (See > https://pc.nanog.org/static/published/meetings/NANOG77/2108/20191028_Elverson_Your_As_Is_v1.pdf > for details.) > I think the difference is semantic but a very important one nonetheless. Announcing a netblock that isn't yours and that you don't have authorization to use to others under the same terms and assumptions as you announce those to which you do hold legitimate rights or otherwise purporting to be a legitimate user of them on what we know as the "public Internet", that is the Internet where numbers are managed by IANA and the relevant RIRs is a "big deal". Using numbers in a manner contrary to how they are assigned on the "public Internet" within a more limited scope where everybody agrees that the use of such numbers may be contrary to IANA and relevant RIR assignments is more along the lines of "you operate your network however you want". Other things would fall under the same purview. For example "alternate root" DNS hierarchies with extra TLDs or even TLDs used in contrast to ICANN recommendations would have similar considerations. -- Brandon Martin
Re: DoD IP Space
On 1/20/21 9:58 AM, j k wrote: My question becomes, what level of risk are these companies taking on by using the DoD ranges on their internal networks? And have they quantified the costs of this outage against moving to IPv6? Honestly I can't think of much unless maybe they're a defense contractor that would potentially end up with DoD ranges (non-isolated/classified networks) in their view of the global routing table. Appropriately treating it like "my networks" and/or RFC1918 in your routing policies (not exporting it, not accepting routes for it, etc.) would be required to properly ensure network stability of course. Some OSes treat RFC1918 space as inherently "special" (extra trusted, etc.) and wouldn't treat the DoD ranges as such, but those behaviors are typically undesirable or at least not relied on on a network of that scale, anyway. Not that I'd recommend it. -- Brandon Martin
Re: Hosting recommendations ... ?
On 1/19/21 12:56 PM, Bryan Holloway wrote: I'm very curious about your assertion: Is nested virtualization really a thing? I mean, I'm not exactly trying to render Pixar's latest movie ... just trying to push some bits around (light web-sites, some e-mail ...) It just seems inherently prone to issues. Could you back this up with any white-papers or documentation on the subject? I'm genuinely interested ... With KVM, if you have a recent kernel and qemu, it pretty much "just works" on supported hardware. AFAIK Xen supports "Xen on Xen", too, but I haven't used it and don't know much about it. The use case is pretty much exactly this. You (the product consumer) are handed a product that amounts to a virtual machine on somebody else's $BIGBOX. You want to deploy multiple virtual machines where you have direct control over their lifecycle, configuration, etc. and can bring in additional I/O resources, etc. at the hypervisor level (consider that, with KVM, the Linux kernel basically IS the hypervisor). So, you run one or more VMs inside the top level VM that you're handed. It's full of lots of little wiggles and can be a pain to maintain if you have visibility into both levels of the equation, but it does seem to work and is surprisingly performant. See e.g. https://tips.graphica.com.au/nested-kvm/ -- Brandon Martin
Re: Hosting recommendations ... ?
On 1/19/21 1:50 PM, William Herrin wrote: I haven't used Proxmox but from a 60 second glance through Google that looks like you're asking for nested virtualization. If it works at all, you'd take a double-hit on everything that wants to run in ring 0, a double-hit on virtualized I/O and a double-hit for OS overhead making the result more than a little sluggish. Kinda has "bad idea" written all over it. KVM, at least, and I think Xen as well, have some features for "shunting" I/O and hypervisor calls through to the bare-metal hypervisor where possible and avoiding double processing and trampolining. It's not nearly as bad as you might think in terms of performance as long as the hardware supports it (nested page tables being the big one). The little I've played with it mostly has proven to be an administrative hassle rather than performance. I would not recommend mixing and matching hypervisors (e.g. Xen on KVM or vice-versa), though. I'm not even sure you can do so meaningfully, though I bet someone's working on it. -- Brandon Martin
Re: Hosting recommendations ... ?
On 1/19/21 11:44 AM, William Herrin wrote: Cloud = you get virtual servers with virtual storage, generally adjustable to meet your needs. You manage the operating systems and storage within the virtual environment. You DO NOT manage the host operating systems or hypervisors. It's worth pointing out that nested virtualization is a thing these days, and some providers might even support it! That means you could buy one large instance and sub-divide it yourself into multiple VMs if you want to. In practice, unless you need that flexibility to dynamically spin the VMs up and down with various specs AND don't want to or cannot use a provider's API for that, I'm not sure why you'd want to if you didn't have to for some crazy reason. -- Brandon Martin
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On 1/5/21 7:29 PM, Chris Adams wrote: I don't know if an unsubscribed cell phone gets the emergency alerts (I know you are supposed to be able to call 911 from any cell phone, even if not carrying paid service). If so, that'd be another cheap way to get alerts. They pretty much universally should as long as they still have a SIM in them (or are eSIM/ESN-only devices) to give them some idea of their preferred network to which to register. Even if not, they're supposed to register with the "best network available" for emergency calling and alerting only, though I'm not sure how robust that is. I have definitely received SMS-broadcast emergency alerts on an "inactive" phone that was on and not in airplane mode for various reasons, so it does seem to work. It was a CDMA2000 ESN-only device, though, so still had provisioning info. I usually keep such devices in airplane mode, if they're still in use, though, and obviously then the cell radio is inactive so no alerts.
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On 1/4/21 9:07 PM, Masataka Ohta wrote: > but harder to understand for people who lack precise > knowledge on what computers and OSes are. Hi, embedded developer here who spends a considerable amount of time writing firmware for "bare metal" systems with "no OS". I have fairly high confidence that what Mike was referring to was "whatever base level software ships on the doohickey and provides the underlying infrastructure for the user-visible 'apps' that move media from the Internet to the monitor". Mike, please correct me if I'm wrong. In that context, it doesn't really matter what the box is running. Could be Linux, could be Windows, could be QNX, could be a "while(1) scheduler" and some embedded IP stack. Anything smart enough to fall under the purview of the discussion we're having regarding "streaming services" is going to have some sort of "OS-like" infrastructure that could, if desired, centrally handle these kinds of alerts so that every single streaming "app" doesn't have to concern itself with that. I can't fathom somebody making a "media streaming device" these days without that kind of separation of duties internally regardless of what actually runs underneath the user-visible application. It's not that you couldn't but rather that you wouldn't. -- Brandon Martin
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On 1/4/21 10:01 AM, Masataka Ohta wrote: Any device with speaker should produce audible alert and any device with display should produce visible alert. I'm not sure typical North American residential construction could tolerate the sonic pressure generated by such a "goal"... Streaming devices, sure. They're in-line with conventional distribution channels for emergency alerts such as television, radio, etc. That would include "smart speakers", TV streaming sources, etc. But my refrigerator, washing machine, etc. does not need to do this...many could (they have Internet connectivity in some cases), but that's just overkill and honestly silly. I'm also of the mindset that, in the end, the owner/operator of a given device should be given the authority to disable emergency alerts on that device. It's their device, after all. They may have other ways they prefer to receive such alerts, or they may want to die in a tornado. I'm not going to stop them. Conventional devices like TVs only alert when on, and things like weather radios can be placed into a non-alerting mode without losing other owner-relevant functionality. I'll note that most mobile phones allow the user to turn off most (though usually not all) emergency alerts. Non-OEM OS ROMs often go further. -- Brandon Martin
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On 1/3/21 4:22 PM, Mark Delany wrote: Creating quiescent sockets has certainly been discussed in the context of RSS where you might want to server-notify a large number of long-held client connections very infrequently. While a kernel could quiesce a TCP socket down to maybe 100 bytes or so (endpoint tuples, sequence numbers, window sizes and a few other odds and sods), a big residual cost is application state - in particular TLS state. Even with a participating application, quiescing in-memory state to something less than, say, 1KB is probably hard but might be doable with a participating TLS library. If so, a million quiescent connections could conceivably be stashed in a coupla GB of memory. And of course if you're prepared to wear a disk read to recover quiescent state, your in-memory cost could be less than 100 bytes allowing many millions of quiescent connections per server. Having said all that, as far as I understand it, none of the DNS-over-TCP systems imply centralization, that's just how a few applications have chosen to deploy. We deploy DOH to a private self-managed server pool which consume a measly 10-20 concurrent TCP sessions. I was thinking more in the original context of this thread w.r.t. potential distribution of emergency alerts. That could, if semi-centralized, easily result in 100s of million connections to juggle across a single service just for the USA. While it presumably wouldn't be quite that centralized, it's a sizable problem to manage. Obviously you could distribute it out ala the CDN model that the content providers use, but then you're potentially devoting a sizable chunk of hardware resources at something that really doesn't otherwise require it. The nice thing is that such emergency alerts don't require confidentiality and can relatively easily bear in-band, application-level authentication (in fact, that seems preferable to only using session-level authentication). That means you could easily carry them over plain HTTP or similar which removes the TLS overhead you mention. Several GB of RAM is nothing for a modern server, of course. It sounds like you'd probably run into other scaling issues before you hit memory limitations needed to juggle legitimate TCP connection state. -- Brandon Martin
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On 1/3/21 3:11 PM, Jay R. Ashworth wrote: Well, TCP means that the servers have to expect to have 100k's of open connections; I remember that used to be a problem. Out of curiosity, has anyone investigated if it's possible to hold open a low-traffic, long-lived TCP session without actually storing state using techniques similar to syncookies and do so in a compatible manner? I suspect no since you don't have control over your peers sequence numbers, but then someone smarter than I came up with syncookies... -- Brandon Martin
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On 1/2/21 8:41 AM, Masataka Ohta wrote: As streaming services are often offered from distant places including foreign locations, generations of emergency alert packets *MUST* be responsibility of *LOCAL* ISPs. I mean, if you know where you are, it's trivial to ask various services that already exist (in most cases, in some form) if there are emergency alerts for your location. It wouldn't be hard to make this a pubsub type system so that a device can just subscribe to it and be notified if it happens over a "NAT is everywhere" friendly long-term TCP session with TCP and occasionally application-level keepalives. Media streaming devices could essentially do this now. The governments which publish this information could help by running services that make this data more readily available in standard formats and with well-known locations and APIs. IDK if they currently do that. This is, IMO, how the Internet is supposed to work. Somebody makes content available. If you want it, ask them for it. The network just moves the data. ISPs are not typically in the business of flinging unsolicited traffic at endpoints. We're not cable companies (or at least some of us are not). And, as you point out, unsolicited UDP traffic is almost guaranteed to get dropped even if you have end-to-end address transparency as stateful firewalls are quite common even then. What the ISP can potentially help a lot with is having some easily-discovered service to provide the ISP's notion of "where am I (probably)?". I wouldn't expect E911 levels of granularity on this, or at least I don't think that's a reasonable request to make of most ISPs as that would require live data from DHCP, billing, etc. all to be put together in ways that could be difficult and cause security or privacy concerns. What I think IS feasible is something along the lines of a response that says "Well, the gear you're terminated on hosts customers within this city or zip code or whatever, so that's where you probably are." This is largely static data that you can infer based on large IP swaths (many ISPs already essentially put it in their synthesized rDNS) for many common configurations and is sufficient for filtering most kinds of emergency alerts. Devices which have GPS can obviously supplement/replace with their own location data. Devices which have access to Wi-Fi/Bluetooth beacon location databases can largely do the same. This is almost guaranteed to be more accurate AND more precise. -- Brandon Martin
Re: [External] Re: 10g residential CPE
On 12/27/20 5:26 AM, Mark Tinka wrote: I'm just not sure where all that Li-Ion will go after 15 - 20 years of use, though... One European manufacturer (the one whose battery I bought) says that as of now, they can only recycle 20% of each battery they sell. To me, that sounds like just the metal case enclosure, and the plastic facia. Ah well, maybe disposal tech. for Li-Ion storage will have improved by 2040. Interestingly, the Lithium content is the, in theory, valuable part of it. There's not actually much Li in a typical Li-Ion rechargeable battery (much less than a Li metal primary cell), but my understanding is that it's enough to have people interested considering that we're already basically consuming the world's Lithium supply just about as fast as we can economically mine and refine it. However, that may account for the apparently low recyleable content of a given battery. By mass and volume, it's mostly electrodes, which are common metals, and paper separator which is worthless. I would imagine that, as "dead" Li-Ion cells become more available and demand presumably continues to rise (absent a better battery tech), folks will get more serious about recycling the electrolyte. -- Brandon Martin
Re: 10g residential CPE
On 12/24/20 7:13 PM, Steven Karp wrote: Copper 2.5 Gbps Multi-gig uplinks on Wifi 6 gateways are coming out in 2021 from most vendors. I am using XGS PON in trials and have been impressed with the speed and cost. Pretty much this. XGS-PON seems to be "here now" and the costs on both the CO and CPE side have gotten down to where it's probably worth going straight to it (skipping GPON) in new deployments unless you think you can get away with just GPON for 5+ years. I'm not sure if it's worth overlaying existing GPON deployments yet, but we're getting close, and offering "multi-gig" is, while still not very useful from a practical point of view for most customers, a potential marketing advantage. I've been only recommending GPON for new, greenfield deployments in rural situations where expected speeds are low to begin with, density is low, and there may be a desire to push the optical link budget as it is a bit better than typical XGS-PON systems. That's been the case for about a year, now. Customer facing routers are not quite there, yet. I think Asus has one, but I've seen mixed reviews. And what's out now is still limited to 2.5GBASE-T and often only on the WAN port (LAN ports are still 1000BASE-T) meaning in practice customers can't get any more than gigabit speeds to a single endpoint (not that many endpoints can keep up, anyway) for that all-important speed test. One of my router vendors has been teasing me with a "true 10Gb" router due out 1Q 2021. I've been told to expect NBASE-T (1G, 2.5G, 5G, 10G) on both WAN and all LAN ports + 802.11ax "Wifi 6" with at least 5Gbps of real-world IPv4 throughput with NAT and essentially wire-speed IPv6 without NAT or content inspection at a realistic price point. I'll be interested to see what they actually deliver as that would make future-looking multi-gig deployments actually meaningful. Of course, you can replace XGS-PON with 10G-EPON if that's your preference. I actually kinda prefer the IEEE versions, but most of my vendors concentrate on the ITU/Bellcore stuff in North America, so GPON/XGS-PON it is. -- Brandon Martin
Neteng field laptop/tablet
Sorry if this is perhaps a bit OT... Can anyone recommend a smallish (10-13" display), relatively lightweight tablet or laptop (or convertible) with a native PCIe multi-gig Ethernet port, ideally both 10GBASE-T + 2.5GBASE-T (and 5GBASE-T perhaps). I'm not seeing a lot out there, and it's hard to search for multi-gig in a laptop at this point. Failing that, I'm sure someone has a recommendation for a similar device with native PCIe 1000BASE-T + a thunderbolt or similar port I can hang a dongle off of? Ruggedness is useful but not essential. 6-8 hour practical battery life is important but almost implied these days. Must be able to nicely run Linux (distro is unimportant). -- Brandon Martin
Re: Newbie Questions: How-to remove spurious IRR records (and keep them out for good)?
On 10/30/20 9:26 PM, Rubens Kuhl wrote: > 1 - You should worry a little, but not much. Filters allowing unwanted > announcements might be created using these erroneous IRR records, but > they won't do any damage by themselves. An actual wrong BGP > announcement is required for any damage to happen, and even without > those IRR records, a wrong announcement will cause some havoc since > not everyone builds filters based on IRR and not everyone runs RPKI > validation. I've had problems where people who build filters on IRR will build their filters SOLELY based on IRR. That is, they are not permissive and will assume that, if there is an IRR object present for a prefix, that ONLY the announcements matching that object should be accepted. This can lead to severe reachability issues if not corrected. -- Brandon Martin
Re: att or sonic "residential" fiber service at a "nontraditional" residence.
On 11/1/20 8:20 PM, Mark Seiden wrote: (would this violate some tariff? could they refuse to install?) AT's fiber service is not a tariffed service anywhere that I know of. They absolutely could refuse to install it at what they deem a "business" location and likely would. I know Comcast will only install "Business Class" service at what they deem "business" locations. I assume this is, in both cases, due to the substantially higher margin on "business" services. As to what Sonic would do, I have no idea. Their market model is quite a bit different. I also can't imagine they're actually overlaying AT's fiber-to-the-prem network as, to my knowledge, AT does not allow 3rd party access to it in any market. -- Brandon Martin
Re: 100G over 100 km of dark fiber
On 10/30/20 10:27 AM, Vincentz Petzholtz wrote: If it’s just a single 100G channel needed you could try 100GBASE-ZR4. Specified for 80km, 30db power budget they could actually reach more the 80km. Dispersion should also be „no" problem in the 1310nm length. I have to say that I never tried this on 100km distance without coherent solutions. If you end up marginal with the ZR4 at the receive end, you may be able to use a silicon optical preamp to make up the margin. If you are at the noise floor already (ZR4 receivers are pretty good), you may just need to dump more power into the line. I recently came across the PDFA (like an EDFA but the fiber is doped with Praseodymium instead of Erbium) which operate on the 1310 band and can push upwards of 20-23dBm of power out. They are not cheap (low 5 figures), but they are cheaper than coherent and will still let you run on 1310 so you don't have chromatic dispersion issues. With good (ER4 or ZR4) receivers good down to -20dBm or so, you've got 30-33dB of link budget which should just about make your 100km if it's decent fiber. They're also usable as a pre-amp (different configuration optimized for gain and noise figure instead of power, similar to EDFA preamps) and have performance potentially better than silicon amps in that situation. The 1550 PAM4 pizza box EDFA+Mux+DCM that others have mentioned may also work and end up even cheaper, but I normally see those for 40-60km or "up to" 80km with them really pushing the link budget at that point. Honestly, I'd be tempted to just suck it up and do a coherent solution, though I admit it would probably be at least 2x the cost. You can probably get a 200G carrier, though. -- Brandon Martin
Re: cheap MPLS router recommendations
On 10/21/20 4:27 PM, adamv0...@netconsultings.com wrote: Just to clarify what cheap means, ideally -$2000 to $4000 new -new is preferred as buying used kit on second hand market one is at the mercy of the price fluctuations and availability. Do you want SFP or BASE-T on the 1Gb ports? -- Brandon Martin
Re: cheap MPLS router recommendations
Most Arista boxes can do pretty much full MPLS (with appropriate honor-system licensing) as long as you don't need full-table Internet PE capabilities. At those bandwidths, you could easily get a used box off eBay and put it back under support (for more than you paid for the box) if you wanted to save some $$$. Extreme SLX is essentially the same thing with a different badge and a different licensing structure. An old Brocade (now Extreme) NetIron CER-4X (which is still supported and sold but nearing end of useful life for most providers) might even meet your needs. You wouldn't need the enhanced route scale hardware which makes them cheap on the secondary market. Avoid the CES even though it ostensibly does what you want. The MPLS signaling on this platform is probably a bit more mature but also perhaps lacking some modern niceties. Cost is probably not compelling if buying new, but IDK what they're actually selling them for these days. Don't expect high-touch features like you might get from an ASR or MX, but if you just want to push/pop labels, signal L2/L3VPNs, participate in IGP with on-net routes, and move data around, they'll do the job with decent North-America facing sales and support facilities. At those bandwidths and low port counts, you can also potentially use FRR or Quagga on Linux or *BSD on a suitably sized PC platform. Linux has usable MPLS support these days, though documentation is a bit lacking. One of the BSDs has had it longer and may be more thoroughly documented. -- Brandon Martin
Re: Cogent Layer 2
On 10/15/20 6:15 PM, Robert Blayzor wrote: On 10/14/20 1:56 PM, Shawn L via NANOG wrote: When I last spoke to them, it sounded like they were using a bunch of LAG groups based on ip address because they _really_ wanted to know how many ip addresses we had and what kind of traffic we would be expecting (eyeball networks, big data transport, etc). Not why IP addresses are even an issue on an a "Layer 2" service. But then again, this is Cogent we're talking about here. Hashing on LAGs within their core. Even otherwise fairly braindead Ethernet switches often hash on L3 to try and get more entropy. I hope they hash on L2 MAC, as well, but a pretty common scenario for an L2 interconnect only has one MAC on each end of the link, so that doesn't help much. They rallly don't want all your traffic ending up on one side of a LAG. -- Brandon Martin
Re: Ingress filtering on transits, peers, and IX ports
On 10/13/20 9:40 PM, Nikolas Geyer wrote: Tl;dr - definitely don’t accept your own prefix from the site it originated from, or other sites that have internal connectivity. But also don’t assume that an AS has a full-mesh of internal connectivity behind it and shouldn’t accept its own prefixes for any reason. While I can understand some reasons why people don't do it, I believe the proper thing to do in this case is have multiple ASNs - one for each island. They obviously have distinct routing policy and thus qualify at least under ARIN policy AFAIK. With AS4, we don't have any imminent shortage of ASNs and don't need to be particularly stingy about allocating them as long as a need is met. -- Brandon Martin
Re: Hurricane Electric AS6939
On 10/13/20 7:29 PM, Aaron Gould wrote: Do y’all like HE for Internet uplink? I’m thinking about using them for 100gig in Texas. It would be for my eyeballs ISP. We currently have Spectrum, Telia and Cogent. They're a good bulk/budget option in a blend. A decent number of content hosts are keen to source traffic into them. I would be loathe to be single-homed to them, but even then they're not the worst option in that department. If you've already got Telia, Spectrum, and Cogent, 6939 is probably a great addition to your blend. They'll probably want a 5yr contract out of you to get their best (and headline per-Mbps) rate. Evaluate carefully what position that puts you in based on the continually dropping cost of wholesale transit and bulk interconnect opportunities. You may prefer a shorter contract term at slightly higher rates. As others said, if you don't need full routes from them, they have a VERY open peering policy, and that 100G port might be better suited to a local IX where you can pick them up along with a bunch of other content networks. -- Brandon Martin
Re: Passive Wave Primer
On 10/13/20 4:01 PM, Mike Hammett wrote: It seems incredibly simple to do, depending on the capabilities of your platform. What am I missing? If the span between the mux/demux pair is entirely passive, it's fairly straightforward. That's going to limit distances to around 80km or so with conventional systems or maybe 120km with systems designed entirely around modern coherent optics. If there are photonic devices in the span, you now have customer-supplied light being part of the rainbow that those photonics have to handle. Balancing things at amplifiers requires careful coordination with the customer (or adding a separate managed/monitored VOA for each alien wave which somewhat defeats the point). You end up with a scenario where a customer can do something screwy and potentially affect other waves on potentially multiple spans which your big-name carriers are obviously completely freaked out by. It's obviously possible, but the operational headache seems large enough that the major mid-haul and long-haul carriers I've talked to (all North America and all midwest, for that matter), don't seem to want to sell it despite all the major optical transport platform vendors not just supporting it by heavily pushing it. I really do hope it becomes a real product that I (as a smaller, local island operator) can buy, but it just doesn't seem to be there yet at least in my region. -- Brandon Martin
Re: Passive Wave Primer
On 10/13/20 3:35 PM, Tony Wicks wrote: We sell some wavelengths on passive CWDM/DWDM path's between Datacentres (less than 80Km) to customers to spread the cost of leasing the dark fibre. But yes, as far as long distance (apart from bespoke offerings) I'm yet to see a productised alien wave service. If you are spending all that money on OTN kit the extra cost of the transponders is not really significant I suppose. It's in some providers' catalogs (amazingly) but they seem loathe to actually sell it when asked. Even then, you're spot on with the description of "bespoke". I saw Zayo's product description sheet for it, and, while it did seem to check the boxes I'd expect, it was also quite expectedly very complex (they also wouldn't actually sell it to me). At less than 80km, you don't have to worry so much about balancing light levels, etc. as you can usually just throw things straight into a mux/demux on each end and rely on the power budget of the transceiver itself, so that makes sense for cheap DCI. -- Brandon Martin
Re: Passive Wave Primer
On 10/13/20 8:27 AM, Rod Beck wrote: Looking for a tutorial on passive waves. How it works. Pros and cons. . If you're talking about what I think you are, the term the folks who make the transport gear seem to use is "spectrum" as in you (as service provider) sell your customer some portion of the WDM transport spectrum. It typically comes in 50GHz increments or sometimes 100GHz corresponding to the standard ITU channel system but not always. To the service provider, this is then an "alien wave" in that they have essentially no control or visibility into it other than light shows up, and they're responsible for getting it to the other end of the path with acceptable path characteristics. I have yet to find a service provider that is actually willing to sell this even when they have it in their service offering catalog. The difficulties of coordinating everything with the customer are so extreme that it seems to usually make sense to either lease the customer dark fiber or capitalize the transponders needed to carry it as a managed wave on the provider's transport system. Might make sense if you literally want half the spectrum on a long-haul span or something. -- Brandon Martin
CyrusOne Sales Contact?
I've been trying unsuccessfully for the past couple weeks to get in touch with the sales folks at CyrusOne. E-mails and voicemails have gone unreturned. Anyone have a usable contact there or able to matchmake? -- Brandon Martin
Re: Ipv6 help
On 8/26/20 12:48 PM, JORDI PALET MARTINEZ via NANOG wrote: I work and I'm in touch with many CPE vendors since long time ago ... many are on the way (I can remember about 12 on top of my head right now, but because contracts, can't name them). It takes time. However, in many cases, they just do for specific customers or specific models. I know other people that contacted the same vendors and they told them "we could do it for the model you use as well". In some cases, they require a minimum volume per year (less than what you could expect. I've seen cases that start with just 500 units per month). But this only works if you contact them. The CPE vendors business model seems to be very "ISP" direct. I think the retail marked models, unfortunately, will take a bit more time. A hint about some vendors: You may take a look at the co-authors in the RFC. The whole point here is not that some vendors can support these features in a semi-custom firmware image that's specific to a particular ISP deployment - I know that's a possibility and have vendors willing to work with me on a much smaller volume than even what you've indicated - but rather what about customers who want to "upgrade" their router or, for whatever reason (and there are some very valid ones) want to provide their own. Right now, it's essentially impossible for them to walk into a local retailer and walk out with a model that they know for sure will work with my network if I'm requiring e.g. 464XLAT for basic functionality. Even if they buy online and dive fairly deep into model documentation, it is still hard to come up with a model that they know will work, and the lack of documentation will limit their choice of models unnecessarily (i.e. there are probably some options that support the necessary functionality but don't advertise it in the slightest). If someone wants me to provide them with a router, then of course I'll hand them one that I know works on my network. That's easy since I have control over the selection of it (and have presumably done some testing) even if I don't have my own provider-customized firmware. I'll point out that 500 new services (taking a new router) per month is not a particularly small provider. It's not large, no, but it's also a lot bigger than many deployments are at least when they're new, and these are questions you have to essentially answer "up front" in many cases. -- Brandon Martin
Re: Ipv6 help
On 8/26/20 2:48 AM, JORDI PALET MARTINEZ via NANOG wrote: This is why we wrote RFC8585, so users can freely buy their own router ... It's a great RFC. Hopefully it continues to gain traction. Do you know of a single router available in the US (or even broader North American) retail market that has "RFC8585" printed anywhere on the outside of the box or even in the documentation one might actually consult pre-purchase? I would love to evaluate it (or, even better, a few of them) to ensure I'm compatible on the provider side with how the equipment makers have interpreted the RFC! Then I can also have some specific models to direct people toward along with "Or just look for 'RFC8585' on the box". But, right now, I am aware of none. -- Brandon Martin
Re: Ipv6 help
On 8/26/20 4:49 AM, Bjørn Mork wrote: You aren't forcing anything if you allow the users to use any CPE and document the features it must/should have. You want IPv4 access without DNS? Then you need CLAT You don't know what CLAT is? Call your CPE vendor for support You don't care what CLAT is? Use our CPE You want to call us for support? Use our CPE There is no force here. It all is pretty similar to You want to connect the CPE to our ONT? Then you need Ethernet etc. excluding all those TokenRing routers. I don't force them to. I was countering the other arguments up-thread from folks who do so, and I understand why they do. I'd say easily 90% of my customers take my offered RG-CPE without any questions whatsoever - they in fact have come to expect that I provide one. Of the remaining 10%, easily half or more of them are satisfied with the RG-CPE I provide after I explain a few things about it (and I have a cut-sheet for the support folks to do so where applicable). They mostly want to know that it's not a braindead piece of crap presumably because they've had bad experiences in the past with SP-provided RG-CPEs (e.g. AT U-Verse). It's the remainder I'm talking about. It's almost all "power users". but even where they do have a fairly firm grasp of basic and even moderately advanced home/SMB networking, they're often unfamiliar with SP-side features that have cropped up and start to burden the routers such as IPv6-IPv4 transition features. This is what I'd like to address in a more streamlined manner. To wit: It would be nice if the consumer router industry could get its collective act together and at least come up with some easy-ish to understand feature support table that customers can match up with their service provider's list of needs. If you create such a feature table as the service provider, and the customer is unable to match it against their CPE documentation, then that's a problem between the CPE vendor and the customer. I can't understand why you want to make it your problem, as long as you offer a CPE that just works. I would LOVE to be able to just create such a required features table. The issue is that there are virtually no retail (even niche online channels) CPE devices that clearly document their capabilities to match up with my feature table. That's what I'm whinging about that the retail RG-CPE industry really should address, IMO. I can adopt best practices to make sure I provide configuration info via the proper DHCP(v6) options, attempt to delay making such features mandatory by providing e.g. NAT444 fallback, etc. as long as possible, etc., but eventually, people are going to have to migrate to equipment that supports these more modern features or be left behind, and, right now, it's very tough to even identify whether a device you're looking at in Best Buy or WalMart supports them or not (leaving aside the fact, for now, that the answer is often "it doesn't"). So, I'm left with the "do what works" option of attempting to enumerate models known to work. Nobody likes this. Customers feel like they're unnecessarily constrained, and service providers have to maintain that list and deal with questions about it for something that should be 100% a customer decision. Or, I can just say "You have to use our RG-CPE otherwise you're on your own and I can't guarantee anything useful will even work.", and that's not a good way to sell service to the handful of generally outspoken customers who do want to do things their own way. -- Brandon Martin
Re: Ipv6 help
On 8/25/20 3:38 PM, JORDI PALET MARTINEZ via NANOG wrote: This is very common in many countries and not related to IPv6, but because many operators have special configs or features in the CPEs they provide. I really, really hate to force users to use my network edge router (I provide the ONT, though, and I provide an edge router that works and most users do take it), but it can be tough to ensure users have something that supports all the right modern features and can be configured via standard means. It would be nice if the consumer router industry could get its collective act together and at least come up with some easy-ish to understand feature support table that customers can match up with their service provider's list of needs. The status quo of a list of devices that work right (which is of course often staggeringly short if you're doing any of these modern transition mechanisms) that needs constant updating and may not be easily available is not ideal. Heck just having a real, complete list of supported features on the model support page on their website would be an improvement... -- Brandon Martin
Re: Ipv6 help
On 8/25/20 12:28 PM, Ca By wrote: I am aware of other big CPE makers too, but this is the public one providing product today. Also, anything based on OpenWRT works... which is increasingly the base vendors build on. Last I asked SmartRG (Adtran), they were supporting 464XLAT with CLAT, though I haven't verified that it works. They're at least acknowledging demand for it which is a nice step forward. -- Brandon Martin
Re: Fiber Automatic Transfer Switch
On 8/17/20 3:33 PM, William Herrin wrote: I want to dissuade you from using this architecture. When you have two paths, it's important to keep them both lit so that you can detect faults and correct them in a timely manner. The most intractable problem with active/failover architectures is that the failover proves inoperable when it's needed. The old backup tape that doesn't restore. Keep your layer-1's active all the time and do fault handling at a higher layer. They have their uses - mostly protecting layer 1 products sold as such but also protecting things that can't be protected easily at higher levels such as RFoG. However, if you're using them to sell protected layer 1 products (protected waves or OTN paths, basically), it's important to make sure you have at least some active traffic on the link at all times that can be monitored for exactly the reasons Bill alludes. For a lot of networks, this can end up being just the OSC, but as that's often not subject to the full photonic path, I'd likewise advise against that being the case and to make sure you have at least some fully "in band" traffic that can be monitored along both legs. -- Brandon Martin
Re: MAP-T in production
On 7/24/20 10:46 PM, Brian Johnson wrote: OK Randy. How about a suggestion that is useful. My approach thus far absent CPE support for transition mechanisms has been native IPv6 across the board + NAT444, but I use a VRF to regionalize the NAT444 routing and bring it to a semi-centralized gateway much like one would using DS-Lite, 464XLAT, MAP, LW4o6, etc. No need to forklift anything, and you can deploy whatever suits you incrementally in regions where you need to. It also works with all user-supplied CPE routers which is a bonus as I hate to require that users use my CPE router, and it's not yet easy for consumers to verify beforehand that the router they're buying at Best Buy will support any particular transition tech, though I'd really like to get that fixed. I'm quite small, though. I can imagine this would be a hassle compared to running a single stack access layer at scale, and of course the NAT is stateful no matter what you do with this technique. -- Brandon Martin
Re: MAP-T in production
On 7/22/20 6:04 PM, JORDI PALET MARTINEZ wrote: > The comparison between MAP-T and 464XLAT is not just state. > > With 464XLAT you can have more subscribers (almost unlimited) per IP address, > without a limitation on the number of ports, so you save a lot of money in > addresses. > > And of course, a limited number of ports in MAP-T means troubles for > customers, so help desk cost. Indeed, the static nature of the carrier-side NAT64 translation, while removing state, also imposes restrictions that get more severe as you increase the degree of address overload. I can certainly see why the cellular folks can't feasibly adopt it. However, for strictly wireline folks, especially those just starting to run into address space exhaustion problems, even a 4:1 overload or so is quite useful and is likely, I think, to generate no more support load than fully stateful carrier-side NAT64 ala 464XLAT or NAT444 which is the punt solution, per se. I think that both technologies have their strong use cases. Folks needing lots of overload will probably prefer 464XLAT and just suck up the state handling for reasons you describe, while folks who figure they can essentially run out the clock on nearly-complete IPv6 transition with only modest overload may prefer MAP or LW4o6. > I've been working a lot with CPE providers (see RFC8585), and I believe that > 464XLAT is getting more support. This has also been my experience. My preferred CPE vendor is claiming 464XLAT support now (though I've not tested it), but doesn't appear to even know what MAP or LW4o6 are and certainly has expressed no plans to support it at least at the sales engineer questionnaire level. -- Brandon Martin
Re: questions asked during network engineer interview
On 7/22/20 6:55 PM, Łukasz Bromirski wrote: And yes (to the main topic of this thread) - I have some certs. I understand people without certs tend to discard them as non-relevant or even toxic. Yes, I’ve met “paper” CCIEs, but also JNCIEs and I can see the point being made. I’ve met great minds (also on this list) without any networking certificates. I believe that until you see real person on the other side of table and not her/his cert(s), good chat and questions will remove all doubts. Everyone has to start somewhere and make those first errors, and being ‘expert’ doesn’t mean you’re not making them anymore. The CCIE and JNCIE (and perhaps other vendor equivalents) are some of the few vendor certs I've found often (though not always) meaningful. If the candidate takes it upon themselves to really understand the why of what's going on in the prep and testing for those certs, it can be a very meaningful track. Of course if they just answer cram, it's bordering on useless, but (and not having either I can't say this with certainty) those particular tests seem to try to make such cramming at minimum impractical if not impossible. Of course, there's also plenty of folks out there without them or any certs at all that are just as useful in practice. Getting those particular certifications does, however, seem to be a useful path to learning things that are actually of use in the "real world". I look at such certificates similar to how I'd look at a 2- or 4-year degree in a related IT field and just a somewhat different, and perhaps more approachable for the self-coached or differently-learning, path. At minimum, I think it's a useful jumping off point in an interview for a candidate who has paper experience but not a lot of real-world experience: "So, tell me about a particularly dicey interoperability scenario you encountered while going for your CCIE? What steps did you take to troubleshoot and either solve or work around it?" or similar. -- Brandon Martin
Re: MAP-T in production
On 7/22/20 5:15 PM, Brian Johnson wrote: Has anyone implemented a MAP-T solution in production? I am looking for feedback on this as a deployment strategy for an IPv6 only core design. My concern is MAP-T CE stability and overhead on the network. The BR will have to do overloaded NAT anyway to access IPv4 only resources. The idea being that when IPv4 is no longer needed, this will be a quicker “clean-up” project than a dual-stack solution. I have reviewed Jordan Gotlieb’s presentation from Charter and would love to hear if this is still in use at Charter or if was ever fully implemented and the experiences) I’d love any real life examples and success/failure stories. I'd love to hear about this (or MAP-E, or lw4o6) as well especially with regard to CPE support. My preferred CPE vendor keeps punting on it (though they do claim to support 464XLAT), and I'd really like something to point them to that will show them it's a "real thing". Getting rid of state at the CGN as is (or can be, at least) necessary with 464XLAT seems like a real boon while placing minimal additional burden on the CPE. -- Brandon Martin
Re: questions asked during network engineer interview
On 7/21/20 12:55 AM, Mark Tinka wrote: Suffice it to say, to this day, we still don't know what SDN means to us, hehe. I think that's part of the problem. It means too many different things to different people. Much of what people refer to SDN is useful, albeit often pre-existing before the SDN craze...you just have to know what it is. Reminds me of the early days of ".NET" at Microsoft. Everything was ".NET", and eventually it became an actual thing. -- Brandon Martin
Re: questions asked during network engineer interview
On 7/20/20 4:02 PM, William Herrin wrote: I find there's a strong INVERSE correlation between the quantity of certificates on an applicant's resume and their ability to do the job. I still have to laugh about the guy who let me know via his resume that he was certified in setting up Kentrox CSU/DSUs. Pass given to those who cram them into a "certificates" or "specifics" line or similar in order to get around HR filters, limit them to major certs (or ones your HR dept. specifically demanded), and don't really mention them otherwise. Bear in mind as well that, even if your hiring process doesn't demand them, others' will, and many people have a standard-ish resume with application-specific cover letter. -- Brandon Martin
Re: Anyone running C-Data OLTs?
On 7/10/20 6:22 PM, Alexander Neilson wrote: I haven’t checked (on mobile) but those affected model numbers could confirm if it’s OLT, ONT, or both. Possibly the confusion could come from the bug affecting both. All of the part numbers I was able to find a description of (after sifting through the numerous pages copying the vulnerability disclosure) appeared to be low-cost, low- to mid-density pizza-box EPON OLTs. I didn't see any ONUs, but then I also didn't find data on everything. I know a low of EPON deployments go for all-in-ones with the ONU, router, WLAN, etc. integrated into a single box presumably because it's cheaper for initial deployment than separate boxes for ONU and CPE router/AP. No indication of those being affected in this notice, at least that I could find. -- Brandon Martin
Re: Layer 3 Switches
On 6/26/20 10:53 PM, Nathaniel Wingard via NANOG wrote: I’m looking to replace some access switches (Cisco Catalyst 3750 and 3560G). I really just need L2 features (stacking, PoE+, VLAN). I’ve found a 2960X that I like, but Cisco is pushing their 9200 series. The only downside I see is that the 9200s look to all have Layer 3 features. I’ve always shied away from L3 switches when I don’t need the L3 features, but I don’t have any solid reason not to just use the switches and turn off the L3 features I don’t need. I’m looking for thoughts on this approach. While I can't speak for Cisco, L3 usually comes free (software licenses notwithstanding) from most vendors these days. The off-the-shelf silicon generally handles it along with L2 switching. I'm not sure if you can "turn off" the L3 features in IOS XE (which the 9200s run), but you can of course just not configure them if you don't need them. Are you married to Cisco? The 9200 is not a bad pizza box platform, but you can definitely get comparable features and bandwidth cheaper (or more bandwidth for the same price) from other folks. -- Brandon Martin
Re: Router Suggestions
On 6/15/20 8:00 AM, Colton Conor wrote: For around $11,000 right now, you can get a brand new Juniper MX204 router. Alternatively, you can get a used MX240 / MX480 with quad power supplies, redundant quad core RE's, and 2 16X10G MIC cards for around $12,000. My question, is there anything else worth looking at in this price range / port configuration? Open to both new and used options. Looking to take full BGP routes. Do you want high-touch or a packet pusher? The MX204 is somewhere in the middle. Extreme SLX9540 and Arista 7280SR will "take full tables" with some FIB compression and route caching. YMMV if they'll actually work in your application, but my experience with the 9540 has been positive in a typical leaf edge application. Street price is in the ballpark of what you're talking, and you get a few 100GbE ports to go with your 10GbE ports. The SLX9640 or 7280R will apparently actually fit full routes in hardware, but the pricing seems to be a fair bit higher than you're talking. All of these are pretty much packet pushers with minimal "touch". In particular, traffic control capabilities are somewhat limited aside from applying them to the port itself, and they definitely won't do "BNG" type functionality with PPPoE or tag-per-customer with shared L2 appearance at least not at any real scale. -- Brandon Martin
Re: Outsourced NOC Solutions
On 6/8/20 3:01 PM, Matt Harris wrote: Is that considered true by most leased dark fiber providers? If I'm leasing a dark fiber circuit from a provider, I generally expect that what I'm leasing is in fact one [or more] physical strands of fiber - not a somehow redundant connection. Since he mentioned that this would be a dark fiber network, I would tend to assume that's the product that he'd be offering. Indeed, this has also been my experience with other providers, including very large and relatively smaller ones - when leasing dark fiber, or subscribing to a DWDM-based service, I'm going to be tied to a single, specific path and physical disruptions to said path will impact my connectivity. That's always been my expectation and experience at least - am I wrong, or has this changed at some point? Some carriers offer protected waves. They're protected at layer 1/1.5 using a combination of OTN wrappers and optical switches. My experience has been that "wave" services are generally unprotected unless you request otherwise. They're also one of the few "lit" services where grooming clauses are not just well-accepted but often standard or even implied in the service definition (the service is defined as traversing a specific path/paths). Protection usually comes at a premium cost since you're essentially buying the same lambda (or ODU) along multiple paths. Glass is glass. If you want protection, find more glass. I'm not even sure how you'd offer a protected "dark fiber" service without encroaching on the ability of the subscriber to light it to their pleasing. -- Brandon Martin
Re: understanding IPv6
On 6/7/20 6:01 AM, Denys Fedoryshchenko wrote: There are very interesting and unobvious moments on IPv4 vs IPv6, for example related to battery lifetime in embedded electronics. In ipv4, many devices are forced to send "keepalives" so that the NAT entry does not disappear, with IPv6 it is not required and bidirectional communications possible at any time. And in fact, it has a huge impact on the cost and battery life of IoT devices. When I developed some IoT devices for clients, it turned out that if "IPv6-only" is possible, this significantly reduces the cost of the solution and simplify setup. This is difficult to understate. "People" are continually amazed when I show them that I can leave TCP sessions up for days at a time (with properly configured endpoints) with absolutely zero keepalive traffic being exchanged. As amusingly useful as this may be, it pales in comparison to the ability to do the same on deeply embedded devices running off small primary cell batteries. I've got an industrial sensor network product where the device poll interval is upwards of 10 minutes, and even then it only turns on its receiver. The transmitter only gets lit up about once a day for a "yes I'm still here" notification unless it has something else to say. In the end, we made it work across IPv4 by inserting an application level gateway. We just couldn't get reliable, transparent IPv6 full-prefix connectivity from any of the cellular telematics providers at the time. I don't know if this has changed. For our application, this was fine, but for mixed vendor "IoT" devices, it would probably not work out well. -- Brandon Martin
Re: Integrated WIFI router and phone adapter
On 5/18/20 1:00 AM, K MEKKAOUI wrote: Anyone knows about a good integrated WIFI router and phone adapter that can be used to provide home and business internet and phone service. We tried couple of them but we’ve seen some instability and reliability issues (i.e. wifi issues, phone issues, etc.). Also some of them are designed to work better over DSL but not over DOCSIS. SmartRG (now part of Adtran) has some Ethernet-connected and therefore largely provider-tech agnostic models with FXS ports. I've not used the voice functionality of them, but I've been quite happy with the Wi-Fi and NAT, and they generally "do the right thing" out of the box for most folks. -- Brandon Martin
Re: How to manage Static IPs to customers
I'm curious... Is it part of the DOCSIS spec that the CMTS terminates L3, or can they bridge to IEEE 802(.3) and delegate that to some other piece of gear? I'm unfortunately not familiar with the MSO world much at all aside from a little bit of L1. -- Brandon Martin
Re: How to manage Static IPs to customers
On 5/7/20 4:49 PM, Javier Gutierrez Guerra wrote: Just wanted to reach out and get an idea how is people managing customers with static Ips, more specifically on Docsis networks where the customer could be moved between cmts's when a node is split Around here, Comcast seems to provision a GRE tunnel from the CPE back to some router within their network and run it over whatever IP address the CMTS hands out to the modem. Not very efficient, and it mandates that you use their CPE (they won't give you the necessary info to set it up yourself). AFAIK, such service is only available on their "business class" DOCSIS product and is upcharged even then. -- Brandon Martin
Re: alternative to voip gateways
On 5/7/20 12:03 PM, Mel Beckman wrote: > In the OP’s case however, the copper plant is private, and wholly owned and > already in operation. So surely in that situation fiber would be much more > expensive to dig and trench. Indeed, I was responding to Ohta's comments regarding copper vs. fiber. In this case, using DSL over the existing plant seems like a slam dunk unless very high speeds are needed or the plant is in very poor condition. Modern VDSL/2 DSLAMs are relatively inexpensive and will push 100Mbps over surprising distances with essentially seamless fallback to ADSL2+ at ~24Mbps for long-reach situations. -- Brandon Martin
Re: McAfee's certificate on akamai seems to be invalid
On 5/7/20 12:16 PM, Niels Bakker wrote: It looks like you shouldn't attempt to access that site over HTTPS, just via plain HTTP. Do you have any official bit of documentation that links to the HTTPS version? Given the prevalence of opportunistic upgrades to TLS these days, I'd argue that having a misbehaving server listing on 443 (and accepting SNI for a name that works on plain HTTP, if applicable) at the same domain as a well-known, public HTTP server, especially from a "security" company, is a poor idea. -- Brandon Martin
Re: alternative to voip gateways
On 5/7/20 5:13 AM, Masataka Ohta wrote: Investment for FTTH is 10 times or more than that for plain DSL. Only if you're comparing entirely new copper plant to existing copper plant (including drops), in my experience. If you compare greenfield to greenfield, the cost of fiber to the prem is not much greater than copper (coax or twisted pair). If you've already got access to existing copper plant, then reusing at least the drops is definitely worth looking into, yes. In most of the USA, it's simply not cost-feasible to get access to that unless you either are the ILEC or are a well-established CLEC from a long time ago. The ILEC mostly gets free reign to set the access costs, and they set them sufficiently high as to "discourage" competition from using it where they can get away with it. -- Brandon Martin
Re: Arista Switches rebooting
On 5/5/20 2:09 AM, Saku Ytti wrote: I2C is a pretty terrible bus, particularly if you try to actually hang everything off of a single I2C bus, single misbehaving speaker and you might get your power supplies offline. Hopefully we'll move to I3C or 10SPE Ethernet soon. Or maybe some sort of I2C switch where every connection is on its own bus. I was of the impression that, due to addressing, I2C bus switches are already typically used between each transceiver port and the system bus (hopefully one of many) that connects the micro to the ports (hopefully relatively dedicated to that purpose). That's certainly been the case in all of the switches I've torn down and, last time I checked at least the SFP specification, there wasn't much of a way around it since there was each transceiver uses the same, fixed addresses for ID and DDM. But yes, I2C, while very useful, is the devil. Clock stretching is particularly annoying along with the requisite use of open-drain drivers to accomplish it. I was not aware of 10SPE, though...looks very useful (for lots of purposes). Physical multi-drop on low-cost cabling is quite useful. -- Brandon Martin
Re: alternative to voip gateways
On 5/4/20 9:44 AM, Colton Conor wrote: Adtran has a built in web interface too. I it slow, but it does work. I like CLI better. Oh yeah, I forgot about that. It does work for most day-to-day tasks, though there are some things you can't do from it and have to drop to the CLI for. Overall, I prefer the CLI. -- Brandon Martin
Re: alternative to voip gateways
On 5/4/20 6:11 AM, Nick Edwards wrote: Thanks for suggestion, as per previous, how easy it to configure? It needs to be understood by laymen if possible, i'm no layman, but im no carrier grade networking guru either, most my setups are 300 odd users, where the gateway and dslam method is cost feasible, but not when your looking at the numbers of this project - hence reason for my post:) I've not used Calix gear, but the Adtran TA5000 supports a Cisco-like CLI. It can also be provisioned entirely using SNMP, if that's more to your liking, and in fact that is how Adtran's in-house provisioning suite works. It also has some TL1 support if you really must... The CLI has some necessary deviations from Cisco IOS, of course, as almost all "industry standard" CLIs do, but you can probably pick it up pretty quickly. If you buy new/prime gear directly from an authorized Adtran disty you also get their provisioning and monitoring suite (AOE) "free" as long as you maintain a support contract (which isn't particularly expensive). It's kinda blah (and Flash-based, but I'm told that's changing by the end of the year...) but does work. -- Brandon Martin
Re: CGNAT Solutions
On 4/29/20 10:12 PM, William Herrin wrote: What allows them to work with v6 in such an efficient manner? A piece of client software is installed on every phone that presents an IPv4 address to the phone and then translates packets to IPv6 for relay over the network. This works because T-Mobile has considerable control over the phone. FWIW, this software component (the CLAT) can also be on the CPE edge router which many ISPs either control outright these days or at least can influence. -- Brandon Martin
Re: CGNAT Solutions
On 4/29/20 2:35 AM, Masataka Ohta wrote:
If you mean getting rid of logging, not necessarily. It is enough if
CPEs are statically allocated ranges of external port numbers.
Yes, you can get rid of the logging by statically allocating ranges of
port numbers to a particular customer.
What I was referring to, though, was the programmatic state tracking of
the {external IP, external port}-{internal IP, internal port} mappings.
You can't eliminate that unless the CPE also knows what internal port
range it's mapped to so that it restricts what range it uses. If you
can do that, you can get rid of the programmatic state tracking entirely
and just use static translations for TCP and UDP which, while nice, is
impractical. You're about 95% of the way to LW4o6 or MAP at that point.
--
Brandon Martin
Re: CGNAT Solutions
On 4/28/20 4:53 PM, William Herrin wrote: How small is small? Up to a certain size regular NAT with enough logging to trace back abusers will tend to work fine. if we're talking single-digit gbps, it may not be worth the effort to consider the wonderful world of CGNAT. Depending on how many IPs you need to reclaim and what your target IP:subscriber ratio is, you may be able to eliminate the need for a lot of logging by assigning a range of TCP/UDP ports to a single inside IP so that the TCP/UDP port number implies a specific subscriber. You can't get rid of all the state tracking without also having the CPE know which ports to use (in which case you might as well use LW4o6 or MAP), but at least you can get it down to where you really only need to log (or block and dole out public IPs as needed) port-less protocols. -- Brandon Martin
Re: Are underground utility markers essential workers?
On 4/21/20 2:57 PM, Sean Donelan wrote: Utility markers don't get the recognition they deserve. If they aren't essential workers, they should be and get hazard pay. They help protect everyone's fiber and cables and pipes that go boom. If underground construction is an essential activity (and it certainly is, at least repairs generally are - new construction perhaps could be argued), then underground utility marking is, too, since it's mandatory for safely performing underground construction. -- Brandon Martin
Re: xplornet contact or any experience with their satellite service?
On 4/21/20 2:54 PM, Mel Beckman wrote: > It’s not really oversold bandwidth. It’s just that the turnaround time for a > bolus of data is too long for two-way video conferencing to be smooth or > reliable. It’s like video conferencing using post cards :) Are consumer satellite provider networks TDD or FDD? I guess I had assumed the latter, but maybe not? Assuming FDD, I don't see why the downstream needs to necessarily have problems with extremely long user-data-striping periods unless there's some factor I am just totally not considering. The upstream is of course more of a problem. I assume it's TDMA, and the terminals have imperfect clocks. -- Brandon Martin
Re: xplornet contact or any experience with their satellite service?
On 4/21/20 2:35 PM, Brian J. Murrell wrote: > Interesting. So basically as Mel said, over-sold network. :-( This is pretty typical of consumer VSAT and such. You can of course get better performance...if you're willing to pay for it. If you find the right carrier/re-seller, you can perhaps find one whose "system" (to include ground station, terminals, and smarts on the bird) can respect DSCP and flag at least your voice traffic appropriately (probably EF) to perhaps lower the jitter and make conferencing more palatable. Finding competent folks at a typical consumer provider's helpdesk to talk to about such things is probably the limiting factor. The higher up the foodchain you go towards the folks who "own" the spectrum rather than re-sell will perhaps get you more luck on something like this though probably also at higher MRC. Unfortunately, it's just what happens when you spread an already limited resource (transponder bandwidth) out over essentially an entire continent or at least substantial portions of it. Imagine if you had a cable provider with a single node for an entire, say, US state. -- Brandon Martin
Re: Constant Abuse Reports / Borderline Spamming from RiskIQ
On 4/15/20 11:33 PM, Ross Tajvar wrote: Can you give some examples of the things you mention above? I'm not doing much in terms of customer filtering and would be interested to hear what others consider best practice. My experience is that there's two groups of customers that are problematic from an abuse standpoint: * Those who intend to abuse your network * Those who enable others to abuse your network The former are of course a little easier to detect up front and much, much easier to give the axe when they do commit AUP violations. It looks like others have already given some hints as to how to detect these kinds of folks up-front. I'd also recommend looking for references for any new customer who wants a very large amount of resources, explicitly wants to send email, is bringing their own IP space (especially if they are leasing it), etc. The latter are far more problematic for legitimate operations. I don't really run "hosting" providers as I'm mostly in the business of mid- and last-mile networks, but I always try to ask anyone who's either buying a plan that explicitly permits "hosting" or who is asking for personal-use exemptions to anti-hosting provisions in the AUP (which I do permit) what their intent is. I don't really care so much what they're doing as long as they know what they're doing and that I get a vibe from them that they are competent. "I want to host my wordpress blog" is an instant red flag since compromised wordpress instances are one of the biggest sources of snowshoe hosting in my experience. -- Brandon Martin
Re: attribution
On 4/13/20 4:31 PM, Randy Bush wrote: it seems a lot of folk think prepending acrually works. I mean, there's prepending and then there's prepending 50+ times... Has the latter EVER been useful in any way, shape, or form? -- Brandon Martin
Re: Traffic destined for 100.114.128.0/24
On 4/8/20 2:42 PM, Drew Weaver wrote: Hello, I’ve noticed over the past couple of weeks that some hosts on a network I manage appear to be trying to reach hosts in this network 100.114.128.0/24 It’s an IANA reserved block but I’m really not sure what it’s used for. I just notice it keeps coming up but it doesn’t have a route. Has anyone else been seeing this? This is part of the RFC6598 space for carrier-NAT deployments. If you're seeing traffic inbound to your network to those addresses, someone's presumably got a default toward you and a hole in their internal routing table. If you're seeing traffic outbound toward those addresses, some of your customers have somehow picked up a configuration expecting some sort of service there. Inbound traffic toward your network from or to those addresses is effectively a bogon. Outbound traffic from/to those addresses means you have a misconfiguration somewhere (presumably unintentional and perhaps some poorly behaved automatic config on a CPE). -- Brandon Martin
Re: interesting troubleshooting
On 3/20/20 5:57 PM, Jared Mauch wrote: > It’s the protocol 50 IPSEC VPNs. They are very sensitive to path changes and > reordering as well. Is there a reason these are so sensitive to re-ordering or path changes? ESP should just encap whatever is underneath it on a packet-by-packet basis and be relatively stateless on its own unless folks are super strictly enforcing sequence numbering (maybe this is common?). I can understand that some of the underlying protocols in use, especially LAN protocols like SMB/CIFS, might not really like re-ordering or public-Internet-like jitter and delay changes, but that's going to be the case with any transparent VPN and is one of SMB/CIFS many flaws. For LAGs where both endpoints are on the same gear (either the same box/chassis or a multi-chassis virtual setup where both planes are geographically local) and all links traverse the same path i.e. the LAG is purely for capacity, I've always wondered by round-robin isn't more common. That will re-order by at worst the number of links in the LAG, and if the links are much faster and well utilized compared to the sub-flows, I'd expect the re-ordering to be minimal even then though I haven't done the math to show it and might be wrong. I'd argue that any remote access VPN product that can't handle minor packet re-ordering is sufficiently flawed as to be useless. Systems designed for very controlled deployment on a long-term point-to-point basis are perhaps excepted, here. -- Brandon Martin
Re: Hi-Rise Building Fiber Suggestions
On 2/26/20 11:43 AM, Filip Hruska wrote: Some NICs don't support SM optics, so even if you would like to run SM everywhere, it's not necessarily possible depending on the equipment. For example, I had issues with some SolarFlare cards which happily take 10G-SR MM but won't take 10G-LR SM. Is this because they're dumb, or is there some serious reason? AFAIK, the electrical side of the SFP+ is the same for all 10G-R PHYs. My philosophy has generally been that all fixed infrastructure installed in this era might as well be single-mode. If I'm just dropping a patch cord in a raceway or similar, I'll use multi-mode in many cases. On the fixed side, I have enough trouble convincing folks that APC and UPC plugs are different let alone trying to explain why you can plug SM optics into MMF and it will (generally) work while the other way around does not beyond a few meters and, since SMF can't be gotten rid of entirely in fixed infrastructure, I'll take the normalization where I can get it. -- Brandon Martin
Re: Hi-Rise Building Fiber Suggestions
On 2/25/20 10:48 PM, Abhi Devireddy wrote: L2 rings IMHO seem pretty brittle. I know there are L2 ring products like Juniper BTI, which use ERPS and not strictly STP/RSTP to move blocking ports, and those seem a little better although it's mostly statically configured. For a strict ring topology like this, I'd certainly consider E-RPS or similar over [R]STP if you were going to do this all at L2. It's a lot more "predictable" in my experience insofar as it's harder to shoot yourself in the foot by mistuning some knob somewhere and getting behavior you don't expect. That said, I'd be loathe to put 30+ switches on a ring even within the same building unless I had little other choice. One thing that I haven't seen explored in this thread is the idea of doing things at L3. If you've got 4 fibers, you can use Bi-Di optics to build a partial mesh/ladder/braid as you go up the building. That can be a mess at L2 with (R)STP, but carving out an IGP area and doing it at L3 is often not nearly so ugly. If you've got L3 switches (which are cheap, these days), it may be a good option, though it may also be annoying from an IP subnetting POV unless you overlay it with something like an IPv4-in-IPv6 core (MAP, 464XLAT, etc.) or an L2-in-IP overlay like VXLAN both of which substantially increase the conplexity of the situation. Using CWDM or DWDM with 8-16 channels on either 2 or 4 trunks across your 4 fibers to do a more conventional home-run with multi-chassis LAG or similar is another reasonable option. I'd avoid stacking 30+ switches even where you have stacking support over fiber especially if the switches aren't in a physical stack. Too much opportunity for split-brain scenarios IMO. I'd contribute to the "see really hard if you can just drop more fiber down the riser" echo chamber. -- Brandon Martin
