Re: Reverse DNS for eyeballs?

On 4/21/23 15:02, Frank Habicht wrote: I would say the absence of reverse DNS tells useful info to receiving MTAs - to preferably not accept. As does a randomly-generated one... Mark.

Re: Backup DC power standardization with Photovoltiac battery systems?

On 4/18/23 08:41, Sean Donelan wrote: I'd prefer broadband CPE (UL listed) with a standardized backup power connector (doesn't exist, but I can dream). Out here, most people use this to keep CPE going when the power is out:

Re: Backup DC power standardization with Photovoltiac battery systems?

On 4/15/23 03:06, Sean Donelan wrote: If both PV battery walls and broadband CPE supported Power-Over-Ethernet as a backup power source, that would work too.  POE supports greater distances than USB-C. Well, you generally want to only power your devices off the battery if you are unable

Re: 100G-LR1 (DR/FR)

On 4/3/23 22:54, Tony Wicks wrote: I have been using the QSFP-100G-CWDM4 2k optics for within rack/DC for a couple of years now. They are about the same price as SR optics but allow the use of simple duplex single mode patches without blasting 10K optics at each other over a 2M patch.

Re: 100G-LR1 (DR/FR)

On 4/3/23 02:14, David Siegel wrote: At this point, I'd be happy to see others happily deploy a single-lambda optic of almost any variety!  Since deploying 400G in a clients network (but 100G still being the preferred connection choice), any inquiry with respect to LR1, FR1 or DR+ is met

Re: 100G-LR1 (DR/FR)

On 3/31/23 15:51, Ca By wrote: We use a lot of 100g-FR For dense deployment and limited faceplate space, 100g-fr / dr are the only way. LR4 is dead to me. We run the SR4 optics for in-rack cabling, because they are about 4X cheaper than all the single-mode options. We have been heavy

Re: Is malicious asymmetrical routing still a thing?

On 3/9/23 22:27, Aaron1 wrote: Sounds like something uRPF would prevent Does anyone do uRPF ? lol On routers where we carry a full table, we do. Mark.

Re: A blatant podcast plug

On 3/5/23 22:34, Dave Taht wrote: I rather enjoyed doing this podcast a few weeks ago, (and enjoy this podcast a lot, generally), and it talks to what I've been up to for the past year or so on fixing bufferbloat for ISPs.

Re: Coherent 100G in QSFP28

On 2/28/23 12:23, Pascal Masha wrote: How much will these cost? Unclear at this time. Mark.

Re: Coherent 100G in QSFP28

On 2/13/23 16:47, Tarko Tikan wrote: To the best of my knowledge the actual products are like ~1y away. Yes - if you are keen, reach out to your Adva (Adtran now, really) AM to get some beta units for testing; but FCS is Q2'24. Getting our hands on some to see how they perform. Won't

Re: Coherent 100G in QSFP28

On 2/13/23 15:54, Jared Brown wrote: Looks like coherent 100G in the QSFP28 form factor is finally on the horizon. From the datasheet: * 100G coherent DWDM in QSFP28 form factor * tunable, flexible grid * 300 km with amplification, 120 km without * industrial or commercial temperature * 5

Re: MX204 and MPC7E-MRATE EoL - REVOKED

On 1/28/23 09:29, Saku Ytti wrote: If I'd have to stab in the dark based on nothing, I'd imagine they forgot HMC is no longer shipping, and then panicked and EOLd all HMC boxes, until someone did more work, and gathered they probably can support a few HMC platforms with existing HMC parts

Re: Typical last mile battery runtime (protecting against power cuts)

On 2/6/23 07:42, Sabri Berisha wrote: There were few raindrops, so we have an outage. Again. I timed it. It took me less than 4 minutes to get it up and running. Oh, and you were right about the UPS batteries. The UPS on top of my garage door opener died halfway through opening the door.

Re: Typical last mile battery runtime (protecting against power cuts)

