Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zebra: netstat Recv-Q value is continue keep going up. #15303

Closed
wiselike opened this issue Feb 5, 2024 · 7 comments · May be fixed by #15613
Closed

zebra: netstat Recv-Q value is continue keep going up. #15303

wiselike opened this issue Feb 5, 2024 · 7 comments · May be fixed by #15613
Labels
triage Needs further investigation

Comments

@wiselike
Copy link

wiselike commented Feb 5, 2024


Describe the bug

  • [√ ] Did you check if this is a duplicate issue?
  • [√ ] Did you test it on the latest FRRouting/frr master branch?

Screenshots
image

Versions

  • OS Version:
    CentOS7.8、CentOS8

  • FRR Version:
    quaager 2.07、frr9.1、frr9.0

@wiselike wiselike added the triage Needs further investigation label Feb 5, 2024
@ton31337
Copy link
Member

ton31337 commented Feb 5, 2024

Can you describe a bit your topology, configuration, and the whole scope of messages received/sent?

@lijinxianglogo
Copy link

lijinxianglogo commented Feb 6, 2024

Can you describe a bit your topology, configuration, and the whole scope of messages received/sent?

Hello: I am his friend; in fact this frr does not have any neighbors;
I have some screenshots here, I hope they can be of some help to you
企业微信截图_17072140416343
image

企业微信截图_17072140717127

@donaldsharp
Copy link
Member

How are you starting zebra and what does your configuration look like. I am not seeing this locally so I need proper recreation steps.

@lijinxianglogo
Copy link

How are you starting zebra and what does your configuration look like. I am not seeing this locally so I need proper recreation steps.
Sorry, I only replied to you now

I started frr through systemctl restart frr.service

The configuration is as follows
image
Building configuration...

Current configuration:
!
frr version 8.4.2
frr defaults traditional
hostname zebra
log file /usr/local/appdata/normal/log/frr/zebra.log
no ip forwarding
no ipv6 forwarding
hostname ospfd
log file /usr/local/appdata/normal/log/frr/ospfd.log
hostname ospf6d
log file /usr/local/appdata/normal/log/frr/ospf6d.log
hostname localhost.localdomain
!
password zebra
!
interface eth0
ip address 10.2.41.26/22
ip ospf cost 10
ip ospf dead-interval 40
ipv6 address aacc::902/128
ipv6 ospf6 area 0.0.0.10
ipv6 ospf6 cost 10
exit
!
interface lo
ip address 112.23.23.23/32 label lo:1
ipv6 address aacc::2323/128
ipv6 ospf6 area 0.0.0.10
ipv6 ospf6 cost 10
exit
!
router ospf
ospf router-id 10.2.112.26
network 10.2.40.0/22 area 0.0.0.2
network 112.23.23.23/32 area 0.0.0.2
exit
!
router ospf6
ospf6 router-id 10.2.141.26
exit
!
ip nht resolve-via-default
!
ipv6 nht resolve-via-default
!
end

@lijinxianglogo
Copy link

lijinxianglogo commented Feb 12, 2024

How are you starting zebra and what does your configuration look like. I am not seeing this locally so I need proper recreation steps.

My system is centos7.8

A special situation that may help you is to ping the local ipv6 address

Thank you very much for your reply

@ton31337
Copy link
Member

Can you show also /etc/frr/daemons file?

@lijinxianglogo
Copy link

Can you show also /etc/frr/daemons file?

This file tells the frr package which daemons to start.

Sample configurations for these daemons can be found in

/usr/share/doc/frr/examples/.

ATTENTION:

When activating a daemon for the first time, a config file, even if it is

empty, has to be present and be owned by the user and group "frr", else

the daemon will not be started by /etc/init.d/frr. The permissions should

be u=rw,g=r,o=.

When using "vtysh" such a config file is also needed. It should be owned by

group "frrvty" and set to ug=rw,o= though. Check /etc/pam.d/frr, too.

The watchfrr, zebra and staticd daemons are always started.

bgpd=no
ospfd=yes
ospf6d=yes
ripd=no
ripngd=no
isisd=no
pimd=no
ldpd=no
nhrpd=no
eigrpd=no
babeld=no
sharpd=no
pbrd=no
bfdd=no
fabricd=no
vrrpd=no
pathd=no

If this option is set the /etc/init.d/frr script automatically loads

the config via "vtysh -b" when the servers are started.

Check /etc/pam.d/frr if you intend to use "vtysh"!

vtysh_enable=yes
zebra_options=" -A 127.0.0.1 -s 90000000 -f /etc/frr/zebra.conf"
bgpd_options=" -A 127.0.0.1 -f /etc/frr/bgpd.conf"
ospfd_options=" -A 127.0.0.1 -f /etc/frr/ospfd.conf"
ospf6d_options=" -A ::1 -f /etc/frr/ospf6d.conf"
ripd_options=" -A 127.0.0.1"
ripngd_options=" -A ::1"
isisd_options=" -A 127.0.0.1"
pimd_options=" -A 127.0.0.1"
ldpd_options=" -A 127.0.0.1"
nhrpd_options=" -A 127.0.0.1"
eigrpd_options=" -A 127.0.0.1"
babeld_options=" -A 127.0.0.1"
sharpd_options=" -A 127.0.0.1"
pbrd_options=" -A 127.0.0.1"
staticd_options="-A 127.0.0.1"
bfdd_options=" -A 127.0.0.1"
fabricd_options="-A 127.0.0.1"
vrrpd_options=" -A 127.0.0.1"
pathd_options=" -A 127.0.0.1"

configuration profile

#frr_profile="traditional"
#frr_profile="datacenter"

This is the maximum number of FD's that will be available.

Upon startup this is read by the control files and ulimit

is called. Uncomment and use a reasonable value for your

setup if you are expecting a large number of peers in

say BGP.

#MAX_FDS=1024

The list of daemons to watch is automatically generated by the init script.

##watchfrr_options=""

To make watchfrr create/join the specified netns, use the following option:

##watchfrr_options="--netns"

This only has an effect in /etc/frr//daemons, and you need to

start FRR with "/usr/lib/frr/frrinit.sh start ".

for debugging purposes, you can specify a "wrap" command to start instead

of starting the daemon directly, e.g. to use valgrind on ospfd:

ospfd_wrap="/usr/bin/valgrind"

or you can use "all_wrap" for all daemons, e.g. to use perf record:

all_wrap="/usr/bin/perf record --call-graph -"

the normal daemon command is added to this at the end.

@FRRouting FRRouting locked and limited conversation to collaborators Feb 13, 2024
@ton31337 ton31337 converted this issue into discussion #15365 Feb 13, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
triage Needs further investigation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants