标签归档:option

通过DHCP指定mtu

起因

家里的Proxmox母机开了VXLAN的SDN,但是由于vxlan隧道需要吃掉几十个字节作为包的头,导致vxlan的子网里面必须将mtu缩小至1450(母机之间互联用的是1500),但是每次开虚拟机就要手动改mtu这个非常的不友好。

在网上搜索手动指定mtu,文章全部都是使用静态的ip地址,在进一步搜索的时候,发现需要修改Linux的dhcpclient配置,在配置文件里面看到,在客户端发送dhcp请求的时候,是包含接口mtu信息的。

这样就有趣了。

那是不是DHCP服务器可以指定客户端的接口mtu呢?那就不需要我一个一个手动修改了。

进行一番搜索之后,果然发现DHCP里面指定了一个option 26,可以定义接口mtu。而RouterOS也支持自定义dhcp options,官方的wiki里面有关于option的写法。

开搞

配置过程中充满了曲折,我尝试在winbox里面添加option,根据教程,我尝试在value里面填入1400,报错,然后尝试填入0x5aa(1450的十六进制值),也不行。然后我发现,填值据然要加上单引号,于是填入‘1450’,过了。

然而事情并不顺利,我在客户端通过DHCP拿到一个奇怪的mtu,43525。当时我就蒙圈了,这啥情况?

于是我胡乱填了更多的值,得到了更多奇奇怪怪大的一批的mtu值。着实搞不明白,然后仔细看了一下winbox中给的rawvalue,看着怎么这么眼熟,好家伙,这不是把字节的顺序给反过来了吗!

本来应该是05 aa,结果变成了 aa 05

我再确认一下整个活

90000转成十六进制实际上是 01 5f 90,结果变成了 90 5f 01

确认之后,就可以根据需要的raw value反推需要填的值。我们需要 05 aa ,就将 aa 05转换成十进制,得出43525,填入之后得到正确的raw value。

得到正确的raw value。

经测试,能够正常获取到1450的mtu。

报告Bug

这明显是有问题啊,我就去给mikrotik提了个请求,得到回复说马上就修。

mikrotik确认了这个故障,说准备修复。

继续阅读官方wiki

后来仔细阅读了一下官方的wiki,里面提到确实可以用0x来输入十六进制的值,也不用用单引号括住。那为啥我输入0x5aa报错?再来一次的时候发现……0x05aa是完全没问题的,但是0x5aa就不行。

开头的0不能省略

看着顺眼多了。后续等官方修复这个Bug之后或许可以换回去’1450’,这样就更直观了。