On 2/5/23 11:12, William Herrin wrote: Hi Roy, My guess is that your 20kw Onan isn't up to stably producing 20kw any more. Or perhaps the older transfer switch with its mechanical timer relays has gotten dodgy. The modern consumer gear is very reliable but the pre-2010s

Re: Typical last mile battery runtime (protecting against power cuts)

On 2/5/23 08:56, Roy wrote: I don't know how much the pumps require.  The water well is about 100 feet from the house and the pressure tank. The septic pump has to pump uphill to the drainage field. Distance is about 250 feet and elevation gain of 100 feet or so. The heat pump doesn't

Re: Typical last mile battery runtime (protecting against power cuts)

On 2/5/23 09:32, John van Oppen wrote: 20 KW should easily cover the 9KW you could max draw with your strip heat. It is super uncommon to have even peak loads over 20 KW in a house. Even your peak day was only an average of 6 KW. You might need some load shedding just to keep the big

Re: Typical last mile battery runtime (protecting against power cuts)

On 2/5/23 07:47, Chris Adams wrote: My house isn't very big, and I live alone (so less demand for hot water for example), and I hit a peak demand of 15kW a couple of months ago during a cold snap (I've seen it higher, maybe 16kW IIRC, just didn't dig any deeper). I probably took a hot

Re: Typical last mile battery runtime (protecting against power cuts)

On 2/5/23 07:02, Roy wrote: My all electric house is in a rural area.  The generator that came with the place is a 20KW Onan,  The bad news is in can't handle the house.  I think it is the Aux Heat on the heat pump that is the problem.  I have to also power the well pump and the septic

Re: Typical last mile battery runtime (protecting against power cuts)

On 2/4/23 23:58, Sabri Berisha wrote: I'd say I have something in between. I have a WEN GN875i: https://www.amazon.com/WEN-GN875i-Transfer-Switch-Ready-8750-Watt-Generator/dp/B08STWSWLH/ That's 7kw rated and 8.75kw peak. More than enough to support my home. Yeah, plenty of juice. I

Re: Typical last mile battery runtime (protecting against power cuts)

On 2/4/23 23:36, Sabri Berisha wrote: Those must be different from ours, because we don't have that... Even before we had power issues in South Africa, garage and gate motors had batteries in them. So it appears to be historical, for some reason or other. Pretty impressive. How do

Re: Typical last mile battery runtime (protecting against power cuts)

On 2/4/23 08:11, William Herrin wrote: Not for more than a decade now, at least not in the U.S. When you're up to whole-house generator prices everyone expects electric start. Half the portables have electric start. Most lawnmowers have electric start. Once you have that, the cost to make

Re: Typical last mile battery runtime (protecting against power cuts)

On 2/4/23 07:48, William Herrin wrote: Pre-wired makes it a standby generator, which 9 times out of 10 is automatic start with an automatic transfer switch. It's running within seconds whether you're home or not. Electricians cost too much and 20kva natural gas / propane generators with an

Re: Typical last mile battery runtime (protecting against power cuts)

On 2/4/23 07:29, William Herrin wrote: If it's just a little gasoline generator, 30 minutes is about right. It takes 10 minutes to decide the power isn't coming back soon and another 10 to drag the generator out of the shed, hook up the wires and get it going even though it's cold, wet, and

Re: Typical last mile battery runtime (protecting against power cuts)

On 2/3/23 21:11, Sabri Berisha wrote: Living in an area served by PG, I've had my share of power cuts. At home I have a 600va UPS that protects my cable modem, RPI router, and POE switch which serves 2 APs. That lasts about 30 minutes, which gives me enough time to fire up my generator.

Re: Typical last mile battery runtime (protecting against power cuts)

On 2/3/23 19:53, Saku Ytti wrote: In practice I would default to expecting 0 min availability during power outage, regardless of how resilient my CPE is. We can scarcely make the Internet work at the best of times. Agreed, this is a good place to start. It's a bit doom & gloom, but most

