- Test - lists.nanog.org

Re: Strange behavior on the Juniper MX240
by Saku Ytti 06 May '22

06 May '22

On Fri, 6 May 2022 at 12:17, Mark Tinka <mark(a)tinka.africa> wrote: > We have run into issues with platforms that have shipped with FIB's in favour of IPv4 and less for IPv6 and MPLS labels. Shifted around, you could give up whatever is left for IPv6 and ACL's to give more to IPv4, but you then end up losing native IPv6 scalability. And, of course, whatever other permutation you may think of that leaves you in a babysitting scenario for the protocol(s) assigned to peasantry. 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. Existence or non-existence of configuration toggle to affect this doesn't make that situation worse or better. It is not implied to be a tactical short-term fix, it depends and you must understand what you are doing to determine your position in any case. -- ++ytti

2 1

Strange behavior on the Juniper MX240
by Nehul Patel 06 May '22

06 May '22

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 suggest how to resolve it May 4 12:42:00 cr01 newsyslog[44735]: logfile turned over due to size>1024K May 4 12:42:01 /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 5 (Invalid) May 4 12:42:01 /kernel: RT_PFE: RT msg op 3 (PREFIX CHANGE) failed, err 5 (Invalid) May 4 12:42:01 last message repeated 4 times May 4 12:42:01 fpc0 RT: IPv6:0 - 2600:40fc:1011::/48 (add rt entry into jtree failed) May 4 12:42:01 fpc0 RT-HAL,rt_entry_add_msg_proc,2028: rt_halp_vectors->rt_create failed May 4 12:42:01 fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto ipv6,len 48 prefix 2600:40fc:1011::/48 nh 1048576 May 4 12:42:01 fpc0 RT-HAL,rt_msg_handler,540: route process failed May 4 12:42:01 fpc0 RT: Failed prefix add IPv6 - 2001:67c:20fc::/48 (No memory) on FE 0 May 4 12:42:01 fpc0 RT: IPv6:0 - 2001:67c:20fc::/48 (add rt entry into jtree failed) May 4 12:42:01 fpc0 RT-HAL,rt_entry_add_msg_proc,2028: rt_halp_vectors->rt_create failed May 4 12:42:01 fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto ipv6,len 48 prefix 2001:67c:20fc::/48 nh 1048576 May 4 12:42:01 fpc0 RT-HAL,rt_msg_handler,540: route process failed May 4 12:42:01 fpc0 RT: Failed prefix add IPv6 - 2606:2800:e004::/48 (No memory) on FE 0 May 4 12:42:01 fpc0 RT: Failed prefix add IPv6 - 2a05:3181:ffff::/48 (No memory) on FE 0 May 4 12:42:01 /kernel: RT_PFE: RT msg op 3 (PREFIX CHANGE) failed, err 5 (Invalid) May 4 12:42:01 /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 5 (Invalid) May 4 12:42:01 /kernel: RT_PFE: RT msg op 2 (PREFIX DELETE) failed, err 5 (Invalid) May 4 12:42:02 fpc0 RT: Failed prefix add IPv4 - 79.120.22/24 (No memory) on FE 0 May 4 12:42:02 fpc0 RT: IPv4:0 - 79.120.22/24 (add rt entry into jtree failed) May 4 12:42:02 fpc0 RT-HAL,rt_entry_add_msg_proc,2028: rt_halp_vectors->rt_create failed May 4 12:42:02 fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto ipv4,len 24 prefix 79.120.22/24 nh 1048583 May 4 12:42:02 /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 5 (Invalid) May 4 12:42:02 fpc0 RT-HAL,rt_msg_handler,540: route process failed May 4 09:33:17 fpc0 RSMON: Resource Category:jtree Instance:jtree2-seg0 Type:free-pages Available:20 is less than LWM limit:1638, rsmon_syslog_limit() May 4 09:33:17 fpc0 RSMON: Resource Category:jtree Instance:jtree2-seg0 Type:free-dwords Available:1280 is less than LWM limit:104857, rsmon_syslog_limit() May 4 09:33:18 fpc0 RSMON: Resource Category:jtree Instance:jtree3-seg0 Type:free-pages Available:19 is less than LWM limit:1638, rsmon_syslog_limit() May 4 09:33:18 fpc0 RSMON: Resource Category:jtree Instance:jtree3-seg0 Type:free-dwords Available:1216 is less than LWM limit:104857, rsmon_syslog_limit() May 4 09:33:18 fpc1 RSMON: Resource Category:jtree Instance:jtree0-seg0 Type:free-pages Available:16 is less than LWM limit:1638, rsmon_syslog_limit() May 4 09:33:18 fpc1 RSMON: Resource Category:jtree Instance:jtree0-seg0 Type:free-dwords Available:1024 is less than LWM limit:104857, rsmon_syslog_limit() May 4 09:33:18 fpc1 RSMON: Resource Category:jtree Instance:jtree1-seg0 Type:free-pages Available:15 is less than LWM limit:1638, rsmon_syslog_limit() May 4 09:33:18 fpc1 RSMON: Resource Category:jtree Instance:jtree1-seg0 Type:free-dwords Available:960 is less than LWM limit:104857, rsmon_syslog_limit() May 4 09:33:18 fpc1 RSMON: Resource Category:jtree Instance:jtree2-seg0 Type:free-pages Available:19 is less than LWM limit:1638, rsmon_syslog_limit() May 4 09:33:19 fpc1 RSMON: Resource Category:jtree Instance:jtree2-seg0 Type:free-dwords Available:1216 is less than LWM limit:104857, rsmon_syslog_limit() May 4 09:33:19 fpc1 RSMON: Resource Category:jtree Instance:jtree3-seg0 Type:free-pages Available:17 is less than LWM limit:1638, rsmon_syslog_limit() May 4 09:33:19 fpc1 RSMON: Resource Category:jtree Instance:jtree3-seg0 Type:free-dwords Available:1088 is less than LWM limit:104857, rsmon_syslog_limit() May 4 09:33:19 fpc2 RSMON: Resource Category:jtree Instance:jtree0-seg0 Type:free-pages Available:15 is less than LWM limit:1638, rsmon_syslog_limit() May 4 09:33:19 fpc2 RSMON: Resource Category:jtree Instance:jtree0-seg0 Type:free-dwords Available:960 is less than LWM limit:104857, rsmon_syslog_limit() May 4 09:33:19 fpc2 RSMON: Resource Category:jtree Instance:jtree1-seg0 Type:free-pages Available:15 is less than LWM limit:1638, rsmon_syslog_limit() May 4 09:33:19 fpc2 RSMON: Resource Category:jtree Instance:jtree1-seg0 Type:free-dwords Available:960 is less than LWM limit:104857, rsmon_syslog_limit() Any suggestions will be helpful Please do let me know if you have any questions. Regards and thanks, Nehul

9 25

Re: [NANOG] [Mailman List] Strange behavior on the Juniper MX240
by Nehul Patel 06 May '22

06 May '22

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 to upgrade the Junos to the newer version in order to try above command of it. On Thu, May 5, 2022 at 11:55 AM Mark Tinka via NANOG < admin(a)community.nanog.org> wrote: > Mark_Tinka4 <https://community.nanog.org/u/mark_tinka4> > May 5 > > If memory serves, I believe the DPC used I-chip for Layer 3, and EZ-chip > for Layer 2 (Ethernet framing + MAC look-up). Someone with a longer memory > may need to chime in. Mark. > ------------------------------ > > Visit Topic > <https://community.nanog.org/t/strange-behavior-on-the-juniper-mx240/55213/21> > to respond. > > To unsubscribe from these emails, click here > <https://community.nanog.org/email/unsubscribe/003092263321bdfde4f4ae64f65f0…> > . > >

2 1

Re: [NANOG] [Mailman List] Strange behavior on the Juniper MX240
by Nehul Patel 05 May '22

05 May '22

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 On Thu, May 5, 2022, 08:20 Nehul Patel <nehul.patel(a)gmail.com> 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 > > > > On Thu, May 5, 2022, 01:46 Mark Tinka via NANOG <admin(a)community.nanog.org> > wrote: > >> Mark_Tinka4 <https://community.nanog.org/u/mark_tinka4> >> May 5 >> >> Certainly an option, but this requires quite a bit of babysitting, >> because as the DFZ oscillates, you can run into issues that send you into >> circles, largely unaware about FIB issues, especially when just a subset of >> routes are affected. >> >> So yes, definitely an option, but the OP will need to watch the line >> cards like a hawk, and be ultra sensitive to debugging regular issues vs. >> FIB-related issues. >> >> Mark. >> ------------------------------ >> >> Visit Topic >> <https://community.nanog.org/t/strange-behavior-on-the-juniper-mx240/55213/18> >> to respond. >> >> To unsubscribe from these emails, click here >> <https://community.nanog.org/email/unsubscribe/47c76e5320108f540dc1dd4ac05e9…> >> . >> >> >

2 1

Ready to compromise? was RE: V6 still not supported
by Pascal Thubert (pthubert) 05 May '22

05 May '22

Dear all Following advice from thus list, I updated the YADA I-Draft (latest is https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html, more to come soon if feedback is heard) and proposed it to the v6ops WG at the IETF. For memory, the main goal here is to find a compromise as opposed to yet another transition solution, though it can be used as a side effect to move along the ladder. The compromise does not change IPv4 or IPv6, tries not to take side for one or the other, and add features to both sides which, if implemented, reduce the chasm that leads to dual stack and CG-NATs. There's value for the movers, lots more public address space for the IPv4-only stack/networks and free prefixes per node and new deployment opportunities for the IPv6-only ones. One major update from the original text accounts for Dave's comment in this list on BCP 38 enforcement, I believe it's solved now. I also added format layouts to Abe Chen's question, and text on the naïve version vs. all the elasticity that exists there and in IP in general to allow real world deployments. Comments welcome, here and/or at v6ops for those who participate there. Many thanks in advance; Pascal

2 4

OARC 38 Call for Contributions
by John Todd 02 May '22

02 May '22

