呵呵呵呵呵呵呵呵，公司的网络已经建好三年，可是经常受到网络小白的推责，比如扫描枪不会操作要触发两次，也扯到跟无线网络有关，不知道什么跟什么。
知道什么叫不尊重他的成果
我会因为别人是网络小白，连故障原因都判断不清楚，去在一万平方场地重建网络，开玩笑。
置疑他的水平
老板找来移动专业人员，又找来
erp 实施方的硬件人员本来就是用来判断到底是他们的软件有问题还是公司的网络有问题。结果完全凭经验不凭数据，进来就是服务器 io 不行，io ？网线超过 60 米有损耗？三层交换多 vlan 有性能问题。实际上 mssql 查询返回结果能几百 kb ，最多也就产品图片 4MB/s 。
这种状态玻璃心做怪，能花钱解决的事情花钱去呗，我给他省什么钱。买新服务器+新 ap+大量布点，越是会忽悠越是会花钱，爱情的天秤理论谁付出的多，谁心才流血。

说到底是谁做事的问题，这是来工作量啊！开会的时候说话简单，做事的人才知道难度在哪里，特别是那种三天两头翻来覆去做的事情。建议还是先了解事情要怎么做，再争论。

有 dnsmasq

#address=/cyberpolice.cn/127.0.0.1

挺漂亮的要内容有内容要配色有配色。还以为真正的 txt 上线，那真的是 abc+那种什么图，在 txt 里还能如何表现。

https://openwrt.org/toh/ubiquiti/edgerouter_4
https://openwrt.org/toh/ubiquiti/unifiac

我没有这两个硬件，但看起来已经被支持了。ubnt 的东西还是要小心点，可能还是有点版本区别的。

我们公司就
erx(openwrt)+huawei s5720s li 52p pwr(所谓的弱三层 vlan+acl 控制功能蛮多的，华为的东西就是文档齐全看文档都会了+固件更新勤快当前的都更新 33 个补丁了，上面还有两个大版本更新。。。)+uap ac(openwrt)
网络结构越简单越好，网管交换机也有助于发现网络异常。

看来你们的经验都是一种理想化的，可能从来没经历过因为电而导致的硬盘挂，重则整盘挂，轻则单分区出现坏道。是不是另年头 SSD 都不坏了，我竟然建议财务购买机械硬盘。。。这时候该如何分辩什么区域有坏道。

方便，不要跟方便难过，正常的装系统 2 小时至少。。。高重要的电脑都要经历系统备份再重装，是备份在硬盘的其它分区快，还是网络磁盘，还是不可靠的移动硬盘。

这么多年，习惯了 系统分区+QQ 这种需要备份的软件安装分区+第三分区，至少也要双分区。一个作为另外一个的备份分区。

做在交换机的 vlan 流控(仅仅只是个限速)和在路由上行方向的流控效果是不一样的，openwrt 的 CONNMARK 可以将上行标记带到下行流量。而且按照 tcp 握手过程，更早出去的上行流量也带来了更早的下行流量。
也许可以尝试一下 openwrt 里的 qos-scripts 。

这是 QOS 的话题。
描述中的什么设备能做到两个直播间能平均使用，不相互影响。指的是使用 200M/180M 这根宽带?

没玩过直播，不知道并发数是直接来源于入口，还是反向到相应的平台。

对于 QOS 来说,市面上宣传有这功能的有 ros/爱快 /高恪,但是 QOS 的优先级实现是非常有针对性的配置,也许得找人家帮你配置好.
用 180M 来保障 2 台电脑+4 个手机的上行+120 台电脑,我觉得是小菜一碟.

对于 openwrt htb 算法来说
1.它的 class 可以用来将大水管分成各种小水管,并且通过 ceil 来限制上限
2.它有 prio 优先级,可以保障 6 个终端的 IP 高优先级出列,或者更精确的服务端口.
3.然后就是如何理解通过的流量饱合程度造成的延迟变化,当时是按照 ADSL 线路 60%的流量低延迟,80%延迟可以接受.来相应的设定 rate 保障值
#$TC class add dev $UDEV parent 1:1 classid 1:2 htb rate $((UPLINK*8/10))kbps ceil $((UPLINK*9/10))kbps

#$TC class add dev $UDEV parent 1:1 classid 1:10 htb quantum 1514 rate $((UPLINK*1/10))kbps ceil $((UPLINK))kbps prio 0
#$TC class add dev $UDEV parent 1:1 classid 1:20 htb quantum 1514 rate $((UPLINK*1/10))kbps ceil $((UPLINK))kbps prio 2
#$TC class add dev $UDEV parent 1:2 classid 1:30 htb quantum 1514 rate $((UPLINK*3/100))kbps ceil $((UPLINK*90/100))kbps prio 3
#$TC class add dev $UDEV parent 1:2 classid 1:40 htb quantum 1514 rate $((UPLINK*5/100))kbps ceil $((UPLINK*85/100))kbps prio 4


类似这种基于 ip 的优先级实现.QOS 通过对各种小水管通过的流量饱合程度来解决延迟问题.它在同样的一个带宽可以造成高优先级 19ms,低优先级接近 600ms 的延迟.
以下只是一个示例,现在不用这种基于 ip 的实现,对于 iptables 来说规则越多越耗 cpu,性能也相应的变低.

#!/bin/sh

iptables -t mangle -F POSTROUTING
tc qdisc del dev br0 root 2> /dev/null > /dev/null

tc qdisc add dev br0 root handle 1: htb default 119
tc class add dev br0 parent 1: classid 1:1 htb rate $((3072))kbps

tc class add dev br0 parent 1:1 classid 1:2 htb rate $((3072*6/10))kbps ceil $((3072*6/10))kbps

IP=101;while [ $IP -le 125 ];do
tc class add dev br0 parent 1:2 classid 1:$IP htb rate $((3072*1/10))kbps ceil $((3072*1/4))kbps prio 4
tc qdisc add dev br0 parent 1:$IP handle $IP: sfq perturb 10
tc filter add dev br0 parent 1: prio 20 protocol ip handle $IP fw flowid 1:$IP
iptables -t mangle -A POSTROUTING -d 192.168.8.$IP -j MARK --set-mark $IP
iptables -t mangle -A POSTROUTING -d 192.168.8.$IP -j RETURN;let "IP+=1";done

tc class add dev br0 parent 1:1 classid 1:3 htb rate $((3072*5/10))kbps ceil $((3072*10/10))kbps prio 0
tc qdisc add dev br0 parent 1:3 handle 3: sfq perturb 10
tc filter add dev br0 parent 1: prio 10 protocol ip handle 3 fw flowid 1:3

iptables -t mangle -I POSTROUTING -m iprange --dst-range 192.168.8.200-192.168.8.205 -j RETURN
iptables -t mangle -I POSTROUTING -m iprange --dst-range 192.168.8.200-192.168.8.205 -j MARK --set-mark 3

职场还是个非常复杂的地方，年初就将朋友圈对公司所有的同事关闭。
曾经就因为在朋友圈说公司被老板约谈 2 次。。。语言这种东西不同人理解起来，处于不同位置都会听起来有严重歧义。
今天老板又赞扬了一下，上星期也赞扬了一下，其实有时候明明自己挺爱公司的怎么听到他的说话怪怪的。比如今年比去年有更好的改变，也不是忽攸你之类的。哈哈，我们老板还算开明，什么话都敢说。但有时候听着听着我也觉得像套路。所以朋友圈这种地方真不应该对同事开放。有时候开会的时候都不知道为什么才说一句话，突然被大批一通，就是长期被人告密造成的。。。不得不说有些人的存在看起来没什么能力，脏事坏事她都干了，连带办公室说话风吹草动也传到老板那。。。她们就是这样存在的，大内密探。

然后发的牢骚就一丁一点被积累，说一句话就感觉不知道为啥被批一通。。。职场啊。干的不爽就炒了老板。。。

需要一台有公网 ip
其它的反向连接到这台形成局域网，这方面人见人推 softether 可以安装在 Windows 也可以安装在路由，Windows 可以用命令行 l2tp 也可以使用 softether 自带协议。

前段时间一个用法就是在 vps 使用 haproxy 代理到 vpn 内网提供的 web 服务，成功了，甚至根本无需做 iptables nat/端口映射之类的操作，网上应该也有代理 3389 的实现。

softether 最好的 vpn 。

曾经在 dos 下，应该是分区摩术师，因为没有其它方法备份，只能在线调整 ntfs 分区，心惊胆颤好几小时。那次以后，再也没用过这种方法。宁愿备份心里有底，再调整分区，数据恢复。

为老板服务
为人民币服务。。。

看板目前用下来在大屏幕比较接近 trello 的是 wekan,可惜没有 app 。在手机屏幕由于支持拖动，就不好操作了。还是想找一个可以手机操作的，看来希望渺茫。
之前找了个 kanbani Android 端的缺乏标签功能，但手机端预览就方便多了。

今天又被叫去处理 2L4 处的 AP 断线问题，该处有 3 台电脑通过无线连接。由于其它 2 台电脑正常，另外一台頻繁出现掉线，用排除法的话多数为笔记本有问题。由于在现场笔记本頻繁的 ERP 断开，进入设备 AP 管理页面工作不到 49 天，却用掉了 swap 内存，最后无奈只能以重启 AP 结束。
终于忍无可忍对 Auto port-defend started.问题进行处理。之前在华为论坛询问关于该日志到底是端口抑制功能还是关闭功能，没有人给出准确的回答。这几天 google 了一下，部分文档提到了在启用 auto port-defend 时，系统将以 75%预设 CBR 速率进行工作。所以这应该属于端口抑制并不是关闭功能。由于华为交换机型号非常多，自己也不敢在业务系统上进行验证，想当然的就是这样了呗。

背景信息
如果某个端口下存在攻击者发起 DoS 攻击，从该端口上送 CPU 处理的大量恶意攻击报文会挤占带宽，导致其他端口的协议报文无法正常上送 CPU 处理，从而造成业务中断。
通过部署基于端口的防攻击功能，可以有效控制从端口上送 CPU 处理的报文数量，以防御针对 CPU 的 DoS 攻击。
该功能默认已使能。只有端口防攻击功能在已使能的情况下，才允许配置端口防攻击的其他相关功能。

s5720s-li 默认启用了 auto-defend 针对 source-mac/source-ip 特定的终端出现发包异常以后的自动防护处理。auto-port-defend 这个则是针对该端口，由于 AP 上接入了大量终端，很可能在这 AP 上的大量终端因为其中的一个终端发包有问题就导致该端口出现发包抑制，那么该端口上的其它的终端也可能连带出现网络异常。
观察了 display auto-defend attack-source history 并未出现办公用笔记本有发包超限记录所以不启用 whitelist 管理。简单的关闭 auto port-defend 功能，通过 auto-defend 对所有终端进行超过 60pps 以后发包抑制。感觉网络又快了点，希望这次能彻底解决无线网络问题。

display cpu-defend configuration all
display auto-defend attack-source
display auto-defend attack-source history
display auto-defend attack-source detail
display auto-port-defend whitelist
display auto-port-defend attack-source
display auto-port-defend statistics
reset auto-port-defend statistics
display arp static

使用实例
# 创建名称为 test 的防攻击策略。
<HUAWEI> system-view
[HUAWEI] cpu-defend policy test
[HUAWEI-cpu-defend-policy-test]display cpu-defend policy
[HUAWEI-cpu-defend-policy-test]display cpu-defend policy test
[HUAWEI-cpu-defend-policy-test] display cpu-defend configuration all #查看默认
[HUAWEI-cpu-defend-policy-test] dis this
auto-defend enable
auto-defend attack-packet sample 5
auto-defend threshold 60 #非 60 就有显示
auto-defend trace-type source-mac source-ip #默认不包含 source-portvlan
auto-defend protocol arp icmp dhcp igmp tcp telnet 8021x

undo auto-port-defend enable
quit
#cpu-defend-policy test #报错，似乎是无效规则。Info: Only car configuration can be activated on main control unit.
cpu-defend-policy test global
display auto-defend attack-source detail
display auto-defend attack-source history

[Switch]display auto-port-defend configuration
Info: Auto port defend is disabled on slot 0.
[Switch]

# 将源 IP 地址为 10.1.1.1 和 10.1.1.2 的用户加入攻击溯源的白名单。
<HUAWEI> system-view
[HUAWEI] acl 2000
[HUAWEI-acl-basic-2000] rule permit source 10.1.1.1 0
[HUAWEI-acl-basic-2000] rule permit source 10.1.1.2 0
[HUAWEI-acl-basic-2000] quit
[HUAWEI] cpu-defend policy test
[HUAWEI-cpu-defend-policy-test] auto-defend enable
[HUAWEI-cpu-defend-policy-test] auto-defend whitelist 1 acl 2000
display auto-port-defend whitelist

