OSPF is sensitive to MTU changes. You probably want the change in
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/ospfd/ospfe.c.diff?r1=1.96&r2=1.97
from -current. This will track interface MTU changes.
On 2017 Feb 09 (Thu) at 14:51:05 +0100 (+0100), Maxim Bourmistrov wrote:
:This actually a default setting for this switch, then you don’t configure
:jumbo at all.
:'sh running-config all’ shows this.
:
:I had ’ip ospf mtu-ignore’ in the config as well, but it didn’t help, so
:it is gone now.
:
:I’ll try with 1518.
:As seen in tcpdump, both obsd and dell announcing them selves with MTU 1500 in
:ospf.
:ospfd complains in loggs on bad seq.
:
:ospfd[39074]: recv_db_description: neighbor ID 10.4.255.29: seq num mismatch,
:bad flags
:
:Question is why ’ifconfig trunk1 mtu 1500’ triggers this, while initial
:setup is already with MTU 1500?
:
://mxb
:
:
:> 9 feb. 2017 kl. 14:31 skrev Peter Hessler <phess...@theapt.org>:
:>
:> Are you establishing an ospf session with the N3048? If you are, then
:> there is an MTU miss-match.
:>
:> Either "system jumbo mtu" refers to the IP packet, which doesn't match
:> the 1500 set on trunk1, or it refers to the ethernet packet which should
:> be 1518 (16 bytes for the ethernet header).
:>
:> Is it fixed if you change it to 1518, or drop that line completely?
:>
:>
:>
:> On 2017 Feb 09 (Thu) at 14:12:32 +0100 (+0100), Maxim Bourmistrov wrote:
:> :I see similar behavior with Cisco Nexus and 5.9-stable.
:> :How ever not 100% sure if it is the same trigger.
:> :
:> :
:> :
:> :> 9 feb. 2017 kl. 14:08 skrev Maxim Bourmistrov <m...@alumni.chalmers.se>:
:> :>
:> :> Hey,
:> :>
:> :> ospfd on 6.0-stable stucks in EXCHG/EXSTA while neighboring with Dell
:N3048
:> :switch.
:> :> According to some documentation around, this is due to MTU mismatch.
:> :>
:> :> This is not in my case.
:> :>
:> :> N3048:
:> :> system jumbo mtu 1512
:> :>
:> :> obsd:
:> :> trunk1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu
:1500
:> :> lladdr 00:25:90:78:62:b6
:> :> description: HW_INTERNAL
:> :> index 12 priority 0 llprio 3
:> :> trunk: trunkproto lacp
:> :> trunk id: [(8000,00:25:90:78:62:b6,4064,0000,0000),
:> :> (0001,f8:b1:56:61:a1:e4,02AE,0000,0000)]
:> :> trunkport bnx1 active,collecting,distributing
:> :> trunkport em1 active,collecting,distributing
:> :> groups: trunk
:> :> media: Ethernet autoselect
:> :> status: active
:> :> inet 10.4.255.27 netmask 0xffffffe0 broadcast 10.4.255.31
:> :>
:> :> ping with diff size of pkts and tcpdump reveals that there is no MTU
:> :mismatch.
:> :>
:> :> Restart of ospfd does not helps, only REBOOT.
:> :>
:> :> I decided to dig into this and found that changing MTU size on trunk1
:can
:> :reproduce this 100%.
:> :> Actually value does not changes, but problem with ospfd can be triggered
:> :this way:
:> :>
:> :> # ifconfig trunk1 mtu 1500
:> :> # rcctl restart ospfd
:> :>
:> :> and now ospfd will be stuck in EXCHG/EXSTA. Reboot helps always.
:> :>
:> :> Then I tried to put mtu for each face involved in trunk1. Result is then
:> :same - triggered with ’ifconfig trunk1 mtu 1500’.
:> :>
:> :> # cat /etc/hostname.bnx1
:> :> up mtu 1500
:> :>
:> :> # cat /etc/hostname.em1
:> :> up mtu 1500
:> :>
:> :> Any ideas?
:> :>
:> :> Br
:> :> mxb
:> :
:>
:> --
:> No matter how subtle the wizard, a knife in the shoulder blades will
:> seriously cramp his style.
:
--
It's not an optical illusion; it just looks like one.
-- Phil White
