用RouterOS作为远程DHCP服务器

Cisco的DHCP服务器太难用了,查询起来不直观,要设置个固定的release累死人。Linux上那一堆DHCP daemon也没好到哪里去。想了想作为DHCP服务器的话,最直观方便的也就RouterOS了。简要记述一下把RouterOS作为远程DHCP服务器(不接入客户端所在二层)的配置方法。

配置

三层交换机(Cisco IOS):首先我们关闭ip helper对除DHCP以外其它协议的转发;然后在接口上设置helper address为RouterOS的IP地址即可。

no ip forward-protocol udp
interface Vlan100
 ip address 192.168.1.1 255.255.255.0
 ip helper-address 192.168.0.2

RouterOS:对每个DHCP server配置,接口设置为转发包的来源接口,relay设置为三层交换机面向DHCP客户端的内网端口的IP。

/ip pool
add name=dhcp ranges=192.168.1.10-192.168.1.254
/ip dhcp-server
add address-pool=dhcp conflict-detection=no disabled=no interface=bridge name=user-vlan relay=192.168.1.1
/ip dhcp-server network
add address=192.168.1.0/24 gateway=192.168.1.1 netmask=24

调试

Cisco IOS上可以用debug ip dhcp server packetdebug ip dhcp server events看到每个请求的转发过程。

RouterOS DHCP lease里面出现大量busy是因为conflict detection没有关闭,这种配置下conflict detection时间很长,可能会导致部分客户端超时以后疯狂重试,进而吃光DHCP地址池。因此参考配置里面关掉了conflict detection。


参考:

设置Rancher创建的Kubernetes集群的eviction策略

我一直把Rancher当Docker控制面板用,每个cluster都是单节点,启动一个算一个。最近就遇到这么个问题,一个node硬盘不足,触发了kubelet的eviction策略,于是kubelet干掉了两个container,又重启了两个——在唯一那个node上。如此循环往复了一刻钟,我就收获了几十个failed的container。

解决这个问题的方法很简单,用YAML方式编辑Rancher Cluster的设置,把kubelet的eviction策略设成空即可。

services: 
  kubelet: 
    extra_args:
      eviction-hard: ""
      eviction-soft: ""
      eviction-minimum-reclaim: ""

然后测试一下:

fallocate -l 37580963840 test.35g

应该就不会触发DiskPressure了。

说来这个eviction的设计也是很扯淡,它竟然是kubelet在本地计算的,不考虑整个cluster的情况。那我花那么多内存跑个etcd意义何在呢?

继续阅读