Re: Typical last mile battery runtime (protecting against power cuts)

On 2/3/23 19:25, Brian Turnbow via NANOG wrote: They have been discussing it here in Italy as well. The isp/telecommunication industry here is tryng to get Cos/pops/cabinets listed as critical infra and removed from rolling power cuts. I would say plan for the worst, because there will

Re: Typical last mile battery runtime (protecting against power cuts)

On 2/3/23 16:11, Israel G. Lugo wrote: Hi folks, At $day_job, I have a team of engineers who are oncall for critical services in the United Kingdom. For $reasons, the national power grid is announcing the possibility of rolling power cuts over the coming months. Right now it's

Re: MX204 and MPC7E-MRATE EoL - REVOKED

On 1/27/23 00:50, Aaron Gould wrote: Did you hear? EoL was revoked December 2022... I'm so glad, I like and use the MX204 and the MPC7E-MRATE Yes, the decision was made in November of last year, but only communicated to customers in December. Apparently, the shortage of chips for the

Re: Large prefix lists/sets on IOS-XR

On 12/12/22 12:26, t...@pelican.org wrote: That's a take on it I really hadn't considered. I'm very aware that moving from a decade or two of legacy manual config to full data model/automation in a big bang is never going to work, but I'd been looking at what individual elements could be

Re: Large prefix lists/sets on IOS-XR

On 12/9/22 16:38, Saku Ytti wrote: I refrain from expressing my disillusionment with the utility of doing IRR based filtering. I won't (refrain). We don't, for this very reason :-). Mark.

Fwd: [apops] APRICOT 2023 Call for Presentations

Presenters should endeavour to get material to the PC sooner rather than later. Any questions or concerns should be addressed to the Programme Committee Chairs by e-mail at: pc-chairs at apricot.net We look forward to receiving your presentation proposals. Mark Tinka & Marijana Novakovic

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

On 11/20/22 19:02, Abraham Y. Chen wrote: Dear Mark: 0)  I am surprised at your apparently sarcastic opinion. 1)  The EzIP proposal as referenced by my last MSG is the result of an in-depth system engineering effort. Since the resultant schemes do not rely on any protocol development,

Re: Alternative Re: ipv4/25s and above

On 11/19/22 05:50, Abraham Y. Chen wrote: Dear Owen: 1) "... Africa ... They don’t really have a lot of alternatives. ...": Actually, there is, simple and in plain sight. Please have a look at the below IETF Draft: It's most amusing, to me, how Africa needs to be told how to be... Some

Re: ipv4/25s and above

On 11/18/22 13:44, Joe Maimon wrote: its almost 2023. /31 support is easily mandatory. You should make it mandatory. I don't make the gear. How many customer addressing designs does that total, 2? So that would be 1 more than you have already? Dont buy it. That's fine. Its 2023,

Re: ipv4/25s and above

On 11/17/22 19:55, Joe Maimon wrote: You could instead use a /31. 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. Or private/enterprise-private Yeah, don't like that,

Re: ipv4/25s and above

On 11/16/22 16:39, Dave Taht wrote: I am kind of curious as to the distribution of connections to smaller companies and other entities that need more than one ipv4 address, but don't run BGP. So, for as an ISP or infrastructure provider, what is the typical percentage nowadays of /32s /31s

Re: Jon Postel Re: 202210301538.AYC

On 10/31/22 00:41, Abraham Y. Chen wrote: 2)  To follow what you are saying, I wonder how could we think "out of the box" or go "back to the future", before it is too late for our world wide communications infrastructure to serve as a reliable daily tool without being a distraction

Re: any dangers of filtering every /24 on full internet table to preserve FIB space ?

On 10/11/22 00:37, Matthew Petach wrote: They became even more huffy, insisting that we were breaking the internet by not following the correct routing for the more-specific /24s which were no longer present in our tables.  No amount of trying to explain to them that they should not

Re: any dangers of filtering every /24 on full internet table to preserve FIB space ?

On 10/10/22 17:26, William Herrin wrote: The Internet FIB is around 900k IPv4 routes. You have years before exhausting a 2.2M table. Depends on what else they may be carrying in their IGP, MPLS domain, SR domain, e.t.c. Mark.

Re: any dangers of filtering every /24 on full internet table to preserve FIB space ?

On 10/10/22 16:58, Edvinas Kairys wrote: Hello, We're considering to buy some Cisco boxes - NCS-55A1-24H. That box has 24x100G, but only 2.2mln route (FIB) memory entries. In a near future it will be not enough - so we're thinking to deny all /24s to save the memory. What do you think

Re: Disney+ Contact

On 8/31/22 11:03, Brian Turnbow wrote: Hi Mark Anyone from Disney who can help with a geo issue on-list? We have customers in South Africa mapping to India. Thanks. Did you try the emails in thebrotherswisp geo page? I have had some success though the Techops emails. Sometimes it does

Disney+ Contact

Hi all. Anyone from Disney who can help with a geo issue on-list? We have customers in South Africa mapping to India. Thanks. Mark.

Re: SAFNOG-7: 3 Days to Go! Register Now to Attend

ttps://grandafrica.com/grand-africa-cafe-beach/venue/grand-africa-cafe-beach-entire-venue-solo-use/ See you all soon, and happy travels :-). Mark. On 8/19/22 15:05, Mark Tinka wrote: Hello all. With 10 days to go to the 7th edition of SAFNOG, we are delighted, and excited, to welcome you all to s

SAFNOG-7: 10 Days to Go! Register Now to Attend

Hello all. With 10 days to go to the 7th edition of SAFNOG, we are delighted, and excited, to welcome you all to sunny and vibrant Cape Town, where we can all see each other after 2 years of social distancing. We have put together a very exciting program that covers a number of new,

SAFNOG-7: CfP Announcement

Hello all. The CfP (Call for Papers) for the SAFNOG-7 conference, due to take place in-person on the 30th - 31st August, 2022, at the Lagoon Beach Hotel in Cape Town, South Africa, is now open. Please find more details about the CfP at the link below: https://safnog.org/event/papers.html

Re: Serious Juniper Hardware EoL Announcements

So there have been some developments re: this thread. As it pertains to the both the MX204 and MX10003, Juniper have made the following amendments: * EoS = 2023. * End of new features = 2024. * End of bug fixes = 2028. * End of critical features = 2028. * EoL = 2029. FWIW. Mark.

Re: Serious Juniper Hardware EoL Announcements

On 6/18/22 15:04, Robert Webb wrote: I just have one question? Why are we discussing IP allocations and IANA in an email thread about EoL Juniper gear? Something about having more time to fix other softer issues we've long ignored, since we won't be busy installing any hardware :-).

Re: Serious Juniper Hardware EoL Announcements

On 6/17/22 14:47, Saku Ytti wrote: I can't pinpoint HMC as a bad solution, yes we've had our share of HMC issues, but we've also on JNPR and some other vendors previously replaced all linecards due to memory issues, before stacked DRAMs were a thing, memories are notoriously fragile. I can

Re: Serious Juniper Hardware EoL Announcements

On 6/14/22 18:06, JASON BOTHE via NANOG wrote: Saw this coming a mile away. With chips and technology progressing despite ability to manufacture, I’m certain many are going to do this. All this will do is keep these boxes off the open market, which will simply bump up open market prices,

Serious Juniper Hardware EoL Announcements

So Juniper have gone ahead and announced the EoL of some key devices that, IMHO, are nowhere near past their prime:     - MX204 (to be replaced by the MX304)     - MX10003 (to be replaced by the MX304)     - PTX1000 (to be replaced by the PTX10001) Re: the PTX1000, I know it is a component

Re: Upstream bandwidth usage

