Hm, seems that I mistyped MTU in my original mail. lacp system-priority 1 rate-limit cpu direction input pps 1024 system jumbo mtu 1518
It is 1518 by default. > 9 feb. 2017 kl. 14:51 skrev Maxim Bourmistrov <m...@alumni.chalmers.se>: > > > 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.
