Re: Best TAC Services from Equipment Vendors

[Pascal Masha]

The only issue,that I have experienced, with Nokia TAC is throwing stuff
from team to team and before you get things done, each team has blamed the
other team.

On Thu, 14 Mar 2024 at 01:43, scott via NANOG  wrote:

>
>
> In light of this thread's contents, I have to give a shout out to Nokia
> TAC.  Maybe because we buy a lotta stuff and have a lotta maint
> contracts, but they don't do things like what has been mentioned.  Of
> course, I see some stuff from Level 1 folks where I think 'whaaat???'
> but they haven't done anything like what I have heard on this thread in
> the past 5 years I have been using them.  Even for 'informational'
> tickets they respond quickly.
>
> scott
>

Registration is Open for NANOG 91! + More

[Nanog News]

*Registration is Open for NANOG 91!*
*Join Us in Kansas City, MO. from 10 - 12 June*

Take advantage of early bird discounted pricing!

*REGISTER NOW * 

*Call for Presentations: NANOG 91 *
*NANOG 91 Will Cover a Wide Array of Topics *

Requested topics include network automation, Kubernetes, the future of
networking, Research and Education, security, optical networking, tutorials
and more.

The PC is also looking for a focus on cloud operations, including:

   - Best practices
   - “What I learned setting up my cloud network”
   - A panel discussion on how ISPs, Research + Education, Enterprise, and
   other industry sectors use the cloud
   - Security in the cloud

*MORE INFO  *

*Something New is Coming to NANOG!*
*Become a Part of the NANOG Showcase!*

Join the NANOG Showcase — our newest offering to reserve a table + connect
and network with NANOG attendees over a three-hour time block in high
traffic areas.

*Contact Shawn Winstead at swinst...@nanog.org  to
learn more and sign up!*

*Video of the Week *
*APNIC's Geoff Huston Presents "BGP in 2023"*

At over 1k views in just a few weeks — watch APNIC's Chief Scientist Geoff
Huston discuss "BGP in 2023" at our most recent meeting, NANOG 90.

*WATCH NOW * 

[NANOG-announce] Registration is Open for NANOG 91! + More

[Nanog News]

*Registration is Open for NANOG 91!*
*Join Us in Kansas City, MO. from 10 - 12 June*

Take advantage of early bird discounted pricing!

*REGISTER NOW * 

*Call for Presentations: NANOG 91 *
*NANOG 91 Will Cover a Wide Array of Topics *

Requested topics include network automation, Kubernetes, the future of
networking, Research and Education, security, optical networking, tutorials
and more.

The PC is also looking for a focus on cloud operations, including:

   - Best practices
   - “What I learned setting up my cloud network”
   - A panel discussion on how ISPs, Research + Education, Enterprise, and
   other industry sectors use the cloud
   - Security in the cloud

*MORE INFO  *

*Something New is Coming to NANOG!*
*Become a Part of the NANOG Showcase!*

Join the NANOG Showcase — our newest offering to reserve a table + connect
and network with NANOG attendees over a three-hour time block in high
traffic areas.

*Contact Shawn Winstead at swinst...@nanog.org  to
learn more and sign up!*

*Video of the Week *
*APNIC's Geoff Huston Presents "BGP in 2023"*

At over 1k views in just a few weeks — watch APNIC's Chief Scientist Geoff
Huston discuss "BGP in 2023" at our most recent meeting, NANOG 90.

*WATCH NOW * 
___
NANOG-announce mailing list
NANOG-announce@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: Best TAC Services from Equipment Vendors

[Justin H.]

Richard Laager wrote:

FWIW, I haven't tried calling after hours.
If I have to call after-hours, I get an answer from someone who is going 
to be handling my case (assuming that it doesn't have an engineer who's 
on-shift already assigned to it).  Yes, after-hours has traditionally 
been when I talk to the folks who are still learning, but when hasn't 
that been true?  Having said that, I always get the impression that 
they're having a side-line conversation with a more senior engineer who 
is helping them with any troubleshooting that they're not familiar with.


I admit, I don't use any particularly advanced features, so my 
experience may not be typical, but I've never had an operational issue 
that they haven't been able to solve fairly quickly.


Justin H.

Re: Value of linux net.ipv6.route.max_size

[Toke Høiland-Jørgensen via NANOG]

Willy Manga  writes:

> Hi,
>
> I recently noticed an issue with some routers complaining with that message:
>
> "kernel: Route cache is full: consider increasing sysctl 
> net.ipv6.route.max_size."
>
> These routers are running FRR on Debian 12 , kernel 6.1.0-17-amd64. They 
> are receiving full routing table and routes are inserted into the kernel 
> routing table.
>
> I saw a similar error here [1] and it leads me to [2] as well but I 
> should admit I did not read everything.
>
> I did not dive into the details of the two links but for now , I want to 
> increase that value (and find the source of that error).
>
> The current value of net.ipv6.route.max_size is: 4096 . I guess it's the 
> default on at least that kernel.
>
> For reference net.ipv4.route.max_size=2147483647 .
>
> Of course, we cannot correlate the two but I was wondering, what either 
> people are using or what might be a reasonable value for the IPv6 
> counterpart.

The check (and error message) was removed entirely starting with kernel
6.3[0], so setting it to the same INT_MAX value as for IPv4 should
probably be fine.

The memory leak that mail thread you linked to references should have
been fixed already in the kernel you're running (the fix[1] went in
during the 5.16 cycle).

-Toke

[0] https://lore.kernel.org/all/20230112012532.311021-1-jmaxwel...@gmail.com/
[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cdef485217d30382f3bf6448c54b4401648fe3f1

Value of linux net.ipv6.route.max_size

[Willy Manga]

Hi,

I recently noticed an issue with some routers complaining with that message:

"kernel: Route cache is full: consider increasing sysctl 
net.ipv6.route.max_size."


These routers are running FRR on Debian 12 , kernel 6.1.0-17-amd64. They 
are receiving full routing table and routes are inserted into the kernel 
routing table.


I saw a similar error here [1] and it leads me to [2] as well but I 
should admit I did not read everything.


I did not dive into the details of the two links but for now , I want to 
increase that value (and find the source of that error).


The current value of net.ipv6.route.max_size is: 4096 . I guess it's the 
default on at least that kernel.


For reference net.ipv4.route.max_size=2147483647 .

Of course, we cannot correlate the two but I was wondering, what either 
people are using or what might be a reasonable value for the IPv6 
counterpart.



1. https://bugzilla.redhat.com/show_bug.cgi?id=1813691

2. 
https://lore.kernel.org/netdev/e022d597-302d-c061-0830-6ed20aa61...@qtmlabs.xyz/T/#u


--
Willy Manga

Looking for a cyberArc EPm sales rep/vendor for the UK

[touseef.rehman1--- via NANOG]

 So starting a new gig where I previously worked looking to use this 
least priviliage software for dev machines in windows 365  and physical. 
Looking for some routes into puchasing the software per user- not sure 
if other aspects of cyber arc are required anyway if anyone has some 
good contacts to negotiate purchasing?






Sent via BT Email App