Bug 1303272 - quagga starts after networking but ospf6d doesn't use the autodetect MTU
quagga starts after networking but ospf6d doesn't use the autodetect MTU
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: quagga (Show other bugs)
7.2
All Linux
unspecified Severity medium
: rc
: ---
Assigned To: Michal Ruprich
qe-baseos-daemons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-29 22:46 EST by Matyas Koszik
Modified: 2017-08-03 03:33 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matyas Koszik 2016-01-29 22:46:59 EST
Description of problem:
ospf6d uses MTU seen during initialization, which happens before networking, so it ignores the one set in the configuration.

Version-Release number of selected component (if applicable):
quagga-0.99.22.4-4.el7.x86_64

How reproducible:
very


Steps to Reproduce:
1. echo MTU=9000 >> /etc/sysconfig/network-scripts/ifcfg-enp7s0f0
2. echo -n 'router ospf6\ninterface enp7s0f0 area 0.0.0.0' > /etc/quagga/ospf6d.conf
3. reboot


Actual results:
sh ipv6 ospf int shows this:
Instance ID 0, Interface MTU 1500 (autodetect: 9000)
1500 is being used in the database description packets, making it impossible to peer with routers that check the mtu settings (which is the default, even in quagga).


Expected results:
Either the networking setup should occur before starting quagga, so changes like this are seen during initialization, or ospf6d should use the actual detected MTU.

Additional info:

Note You need to log in before you can comment on or make changes to this bug.