OARC 38 will be a two-day hybrid meeting held on July 30th and 31st, 2022 starting at 10 am (Eastern). The onsite part of the meeting will be co-located with IETF 114 (Philadelphia). The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: - Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). - Deployment: DNS config management and release process. - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. - Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency - Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT As it is an hybrid workshop, we'd like to encourage brevity; presentations should not be longer than 20 minutes (with additional time for questions). **Workshop Milestones:** 2022-05-01 Submissions open via Indico 2022-06-20 Deadline for submission (23:59 UTC) 2022-06-21 Initial Contribution list published 2022-06-28 Full agenda published 2022-07-12 Deadline for slideset submission and Rehearsal 2022-07-30 OARC 38 Workshop - Day 1 2022-07-31 OARC 38 Workshop - Day 2 The Registration page and details for presentation submission are published at: https://www.dns-oarc.net/oarc38 To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. Additional information for speakers of OARC 38: * your talk will be broadcast live and recorded for future reference * your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting * Remote speakers have mandatory rehearsal on 2022-07-12 at 15:00 UTC. It would be very useful to have your slides (even if draft) ready for this. Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via <submissions(a)dns-oarc.net> John Todd, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact <sponsor(a)dns-oarc.net> if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) -- John Todd - jtodd(a)quad9.net General Manager - Quad9 Recursive Resolver

1 0

Could people with experience with ARIN's IRR API contact me off-list?
by Dan Mahoney (Gushi) 02 May '22

02 May '22

All, Dayjob uses RADB mainly but would like for authority purposes to put some things in ARIN. I've had an ARIN help desk ticket in for a couple days, and would like to move to letting our IPAM files be the source of truth and push everything in via the API, but I'm finding a few things about the API just obtuse. I could post that laundry list here, but I'd prefer to get confirmations from people who've written tools against it what tools you found useful, and if the broken things I'm seeing are actually as broken as I think they are. ARIN people who implemented this, I'd love to hear from you as well. Best, -Dan --

3 2

Disney+ Issues
by Norman Jester 02 May '22

02 May '22

Anyone from Disney+ here? If you can reply off-list I'd appreciate it. I have emailed every place I can think of to solve a geoip problem affecting hundreds of customers, no reply in weeks. Would appreciate some help thanks in advance. -- Norman JellyDigital

12 14

how networking happens in Hawaii
by scott 01 May '22

01 May '22

I thought I'd put a smile on your faces for Friday. This is how networking happens in Hawaii... https://www.civilbeat.org/2022/04/thousands-of-hawaiians-could-lose-phone-a… ---------------------------------------------------------------------- "State regulators have opened an emergency investigation of Sandwich Isles Communications..." "The investigation comes as Sandwich Isles is apparently blocking access to its telecom infrastructure to another provider, Hawaiian Telcom, alleging trespass, filing police reports and putting customer phone and internet service at risk." "Sandwich Isles Communications is an Oahu-based telephone company founded in 1995 with a mission to provide communication services to Native Hawaiians living on homesteads" "In 2015, founder Albert Hee was convicted of criminal tax fraud...Hee was sentenced in 2016 to 46 months in prison." "With federal backing, the company built the Paniolo Network, a web of undersea and terrestrial fiber optic cables." "...a bankruptcy trustee ordered the sale of the Paniolo Network to Hawaiian Telcom." "Hawaiian Telcom says Sandwich Isles has removed, destroyed or tampered with Hawaiian Telcom locks on perimeter fences surrounding buildings purchased by Hawaiian Telcom. And that Sandwich Isles has installed its own locks and devices on buildings and premises owned by Hawaiian Telcom, as well as welding shut access gates. The company also says Sandwich Isles has made multiple false police reports alleging Hawaiian Telcom is trespassing on its property." "Al Hee was requesting that Hawaiian Telcom’s lock on its Paniolo Building at Laiopua on the Big Island be replaced. Otherwise, Hee said he would call the police." "In a Sept. 11 letter to customers, Sandwich Isles blamed the situation on Hawaiian Telcom." ---------------------------------------------------------------------- When your brother is very connected politically I guess one feels invincible... "...welding shut access gates..." hahaha! Insanity! There're other 'outages' that didn't make the article. Repeated fiber damaged off shore, etc. scott

6 8

Centurylink\Lumen
by Mike Hammett 29 Apr '22

29 Apr '22

There's a nearby Lumen route (originally Digital Teleport) where they have built their route to someone else's network where they've built a POP between their own construction and that third party dark fiber provider. That dark fiber provider is friendly. Knowing what they've built out in other places (compared to the number of strands available on the route), I was looking to utilize that lateral to get into the Centurylink POP from the dark fiber network. They've more or less said it doesn't exist and that it'd be $100k for the privilege of paying them more than I'm paying anyone else for a wave. I know it exists because they have no other way out. I'm hoping to find someone in Centurylink\Lumen with a clue that can look up a POP, look at what cables are actually there, strand counts, how big their IRU is, identify excess assets and let me use them to overpay them for service. Why I'm so specifically wanting Lumen is there are very limited options on the route I'm asking for. I'm already doing business with the others, so I'd like some entity diversity. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP

1 0