Auto port-defend started.
3L5
Jun 3 2020 08:49:19 GigabitEthernet0/0/3
3L6
Jun 3 2020 11:42:17 GigabitEthernet0/0/9
2L4
Jun 3 2020 07:37:25 GigabitEthernet0/0/25
Jun 3 2020 08:01:36 GigabitEthernet0/0/25
Jun 3 2020 09:06:27 GigabitEthernet0/0/25
Jun 3 2020 11:58:33 GigabitEthernet0/0/25
Jun 3 2020 12:27:16 GigabitEthernet0/0/25
Jun 3 2020 12:52:15 GigabitEthernet0/0/25
2L3
Jun 3 2020 08:02:18 GigabitEthernet0/0/29
Jun 3 2020 08:47:16 GigabitEthernet0/0/29
Jun 3 2020 11:02:18 GigabitEthernet0/0/29
Jun 3 2020 11:46:23 GigabitEthernet0/0/29
Jun 3 2020 11:54:59 GigabitEthernet0/0/29
Jun 3 2020 14:07:37 GigabitEthernet0/0/29
1L2
Jun 3 2020 12:14:54 GigabitEthernet0/0/37
1L3
Jun 3 2020 12:56:30 GigabitEthernet0/0/41

这种可以上网查找一下 arp 实现过程，最好带上交换机型号。
像使用的 s5720s-li 52p pwr 。它的很多默认设定就是不适合 ap 环境，像终端在不同端口飘移会导致被抑制


经常要向同事解释一些我自己都觉得说不通的问题。
今天在立式线，10 米以内就有两个 AP 。笔记本出现了断了又信号非常好的情况，可是网络不通。。。当时是在同步文件时，突然没有下载速度。从距离和信号强度判断不应该发生的事，但当时就是这样。当然这种情况平时发生多半通过禁用 /修复无线网卡就可以了。
然后这几天测试接在 vlan5 的无线打印机时，vlan1 的电脑时通时不通。包括一直反应的车间打印机时通时不通。。。那台打印机就是从 xp 换成 win7 什么也没动，然后一直被反应经常打印不出来。在老厂就有长时间打印机睡着问题就想通过计划任务定期去唤醒打印机，好像最终也没结果。
之前遇到的同一 ap 上两台电脑互相 ping 不通，通过互相指定静态 arp 解决。同一端口怀疑接入 ap 点，因为客户端数量增加而导致的端口速率抑制问题。
最近这个时通时不通就不好解释了。晚上查了这个 mac 地址飘移问题，按文档解释是针对网络环网情况。至于无线终端通过不同接口漫游导致的 mac 地址飘移属于正常现象，通过日志分析，也确实都是在 ap 连接的端口做飘移。只是今天才看到这个选项里怎么有一个 quit vlan recover time,从字面上解释，退出 vlan 的恢复时间 10 分钟这是什么意思。似乎挺符合那个时通时断的现象，又有点说不通，必竟现场的终端在时刻移动中。那不就成 10*N 。也许又通过 mesh 的路由协议到达网络目的地。
今天被同事问到无线不好，要不要换宽带。。。要学会花钱，连原因都判断错，那就成乱花钱。确实也一直在强调通过花钱来提升工作效率。整天被怨电脑不行，网络不行这个不行，那个不行。哎，严重阻挡别人的工作效率，该换的陈年老古董就该换了。这么多可能，万一换了没效果谁来背锅。。。

最后在 dis anac-address flapping 将 vlan5 AP 加入 exclude vlan list 。应该还有一个问题，这些问题都是在使用了两年以后才发现，可能之前用 mesh,网状结构自行解决了一些。

我记得华为的 airengine 系列在描述 leaderAP
大意是胖 ap 需要一个个设定很麻烦
采用 leaderAP 可以省掉 ac 的钱，又可以集中化配置，再加上一笔有更好的决定漫游效果。至于好在哪，没有硬件不知道。
当年 uap 系列的 ac 是可以周期性的向 ap 执行踢除弱信号的功能，当在 ap 端用脚本实现，我就认为 ac 无用论了。。。tplink 的 ac 都要花几百。

可以考虑一下华为的 airengine 系列，华为的东西好在文档齐全，固件更新勤快，tplink 和华为支持差距太大，连硬件使用高通还是 mtk 都是保密。。。