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.
