vxlan code is missing max_frame_size callback which is now mandatory if you
want to be able to do the change.
If vxlan code doesn’t care about that change, it can be as simple as:
vxlan_set_max_frame_size (vnet_main_t *vnm, vnet_hw_interface_t *hw, u32
frame_size)
{
return 0;
}
and:
Hoi Artyom,
Not an authoritative answer, although perhaps Damjan can confirm:
Is the semantic difference between max frame size (==device will reject
frames larger than that on Rx, and never Tx frames larger than that) and
mtu (L3 IP/IP6/MPLS packets will not be larger than that) with an
Artyom,
> Could someone please explain to me why VxLAN L3-mode was inverted here?
> https://gerrit.fd.io/r/c/vpp/+/34721
>
> The 'isL3' argument in api or 'l3' in CLI means "use this in L3 mode",
> doesn't it?
>
> This looks confusing, because we set L3 but the tunnel has MAC-address:
>
Hello,
There is a problem with setting MTU for VxLAN. I see, that there was a
change related to MTU and Max_frame_size -
https://gerrit.fd.io/r/c/vpp/+/34928
I don't know, what VxLAN configuration is right (I've asked about it here
Hello,
Could someone please explain to me why VxLAN L3-mode was inverted here?
https://gerrit.fd.io/r/c/vpp/+/34721
The 'isL3' argument in api or 'l3' in CLI means "use this in L3 mode",
doesn't it?
This looks confusing, because we set L3 but the tunnel has MAC-address:
DBGvpp# create vxlan