On 6/11/22 22:20, Karsten Thomann via NANOG wrote: Does anyone know the Asian market where they are using E-PON? After my very short search it seems they provide best effort up to 1G without any real plans... When I was in Malaysia years back, we did use ZTE for some EPON services. But

Re: Upstream bandwidth usage

On 6/10/22 17:26, Kord Martin wrote: Especially when you consider that XGSPON and GPON and coexist. We've seen proposals from Huawei, for example, where OLT shelves can support both GPON and XG-PON line cards. Just not seeing our market going in that direction yet. Mark.

Re: Aftermarket switches that were manufactured in any sort of quantity?

On 6/10/22 17:13, Robert Blayzor via NANOG wrote: Are they "cheap" or is everyone else just "overpriced". ?  Thats the real question. Of course it all comes down what you're willing to pay for it. And almost always, you get what you pay for... or as the case may be, what you don't pay

Re: Upstream bandwidth usage

On 6/10/22 12:01, Jared Mauch wrote: You would be surprised. The equipment isn't that expensive in the grand scheme of things. Fair point, it's not part of our scope at $day_job. Most of the greenfields I'm seeing in my region are standard GPON, and I'm not hearing of existing

Re: Upstream bandwidth usage

On 6/10/22 10:09, Dave Bell wrote: We are rolling out XGS-PON everywhere which is 10G symmetric. Just because the PON runs at 10G, doesn't mean you need to provision all of your customers at 10G. We have a range of residential packages from 150Mbps up to 1Gbps symmetric. The ONT is the

Re: Upstream bandwidth usage

On 6/10/22 09:52, Vasilenko Eduard via NANOG wrote: I did believe that it is about the cost of SFP on the CPE/ONT side: 5$ against 7$ makes a big difference if you multiply by 100. By the way, there are many deployments of 10G symmetric PON. It was promoted for "Enterprise clients".

Re: Upstream bandwidth usage

On 6/9/22 21:19, Fletcher Kittredge wrote: OVBI: Average upstream data usage has nearly tripled since 2018 People love to share. It's a pattern we began to see back in 2009, which was the

Re: Aftermarket switches that were manufactured in any sort of quantity?

On 6/9/22 18:41, Drew Weaver wrote: Hello, We had been purchasing some used 48 port 1BaseT switches /w 6x QSFP28 ports for around $3000 until about 2021. In 2021 the aftermarket pricing went from $3,000 each to $15,000 each. Now these particular switches are selling for $20,000 each

Re: Upstream bandwidth usage

On 6/9/22 22:46, Michael Thomas wrote: If it's so tiny, why shape it aggressively? Why shouldn't I be able to burst to whatever is available at the moment? I would think most users would be happy with that. The issue is generally the underlying last mile access. Even GPON is not

Re: Upstream bandwidth usage

On 6/9/22 22:26, Mel Beckman wrote: With 430 GB versus 32 GV average down versus up usage today, according to your article, this is still not a case for symmetrical consumer bandwidth. Yes, the upstream usage increased slightly more than the downstream usage. But the ratio was still so big

Re: Any sign of supply chain returning to normal?

On 5/20/22 14:44, Simon Lockhart wrote: I've heard that some vendors are prematurely EoS/EoL'ing kit as a result of the silicon shortages - and redesigning kit to use silicon that's easier to get hold of. This was my suspicion, because we started using this box in 2017. I can't remember

Re: Any sign of supply chain returning to normal?

On 5/20/22 10:24, Saku Ytti wrote: That's engineering, understanding what risks and compromises are worth carrying. If you do it by the book, you're not even needed, just 0-rate AS/PS services to your RFP and the vendor is happy to do it by the book for you. And fully agreed, in many cases

Re: MSA’s and network architecture

On 5/18/22 11:30, Etienne-Victor Depasquale wrote: Agreed - but wouldn't it be fair to say that, nonetheless, the availability of an MSA supports the development of network architecture? Of course, it would. After all, we want two sides to be able to speak to each other, to create this

Re: Any sign of supply chain returning to normal?

