Re: 100G-LR1 (DR/FR)
On Tue, 4 Apr 2023, Jared Mauch wrote: We are willing to do 100G-LR1 if someone asks these days. It lets us be able to roll it up into 400G optics on our side as appropriate. I hope the industry moves to 100G-LR1, as doing 2x100GBASE-LR4 in a 400G port is quite meh when it comes to faceplate capacity. Unfortunately 100GBASE-LR4 will be with us for a long long time. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: SOHO IPv6 switches
On Tue, 18 Jan 2022, Sean Donelan wrote: What's the goto SOHO-class switch for IPv6? Zyxel/Netgear/TP-Link all have switches in the 100-200USD range that can do some basic stuff (filter on ethertype, some DHCPv6/RA inspection, SNMP polling via IPv6 etc). I was surprised by what I found (and this was 5-8 years ago), but I never went all-in on testing all of this, but looking at the feature set it actually seemed like they tried to support BCP38/SAVI, so I imagine some of these switches are actually used by ISPs as ETTH equipment. https://www.tp-link.com/us/business-networking/managed-switch/tl-sg3428/v2/ "IPv6 functions such as Dual IPv4/IPv6 Stack, MLD Snooping, IPv6 ACL, DHCPv6 Snooping..." -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IPv6 and CDN's
On Tue, 26 Oct 2021, David Conrad wrote: Ah. Cogent. I suspect IPv6 peering policies. Somebody should bake a cake. According to https://twitter.com/Benjojo12/status/1452673637606166536 Cogent<->Google IPv6 now works. A cake is in order, but perhaps a celebratory one!? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Never push the Big Red Button (New York City subway failure)
On Fri, 10 Sep 2021, Sean Donelan wrote: 1. The “Emergency Power Off” button did not have a protective cover at the time of the shutdown or the following WSP investigation. Aka "molly-guard". https://en.wiktionary.org/wiki/molly-guard -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Muni broadband sucks (was: New minimum speed for US broadband connections)
On Fri, 4 Jun 2021, Masataka Ohta wrote: As cabling cost is mostly independent of the number of cores in a cable, as long as enough number of cores for single star are provided, which means core cost is mostly cabling cost divided by number of subscribers, single star does not cost so much. Then, PON, needing large closures for splitters and lengthy drop cables from the closures, costs a lot cancelling small cost of using dedicated cores of single star. On the other hand, if PON is assumed and the number of cores in a cable is small, core cost for single star will be large and only one PON operator with the largest share (shortest drop cable from closures to, e.g. 8 customers) can survive, resulting in monopoly. My experience is that people can prove either active-e or pon is the cheapest by changing the in-parameters of the calculation. There are valid concerns/advantages with both and there is no one-size-fits-all. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Muni broadband sucks (was: New minimum speed for US broadband connections)
On Thu, 3 Jun 2021, Mark Tinka wrote: I'll let Mikael confirm, but last time I checked, Stokab was mostly (if not all) Active-E. Sweden is mostly Active-e. There is some PON nowadays though. Stokab typically only rents out dark fiber, so they don't have any of it. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Muni broadband sucks (was: New minimum speed for US broadband connections)
On Thu, 3 Jun 2021, Masataka Ohta wrote: Mark Tinka wrote: Which is the Stokab model. Does it use single star? The city should provide base infrastructure, lease it to operators atthe same price, and get out of the way. End of. With single star topology, that's fine. https://stokab.se/download/18.310b3d5c174c5513aec263/1601471204836/Framtidens%20kommunikationsn%C3%A4t%20LOWRES.pdf It's in swede-crypt, but it boils down to single strand of fiber from a central area node, to the basement, one for each apartment. However, the building owner has to arrange for the cabling within the building. It's single star, and typically the "node" it's all connected to will serve thousands of apartments. So an ISP will colocate in this "node" and can then rent fibers to provide FTTH services, at a fixed monthly cost (last I heard it was in the ~10USD a month range). Stokab isn't alone in this model, they're not the most successful, there are better examples of this. Sweden is also home to a lot of worse examples, all from "muni networks" that will be L2 transport providers, that will have L3 networks, to the ones who are L2/L3 but also sell services themselves. It's a zoo. There is muni broadband that sucks and there is muni broadband that is great. Without defining what kind of muni broadband we're talking about it's impossible to have a productive discussion. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: OT: Re: Younger generations preferring social media(esque) interactions.
On Mon, 22 Mar 2021, Grant Taylor via NANOG wrote: If it's the latter, does that mean that you have to constantly keep changing /where/ messages are sent to in order to keep up with the latest and greatest or at least most popular (in your audience) flavor of the day / week / month / year social media site? All good questions. I've been using IRC+email for 25+ years now and from what I can see, IRC has been replaced by slack/discord etc, and email has been replaced by Reddit or Github Issues discussions etc. I was on a project where the mailing list was shut down and all further discussions were pushed to github instead. I personally think the "web forum" format is inferior but that might be a way to reach out as well... -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Famous operational issues
On Tue, 16 Feb 2021, John Kristoff wrote: Friends, I'd like to start a thread about the most famous and widespread Internet operational issues, outages or implementation incompatibilities you have seen. Which examples would make up your top three? https://blogs.oracle.com/internetintelligence/longer-is-not-always-better -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: Texas internet connectivity declining due to blackouts
On Mon, 15 Feb 2021, Sean Donelan wrote: Strange the massive shortages and failures are only in one state. The extreme cold weather extends northwards across many states, which aren't reporting rolling blackouts. https://www.texastribune.org/2011/02/08/texplainer-why-does-texas-have-its-own-power-grid/ Going at it alone can be beneficial sometimes, sometimes it's not. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: 10g residential CPE
On Sat, 26 Dec 2020, Baldur Norddahl wrote: I demonstrated that it is about buffers by showing the same download from a server that paces the traffic indeed gets the full 930 Mbps with exactly the same settings, including starting window size, and the same path (Copenhagen to Stockholm). You demonstrated that it's about which TCP algorithm they use, probably. They all respond very differently to increase in RTT vs loss. https://arxiv.org/pdf/1903.03852.pdf Generally the Internet doesn't need more buffers, it needs less. If you have only FIFO available, configure it to tail-drop at 10ms or so, to help your customers with what they really care about, interactive performance. I debloat my 1000/1000 with bidir 900/900 FQ_CODEL to avoid my downloads affecting my interactive performance. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: 10g residential CPE
On Sat, 26 Dec 2020, Baldur Norddahl wrote: It is true there have been TCP improvements but you can very easily verify for yourself that it is very hard to get anywhere near 1 Gbps of actual transfer speed to destinations just 10 ms away. Try the nlnog ring network like this: gigabit@gigabit01:~$ iperf -c netnod01.ring.nlnog.net Client connecting to netnod01.ring.nlnog.net, TCP port 5001 TCP window size: 85.0 KByte (default) [ 3] local 185.24.168.23 port 50632 connected with 185.42.136.5 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 452 MBytes 379 Mbits/sec Why would you just use 85KB of TCP window size? That's not the problem of buffering (or lack thereof) along the path, that just not enough TCP window size for long-RTT high speed transfers. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: 10g residential CPE
On Sat, 26 Dec 2020, Baldur Norddahl wrote: That is why. The RTT to the source can not be larger than the minimum buffer size in the transport path. Otherwise the speed will start decreasing. This is no longer correct. There has been lots of TCP innovation since this was true. Please stop repeating it. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: 10g residential CPE
On Sat, 26 Dec 2020, Mark Tinka wrote: My experience with customers who've bought 1Gbps FTTH service is that on a good day, they may see 500Mbps. On average, they'll live somewhere between 180Mbps - 350Mbps, with a random spot-check. It's alright for providers who offer this to let their NOC's handle the problem, because most users are connected to the Internet wirelessly, using devices that do not require more than a couple of Mbps of bandwidth at a time. Wired devices such as gaming consoles won't tell you anything more than how long it will take a download to complete. So you are not probably going to work out whether the PS5 is running at 1Gbps or 230Mbps, as long as your psyche is happy with the service you are buying from your provider. Steam and Microsoft will say download speed. I regularily see 100MB/s or more. Perhaps there are some issues at other parts of the network that limits their speeds? I'm in Stockholm, Sweden, with plenty of local CDNs located just 1-3ms away from me. Here the "truth" is that if you game, you need to have a wired connection to your gaming computer. All gamers "know" this. I don't have experience with PS5 and perhaps what you're saying is true for that customer base. I'd say it's not true for Xbox or Steam customers as they see speed prominently displayed on the screen. https://support.xbox.com/en-US/help/games-apps/troubleshooting/troubleshoot-slow-game-or-app-downloads-on-xbox-one "Go to My games & apps > Manage > Queue and note the download speed shown on the game or app that’s being installed. " -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: 10g residential CPE
On Sat, 26 Dec 2020, Mark Tinka wrote: No one argued that Sony could build a half-decent console. Wired via Ethernet, that's unlikely to be the bottleneck. Considering my PC often saturates my 1000/1000 Internet access when downloading, I don't see why the 1GE NIC on PS5 wouldn't be the bottleneck if it's sitting on higher speed Internet access. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: [External] Re: 10g residential CPE
On Fri, 25 Dec 2020, Chris Adams wrote: Queueing doesn't get me my next game in time to play it tonight. I've always seen general queueing as a work-around for "not enough bandwidth and can't add more"... but when more is available, why not just use more? I de-bloat my 1000/1000 with FQ_CODEL. It's worthwhile because even 1000/1000 can see RTT spikes of tens of milliseconds otherwise. Bandwidth doesn't solve queuing and queuing doesn't solve bandwidth. They're both needed. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: 10g residential CPE
On Fri, 25 Dec 2020, Mikael Abrahamsson wrote: On Thu, 24 Dec 2020, Ben Cannon wrote: Anyone else doing it? Do you like your gear? Haven't tested it myself, but the 10GE residential provider here in Sweden is using some kind of Huawei HGW that typically is used for XGPON but has had its WAN MAC swapped out for 10GBASE-LR use. https://www.sweclockers.com/nyhet/26446-bahnhof-och-huawei-slapper-10-gbit-router-for-hemanvandare You can run it through google translate. Do note that this "news" is from October 2018. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: 10g residential CPE
On Thu, 24 Dec 2020, Ben Cannon wrote: Anyone else doing it? Do you like your gear? Haven't tested it myself, but the 10GE residential provider here in Sweden is using some kind of Huawei HGW that typically is used for XGPON but has had its WAN MAC swapped out for 10GBASE-LR use. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: favourite YANG data-store?
On Wed, 17 Jun 2020, adamv0...@netconsultings.com wrote: Hi folks, Was just wondering what are you folks using as production YANG data store and what do you like about the particular one you're using? Or maybe folks using OANP what is your YANG DS of choice? Plan on using it as in memory DS primarily for service, network YANG modules, (in addition to the usual use case of device modules), - so quite a lot of data as you can imagine storing data for higher abstraction layers Service & Network. Been looking at ODL and Confd thus far. http://www.sysrepo.org/ -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: RIPE NCC Executive Board election
On Wed, 13 May 2020, Elad Cohen wrote: LOL funny seeing you changing your mind by 180 degrees when someone you know in the community writing to you the exact same thing. "In addition, the sockets API should be extended to support IPxl with a new socket domain PF_IPXL which is identical to PF_INET in every respect save that the IP addresses are 8 bytes long instead of 4." Do you realise that this means you're requiring changing *every* socket-speaking application in the world? It's taken us decades to get applications to use the new struct to support IPv6+IPv4, resetting the timer back to 0 and starting over does not help deployment. It just kicks it another 20 years down the line. You're just inventing yet another incompatible standard and you have to touch everything, DHCP, DNS all applications etc. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: CGNAT Solutions
On Wed, 29 Apr 2020, Robert Blayzor wrote: So as a happy medium of about 2048 ports per subscriber, that's roughly a 32:1 NAT/IP over-subscription ? Yes, around that. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: CGNAT Solutions
On Wed, 29 Apr 2020, Robert Blayzor wrote: One would think a 1000 ports would be enough, but if you have a dozen devices at home all browsing and doing various things, and with IOT, etc, maybe not? https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-best-practices.html There are some numbers in there for instance talking about 1024 ports per subscriber as a good number. In presentations I have seen over time, people typically talk about 512-4096 as being a good number for the bulk port allocation size. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: ECN
On Wed, 13 Nov 2019, Baldur Norddahl wrote: In any case, is it not recommended that users of anycast proxy packets that arrive at the wrong place? To avoid this kind of issue. In typical anycast deployments there is no feasible way to figure out where the "right place" is. It would be very interesting if your could share what equipment you're using that is doing ECMP hashing based on ECN bits. That vendor needs to fix that or people should avoid their devices. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Protecting 1Gb Ethernet From Lightning Strikes
On Wed, 14 Aug 2019, Chris Knipe wrote: Think surge protectors will protect against strikes that is far away, and the residual surge it creates. A direct strike? Don't think there's anything that will really protect against that. https://imgur.com/a/dzTVw5a has been posted lately here in a swedish fiber-related facebook group. So even though you might have fiber coming in, remember that both the power grid and copper network cables are conductors and can make the lightning strike jump between devices. So the OP of this thread is right in wanting to protect both the network cables and power cables. PS. I don't have more details about this specific case. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: MAP-E
On Thu, 8 Aug 2019, Jay Hanke wrote: Actually your post is better than a presentation. I was quite surprised at the adoption rate of DS-Lite. There must be some pretty decent B4 implementations with that many operators deployed. The DOCSIS residential gateway vendors seem to have converged on ds.lite, probably because it was the first one out the gate. I've seen support for this on RGs for other WAN technologies. It's not great, but it's what has the most support in devices available. Lots of ds.lite is in Germany, and most/all the cable operators there have converged on ds.lite. This is not uncommon that several operators in a country converge on a similar strategy. Engineers moving employment between operators bring with them the know-how and do the same thing over again at the new place, and also there is a kind of "herd immunity" against customer complaints if your deployment and service offering has similar properties to most of your competitors in the country. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: MAP-E
On Fri, 2 Aug 2019, Brian J. Murrell wrote: Will any of these (including MAP-E) support such nasty (in terms of burying IP addresses in data payloads) protocols as FTP and SIP/SDP? LW4o6 is regular NAT44 and then tunnel encap. MAP-E is similar. So if there is NAT44 helper for these protocols then it should work the same as if you just had NAT44. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: MAP-E
On Fri, 2 Aug 2019, Baldur Norddahl wrote: be a demand. Alternatively I need to find a different CPE vendor that has MAP-E support, but are there any? Broadcom supports MAP-E and LW4o6 encap/decap in fastpath on at least BCM63138 with their latest BSP versions. -- Mikael Abrahamssonemail: swm...@swm.pp.se
240/4 (Re: 44/8)
On Mon, 22 Jul 2019, Owen DeLong wrote: 2. It was decided that the effort to modify each and every IP stack in order to facilitate use of this relatively small block (16 /8s being evaluated against a global run rate at the time of roughly 2.5 /8s per month, mostly to RIPE and APNIC) vs. putting that same effort into modifying each and every IP stack to support IPv6 was an equation of very small benefit for slightly smaller cost. (Less than 8 additional months of IPv4 free pool vs. hopefully making IPv6 deployable before IPv4 ran out). Well, people are working on making 240/4 usable in IP stacks: https://raw.githubusercontent.com/dtaht/unicast-extensions/master/rfcs/draft-gilmore-taht-v4uniext.txt There have been patches accepted into some BSDs and into Linux tools/kernel and other operating systems to make 240/4 configurable and working as unicast space. I don't expect it to show up in DFZ anytime soon, but some people have dilligently been working on removing any obstacles to using 240/4 in most common operating systems. For controlled environments, it's probably deployable today with some caveats. I think it'd be fine as a compliment to RFC1918 space for some internal networks. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: 44/8
On Fri, 19 Jul 2019, Phil Karn wrote: And one of the principal people in the network telescope project was KC, who also weaseled herself onto the ARDC board without even holding an amateur radio license. Conflict of interest here, holy carp. You are not in possession of all the facts. KC (Kim Claffy) is KC6KCC. https://www.fccbulletin.com/callsign/?q=KC6KCC The grant date was 2018-02-21. So both of the above statements can be true at the same time since I have no idea when KC joined the ARDC board. When was that? Also, reading: http://wiki.ampr.org/wiki/ARDC "It solely manages and allocates Internet address space, subnets of network 44 (AMPRNet), to interested Amateur Radio operators." Seems ARDC does more than this nowadays. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Multi-day GNSS Galileo outage -- Civilization survives
On Fri, 19 Jul 2019, Sean Donelan wrote: So much for the disaster scenarioes about a global clamity, planes falling out the sky, the end of civil society because a global navigation satellite system fails. The European Galileo GNSS was down for days, and life went on. It wasn't even in full production, and I am not aware of much equipment that solely relies on Galileo. A lot of devices today can use multiple GNSS and this is great, as this incident shows that one of them can go offline. Relying on only one of them is risky. This outage and its lack of ramifications doesn't imply that if GPS went offline there woulnd't be consequences. Galileo is just a few years old, and wasn't even in production. If GPS would go offline, you'd see a lot different fallout. Lots of things rely on GPS solely. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: DOs and DONTs for small ISP
On Mon, 3 Jun 2019, Mehmet Akcin wrote: I am putting together a public DOs and DONTs blog post and would love to hear from those who have built ISPs and have recommendations from Billing to Interconnection, Routing policy to Out of the band & console setup, Software recommendations, etc. Bottom line is that I would like to publish a checklist with these recommendations which I hope will be useful for all. The "ISP Essentials" publication is still valid in a lot of cases. It might not cover everything but gets a lot of the basics right. ftp://ftp.securecomp.net/EBook/Cisco%AE%20ISP%20Essentials.pdf -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: DHCPv6-PD relay route injection - standard?
On Sun, 19 May 2019, Brandon Martin wrote: I guess my impression from RFC8415 was that it was up to the network administrator and their equipment vendor to resolve this. Certainly, I wouldn't have expected automatic route injection, though having such a There needs to be interaction between the packet forwarding layer and the DHCP layer when doing things like DHCPv6-PD, otherwise it's not of any use. Another thing that will be in this document is that we've observed quite a few gotchas that aren't obvious, and for different deployment scenarios you want things handled differently by the relay. One example: What do you do when you have an active lease and the same DUID shows up on another interface, requesting a prefix? If you're a wireline operator then you most likely want to hand out a different prefix, because this is now two different customers and you want to treat them as two different clients even if they happen to have the same MAC address and DUID. If you're instead an enterprise for instance, and you want to support devices moving around and having their PD follow them, then you want to the opposite, you instead want to just treat it as the same client that now moved. Back in 2005 I was involved in an wireline deployment, and I checked the customer mac addresses. 5% of the customers had the same mac address visible to us. Seems a very popular electronics store router vendor had shipped all their routers of a certain model with the same MAC address as its default address. I was happy I had designed the wireline solution with one vlan per customer so this wasn't a problem. Other ISPs weren't so fortunate and had to spend significant customer support time/money helping customers use the "clone PC MAC address" functionality in the HGW to work around this problem. In DHCPv6 the DUID is considered "world unique", but as wel all know who work in operational environment, the world typically doesn't adhere to strict rules. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: DHCPv6-PD relay route injection - standard?
On Tue, 14 May 2019, Brandon Martin wrote: Is there a standard that defines/recommends behavior for route injection of snooped DHCPv6-PD (or IA, I guess) assignments on routers running relay agents? No, there isn't. However, there is now work ongoing work in the IETF to at least create a functional description of one. I read a pre-version of the -00 yesterday (my colleague is one of the authors), hopefully a first version of it should be posted coming week. Check out the IETF WG mailing list for when it's posted. The area of how the router on the LAN gets the DHCPv6-PD route injected never was standardized because consensus couldn't be reached on how to do it, so it was glossed over and vendors solved it the way they saw fit. I've seen implementations where no route was injected (to customer astonishment of course becase it's useless without this), so this is functionality that needs at least some kind of specification. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: any interesting/useful resources available to IPv6 only?
On Mon, 6 May 2019, Brian J. Murrell wrote: That and that such a VPS is only reachable from IPv6 addresses, if I were to have one, makes more of a case why other ISPs should support IPv6 rather than my own ISP. I have things at work that is only reachable using IPv6. This is not of general interest to anyone, but it does make it annoying for me when I happen to be on IPv4 only as I have to perform extra steps to reach these IPv6 only resources. I also have devices in my home I can only login directly to via IPv6, as I have opted not to have any IPv4 port forwards in my router. So the best case you can probably make is that there are things out there that are IPv6 only, not just the kinds of services that most people would care about (since if they would, someone would want it as widely available as possible, this making it dual stack). -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Gi Firewall for mobile subscribers
On Wed, 10 Apr 2019, Jan Chrillesen wrote: Also keep in mind that most GGSN/PGW will assign a /64 (and not a /128) All 3GPP devices assign /64 per bearer because that's what's in the 3GPP spec. I've been told 3GPP went to IETF and asked what to do, IETF said "assign /64 per device" and that's what ended up in the specs. so if someone does a scan targeting that specific /64 you might see a lot of traffic to the device. I would strongly suggest deploying a stateful device - purely to protect the radio and signaling network - not the terminal/phone If they scan the /64 then this won't cause excessive paging traffic as the device will already be out of low power mode. The balanced solution is to have a stateful device that typically does nothing but has some kind of "abuse detection" which triggers filtering certain Internet sources when it decides that this device is performing scans of larger IP spaces. This protects the mobile network from paging storms but also allows users to be reachable from the Internet. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: modeling residential subscriber bandwidth demand
On Tue, 2 Apr 2019, Paul Nash wrote: FWIW, I have a 250 subscribers sitting on a 100M fiber into Torix. I have had no complains about speed in 4 1/2 years. I have been planning to bump them to 1G for the last 4 years, but there is currently no economic justification. I know FTTH footprints where peak evening average per customer is 3-5 megabit/s. I know others who claim their customers only average equivalent 5-10% of that. It all depends on what services you offer. Considering my household has 250/100 for 40 USD a month I'd say your above solution wouldn't even be enough to deliver an acceptable service to even 10 households. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: modeling residential subscriber bandwidth demand
On Tue, 2 Apr 2019, Tom Ammon wrote: Netflow for historical data is great, but I guess what I am really asking is - how do you anticipate the load that your eyeballs are going to bring to your network, especially in the face of transport tweaks such as QUIC and TCP BBR? I don't see how QUIC and BBR is going to change how much bandwidth is flowing. If you want to make your eyeballs happy then make sure you're not congesting your upstream links. Aim for max 50-75% utilization in 5 minute average at peak hour (graph by polling interface counters every 5 minutes). Depending on your growth curve you might need to initiate upgrades to make sure they're complete before utilization hits 75%. If you have thousands of users then typically just look at the statistics per user and extrapolate. I don't believe this has fundamentally changed in the past 20 years, this is still best common practice. If you go into the game of running your links full parts of the day then you're into the game of trying to figure out QoE values which might mean you spend more time doing that than the upgrade would cost. -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: Last Mile Design
On Thu, 14 Feb 2019, Aaron Gould wrote: Not sure if this is what y'all are talking about, but I use lots of Juniper ACX5048 (previously Cisco ME3600 or ASR9000) for mpls-capable router edging in native ip/ethernet from ftth gpon network into mpls l2circuits and LOTS of vrf vrf for public ip, vrf for cgnat for private ip, vrf for voice... I'm glad I did it. Residential- ONT-ftth/gpon--OLT--ACX5048-mpls/vrf x---cgnat/inet-- Residential- DSL Modem-DSLAM---ACX5048-mpls/vrf y---cgnat/inet-- Residential- Cable Modem-CMTS---ACX5048-mpls/vrf z---cgnat/inet-- Residentialfiber media converter---L2 switch-- and then the rest of the setup you can re-use. AE isn't magic, insted of having an OLT,CMTS or DSLAM you just have an L2 ethernet switch. They're mostly just media converters anyway. 15 years ago I deployed ADSL like this: Residential---DSL modem---DSLAML3 switch So DSL-modem---DSLAM was just doing RFC1843bridged over ATM. Just media converters. Same thing, just different type of media converter. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Last Mile Design
On Wed, 13 Feb 2019, Colton Conor wrote: Just wondering, but what IP-capable MPLS switches are people using to deploy AE to residential internet connections? Most 48 port AE switches from repetuable vendors are crazy expensive, and I can't see how the ROI would ever work compared to GPON. Why do you need MPLS? Most people just use regular L2 switches with some SAVI functionality (DHCP inspection, RA guard tec). When I did this, we happened to have an L3 switch there so I made each customer IPv6 (protocol based vlan) broadcast domain unique for each customer, and the L3 switch had built in DHCPv6-PD server. So just route a /51 to it, and it was a self contained IPv6 upstream router. For IPv4 we had a shared vlan and I didn't change that design at all. For the FTTH deployment I am currently connected to, other end of my fiber is a big L2 chassi switch (~600 ports) with 10GE uplink to somewhere, and it does SAVI and then there is some BNG somewhere at the other end of this 10GE uplink. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Last Mile Design
On Mon, 11 Feb 2019, Mark Tinka wrote: We have the same problem here in Africa too (and I saw it in Asia-Pac while I was there as well)... non-telco-centric companies that deployed Speaking of an Asia-Pac example, Thailand, the government owned telco. https://www.tot.co.th/%E0%B8%9A%E0%B8%A3%E0%B8%B4%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%AD%E0%B8%B4%E0%B8%99%E0%B9%80%E0%B8%97%E0%B8%AD%E0%B8%A3%E0%B9%8C%E0%B9%80%E0%B8%99%E0%B9%87%E0%B8%95/tot-fiber-2u Typically there are 1-3 different FTTH providers if you live in something that resembles a town, pay 50-100EUR installation fee, they show up within days to pull your new fiber and now you can have 150/50 for around 20EUR a month. The price level has remained the same the past 5-6 years, but speed has gone up from 10/3 to 150/50 for the same monthly payment. Last year the 150/50 price level offering was 100/20 instead. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Last Mile Design
On Mon, 11 Feb 2019, Mark Tinka wrote: someone else" they will say "huh? what do you mean". There is an unfortunate common conflation between the fiber optic cable and the services offered on it. I get what you're saying, but sadly, someone has to take the risk to build out a network. Unless you are a large incumbent like Telia, chances are it will be company whose sole focus is just fibre network construction, and anything higher up in the layers is of no interest to them. The problem here is that it might be an energy company or someone who isn't really into datacom. Now they're going to have to operate an active network to provide this "bitstream access" with DHCP relays, BCP38 support and all that comes with it. The result is that right now, most of these networks do not support IPv6 and they do not support > 1 gigabit/s speed (some don't even support more than 100-500 either). If they had just stayed at the L1 level and provided dark fiber for the amount of money mentioned before (for instance 10-15 EUR a month) then a lot of the problems wouldn't be there. They could have used the same organisation as before that now could do fiber as well, and that's that. Simple product, can't go wrong in a lot of weird ways. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Last Mile Design
On Mon, 11 Feb 2019, Mark Tinka wrote: In any case, we are now building out our own fiber to cover the gaps left by TDC. Here the end user has to pay DKK 12,000 (USD 1,824 / EUR 1,608) one time fee and with that he gets everything including 5 years of free internet. This works out at DKK 200 / month including 25% VAT tax (USD 30 / EUR 27). Very interesting - don't you feel that an initial outlay like that could put some potential customers off? Then again, per capita income in Denmark, I'd imagine, could allow most to think about this. If all that buys me Internet access for 5 years before I have to shell out anymore wedge, I'd do it. In Sweden it's very common that people who live in detached house areas have to pay 1500-3000EUR to get attached to the fiber network as it's being built out. There are even bank loans you can get to pay for this, and pay it off over time. It's considered to be a good deal because it improves the value of the house as well as a huge improvement over having satellite-dish/terrestrial TV and ADSL/LTE for Internet access, now instead you can pay 30-40EUR a month to get a everything over the fiber. Now, I like the LLUB model where ISPs get access to the dark fiber all the way to the customer, and we do have that here as well, just not as commonly as I'd like. That's where https://www.bahnhof.se/villafiber/ comes from where they offer 10GE for 50EUR a month. This is done on Telia LLUB:ed dark fiber which costs around 15EUR a month (regulated price). It's a great PR case for "dark fiber access rocks and bitstream sucks". You get IPv6 in there as well, which isn't commonly available on most of the bitstream access services (because not only do we not do PON, we don't do PPPoE either here in Sweden). So it's a mixed bag and pricing and functionality could definitely be better, but the FTTH rollout has gone quite well here and it's as usual 10-15 different factors contributing but the willingness of the population who lives in houses to fork out 1500-3000EUR for fiber install has made this a lot less cash flow misery for the ISPs that roll this out. I just wish there would have been a requirement for everybody to actually rent this dark fiber out (which there isn't unless you're one of the biggest players) because after paying those 1500-3000EUR and you ask the fiber installation company "who owns this fiber?" they say "we do" and if you ask "ok, I'd like it connected to someone else" they will say "huh? what do you mean". There is an unfortunate common conflation between the fiber optic cable and the services offered on it. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Last Mile Design
On Sun, 10 Feb 2019, Mark Tinka wrote: Fair point, my mate is on a Stokab-driven network, but EUR35 for 250Mbps is nothing to laugh at. I'm paying double that for 100Mbps in Johannesburg, on GPON. I also have available 250/50 via DOCSIS for approx the same EUR35. Basically access technology (AE/GPON/DOCSIS) doesn't matter a huge part, it's all about market and competition. -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: Last Mile Design
On Sun, 10 Feb 2019, Tony Wicks wrote: Certainly the devil is in the details, in New Zealand the access layer (GPON plus local transport) is largely regulated. Then Retail service providers buy the access component wholesale and add layer3, national backhaul etc. Retail for unlimited 1G/500M internet is about $75USD/month, for 100/50 you are looking at about 50USD/month. Key to this was the breakup of the incumbent into an access plus retail provider. This was done by allowing power (lines) companies in a few regions to win the access component contract. The general going rate for a 250/100 in Sweden is around 35EUR for the kind of service where you can then choose any ISP. Typically the first-mile provider takes the bulk of this money. In the cases where the proprty is on STOKAB fiber footprint (or equivalent) and you have a reasonably large MDU the landlord can contract an ISP to deliver ETTH to all apartments (typically CAT6 from switch in basement) where the going rate per apartment is around 5-15EUR a month for something like 100/100, 1G/100M or 1G/1G. All of this with *PON nowhere to be seen. It's all AE over fiber or CAT5/6/7. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Last Mile Design
On Sat, 9 Feb 2019, Mark Tinka wrote: If I had to build a consumer broadband network and had the budget (and owned the fibre) to do so, I'd definitely always choose Active-E: For anyone saying it's "impossible" to do AE they're welcome here to the nordic region and especially Sweden where PON is basically unheard of. We have millions of AE connected households. I live in one of them. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Last Mile Design
On Fri, 8 Feb 2019, Chris Gross wrote: For a lot of us, PONs are a way of life and may not even have any 100G capable devices in our network, muchless enough to make our money on. While you may be so "lucky" to "never really take it seriously", it is supporting hundreds of thousands, if not millions, of homes in the US. PON is the lifeblood if many rural communities. I'm luckily to have a healthy mix of PON and AE operations since I'm located next to cities. But I've met cooperatives in the middle of no where with super low density where it's 6 people + 2 donkeys on staff. AE would never work there, but PONs allow them cheap and available broadband options. Unless someone wants to give enough funding to run AE to people's homes, PONs will continue to allow many communities to have more than cellular internet access options, if that. PON and AE both have their strengths and weakness and make sense for different deployment scenarios. My biggest problem with PON is that it seems some operators build their fiber plant for PON for all deployment cases and then it's extremely hard to back out of it and switch to AE. If you have AE you can switch to PON fairly easily, but not the other way around if you've put splitters in the manholes. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Dnssec still inoperable on the internet ?— was ARIN NS down?
On Fri, 11 Jan 2019, Ca By wrote: Thanks for the update that dnssec STILL causes more real world problems than it solves. Do you feel the same way about RPKI? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IP Dslams
On Sat, 29 Dec 2018, Nick Edwards wrote: Howdy, We have a requirement for an aged care facility to provide voice and data, we have the voice worked out, but data, WiFi is out of the question, so are looking for IP-Dslams, preferably a system that is all-in-one, or self contained, as in contains its own BBRAS/LNS/PPP server/Radius, such as has a property managment API, or even just a webpage manager where admin can Are you sure you need all of that? When I designed ADSL solutions ~15 years ago I built with Paradyne DSLAM with ethernet uplink, then we used rfc 1483 bridged over ATM, so no need for PPP, radius or anything. It was just IPoETHERNEToATM and all the regular IPoE mechanisms could be used (DHCP etc). So we just bundled the DSLAM with an L3 switch and that was that. One vlan per customer which solved the customer isolation problem. Customer could run modem in either bridged mode or terminate the IPoETHoATM PVC on the RG itself. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Auto-configuring IPv6 transition mechanisms on customer devices
On Wed, 2 Jan 2019, Brandon Martin wrote: Out of curiosity, what do you use to terminate the MAP/LW4o6 tunnels/encaps to the public Internet? Plenty of options here, of course, especially at the traffic rates I'm moving. I'm just curious what others' experiences have been as these are still somewhat new in SP deployments, I think. We use https://github.com/snabbco/snabb lwAFTR. We deploy an anycast based solution with self-check and ExaBGP to announce the anycast next-hop the RGs after the lwAFTR instance passes its self check. That means we can deploy these geographically diversely and also with redundancy, and can hitlessly take them out of service if needed. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Auto-configuring IPv6 transition mechanisms on customer devices
On Wed, 2 Jan 2019, Brandon Martin wrote: On 12/14/18 11:51 AM, Mikael Abrahamsson wrote: We use this to configure LW4o6 tunnels using DHCPv6. This is already present in OpenWrt via the MAP package. It supports both MAP-E and LW4o6. So I guess you're deploying "RG" style CPE routers to your customers that you've loaded OpenWRT onto? How's the maintainability of that? Any hardware recommendations? Yes, we're buying devices from a vendor that uses OpenWrt as base for their operating system. We're using this one currently: https://www.intenogroup.com/products/gateways/eg400/ We remotely manage it using Netconf/YANG from our NMS so we can do software upgrades (and other management). If you have low volume you can of course use SSH and script it if that's what you want. They also have TR-69 based management, and perhaps others. The mechanisms mentioned in this thread are exactly what I'm looking for, but I'm having trouble finding any COTS vendor support for them. I'm sure if I wanted to buy 100k units, somebody would put out some custom firmware for me, but as the network I'm doing this on is a brand new startup in a somewhat sparsely populated area, I'd be buying dozens at a time, not thousands. Get in touch with them, tell them I said hi. They might be able to accomodate your low volume by sending you gateways with their default software on it and you'd have to upgrade it to whatever image you want on it, yourself. It only takes a few minutes per box so should be perfectly doable with your low volume. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Auto-configuring IPv6 transition mechanisms on customer devices
On Fri, 14 Dec 2018, Brandon Martin wrote: Are there any (draft, standard, or otherwise) defined mechanisms for indicating to customer-provided devices that they should configure IPv6 to IPv4 transition mechanisms such as MAP, 4rd, 464XLAT, etc. and providing the configuration details thereof? I'm not aware of any. It seems like this is something that, if defined, would make deployment of such mechanisms a lot easier even if SPs provide the customer edge router that implements said mechanisms. I guess they'd probably be implemented as extensions to DHCPv6 or similar or embedded in RAs (the latter seems ugly). We use this to configure LW4o6 tunnels using DHCPv6. This is already present in OpenWrt via the MAP package. It supports both MAP-E and LW4o6. https://tools.ietf.org/html/rfc7598 DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients This document specifies DHCPv6 options, termed Softwire46 options, for the provisioning of Softwire46 Customer Edge (CE) devices. Softwire46 is a collective term used to refer to architectures based on the notion of IPv4 Address plus Port (A+P) for providing IPv4 connectivity across an IPv6 network. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IGP protocol
On Sat, 10 Nov 2018, im wrote: goodmorning nanog, I heard that OSPF is only famous in asia region... So that, please could you explain me 1. what is your backbone's IGP protocol? 2. why you choose it? This is a 20+ year old discussion. There are lots of comparisons. https://nsrc.org/workshops/2017/ubuntunet-bgp-nrens/networking/nren/en/presentations/08-ISIS-vs-OSPF.pdf https://www.nanog.org/meetings/nanog49/presentations/Sunday/Shamim_Which_Routing_N49.pdf https://www.nada.kth.se/kurser/kth/2D1490/03/papers/Comparitive_Study_of_OSPF_and_ISIS.txt -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: WIndows Updates Fail Via IPv6
On Mon, 12 Nov 2018, Mark Tinka wrote: I do run 6-in-4 from my backbone to my house as my FTTH provider does not do IPv6. I can't imagine this to specifically be the issue, as all other IPv6 traffic is fine, but at this point, I'm open to suggestion. Are you doing TCP MSS adjust/clamping? If you don't, try that and see if it helps. This might be a PMTUD issue. Otherwise if possible, try lowering the MTU sent in RA to the one you have on your tunnel (this depends on if this is available to you in your RA sending device). -- Mikael Abrahamssonemail: swm...@swm.pp.se
new diffserv code point LE PHB
Hi, I would like to bring attention to the following IETF draft: https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-04 I believe this is well under way through the IETF process, and if someone has strong opinions on it they should speak up. I am one of the proponents, as I posted to this list back in 2015: https://mailman.nanog.org/pipermail/nanog/2015-July/077040.html I think it's a great idea to have a diffserv code point that is supposed to be treated less than best effort (for backup traffic for instance), but it would be nice if someone would be willing to deploy support for it as well. Thoughts? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: MTU to CDN's
On Sat, 20 Jan 2018, Mark Andrews wrote: Which doesn’t work with IPv6 as UDP doesn’t have the field to clamp. Well, not with UDP/IPv4 either. Actually, the only protocol I know out there that has this kind of clamping (and is in wide use for clamping), is TCP. Thus, my earlier comment about making strong advise for protocols using PLMTUD. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: MTU to CDN's
On Fri, 19 Jan 2018, Mike Hammett wrote: Wouldn't those situations be causing issues now, given the likelihood that someone with a less than 1,500 byte MTU is communicating with you now? If the issue is that you're letting 8996 byte packets through but not 9000 byte packets, then no. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: MTU to CDN's
On Fri, 19 Jan 2018, Mike Hammett wrote: Other than people improperly blocking ICMP, when does PMTUD not work? Honest question, not troll. Mismatch of MTU interface settings between interfaces, mismatch of MTU between L3 devices and intermediate L2 devices, anycast services, ECMP based services where the ICMP error is delivered to the wrong node. So yes, there are plenty reasons that PMTUD doesn't work without anyone doing it because of ill will or incompetence. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: MTU to CDN's
On Thu, 18 Jan 2018, Michael Crapse wrote: I don't mind letting the client premises routers break down 9000 byte packets. My ISP controls end to end connectivity. 80% of people even let our techs change settings on their computer, this would allow me to give ~5% increase in speeds, and less network congestion for end users for a one time $60 service many people would want. It's also where the internet should be heading... Not to beat a dead horse(re:ipv6 ) but why hasn't the entire internet just moved to 9000(or 9600 L2) byte MTU? It was created for the jump to gigabit... That's 4 orders of magnitude ago. The internet backbone shouldn't be shuffling around 1500byte packets at 1tbps. That means if you want to layer 3 that data, you need a router capable of more than half a billion packets/s forwarding capacity. On the other hand, with even just a 9000 byte MTU, TCP/IP overhead is reduced 6 fold, and forwarding capacity needs just 100 or so mpps capacity. Routers that forward at that rate are found for less than $2k. As usual, there are 5-10 (or more) factors playing into this. Some, in random order: 1. IEEE hasn't standardised > 1500 byte ethernet packets 2. DSL/WIFI chips typically don't support > ~2300 because reasons. 3. Because 2, most SoC ethernet chips don't either 4. There is no standardised way to understand/probe the L2 MTU to your next hop (ARP/ND and probing if the value actually works) 5. PMTUD doesn't always work. 6. PLPMTUD hasn't been implemented neither in protocols nor hosts generally. 7. Some implementations have been optimized to work on packets < 2000 bytes and actually has less performance than if they have to support larger packets (they will allocate 2k buffer memory per packet), 9k is ill-fitting across 2^X values 8. Because of all above reasons, mixed-MTU LAN doesn't work, and it's going to be mixed-MTU unless you control all devices (which is typically not the case outside of the datacenter). 9. The PPS problem in hosts and routers was solved by hardware offloading to NICs and forwarding NPUs/ASICs with very high lookup speeds where PPS no longer was a big problem. On the value to choose for "large MTU", 9000 for edge and 9180 for core is what I advocate, after non-trivial amount of looking into this. All major core routing platforms work with 9180 (with JunOS only supporting this after 2015 or something). So if we'd want to standardise on MTU that all devices should support, then it's 9180, but we'd typically use 9000 in RA to send to devices. If we want a higher MTU to be deployable across the Internet, we need to make it incrementally deployable. Some key things to achieve that: 1. Get something like https://tools.ietf.org/html/draft-van-beijnum-multi-mtu-05 implemented. 2. Go to the IETF and get a document published that advises all protocols to support PLMTUD (RFC4821) 1 to enable mixed-MTU lans. 2 to enable large MTU hosts to actually be able to communicate when PMTUD doesn't work. With this in place (wait ~10 years), larger MTU is now incrementally deployable which means it'll be deployable on the Internet, and IEEE might actually accept to standardise > 1500 byte packets for ethernet. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: MTU to CDN's
On Mon, 8 Jan 2018, joel jaeggli wrote: PMTUD has a lot of trouble working reliability when the destination of the PTB is a stateless load-balancer. If your tunnel or host clamps the mss to the appropriate value it can support. it is highly likely that connection attempts to the same destination will work fine. This is understandable, but if this is also an operational practice we as the operational community want to condone (people using solutions where PMTUD doesn't work), then we also need to make sure that all applications do PLMTUD (RFC4821, Packet Level MTU Discovery). This is currently NOT the case, and from what I can tell, there isn't even an IETF document saying this is the best current practice. So, is this something we want to say? We should talk about that. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Waste will kill ipv6 too
On Fri, 29 Dec 2017, sth...@nethelp.no wrote: It's rather interesting how parsing of variable length addresses was thought to be way too complicated - while parsing of IPv6 extension header chains of unknown length was okay. I think this can be explained by "routers don't need to parse extension headers, they're routers, they only act on L3". Some of the people around back in early/mid 1990ies involved in designing IPv6 is still around in IETF, you can always ask them. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Static Routing 172.16.0.0/32
On Fri, 8 Dec 2017, Ryan Hamel wrote: Greetings, A colleague of mine has static routed 172.16.0.0/32 to a usable IP address, to have a single known IP address be static routed to a regions closest server. While I understand the IP address does work (pings and what not), I don't feel this should be the proper IP address used, but something more feasible like a usable IP in a dedicated range (172.31.0.0/24 for example). I would to hear everyone's thoughts on this, as this the first IP address in an RFC1918 range. Last time I tried using the first address of a classful address block (which 172.16.0.0/32 would be) in Cisco IOS (classic), that didn't work properly. This was in IOS 12.0.x. You can't set up BGP peers to something in the network address in classful network space, for instance. So 172.16.0.0/32 or 172.16.255.255/32 wouldn't work (because it's first and last address of class B space), but 172.16.1.0 worked just fine (because in class B space, 172.16.1.0 isn't special). So while this has been allowed per standardssince mid 90:ties, it's not obvious that it'll work in all operating systems that might still be in use. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: AS PATH limits
On Sun, 1 Oct 2017, Hank Nussbacher wrote: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2009-1572 Quagga 0.99.11 and earlier affected. Fixed in 2009. It was fixed in other OSes as well after this, I presume: http://blog.ipspace.net/2009/02/root-cause-analysis-oversized-as-paths.html -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Hurricane Maria: Summary of communication status - and lack of
On Wed, 27 Sep 2017, Sean Donelan wrote: Things are better and worse in Puerto Rico and other Caribbean islands. Help is needed, but anyone wanting to help in the field, be certain you understand what you would be doing, and whether you are actually helping or hindering on the ground efforts. https://www.vox.com/science-and-health/2017/9/26/16365994/hurricane-maria-2017-puerto-rico-san-juan-humanitarian-disaster-electricty-fuel-flights-facts This seems to indicate that it will be 4-6 months until things get back to normal, if there indeed is a huge effort to do so. "But as first responders on the ground in Puerto Rico told Fernández Campbell, this isn’t enough. Trump should also ask Congress to pass a relief package for Puerto Rico to give FEMA and the island more money to rebuild. He could deploy more military resources to help with search and rescue operations." I hope this happens. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: DHCPv6-PD -> Lack of route injection in RFC
On Tue, 26 Sep 2017, Blake Dunlap wrote: Isn't this the topic area that the home networking working group was supposed to resolve? HOMENET was never looking into running a routing protocol between the ISP and the HGW. It was all about running a routing protocol WITHIN the home, not between the home and the ISP. All the work I saw took for granted there was for instance a DHCPv6-PD lease handed to the home gateway router. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Hurricane Maria: Summary of communication status - and lack of
On Tue, 26 Sep 2017, Sean Donelan wrote: It looks like someone kicked the cellular carriers public relations people into gear. Today, instead of the normal "we care" messages; they released statements providing more concrete details about their restoration activity in PR and USVI. What is the US government role in all of this? It sounds like a few https://en.wikipedia.org/wiki/Lockheed_C-5_Galaxy could be of use here to airlift in lots of gear. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IPv6 migration steps for mid-scale isp
On Sat, 23 Sep 2017, Fredrik Sallinen wrote: Please correct me If I'm wrong, AFAIK 464XLAT works best with mobile networks and its not suitable for fixed broadband. right? It's most widely deployed in mobile networks, yes. There is nothing that says it couldn't work anywhere else. However, in fixed networks with PPPoE the most commonly used model is dual stack with RFC7084 style routers. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IPv6 migration steps for mid-scale isp
On Wed, 13 Sep 2017, Fredrik Sallinen wrote: Hello, Recently we have decided to start IPv6 migration in our network. We have ~1K BNGs and connecting our customers to network using PPPoE. I'd be interested in hearing from the technical community about their experiences and recommendations on this process. I'm wondering: Shall I go for IPv6-only deployment or dual stack? For PPPoE with existing IPv4, go dual stack. Where to start with IPv6? (core, edge or ...) Core, peering, work outwards towards end users. What are the best practices for ISPs? What are the costs and return on investment? How to identify address CPE and legacy application issues? There is a lot written and presented about IPv6 deployment. People have been doing this in volume since around 2010, and if you search for IPv6 deployment experience you'll find lots of presentations. Some I found that seem relevant: https://www.nanog.org/meetings/nanog51/presentations/Monday/aronson-pierantozzi-level3-ipv6.pdf https://www.ietf.org/proceedings/54/slides/plenary-15.pdf https://www.apnic.net/community/ipv6-program/ipv6-stories/ https://www.ipv6council.be/experiences-de-deploiements-ipv6/ If you prefer video form, there are lots of presentations from conferences, available on youtube as well. -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: Verizon 701 Route leak?
On Mon, 28 Aug 2017, Marcus Josephson wrote: Damn you Google.. yup. Thanks for links. A public post-mortem would be highly appreciated (from all parties). -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: 100G - Whitebox
On Sun, 20 Aug 2017, Nick Hilliard wrote: Mostly you can engineer around this, but it's not as simple as saying that small-buffer switches aren't suitable for an IXP. Could you please elaborate on this? How do you engineer around having basically no buffers at all, and especially if these very small buffers are shared between ports. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Cogent BCP-38
On Thu, 17 Aug 2017, chris wrote: Time for someone to bake them a bcp38 cake I am all for people deploying BCP38, but from the original email this is definitely not a cause for celebration. BCP38 should be used against single homed customers only if you're doing it by using uRPF. Otherwise extreme care needs to be taken to make sure traffic isn't dropped because uRPF does the wrong thing (like it seems in this case). -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IPv6 traffic percentages?
On Thu, 22 Jun 2017, Radu-Adrian Feurdean wrote: To make it short : education. And we as as small ISP we have neither the resources, nor the motivation (because $$$ on the issue is negative) to do it (the education). An ISP should be an enabler, and have a service portfolio to cover most customers need. Not all customers will want all the services, so if a customer doesn't want IPv6 then fine, turn it off for them. When they come back later and want it, they know you have it. You've done your part, and that's great! -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: PCIe adapters supporting long distance 10GB fiber?
On Wed, 21 Jun 2017, Denys Fedoryshchenko wrote: For switches i guess it is same story as for PoE on them - total power budget matters. So if you will pack whole EX4500 with 10G 80km SFP+ it might have problems as well, but for normal use, and if few only are "long distance/high power", at any case 3.3V supply rail by design in switch should handle many SFP, so if there is 48 ports, it should handle by specs at least 72W peak load. It might be multiple power rails for groups of ports, but still, much better than just 750mA on network card. But that's just guessing, i never seen circuit diagrams of good switches, or at least reference design, as it is all NDA material. Several of the limitations in switches/routers comes out to cooling, especially since there is a requirement for normal operation in case of failed climate control with ambient temp in the 40-50C range. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: PCIe adapters supporting long distance 10GB fiber?
On Thu, 15 Jun 2017, chiel wrote: Hello, We are deploying more and more server based routers (based on BSD). We have now come to the point where we need to have 10GB uplinks one these devices and I prefer to plug in a long range 10GB fiber straight into the server without it going first into a router/switch from vendor x. It seems to me that all the 10GB PCIe cards only support either copper 10GBASE-T, short range 10GBASE-SR or the 10 Km 10GBASE-LR (but only very few). Are there any PCIe cards that support 10GBASE-ER and 10GBASE-ZR? I can't seem to find any. The Intel XF SR2 card actually has XFPs and I have LR optics in one here. I don't see any reason it wouldn't support ER or ZR as well. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: CGNAT
On Fri, 7 Apr 2017, Max Tulyev wrote: BTW, does somebody check how implementing a native IPv6 decrease actual load of CGNAT? Reports are that 30-50% of traffic will be IPv6 when you enable dual stack. This would be traffic that will not traverse your CGNAT. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: 10G switch drops traffic for a split second
On Tue, 29 Nov 2016, TJ Trout wrote: Is it possible to over run the buffers of a 320gbps backplane switch with only 1.5gbps traffic? I think the switch is rated for 140m PPS and I'm only pushing 100k PPS If your switch is the typical small-buffered-switch that has become more and more common the past few years, then the entire switch might have buffer to keep packets for 0.1ms or less. So if someone says "flow control off" for 0.1ms, depending on the implementation, you might then start seeing packet drops on all ports until that device turns flow control back on. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Comcast business IPv6 vs rbldnsd & PSBL
On Tue, 29 Nov 2016, Rik van Riel wrote: Not a symptom I ever expected to see... It's pretty obvious that the CPEs being sold for this "business service" isn't meant for the kind of service you run. They're probably doing connection tracking for ACK optimization, this should not be done for UDP but it's still being done. They probably have a connection limit of a few thousand connections (not uncommon for these kinds of devices) and it's not possible to turn off what you need to turn off to make them work correctly. Do you have any other options in your area for other ISPs that can offer a better service for you? Otherwise you might hack around it by running an IPSEC/UDP tunnel to somewhere else where there isn't this kind of connection limit. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: 10G switch drops traffic for a split second
On Tue, 29 Nov 2016, TJ Trout wrote: Could this be MTU? I've tried flow control, hard code duplex, stp on/off etc As others have pointed out, you probably have a switch with small buffers. If you also have flow control and you have something that triggers flow control to turn off packet forwarding, your small-buffer-switch might fill up all (shared) buffers on that port and now you're dropping traffic to all ports. So trying to find if you have something where flow control is enabled and is being triggered might be something worthwhile to do, and also perhaps just turn off flow control on all ports to make sure. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Voice channels (FTTH, DOCSIS, VoLTE)
On Mon, 21 Nov 2016, Jean-Francois Mezei wrote: I need to verify some claims made by incumbents in Canada that VoLTE data travels on a totally separate channel between the phone and the antenna. Typically it travels on another "bearer" compared to Internet traffic. http://blog.3g4g.co.uk/2013/08/volte-bearers.html Think of bearers as "tunnels" between the mobile core network and the device. They have a lot in common with ATM PVCs in that they can have different QoS characteristics. So the VoLTE bearer can have scheduling priorities that means it'll always be low-latency and highest priority, meaning it might work well when the "Internet" bearer does not. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: OSPF vs ISIS - Which do you prefer & why?
On Thu, 10 Nov 2016, Joel M Snyder wrote: I think you misunderstood his point: it's not the knobs, but the vendors. Generally, when you're trying to integrate random crap into an otherwise well-structured network, you'll find OSPF available, but very rarely IS-IS. This is a feature of IS-IS. You're less likely to get random crap in your IGP. :P -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Dyn DDoS this AM?
On Sat, 22 Oct 2016, Alexander Maassen wrote: Remember ping packets containing +++ATH0 ? THat only worked because of patents: https://en.wikipedia.org/wiki/Time_Independent_Escape_Sequence Inband signaling is bad, mmmkay? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Kudos to Rogers Wireless on IPv6 deployment
On Sat, 1 Oct 2016, Hugo Slabbert wrote: So, kudos, Rogers Wireless! http://labs.apnic.net/cgi-bin/ccpagev6?c=CA Sort on "samples". Seems Telus and Rogers are the only top10 with any double digit % IPv6 users. Telus is at 65-70%, that's a really good number. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: BCP38 adoption "incentives"?
On Tue, 27 Sep 2016, Mike Jones wrote: Any network operator should know if their network is blocking it or not without having to deploy active probes across their network. Err... I was not referring to the operator doing this on the CPEs they provide to their customers. I was referring to enthusiast customers who are running their own CPEs to test if their ISPs are doing anti-spoofing properly or not, and report this information to someone centrally. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: BCP38 adoption "incentives"?
On Tue, 27 Sep 2016, Joe Klein wrote: What would it take to test for BCP38 for a specific AS? Well, you can get people to run https://www.caida.org/projects/spoofer/#software I tried to get OpenWrt to include similar software, on by default, but some people are afraid that they might incur legal action on themselves by doing antispoofing-testing. https://www.ripe.net/participate/ripe/tf/anti-spoofing might be of interest. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: BCP38 adoption "incentives"?
On Tue, 27 Sep 2016, Zbyněk Pospíchal wrote: Dne 27.09.16 v 15:17 Mikael Abrahamsson napsal(a): Hm, so the IX operator looks at packets at the IX (sFlow perhaps), see who is sending attack packets, and if they're spoofed, this ISP is then put in "quarantine", ie their IX port is basically now useless. Definitely not. Try to read first instead of speculations. The first page was completely devoid of any real technical information until I found the PDF (which from the color choice doesn't even look like a link). (https://www.nix.cz/cs/file/NIX_RULES_FENIX) It's still not obvious what the FENIX connection is used for from that PDF. It's called "last resort connection". What does that mean? Apart from that, it looks more like https://www.routingmanifesto.org/ in that organisations that have joined are stating that they will follow some operational guidelines (which make a lot of sense), but it's not that much more technical when it comes to inter-provider traffic. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: BCP38 adoption "incentives"?
On Tue, 27 Sep 2016, Zbyněk Pospíchal wrote: The implementation of BCP38 over local market strongly increased after massive DDoS attacks in 2013 affecting major part of the industry thanks to an initiative of the most important local IXP. Hm, so the IX operator looks at packets at the IX (sFlow perhaps), see who is sending attack packets, and if they're spoofed, this ISP is then put in "quarantine", ie their IX port is basically now useless. That's an effective way of achieving local compliance. Wonder how this would work in other markets, commonly it's bad business to deny service to paying customers... But if most agree that this should be done, it's definitely a way to achieve compliance. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: BCP38 adoption "incentives"?
On Tue, 27 Sep 2016, Stephen Satchell wrote: You have to make their ignorance SUBTRACT from the bottom line. I'd say there is no way to actually achieve this. BCP38 non-compliance doesn't hurt the one not in compliance in any significant amount, it hurts everybody else. The only way I can imagine BCP38 ever happening widely is by means of legislation, which of course is really hard because Internet spans countries/continents. Doing anti-spoofing should be done at the edge, the further up into the core you try to do it, the bigger risk you're breaking lots of users' connectivity, causing customer complaints. In some countries I'm sure BCP38 compliance could be increased by means of legislation and fining companies that do not do BCP38 filtering. But before we do that, we need to agree that BCP38 compliance is a must. I don't think we're there. I have heard people say that if they don't allow some of their customers to spoof, they're losing business, because some customers have built complete (deployed) solutions that are built on the fact that they can spoof packets. These people will have to be convinced that they're doing it wrong and re-design their solutions. This is going to cost them dearly, so they're going to be upset. With all the IoT devices out there, do people even need to spoof anymore? -- Mikael Abrahamssonemail: swm...@swm.pp.se
importance of fiber cleaning
https://www.sunet.se/blogg/long-read-cleanliness-is-a-virtue/ This is an excellent article regarding fiber cleaning and its importance. Please do share with other people in our business. I'm sure lack of proper fiber cleaning causes a lot of unneccessary outages and operational problems worldwide, partly because people aren't aware of its importance. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: comcast and msoft ports
On Sun, 11 Sep 2016, Randy Bush wrote: sigh. well that was some fun hours debugging; not. 135/137/139/445 has seen widespread filtering since... errr.. 2000? I know it was widely done back in those days when people were connecting their computers directly to the bridged modem/ETTH jack and things ended up in the newspapers that peoples files were available on the Internet because they didn't set a password on their windows share or when versions of Windows were pwned during installation of Windows because... Windows. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Optical transceiver question
On Wed, 7 Sep 2016, Frank Bulk wrote: Is it an industry practice to market distance based on the hot optics, not on the worst case, which is minimum TX power? No. If this is 1310nm optics with 0.4dB/km budget, the budget figure should be end-of-life figure, ie worst case according to the specs. I don't like the "kilometer" figures, that can be marketed with very optimistic figures. However, if the transceiver says 0 to -5 transmit, if it doesn't transmit 0 to -5 then it's out of spec. I treat the kilometer figure as "marketing", and look only at the optical specifications. So using your figures, if the device doesn't have 0 to -5 out, and can receive error free at -20, then it's out of spec and it should be replaced free of charge. However, if they market 1310nm with 15dB link budget at 60km reach, then I'd consder that false marketing. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Optical Wave Providers
On Wed, 31 Aug 2016, t...@29lagrange.com wrote: I have been looking at optical wave carriers for some long haul 1G/10G across the US. You probably should describe what you mean by "optical wave". If you mean "I want bit-transparent capacity with grey light handoff, that is not overbooked", then that's not really "optical wave". It will probably do what you want though (if I guess what it is you're looking for). I have had good historical success by asking for STM64/OC192 and then run 10GBASE-LW (WAN-PHY) over it. If you want the provider to treat your bits as bits and not packets, don't even tell them you're running packets. If they're providing OC192, they don't need to know. Don't even give them the chance to do the wrong thing by telling them you're running WAN-PHY over it. They might configure their system to support WAN-PHY and all of a sudden their transponders/muxponders might now understand the packets you're running over OC192 and CRC check them and drop them without you noticing. They don't need to know, so don't tell them. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Managed global low latency network with any to any connectivity
On Wed, 24 Aug 2016, Arqam Gadit wrote: Hello guys, I am looking for a global network with: - lowest possible latency - lowest possible jitter (packet loss and latency variation) - lowest possible monetary cost The few providers I have talked to until now, they all provide a point-to-point low latency link. However, what I am looking for is any-to-any connectivity so I can get from one point to another in least possible time and least possible cost. Would appreciate if you guys can point me in the right direction. The right direction is to decide what is most important to you. There is no network in the world that provides all of your criteria at once. Some people are paying really good money for low latency/PDV. Some other people are paying little money, but in return get low latency and PDV. So what's most important to you? Money or network characteristics? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Arista unqualified SFP
On Thu, 18 Aug 2016, Mark Tinka wrote: All other vendors, explicitly or silently, adopt the same approach. I've heard from people running Intel NICs and HP switches, that this can't be turned off there. You run into very interesting problems when you're trying to use DAC cables between multi vendor. Any pointers to how to turn this of on Intel NICs and HP switches? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Leap Second planned for 2016
On Sun, 10 Jul 2016, Saku Ytti wrote: On 10 July 2016 at 00:12, <valdis.kletni...@vt.edu> wrote: It doesn't help that the POSIX standard doesn't represent leap seconds anyplace, so any elapsed time calculation that crosses a leap second is guaranteed to be wrong So how can we solve the problem? Immediately and long term? Since one problem is that the leap second code isn't exercised regularily, I propose that each month there is a leap second either forward or backward. These forward/backward motions should be fudged to over time make sure that we stay pretty much correct. If POSIX needs to be changed, then change it. By making leap second not a rare event, this would hopefully mean it'll get taken more serously and the code would receive wider testing than today. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IPv6 deployment excuses
On Tue, 5 Jul 2016, Baldur Norddahl wrote: We will tell you to use IPv6 for that or make you pay extra for a dedicated IPv4 address. That is a good solution to that problem. I hope all ISPs implementing A+P protocols does that. It also puts a monthly cost that teleworkers have to pay (or their employers have to pay) for not supporting IPv6 on their enterprise solutions. Hopefully that'll drive IPv6 interest in the enterprise space as well. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IPv6 deployment excuses
On Mon, 4 Jul 2016, Baldur Norddahl wrote: The two other technologies mentioned do the same as MAP more or less, but both requires carrier NAT, which is expensive for the ISP and has a lack of control as seen from the end user point of view (no port forwarding etc). What it does however, is make things like GRE work. Some are surprised that there is actually non A+P protocols being used by customers. For instance legacy PPTP uses this, so some business VPNs run into problem with MAP or LW4o6. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IPv6 deployment excuses
On Mon, 4 Jul 2016, Matt Hoppes wrote: My point is there are more than enough IPv4 addresses. The issue is not resources. It is hoarding and inappropriate use. I tend to make the analogy of land use and/or houses/apartments. Yes, there is that old lady down the street who lives in 300 square meters (~3000 sq feet for those who are !metric), and then there is the student who shares a 30sq meter studio with another student. Now what? Yes, this is not fair and it's inefficient utilization of resources, but how are you going to rectify this? Forcibly take away the apartment from the old lady and tell her to go live somewhere else just because it isn't fair that she has 10 times the apartment size as the student? IPv6 is the answer, because it doesn't have shortcoming when it comes to available "land". Everybody can get plenty. No need to try to take away resources from someone holding them (legitimately) as per the rules of yestercentury.
Re: IP and Optical domains?
On Mon, 20 Jun 2016, Mark Tinka wrote: If you are deploying additional bandwidth just for protection, I hope you're my competitor. So if you have a fiber break, you're not going to have enough overcapacity in your network to remain uncongested until this fiber break is fixed? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: NANOG67 - Tipping point of community and sponsor bashing?
On Mon, 20 Jun 2016, Thomas Mangin wrote: Is this a specific service you purchased, or is this the way they deliver x-connects? It is how they provide x-connects. That's not a x-connect, that's a transport capacity service. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IP and Optical domains?
On Mon, 20 Jun 2016, Mark Tinka wrote: Many of us will remember the days of IPoDWDM. That flopped. E, it didn't flop at all. I know lots of operators that do this. For networks that lease all of their transport, not sure how this will help as transport providers will not open their networks up to 3rd party IP networks. Yeah, that's harder. Doing pure photonic transport is operationally difficult without management integration between optic transport provider and customer. That part hasn't happened. It's two different expenses. If routers made good DWDM switches, this would not be much of a problem, but they don't. So you need to two teams managing two different sets of kit and opex, which is what the industry has been trying to solve for some time now. How do we collapse both of these cost centres into one manageable expense, considering that the primary reason transport networks exist and expand today is to carry IP traffic? I know operators who have collapsed their "core transport group" to handle Fiber+DWDM+SDH+IP (design/planning/3rd line operations). I know others where the IP and optical teams work very closely together and plan the network together. If your main business is transporting IP/MPLS then this is obvious that you need to have the teams work closely together. If your main business is to L2 switch or bit transport lots of TDM/L2 traffic, then it's less obvious. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IP and Optical domains?
On Sun, 19 Jun 2016, Glen Kent wrote: Can somebody shed more light on what it means to say that the IP and optical layers are run as independent kingdoms and why do ISPs need to over-provision? You have a group that runs fiber+dwdm+sonet(or SDH). You have another group that runs IP. When the IP guys ask "please tell us how the optical network is designed, and can we coordinate how they're built and btw, we want to put DWDM optics in our routers", the answer from the fiber+dwdm+sonet group is "no, but we can help you with transport using our transponders, please just order circuits, just give us addresses for each end and we'll take care of things, don't you worry your little IP engineer brain how things are transported long distance". I believe this is still the case at a lot of ISPs. Not all, hopefully not even most, but I'm sure there are some. -- Mikael Abrahamssonemail: swm...@swm.pp.se
