Re: BGP Monitoring
Le Mon, Feb 26, 2024 at 07:12:57PM +0100, Job Snijders via NANOG a écrit : > On Mon, Feb 26, 2024 at 05:41:12PM +, Ray Orsini via NANOG wrote: > > What tools are you using to monitor BGP announcements and route changes? > > The wonderful BGP.tools already has been mentioned a few times. > > Another excellent option is https://Packetvis.com, I find their RPKI > monitoring approach to be very insightful. > Do you know who's behind that site ? Denis
Re: The Reg does 240/4
Le Tue, Feb 13, 2024 at 03:24:21PM -0800, David Conrad a écrit : > This doesn’t seem all that positive to me, particularly because it’s temporary > since the underlying problem (limited resource, unlimited demand) cannot be > addressed. > I agree with this. Yet I am in favor of changing the status of 240/4, just so it can get burned fast, we stop this endless discussion and can start to deploy IPv6 again. Denis
Re: "Lit" Buildings
Le Thu, Dec 07, 2023 at 07:52:09AM -0600, Mike Hammett a écrit : > For those of you who list your network (usually wireline, but sometimes > wireless) with third parties, are you supplying just the KMZ or lit buildings > as well? If lit buildings, are you including residential? How are you > defining near-net? > I only supply "backbone" KMZ and I am not diplaying which building is connected. If you are within a range of a few hundred meters (up to 300m) to the cableline, you are considered near-net.
Re: Pulling of Network Maps
Le Thu, Oct 26, 2023 at 11:17:22AM -0500, Mike Hammett a écrit : > Has anyone else noticed a trend of some network operators that previously > offered street-level detailed maps, not only upon request, but also posted > publicly have started to only provide them upon quotes? > There is no small profit :) Also some will fear sabotage if the pathway is publicly available.
Re: Software to document fiber networks - in house only
Le Tue, Jun 13, 2023 at 03:12:29PM -0300, Jean Franco a écrit : > Hi all, > > I know this must have been on the table before, but I'm looking for a > in-house solution, something I can host on our own datacenter to document > fiber networks, maps and so forth. > I use a mix of Qgis, PostgreSQL, PostGIS and the GraceTHD model (which seems to be France specific though). This requires a bit of work at the beginning but works really great once installed, is self-hosted and does not require too much attention afterwards. Qfield can be used on mobile for usage by field technicians.
Re: What is going on with BGP
Le Tue, Jun 13, 2023 at 02:42:47AM +0100, Ignas Bagdonas a écrit : > A brief overview of developments happening in the IETF working groups > related to BGP evolution. The view is current as of mid-2023, in the > timeframe between IETF meetings 116 and 117, and looking back several years > to cover the recently published documents. The overview is given from the > perspective of development of the protocol mechanics and recommended > operational considerations, and is not directly related to specific > implementation aspects of specific platforms – for that you would need to > consult your vendors’ documentation. It is not expected that all of the > functionality described here will be universally productized, as well as > there will be specific deviations and extensions to functionality > implemented by different vendors as seen required by the market. This is > not an end to end overview of BGP, instead it focuses on specific protocol > changes and therefore it is assumed that a reader has a sufficient > understanding of foundations of BGP and its supporting machinery. It is a > high level overview and does not go deep into the specifics, pointers to > documents are provided for further and more detailed view into the topics > under the discussion. This part covers the core protocol part and > mechanisms specific to IPv4 unicast and IPv6 unicast AFs. > Thank you for this summary.
Re: Routed optical networks
Le Wed, May 03, 2023 at 06:20:48AM +, Vasilenko Eduard via NANOG a écrit : > > Additionally, I am sure that in many countries/Metro it is cheaper to lay > down a new fiber than to provision DWDM, even if it is a pizza box. The > colored interface is still very expensive. > Of course, there are some Cities (not “towns”) where it is very expensive or > maybe even impossible to lay down a new fiber. > Yes, in the majority of cases, it is cheaper to lay down fiber. > You may also take into account the time to deliver. Laying fiber takes much more time than plugging a colored optic.
Re: 2023 State of Network Automation Survey
Le Mon, Feb 27, 2023 at 11:16:13AM -0700, Chris Grundemann a écrit : > Update: The survey has received almost 4 dozen responses already! > > Of course, for the most meaningful results possible, I'd like to see that > about 10x higher. > Don't expect too much when you need a Google account to answer a survey :) > If you help run a network and have not yet responded, please consider doing > so - it really should only take a few minutes, and we'll all be better off > having the additional data point: > https://docs.google.com/forms/d/e/1FAIpQLSc5J_i2rkcpgkvI83Vj3DRVsau5jZ1u99M7p_ecWOgnW_9XHg/viewform?usp=sf_link > > > Thanks so much! > ~Chris > > > > On Mon, Feb 20, 2023 at 6:06 PM Chris Grundemann > wrote: > > > Hail NANOGers! > > > > For those of you who were unable to attend my lightning talk las Wednesday > > (link below) I would like to ask that you all complete the 2023 State of > > Network Automation Survey: > > > > https://docs.google.com/forms/d/e/1FAIpQLSc5J_i2rkcpgkvI83Vj3DRVsau5jZ1u99M7p_ecWOgnW_9XHg/viewform?usp=sf_link > > > > I did my best to make it as short as possible while collecting enough data > > to be useful. I will share the analysed and anonymized results with all > > respondents, as well as (assuming the talk is accepted) at the next NANOG > > meeting. > > > > Feel free to send any questions directly, although I hope the survey is > > self-explanatory. > > > > For a bit more context, the lightning talk can be viewed here: > > https://youtu.be/p7rlhkmlDog > > > > Thanks in advance for your participation! > > > > Cheers, > > ~Chris > > > > > > -- > > @ChrisGrundemann > > http://chrisgrundemann.com > > > > > -- > @ChrisGrundemann > http://chrisgrundemann.com
Re: ipv4/25s and above
Le Sat, Nov 19, 2022 at 01:39:59PM -0500, Bryan Fields a écrit : > On 11/18/22 6:44 AM, Joe Maimon wrote: > >> We could, but many of our DIA customers have all manner of CPE's that > >> may or may not support this. Having unique designs per customer does > >> not scale well. > > its almost 2023. /31 support is easily mandatory. You should make it > > mandatory. > > Mikrotik still doesn't support /31 addressing. I had a customer who was > configuring their "router" the other day and we found this out. Has to move > to a /30 on the link. > You cannot configure a /31 on a Mikrotik yet you can play with /32 to overcome this limit.
Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers
Le Tue, Jun 07, 2022 at 08:12:07AM -0500, Mike Hammett a écrit : > Would it matter if it took 10 minutes or an hour? > Yes, it means the computer could be off for 50 minutes. Also everyone who had a connection reset when uploading a big file after 55 minutes understands why it is good if it only would take 10 minutes. Peace of mind is under-rated :) > > What's the OneDrive rate limit? > > > > > - > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > - Original Message - > > From: "Tony Wicks" > To: nanog@nanog.org > Sent: Monday, June 6, 2022 5:36:13 PM > Subject: RE: FCC proposes higher speed goals (100/20 Mbps) for USF providers > > > > >This whole thread is about hypothetical futures, so it's not hard to imagine > >downloads filling to available capacity. > >Mike > > So, a good example of how this capacity is used, In New Zealand we have a > pretty broad fibre network covering most of the population. My niece asked me > to share my backup copy of her wedding photo’s/video’s the other day. I have > a 4Gb/s / 4Gb/s XGSPON connection and she’s got a 1Gb/s / 500Mb/s GPON > connection. I simply dropped a copy of the 5.1G directory into a one drive > folder and shared it, 10 minutes later (one drive is still limited in how > fast you can upload) she had it all and she was very happy. With these speeds > its not even a consideration to think about capacity, everything just works.
Re: Class D addresses? was: Redploying most of 127/8 as unicast public
Le Wed, Nov 24, 2021 at 05:08:43PM -0800, William Herrin a écrit : > I don't recall there being any equipment or software compatibility > concerns with 1.0.0.0/8. If you do, feel free to refresh my memory. Perhaps not the whole /8 but definitely some buggy implementations : https://seclists.org/nanog/2018/Apr/52
Re: PCH Peering Survey 2021
Le Fri, Oct 29, 2021 at 01:47:37PM +0200, Bill Woodcock a écrit : > If you’re peering with an MLPA route-server, you’re welcome to include just > the route-server’s ASN, if that’s easiest, rather than trying to include each > of the peer ASNs on the other side of the route-server. Either way is fine. > I have an agreement with the RS owner (IXP) but not with each participant. Should the contractual relationship be true or false ?
Re: Rack rails on network equipment
> You mention a 25-minute difference between racking a no-tools rail kit and > one that requires a screwdriver. At any reasonable hourly rate for someone > to rack and stack that is a very small percentage of the cost of the > hardware. If a device that takes half an hour to rack is $50 cheaper than > one that has the same specs and takes five minutes, you're past break-even > to go with the cheaper one. > I can understand the OP if his job is to provide/resell the switch and rack it and then someone else (the customer) is operating it ;-) As my fellow netops said, the switches are installed for a long time in the racks (5+ years). I accept to trade installation easyness for performance/feature/stability. When I need to replace it, it is never in a hurry (and cabling properly takes more time than racking). So easy installed rails may be a plus but far behind enything else.
Re: Setting sensible max-prefix limits
Le Wed, Aug 18, 2021 at 10:46:34AM +0100, Steve Lalonde a écrit : > > We always use PeeringDB data and refuse to peer with networks not in PeeingDB > That !
Re: Tier1 BGP filter generation data sources & frequency
Le Fri, May 21, 2021 at 05:40:21PM -0600, Clinton Work a écrit : > Is there any compiled information for Tier1 providers on the supported BGP > filter generation data sources and frequency? > > This is what I have been able to determine so far: > - TATA AS6453: IRR and RPKI ROAs > (http://lg.as6453.net/doc/cust-routing-policy.html) > - Cogent AS174: unknown > - NTT 2914: IRR, ARIN WHOIS OriginAS, NIC.br whois, RPKI ROAs > (https://www.gin.ntt.net/support-center/policies-procedures/routing/) > - Lumen AS3356: IRR > - Telia AS1299: IRR > https://www.teliacarrier.com/our-network/bgp-routing/routing-security-.html
Re: Unable to email anyone from my primary domain name; thanks Google Mail and G Suite.
On Fri, Oct 25, 2019 at 07:52:17AM -0700, Damian Menscher via NANOG wrote: > > There is a persistent mythos -- a worst practice, actually -- among many > > operations that obfuscating the reasons why messages are rejected is > > useful. > > This is wrong. > > > > Consider: either the sender is benign (as in this case) or they are not. > > > > If they're not benign, then either they don't care enough to acquire > > this information or they do. If they don't care, then providing the > > information doesn't hurt, because it'll be ignored anyway. If they do > > care, then they WILL get it, whether by conducting research or by > > breaching security or by the simpler/cheaper path of paying someone > > on the inside off. > > > > Please post your password to nanog@. Consider: either we're all benign, or > we're not. And if we're not, either we're too lazy to read all the > messages to the list, or we're willing to rubber-hose the password out of > you. Posting your password to the list is the most logical way to avoid > the hose. > I thought we were all educated people on this ML. Please avoid sophism.
Re: IPv6 Pain Experiment
On Sun, Oct 06, 2019 at 05:58:39PM -0400, Valdis Klētnieks wrote: > 8.8.4.5.13.9/40 > 8.8.4.5.17.168/40 > This is so unreadable to me :/ My brain keeps on wondering if this is an "IPv4+" or a phone number or a typo...
Re: AT/as7018 now drops invalid prefixes from peers
On Tue, Feb 12, 2019 at 03:05:28PM +, Nick Hilliard wrote: > Matthew Walster wrote on 12/02/2019 14:50: > > For initial deployment, this can seem attractive, but remember that one > > of the benefits an ROA gives is specifying the maximum prefix length. > > This means that someone can't hijack a /23 with a /24. > > they can if they forge the source ASN. RPKI helps against misconfigs rather > than intentional hijackings. > Only if you specify a a minlen of /23 and a maxlen of /24 and you only announce a /23. Which you should not.
Re: Amazon Peering
> Yup, super professional of them. > Have you tried to order a port on DirectConnect to check if it was hassleless ? :p
Re: Accepting a Virtualized Functions (VNFs) into Corporate IT
> On 28/Nov/16 19:53, Kasper Adel wrote: > > Hi, > > Vendor X wants you to run their VNF (Router, Firewall or Whatever) and they > refuse to give you root access, or any means necessary to do 'maintenance' > kind of work, whether its applying security updates, or any other similar > type of task that is needed for you to integrate the Linux VM into your IT > eco-system. > > Would this be an acceptable offering in today's IT from different type of > Enterprises (Minux the Googles, Facebooks...etc) ? > As long as the vendor will be held liable for ANY (and I mean it) problem that could happen on my infrastructure.
Re: IPv6 deployment excuses
On Sat, Jul 02, 2016 at 10:49:40AM -0600, William Astle wrote: > it usually boils down to "we don't want to put any effort or resources into > updating anything". > And they must be right as their clients won't go away... :p
ERPS/G.8032 interoperability
Hi all, Is there any study on ERPS/G.8032 interoperability between different equipment manufacturer ? Denis
Re: Programmable SFP+ Transcievers
> How does Solid Optics compare on pricing? They don't list them on their > website. > Last time I checked, it was roughly US$90 for a SFP-10G-LR+-SO.
Re: /27 the new /24
> >>Plus one to that. We are such a provider, and IPv6 is on my list of > >>things to implement, but the barriers are still plenty high. Firstly, I > >>do have an Ipv6 assignmnt and bgp (v4) and an asn, but until I can get > >>IPv6 transit, > > > >There are lots of transit providers that provide IPv6. It really is > >time to name and shame transit providers that don't provide IPv6. > > Unless he's buying from Bob's Bait, Tackle, and Internet (who's reselling > service off his Brighthouse cable modem connection), I find it hard to > believe there are "transit providers" in the NANOG region who still cannot > provide dual-stack addressing and BGP for DIA. > Speaking of HE, they can provide IPv6 transit (for some definition of transit) to anyone with an ASN for almost free.
Re: /27 the new /24
> Building a secure firewall takes more than just knowing how to issue > ip6table commands; one also needs to know exactly what goes into those > commands. NANOG concentrates on network operators who need to provide a > good Internet experience to all their downstream customers, which is why I > see the bias toward openness...as it should be. Those of us who run edge > networks have different problems to solve. > NIST has very good publication on this subject : http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf (Table 3-7 is a must read for any IPv6 newbie) Denis
Re: Yet Another BGP (Border Gateway Protocol) Python Implementation
Hi experts Cisco has open sourced one part of their BGP monitoring system - YABGP And hosted source code on GitHub. https://github.com/smartbgp/yabgp Documentation: http://yabgp.readthedocs.org/en/latest/ I don't want to be mean but is it of any use in 2015 to release a tool that doesn't support IPv6 ? Denis
Re: Routing Insecurity (Re: BGP in the Washington Post)
the possibility of building a true 'Internet kill switch' with effects far beyond what various governmental bodies have managed to do so far in the DNS space. Could you elaborate ? I don't see how it could be worse. Comparing with DNS is not relevant IMHO. Everyone is managing its own routing policy, not everyone is managing its own DNS root. Denis
Re: Measuring DNS Performance Graphing Logs
I was wondering which tool(s) can I use to measure the performance of my 3 DNS servers (1 primary, 1 secondary, 1 solely cacheDNS)? From the stats I would like to know if my DNS server is serving as it should be or if any of it's options are set inappropriately and others alike. Perhaps http://dns.measurement-factory.com/tools/dsc/ (used by AS112) can help. Denis
Re: FTTx Active-Ethernet Hardware
Hi, Price and functionality-wise Planet MGSW-28240F and GSD-1020S look pretty close to what I'm looking for. Anyone have real experience with using them on a large scale? Performance? Thank you for the pointer to MGSW-28240F. I am also curious to hear some feedback as the gear is awfully low-priced :) Denis
Re: Mikrotik RouterBoard and Ubiquiti Networks Routing and Switching Solutions
Le 12/08/2014 17:15, Justin Wilson a écrit : Another thing to consider is how you feel about the configuration. Mikrotik has a more polished GUI and command subset. UBNT is still working things out. A lot of what you have to to do with the UBNT line has to still be done in command line. If you are cool with that then not a big deal. The RouterOS is a pretty mature product and has a good backing of forums, wiki, and other things. Not saying uBNT doesn¹t, just not as mature. May we discuss IPv6 support ? Last time I checked, UBNT was lagging behind... Denis
Re: misunderstanding scale
Hi all, Le 23/03/2014 20:13, Mark Tinka a écrit : On Sunday, March 23, 2014 09:05:54 PM Cb B wrote: i would say the more appropriate place for this policy is the printer, not a firewall. For example, maybe a printer should only be ULA or LLA by default. I would support adding security at the host-level, especially because with a centralized firewall, internal infrastructure is usually left wide open to internal staff, with trust being the rope we all hang on to to keep things running. When speaking of IPv6 deployment, I routinely hear about host security. I feel like it should be stated that this is *in no way* an IPv6 issue. May the device be ULA, LLA, GUA or RFC1918-addressed, the device is at risk anyway. If this is the only argument for delaying IPv6 deployment, this sounds more like FUD to me ;-) Denis