On 5/19/22 18:15, Dave Taht wrote: So I kind of view recycling routers, with newer software, as a great way to clean up the present ecosystem. And if you looked at the first url I pasted above, with 4x more throughput, and 10x less latency, on "obsolete", hw. When I had my battle with

Re: Any sign of supply chain returning to normal?

On 5/19/22 15:27, Dave Taht wrote: As I've been saying for a while, instead of buying new kit, perhaps we could spend some time on getting better software onto our older kit? Getting stuff to multiplex better, be more reliable, last longer? So we've been running Arista's 7508E devices as

Re: Any sign of supply chain returning to normal?

On 5/19/22 16:07, NetEquity Sales wrote: As someone who works within the "secondary market" for networking hardware, there is a ton of demand spilling over into the "pre-owned/vendor refurbished" market. Market prices on pre-owned equipment are rapidly increasing in step with increased

Re: MSA’s and network architecture

On 5/18/22 08:39, Saku Ytti wrote: We could also add an explanation to our proposals for the acronym. :) In your fair proposal, MSA is related to network architecture as a way to standardise pluggable (optics). But as always standards are incomplete, ambiguous and do not guarantee

Re: MSA’s and network architecture

On 5/18/22 08:28, Etienne-Victor Depasquale via NANOG wrote: Just to add a bit of fun to the mix - perhaps multi-source agreement was intended :) Considered that, but that would be obvious - we need optics :-). Mark.

Re: MSA’s and network architecture

On 5/18/22 03:55, Martin Hannigan wrote: All, Why do MSA’s matter as related to network architecture? As in "Master Services Agreement"? Mark.

Re: Juniper MX204 allow oversubscription?

On 5/16/22 20:27, Randy Carpenter wrote: Yes... the MX304 is awesome, but the price is going to be crazy. Possibly ~10x MX204 if fully loaded. For me, the MX304 should, really, be an alternative to the MX10003, and not an upgrade of the MX204. Far easier to get more MX204's than even

Re: Juniper MX204 allow oversubscription?

On 5/16/22 20:06, Aled Morris via NANOG wrote: I was hoping the MX304 would be the upgrade, but it seems like overkill - 2U, modular with dual processors, up to 96 x 10/25 GbE, 48 x 40/50/100, 12 x 400 GbE Probably a bit more expensive than MX204 too. There's also ACX7100-48L: 48x

Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s)

On 5/13/22 23:16, Jakob Heitz (jheitz) via NANOG wrote: 'RPKI-tested-only' will store all routes that encounter a 'validation-state' test in the inbound route policy. In that case, when an RPKI server updates a VRP to the router, it can re-run the inbound policy from the stored route and

Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s)

On 5/12/22 23:40, Jakob Heitz (jheitz) via NANOG wrote: To address the risk of somebody exhausting your memory by dumping a ton of routes on you, we added two new options to "soft-reconfiguration inbound" in IOS-XR. RPKI-dropped-only Saves a copy of only the routes dropped by an RPKI

Re: Newbie x Cisco IOS-XR x ROV: BCP to not harassing peer(s) and upstream(s)

