nmcli connection modify “有线连接 4” ethernet.mtu 9014
nmcli con up “有线连接 4”
Views: 0
nmcli connection modify “有线连接 4” ethernet.mtu 9014
nmcli con up “有线连接 4”
Views: 0
qemu guest agent
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-qemu-ga/
qemu guest tools
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/
Views: 0
Linux 6.15 RC1中引入了io_uring zero copy Rx功能,而io_uring zerocopy tx则是在Linux 6.0中引入的,Linux6.1中进行了完善。
io_uring zero copy发送功能比较简单,而Rx功能的实现则比较复杂,还需要配合网卡的硬件支持。根据这篇文章,要使用Rx功能需要网卡支持ntuple filter和Header Split/Header Data Split,目前只有一些企业级网卡才支持。
Header Split是网卡厂商的叫法,在Linux内核中叫tcp data split(io_uring zero copy Rx只支持TCP协议吗?),可以通过ethtool -g命令查看网卡是否支持。
查看网卡是否支持ntuple:
ethtool -k enp2s0|grep ntuple
io_uring主要用于10G以上的网络中,因为在10G以上的网络中软件对软对数据的处理已经成为瓶颈,必须想办法进行优化,开发者展示了用单个CPU核心实现了200G的网络数据处理。
注意:
使用ethtool时要编译最新的版本,旧版本可能不支持相应的功能
参考:
https://kernelnewbies.org/Linux_6.0
https://lwn.net/Articles/879724/
https://docs.kernel.org/next/networking/iou-zcrx.html
https://www.phoronix.com/news/Linux-6.15-IO_uring
https://www.intel.com/content/www/us/en/developer/articles/training/setting-up-intel-ethernet-flow-director.html
Views: 0
使用KVM的时候可以选择多种网卡类型,不同网卡的性能差异较大,以下为性能测试结果:
网卡类型 | 速度 |
---|---|
r8139 | 200-300Mbps |
e1000 | 500-900Mbps |
virtio | 900-1000Mbps |
virtio(虚拟机之间) | 10-100Gbps |
一般来说虚拟网卡性能会低于物理网卡(包括硬件虚拟网卡SR-IOV等),在各种虚拟网卡中virtio是性能损失最小的,几乎忽略不计(10G以上可能会差距比较大)。
在使用SR-IOV时,虚拟机之间互联是通过网卡内部的Virtual Ethernet Bridge (VEB)完成的,VEB的带宽接近PCIE总线的带宽,例如Intel X710可提供50Gbps的内部交换带宽。
如果物理网卡支持VMDq,可以加速virtio对网络流量的处理,VMDq可以把每个虚拟机的流量映射到网卡上不同的队列。要开启VMDq需要物理网卡支持,并且使用virtio虚拟网卡。
结论:建议Linux使用virtio网卡,至少跑满千兆是没问题的,Windows使用e1000或e1000e网卡,因为windows默认情况下没有virtio驱动。
Views: 0
用IP组播地址进行标识的一个集合。任何用户主机(或其他接收设备)加入一个组播组,就成为了该组成员,可以识别并接收发往该组播组的组播数据。
组播组成员
所有加入某组播组的主机便成为该组播组的成员。组播组中的成员是动态的,主机可以在任何时刻加入或离开组播组。组播组成员可以广泛地分布在网络中的任何地方。
组播源
信息的发送者称为“组播源”,组播组地址为目的地址。一个组播源可以同时向多个组播组发送数据,多个组播源也可以同时向一个组播组发送报文。组播源通常不需要加入组播组。
组播设备
支持三层组播功能的路由器或交换机。组播设备不仅能够提供组播路由功能,也能够在与用户连接的末梢网段上提供组播组成员的管理功能。
RPF检查
主要用于过滤非法组播流量和防止环路。RPF检查是通过反向单拨路由来执行的,RPF会使用现在的单拨路由进行RPF检查,也可以配置静态RPF路由使用与单拨不同的路径。
配置RPF路由使用ip rpf-route-static
命令
华为设备不支持静态配置组播路由,只能通过PIM协议实现组播报文转发。
SPT建立过程,即扩散(Flooding)/剪枝(Prune):
1. PIM协议通过Hello消息维护领居状态,每个开启PIM功能的接口都会维护一个PIM neighbor信息表。Hello消息是周期性发送的,类似单播的ARP协议。
2. 扩散:当收到组播数据时,会从第一跳设备开启向所有PIM neighbor逐级扩散(不管PIM设备下有没有组播接收成员)。
3. 剪枝:没有接收成员的PIM设备向上游发送Prune消息进行剪枝,即阻止上游继续向该PIM设备发送组播数据
4. 嫁接:当被剪枝(Graft)分支的节点上出现了组播组成员时,为了减少该节点恢复成转发状态所需的时间,PIM-DM发送Graft消息主动恢复其对组播数据的转发
在DM机制中SPT是通过从组播源向全网组播数据进行扩散再剪枝建立的。
在扩散剪枝机制中,接收端PIM设备通过发送Prune消息进行剪枝,但是hold-time时间过后剪枝就会失效,然后就会重新执行扩散前枝过程。如果不想重复执行扩散剪枝过程则需要定时执行PIM-DM状态刷新,离组播源最近的PIM设备会定时向全网以组播形式发送State-Refresh消息进行PIM-DM状态刷新。默认情况下State-Refresh消息发送的间隔是60秒,默认的hold-time是210秒,一般State-Refresh间隔小于hold-time即可。
名词解释:
DR(Designated Router) 翻译为指定设备,与组播源直连的DR称为源端DR,与组播成员直连的DR称为接收端DR
RP(Rendezvous Point) 汇聚点,在PIM-SM所有组播源发出的数据由源端DR通过单播方式发送到RP,再由RP以组播形式扩散出去。
RPT(Rendezvous Point Tree) 以RP为根建立的组播分发树
SPT(Shortest Path Tree) 以组播源为根建立的组播分发树
BSR(Bootstrap Router) 自举设备,用来收集网络中的C-RP(侯选RP),并发送给所有其它PIM设备,配置动态RP时才需要BSR
Join消息仅用于PIM-SM网络,Join消息是周期性发送的,Join消息过期就会就会阻止对应的数据转发。Join消息使用单播方式发送给所有PIM设备(华为的文档中说是组播,但我认为单播更合理,具体有待验证)。
Prune消息主要用于PIM-DM网络,Prune消息是收到PIM-DM扩散数据时发送的,在SM网络中用于SPT切换。
在SM机制中RPT和SPT都是由接收端通过单播形式逐跳上游PIM设备发送Join消息建立的。
RP的作用是源端和接收端都向RP注册,由RP通过RPT发送首包组播数据,接收端收到首包数据后就知道了组播源,向组播源发送Join消息建立SPT,然手RP和SPT就不再需要了。默认情况下接收端DR收到首包数据后就会立即执行SPT切换,也可以通过spt-switch-threshold配置不执行SPT切换或者达到指定流量时再执行SPT切换。
SSM模式下的PIM-SM
SSM模式下的PIM-SM其实就是不配置BSR和RP的SM,需要接收端DR事先知道组播源,然后向组播源发送Join消息建立SPT,然后就可以通过SPT转发组播数据了。相当于PIM-SM ASM的简化模式。
由以上可知PIM-DM和PIM-SM SSM不需要配置BSR和RP,PIM-SM SSM需要事先知道组播源,别外两种方式则不需要。
在实际配置组播时与组播源相连的接口,中间转发组播数据的设备对应的接口,与接收端相连的PIM接口都要开启PIM功能,同时与接收端相连的设备还要开启IGMP功能。IGMP负责发现组播组成员,PIM负责转发组播数据。
如果组播转发路径与单播转发路径不同还要配置静态RPF路由,因为默认情况下只允许组播数据沿与单播数据相同的路径传播。
在VPN中配置组播时需要配置GRE隧道,因为大部分VPN都是不支持组播和广播流量通过的,需要把组播和广播流量用GRE封装然后再通过VPN传输。
https://www.dqnetworks.ie/toolsinfo/mcasttest/
https://github.com/individuwill/mcast
我在windows上用mcast的时候只能发送,不能接收
https://github.com/barryCrunch/multicast-tool/tree/main
这个经测试也不能在windows上运行
Views: 0
ntp refclock-master
ntp server source-interface all enable # USG6525E不需要执行
ntp ipv6 server source-interface all enable
undo ntp server disable
undo ntp ipv6 server disable
ntp unicast-server 192.168.1.1 #指定ntp服务器IP地址
在USG6525E中默认就是监听所有接口的,在USG6525F中默认是不监听任何接口的,必须配置ntp server source-interface all enable
Views: 0
“`go mod init mybee
go install github.com/beego/bee/v2@latest
go get github.com/beego/beego/v2@2.3.5
go mod tidy
<pre><code class="line-numbers">hello.go
“`golang
package main
import “github.com/beego/beego/v2/server/web”
func main() {
web.Run()
}
虽然很简单,但第一次尝试时却踩了不少坑,2.3.6版本在Windows上有Bug,我看的教程上给的安装命令也不对。
https://github.com/beego/beego/issues/5760
https://www.topgoer.com/beego%E6%A1%86%E6%9E%B6/beego%E5%AE%89%E8%A3%85/bee%E5%B7%A5%E5%85%B7%E7%9A%84%E4%BD%BF%E7%94%A8.html
Views: 0
ssh-keygen -t ecdsa -C backup-server
ecc peer-public-key backup-server encodint-type openssh
public-key-code begin
ecdsa-sha2-nistp256 AAAAE2vj............................. backup-server
public-key-code end
peer-public-key end
aaa
local-user backup privilege level 15
local-user backup service-type ssh
quit
ssh user backup assign ecc-key backup-server
ssh user backup service-type all
ssh user backup authentication-type ecc
user-interface vty 0 4
authentication-mode aaa
protocol inbound ssh
user privilege level 15
如果没有这个配置会出现密码登录正常,公钥登录无法进入系统视图
Views: 0
BSS Color是与动态CCA门限结合使用的,
CCA门限分为协议门限和能量门限,协议门限用来控制检测读取信号的最小能量值,小于CCA协议门限的信号会被忽略,设置较高的协议门限就可以忽略较弱的信号,减少干接收信号时的干扰。
BSS Color和能量门限则用来决定何时可以发送信号,如果收到同频信号且BSS color不同,且其它同频信号的强度低于能量门限则认为无干扰,可以发送信号。
通常收到的信号中OBSS的信号强度(OBSS_PD)不强于MYBSS协议门限20分贝(OBSS_PD介于CCA SD和CCA ED之间),否者执行CMSA/CD。
Views: 4