On 5/11/22 18:53, Job Snijders via NANOG wrote: Hi! In current versions I think enabling “soft-reconfiguration-inbound always” (also described at https://bgpfilterguide.nlnog.net/guides/reject_invalids/#cisco-ios-xr ) should be enough. Make sure to enable it on every EBGP peer you apply

Re: Strange behavior on the Juniper MX240

On 5/6/22 11:26, Saku Ytti wrote: You are always here. You always need to understand your scale and how much resources you have available, what is possible and what is not. Of course, if this was the case with the global Internet, we'd have far fewer problems making it work well than we

Re: Strange behavior on the Juniper MX240

On 5/6/22 10:09, Saku Ytti wrote: This seems like a strange position. The device has 16MB+16MB jtree segments. The first is IP, the second is filters (Broadly). OP has 16MB of first used. OP has <5MB of second used. What if the platform had originally shipped with a different balance

Re: Strange behavior on the Juniper MX240

On 5/5/22 21:50, Nick Olsen wrote: His instance drove us crazy for a bit. The device would learn a route, show that it was installed (show routes) but traffic to said prefix would bounce net unreachable. We even pushed a static just for S's and that still didn't resolve it. It was a single

Re: [NANOG] [Mailman List] Strange behavior on the Juniper MX240

On 5/5/22 21:48, Nehul Patel wrote: ok mark got it currently we are using the following DPCE Cards DPCE-R-4XGE-XFP DPCE-R-Q-4XGE-XFP When we tried using the command set chassis memory-enhanced route on the current Junos version 10.4 it says the command is not supported so we will need

Re: [NANOG] [Mailman List] Strange behavior on the Juniper MX240

On 5/5/22 17:24, Nehul Patel wrote: Ok Mark thank you for the suggestion we are currently running on the RE-S-1300 i am trying to check if juniper docs as the list of the DPCE with the I-Chip but not able to find it yet if you know DPCE model number let me know for it If memory serves, I

Re: Strange behavior on the Juniper MX240

On 5/5/22 07:34, Saku Ytti wrote: And like Jordan said, you are out of resources but can extend them with the command given, which should give you more run rate. You may want to look in more detail how long you can keep running DPCE until you're really out. Certainly an option, but this

Re: Strange behavior on the Juniper MX240

On 5/5/22 05:08, Nehul Patel wrote: Ok, thank you all for the feedback we are going to start with the Junos OS upgrade first on it but have to open the ticket with JTAC since currently on the juniper support website they have the Junos 15.1 is available so not sure we can directly jump

Re: Strange behavior on the Juniper MX240

On 5/5/22 04:11, Jordan wrote: Your line cards (not RE's) are running out of route-storage memory. As a short-term mitigation, you could try borrowing from segment 1, normally dedicated to filters, set chassis memory-enhanced route but this option may not exist in the version of JunOS

Re: Strange behavior on the Juniper MX240

On 5/4/22 21:56, Nehul Patel wrote: Hi NANOG, We are seeing some strange behavior on our Juniper MX240 Chassis it is randomly dropping the routes to the certain destination IP address getting the following errors on the MX240 Chassis If Someone has seen these errors before please

Re: Announcement of Experiments

On 5/1/22 23:59, Alexandros Milolidakis wrote: If, for any reason, you want to opt out from us using your ASN for our experiments, you can do so in the following form before May 9: https://forms.gle/ZvZaodndPhCqMvR89 How do you intend to manage

Re: are underwater routers a thing?

On 3/18/22 06:21, Joel Jaeggli wrote: The mean depth of the worlds oceans is around ~3700 meters below MSL which means most service calls involve deploying to the proximate location of the fault, fishing around for a while and then carefully re-laying  several kilometers of cable on a

Re: "Permanent" DST

On 3/15/22 21:40, Eric Kuhnke wrote: If Canada doesn't do the same thing at the same time, it'll be a real hassle, dealing with a change from -8 to -7 crossing the border between BC and WA, for instance. It has to be done consistently throughout North America. Rwanda and Uganda are

Re: V4 via V6 and IGP routing protocols

On 4/4/22 15:45, Masataka Ohta wrote: MPLS with nested labels, which is claimed to scale because nesting represents route hierarchy, just does not scale because source hosts are required to provide nested labels, which means the source hosts have the current most routing table at

Re: V4 via V6 and IGP routing protocols

On 4/4/22 03:06, Dave Taht wrote: I'm actually not here to start a debate... happy to learn that the v4 over v6 feature I'm playing with actually exists in another protocol, mainly. I'm critically dependent on source specific routing, also, so I am hoping there's an isis or ospf that can do

Re: V4 via V6 and IGP routing protocols

On 4/4/22 02:55, Dave Taht wrote: it was how hard adding source specific routing to isis turned out to be that turned me. At the time I needed simple means to get ipv6 working on multiple consumer uplinks. I suppose the presence of MPLS (and SR) for many operators is probably why this

Re: V4 via V6 and IGP routing protocols

On 4/3/22 13:55, Dave Taht wrote: Periodically I still do some work on routing protocols. 12? years ago I had kind of given up on ospf and isis, and picked the babel protocol as an IGP for meshy networks because I felt link-state had gone as far as it could and somehow unifying BGP DV with

Re: 40G QSFP+ to 4 SFP+ on MX960

On 2/25/22 18:11, Michael Still wrote: Check out the Adva MicroMux Nano for this use case if you haven't already. 10x 1g in a single 10g transceiver using a 24S MPO. They also have a 10x 10g in a single QSFP28 as well. We tend to avoid such solutions because we are now introducing a

Re: Russian aligned ASNs?

On 2/25/22 22:36, Tony Wicks wrote: Haha, we are like the underground cables we service. No one (apart from other engineers) notices or cares how much effort it takes to keep the packets flowing until it stops. One could say this about any service that its patrons aren't professionally

Re: 40G QSFP+ to 4 SFP+ on MX960

On 2/25/22 09:04, Saku Ytti wrote: Then you went too far. For many users the 40G port is there to increase 10G density, by offering 4x10GE breakout. It is already difficult to support 1GE customers and 10GE is starting to become problematic. But SP networks actually have these customers,

Re: [External] More product suggestions: small/cheap IS-IS or VXLAN devices?

On 2/23/22 09:04, Hunter Fuller via NANOG wrote: Two that immediately come to mind are:  - If you don't need anything dynamic, you can run VXLAN on any Linux box. So just a random server would work. https://vincent.bernat.ch/en/blog/2017-vxlan-linux IS-IS support in Quagga and FRR is

Fwd: [members-discuss] Cloud Innovation Ltd vs AFRINIC (SCR 5C/30/21) Court Update

FYI. Mark. Forwarded Message Subject: [members-discuss] Cloud Innovation Ltd vs AFRINIC (SCR 5C/30/21) Court Update Date: Tue, 15 Feb 2022 18:49:56 +0400 From: AFRINIC Communication To: AFRINIC Members Discuss Dear Colleagues, I am pleased to share with you

Re: (Free)RADIUS Front-End

For posterity, finally went with Splynx. Really awesome product, covering not only RADIUS but also CRM, billing, invoicing, remote integration, e.t.c. Just in case anyone else ends up having the same requirement. Mark. On 9/20/21 09:19, Mark Tinka wrote: On 9/20/21 02:16, Philip

Re: Authoritative Resources for Public DNS Pinging

On 2/12/22 16:43, Mike Lewinski via NANOG wrote: Yes, I'm sure it was. Then probably rhymes with the days of "admin/admin". If they have been pushing out security and OS updates since then, and still keep 1.1.1.1 coded, that is purely their fault. Mark.

Re: Authoritative Resources for Public DNS Pinging

On 2/11/22 14:27, Mike Hammett wrote: The device that caused this whole conversation has failover functionality. Both interfaces ping an FQDN (that resolves to 8.8.8.8 and 1.1.1.1, with the device only latching on to one of those). If any of those meet the failure threshold, that interface

Re: junos config commit question

On 2/12/22 00:54, Jon Lewis wrote: Also, get into the habit of never doing a commit without first doing top show | compare so you can see what your change is actually doing to the whole config. i.e. if you did a show | compare at the top of the config and saw the entire interfaces section

Re: Authoritative Resources for Public DNS Pinging

On 2/11/22 22:43, Mike Lewinski via NANOG wrote: On a related note, I just discovered a NID that has 1.1.1.1 assigned to the outband interface by default, and it is apparently not user modifiable. So, not only can these devices never use 1.1.1.1 for name resolution, but attempts to

<    1   2   3   4   5   6   7   8   9   10   >