Tech黑手 - 工作雜記

How to repair and clone disk with ddrescue

2024-08-29T18:32:00.001+08:00

ddrescue is a tool that can be used to repair and clone disks on a Linux system. This includes hard drives, partitions, DVD discs, flash drives, or really any storage device. It performs data recovery by copying data as blocks.

If ddrescue encounters errors from the data it’s trying to copy, it can discard them and keep only the good data. This makes it an ideal tool when trying to recover data from a corrupted disk. In this tutorial, you will learn how to install ddrescue and use it to clone a full disk or partition, and write that data to an empty storage space.

To install ddrescue on Ubuntu, Debian, and Linux Mint:

$ sudo apt install gddrescue

Clone a partition to image file or other disk

In the section, we will use ddrescue to clone a partition or full disk (the process is the same) to an image file. That file can that be written to another disk or partition afterwards. We will also show the process to clone a partition directly to another disk, bypassing the image file creation and instead creating a direct clone onto new hardware.

First, open a command line terminal and identify the device path to the hard drive or partition that you would line to clone. For this, you can use a tool like lsblk, fdisk, etc.
```
$ lsblk
```
Here we find the device path /dev/sdb1 which is the partition we want to clone
Note that the -d option will force ddrescue to ignore the kernel’s cache and instead access the disk directly.
ddrescue process of cloning the partition to an image file
Note that if you are trying to recover data from a corrupted disk, you may want to append the -r option after the first try above. This will instruct ddrescue to retry bad sectors in an effort to recover as much data as possible. You can specify the number of retries after the option. In this example, we will use 3 retries.
```
$ sudo ddrescue -d -r3 /dev/sdX backup.img backup.logfile
```
Next, we will copy the new image file to a different disk or partition. We can use an ordinary dd command for this.
```
$ sudo dd if=backup.img of=/dev/sdX
```
Alternatively, the ddrescue command can be used.
```
$ sudo ddrescue -f backup.img /dev/sdX clone.logfile
```
The -f option indicates that we are sending our output to a block device rather than a file.
If you want to clone a disk or partition directly to another, thereby bypassing any image file, you can do so with the following syntax. In this example, we are cloning partition /dev/sdX1 to /dev/sdX2.
```
$ sudo ddrescue -d -f /dev/sdX1 /dev/sdX2 clone.logfile
```

Next, we will use the following command syntax to copy the partition to an image file. We are using /dev/sdX in the example below, but you would just need to substitute your own partition or device in place of it. The contents will be written to a file called backup.img.

```
$ sudo ddrescue -d /dev/sdX backup.img backup.logfile
```
After completing the steps above, you can access the cloned storage and will hopefully see all of your files there, assuming that ddrescue was successful in recovering them.

PFC优先级流量控制

2024-08-29T18:26:00.005+08:00

From :https://support.huawei.com/enterprise/zh/doc/EDOC1100138438/d1e17776

PFC（Priority-based Flow Control，基于优先级的流量控制）也称为Per Priority Pause或 CBFC（Class Based Flow Control），是对Pause机制的一种增强。当前以太Pause机制（IEEE 802.3 Annex 31B）也能达到无丢包的要求，原理如下：当下游设备发现接收能力小于上游设备的发送能力时，会主动发Pause帧给上游设备，要求暂停流量的发送，等待一定时间后再继续发送数据。但是以太Pause机制的流量暂停是针对整个接口，即在出现拥塞时会将链路上所有的流量都暂停。

而PFC允许在一条以太网链路上创建8个虚拟通道，并为每条虚拟通道指定一个优先等级，允许单独暂停和重启其中任意一条虚拟通道，同时允许其它虚拟通道的流量无中断通过。这一方法使网络能够为单个虚拟链路创建无丢包类别的服务，使其能够与同一接口上的其它流量类型共存。

图2-1 PFC的工作机制

如图2-1所示，DeviceA发送接口分成了8个优先级队列，DeviceB接收接口有8个接收缓存（buffer），两者一一对应（报文优先级和接口队列存在着一一对应的映射关系），形成了网络中 8 个虚拟化通道，缓存大小不同使得各队列有不同的数据缓存能力。

当DeviceB的接口上某个接收缓存产生拥塞时，即某个设备的队列缓存消耗较快，超过一定阈值（可设定为端口队列缓存的 1/2、3/4 等比例），DeviceB即向数据进入的方向（上游设备DeviceA）发送反压信号“STOP”。

DeviceA接收到反压信号，会根据反压信号指示停止发送对应优先级队列的报文，并将数据存储在本地接口缓存。如果DeviceA本地接口缓存消耗超过阈值，则继续向上游反压，如此一级级反压，直到网络终端设备，从而消除网络节点因拥塞造成的丢包。

“反压信号”实际上是一个以太帧，其具体报文格式如图2-2所示。

图2-2 PFC帧格式

表2-1 PFC帧的定义

项目	描述
Destination address	目的MAC地址，取值固定为01-80-c2-00-00-01。
Source address	源MAC地址。
Ethertype	以太网帧类型，取值为88-08。
Control opcode	控制码，取值为01-01。
Priority enable vector	反压使能向量。其中E(n)和优先级队列n对应，表示优先级队列n是否需要反压。当E(n)=1时，表示优先级队列n需要反压，反压时间为Time(n)；当E(n)=0时，则表示该优先级队列不需要反压。
Time(0)～Time(7)	反压定时器。当Time(n)=0时表示取消反压。
Pad	预留。传输时为0。
CRC	循环冗余校验。

总而言之，设备会为端口上的8个队列设置各自的PFC门限值，当队列已使用的缓存超过PFC门限值时，则向上游发送PFC反压通知报文，通知上游设备停止发包；当队列已使用的缓存降低到PFC门限值以下时，则向上游发送PFC反压停止报文，通知上游设备重新发包，从而最终实现报文的无丢包传输。

由此可见，PFC中流量暂停只针对某一个或几个优先级队列，不针对整个接口进行中断，每个队列都能单独进行暂停或重启，而不影响其他队列上的流量，真正实现多种流量共享链路。而对非PFC控制的优先级队列，系统则不进行反压处理，即在发生拥塞时将直接丢弃报文。

但是网络中如果出现大量PFC反压帧，则极有可能诱发网络死锁，出现两个或多个队列发生永久堵塞（等待），每个队列都在等待被其他队列占用并堵塞了的资源，最终导致网络系统性风险。智能无损网络提供了PFC死锁检测功能。当设备在死锁检测周期内持续收到反压帧时，将不会响应，确保不出现PFC死锁情况。

无损与有损的概念

由上述内容可知，报文在以太网络中的无丢包传输是通过PFC流控机制实现的。设备支持基于802.1p优先级的PFC和基于DSCP优先级的PFC：

基于802.1p优先级的PFC：设备将报文中的802.1p优先级值与端口队列一一对应，即优先级值为0对应0号队列、优先级值为1对应1号队列，以此类推。
基于DSCP优先级的PFC：设备根据配置的DiffServ域将报文中的DSCP优先级映射为内部优先级，内部优先级与端口队列一一对应，具体对应关系参见《CloudEngine 12800, 12800E系列交换机配置指南-QoS》中的“优先级映射配置”。

根据报文在网络中传输时是否需要无丢包传输，可以将业务划分为无损业务和有损业务。

无损业务：需要无丢包传输的业务。使能了PFC功能的802.1p优先级或由DSCP优先级映射的内部优先级即为无损优先级，该优先级对应的队列即为无损队列。
有损业务：允许丢包传输的业务。未使能PFC功能的802.1p优先级或由DSCP优先级映射的内部优先级即为有损优先级，该优先级对应的队列即为有损队列

How to use simple speedtest in RaspberryPi CLI

2023-06-26T10:47:00.003+08:00

pi@ChunchaiRPI2:/tmp $ wget -O speedtest-cli https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py

--2023-06-26 10:43:47-- https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py

Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.111.133, 185.199.109.133, 185.199.110.133, ...

Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.111.133|:443... connected.

HTTP request sent, awaiting response... 200 OK

Length: 65334 (64K) [text/plain]

Saving to: ‘speedtest-cli’

speedtest-cli 100%[=====================================================================================================================>] 63.80K --.-KB/s in 0.08s

2023-06-26 10:43:48 (849 KB/s) - ‘speedtest-cli’ saved [65334/65334]

pi@ChunchaiRPI2:/tmp $ sudo chmod +x speedtest-cli

pi@ChunchaiRPI2:/tmp $ ./speedtest-cli --simple

Ping: 7.342 ms

Download: 301.20 Mbit/s

Upload: 251.35 Mbit/s

pi@ChunchaiRPI2:/tmp $

How to decompile dtb file (Device Tree)

2023-06-20T14:42:00.006+08:00

dtc -I dtb -O dts -o devicetree.dts devicetree.dtb

$ sudo apt-get install device-tree-compiler

$ dtc -I dtb -O dts test.dtb > test.dts

$ dtc -I dts -O dtb test.dts > test.dtb

reference: https://forum.digilentinc.com/topic/2427-how-to-decompile-dtb-file/

Device Tree, reference:

Device Tree（一）：背景介绍 http://www.wowotech.net/device_model/why-dt.html

Device Tree（二）：基本概念 http://www.wowotech.net/device_model/dt_basic_concept.html

Device Tree（三）：代码分析 http://www.wowotech.net/device_model/dt-code-analysis.html

Device Tree（四）：文件结构解析 http://www.wowotech.net/device_model/dt-code-file-struct-parse.html

HGU – Supported Service Scenarios

2023-06-01T12:18:00.001+08:00

From https://halny.com/knowledge-base/hgu-supported-service-scenarios/

HGU mode allows to flow multiple traffic classes across VEIP.
All UNI interfaces are belonged to one VEIP and it cannot be controlled by OMCI.
This non-OMCI part can be controlled by Web and Auto provisioning.
Most OLT vendors support dual stack:
– IP-HOST #1 -> MGMT (WEB, XML provisioning) – configure by OMCI (from OLT)
– VEIP (non-OMCI : INTERNET, VoIP, IPTV services) – configure by ONT WEB or provisioning

1.Bridge mode – only INTERNET:1-4/WIFI + MGMT

2.Bridge mode – INTERNET:1-4/WIFI, VoIP Interface + MGMT

3.Bridge mode – INTERNET:1-2/WIFI, IPTV:3-4, VoIP Interface + MGMT

4.Router mode – only INTERNET:1-4/WIFI + MGMT

5.Router mode – INTERNET:1-4/WIFI, VoIP Interface + MGMT

6.Router mode – INTERNET:1-2/WIFI, IPTV:3-4, VoIP + MGMT

SFU – Supported Service Scenarios

2023-06-01T12:15:00.003+08:00

From: https://halny.com/knowledge-base/sfu-supported-service-scenarios/

1.Access mode – only Internet

2.Access mode – only IPTV

3.Transparent mode – Internet, IPTV, VoIP

4.VLAN translation – rBSA

5.802.1q in 802.1q Begin/End of Tunnel

6.Transparent 802.1q in 802.1q

7.OSE/MdO

OMCI協議二層功能的模型選擇

2023-06-01T12:09:00.005+08:00

From:https://blog.csdn.net/JIANGXIN04211/article/details/48294645

我們知道有兩種大的二層功能，即MAC橋以及802.1p映射。MAC橋是IEEE 802.1D描述的，有許多的特性，可以基於MAC地址透明轉發（True bridging）或VLAN characteristics（利用VLAN filter）。而映射功能描述了一個用戶側實體到1到8個網絡側流標記的關係。那種映射與只利用VLAN標記中pbit字段作為VLAN filters的MAC橋是相等的。

那兩種基本二層服務能組合實現各種連接要求。有三種大的基本模式：

N:1 bridging多個用戶端口在同一個橋中，而只有一個網絡服務

1:M mapping基於pbit來將一個用戶端口映射成多個網絡側服務

1:P filtering 基於非pbit的VLAN信息來將單一的用戶端口映射成多個網絡側服務

除了以上三個基本可能外，也有四種複雜的組合。即：

N:M bridging mapping顧名思義，N個用戶端口在一個橋中先橋轉發然後再進行基於pbit的映射。

1:MP map-filtering 一個用戶端口做filtering以及mapping

N:P bridging-filtering N個用戶端口在一個橋中先橋轉發然後再進行基於非pbit的VLAN信息的映射

N:MP bridging-map-filtering顯而易見。

系統性地，tag filtering發生在接近MAC橋而不是tagging操作的部位。如下順序：

ANI—Tag operation—Tag filtering—Bridging—Tag filtering—Tag operation—UNI

許多公司實現了非802.1p模型而採用最簡單的bridging模型，而最簡單一種是每個用戶端在一個Bridge中。1:P模型被採用。如果是多端口的CPE設備（一般由Interworking模塊，如Broadlight chip與交換Switch模塊，如Broadcom switch組成），那塊switch chip每個用戶口有個port VLAN（每個端口不一樣），為了區隔彼此。對於Untag流需要映射pbit的話可以採用管理對象(ID:171 Extended VLAN Tagging operation configuration data)屬性來達到要求。

參考：G.984.4 Section 8.2.2

secure boot（三）secure boot的签名和验签方案

2023-04-10T23:34:00.004+08:00

From:https://cloud.tencent.com/developer/article/2182626?from=article.detail.2182624&areaSource=106000.1&traceId=6TuiWB62dtuJGznPqWlJ1

简介

FIT 格式支持存储镜像的hash值，并且在加载镜像时会校验hash值。这可以保护镜像免受破坏，但是，它并不能保护镜像不被替换。

而如果对hash值使用私钥签名，在加载镜像时使用公钥验签则可以保护镜像不被替换。因此，公钥必须保存在一个绝对安全的地方。

接下来的内容要求大家了解一些密码学的内容，之前也介绍过一些，可以看这篇文章

secure boot (一)FIT Image

secure boot (二)基本概念和框架

secure boot签名的大致流程：

计算镜像的hash值
利用私钥对hash值签名
签名结果存在FIT Image 中。

secure boot验签的大致流程：

读取FIT Image
获得pubkey
从FIT Image 提取签名
计算镜像的hash
使用公钥验签获得hash值，与计算得到的hash值进行对比

签名是由mkimage工具完成的，验签由uboot完成。

签名算法

原则上讲，任何合适的算法都可以用来签名和验签。在uboot中，目前只支持一类算法：SHA&RSA。

RSA 算法使用提前准备好的公钥就可以完成验签，验签相关的代码量也很少。在验签时，RSA只是在FDT中提取必要的数据进行校验。

当然也可以在uboot中添加合适的算法，如果有其他签名算法（如DSA），可以直接替换rsa.c，并在image-sig.c中添加对应算法即可。

创建RSA key和证书

openssl 创建一副2048的密钥对：

$ openssl genpkey -algorithm RSA -out keys/dev.key  -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537

创建包含pubkey的证书：

$ openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt

查看pubkey的值：

$ openssl rsa -in keys/dev.key -pubout

绑定设备树

在FIT Image的签名节点中需要添加以下属性，签名节点与哈希节点处于同一级别，被称为signature@1, signature@2等。

algo: 算法名称
key-name-hint:用来签名的key。密钥对必须存放在单独的文件夹（mkimage 使用-k 参数指定），私钥被命名为 <name>.key，证书命名为<name>.crt。

镜像被签名后，以下这些属性都会被自动强制添加：

value: 签名后的值(RSA-2048 占256 bytes)

以下这些属性是可选的：

timestamp:签名的时间
signer-name:签名者的名字（例如mkimage）
signer-version:签名的版本（例如"2013.01"）
comment:签名者或者镜像的额外信息
sign-images:签名镜像的列表
hashed-nodes:签名者签名的节点列表，一般是包含节点完整路径的字符串。例如：

hashed-nodes = "/", "/configurations/conf@1", "/images/kernel@1",
  "/images/kernel@1/hash@1", "/images/fdt@1",
  "/images/fdt@1/hash@1";

以下是一个待签名镜像的its配置。

/dts-v1/;

/ {
 description = "Chrome OS kernel image with one or more FDT blobs";
 #address-cells = <1>;

 images {
  kernel@1 {
   data = /incbin/("test-kernel.bin");
   type = "kernel_noload";
   arch = "sandbox";
   os = "linux";
   compression = "none";
   load = <0x4>;
   entry = <0x8>;
   kernel-version = <1>;
   signature@1 {
    algo = "sha1,rsa2048";
    key-name-hint = "dev";
   };
  };
  fdt@1 {
   description = "snow";
   data = /incbin/("sandbox-kernel.dtb");
   type = "flat_dt";
   arch = "sandbox";
   compression = "none";
   fdt-version = <1>;
   signature@1 {
    algo = "sha1,rsa2048";
    key-name-hint = "dev";
   };
  };
 };
 configurations {
  default = "conf@1";
  conf@1 {
   kernel = "kernel@1";
   fdt = "fdt@1";
  };
 };
};

以下是配置项签名后的its文件。

/dts-v1/;

/ {
 description = "Chrome OS kernel image with one or more FDT blobs";
 #address-cells = <1>;

 images {
  kernel@1 {
   data = /incbin/("test-kernel.bin");
   type = "kernel_noload";
   arch = "sandbox";
   os = "linux";
   compression = "lzo";
   load = <0x4>;
   entry = <0x8>;
   kernel-version = <1>;
   hash@1 {
    algo = "sha1";
   };
  };
  fdt@1 {
   description = "snow";
   data = /incbin/("sandbox-kernel.dtb");
   type = "flat_dt";
   arch = "sandbox";
   compression = "none";
   fdt-version = <1>;
   hash@1 {
    algo = "sha1";
   };
  };
 };
 configurations {
  default = "conf@1";
  conf@1 {
   kernel = "kernel@1";
   fdt = "fdt@1";
   signature@1 {
    algo = "sha1,rsa2048";
    key-name-hint = "dev";
    sign-images = "fdt", "kernel";
   };
  };
 };
};

pubkey的存储

为了校验签名后的镜像，必须把pubkey存放在可信赖的位置。将pubkey存在镜像中是不安全的，很容易被破解。一般我们将其存放在uboot的FDT中（CONFIG_OF_CONTROL）。

pubkey应该作为一个子节点存放在/signature节点中。节点中要加上以下特性：

algo:算法名称
key-name-hint: 签名使用的key的名称
required: 校验某配置所使用的公钥

除此之外，每个算法都有一些必要的特性。RSA算法中，以下特性必须被添加：

rsa,num-bits:key的位数
rsa,modulus:N，多字节的整数
rsa,exponent:E，64位的无符号整数
rsa,r-squared:(2^num-bits)^2
rsa,n0-inverse:-1 / modulus[0] mod 2^32

下面看一个例子，以下是一个uboot.dtb存放RSA的例子。RSA key被mkimage打包在u-boot.dtb和u-boot-spl.dtb中，然后它们再被打包进u-boot.bin和u-boot-spl.bin。

ubuntu:~/uboot-nextdev$ fdtdump u-boot.dtb | less
/dts-v1/;
....
/ {
        #address-cells = <0x00000001>;
        #size-cells = <0x00000001>;
        compatible = "rockchip,rv1126-evb", "rockchip,rv1126";
        model = "Rockchip RV1126 Evaluation Board";
        // signature节点由mkimage工具自动插入生成，节点里保存了RSA-SHA算法类型、RSA核心因子参
   //数等信息。
        signature {
         key-dev {
    required = "conf";
          algo = "sha256,rsa2048";
          rsa,np = <0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x1327f633 0x00000003 0x00000003 0x00000003 0xc7aead6a 0xb4c79f40 0xa82bdf76 0xfb2f8387 0xa1e06dce 0xd451a706 0xc7f865e3 0x3e2d7ca8 0x6a71762e 0x125f1828 0x36ab1a41 0xb7e9e852 0x7bd0011a 0x7279e0b8 0xf37e189c 0x8cf00963 0x00000100 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000377 0x00000004 0x00000004 0x00000004 0x00000002 0x00000003 0x69616c40 0x00000003 0x6d634066 0x00000010 0x66633630 0x73797363>;
          rsa,c = <0x00000000>;
          rsa,r-squared = <0x00000000>;
          rsa,modulus = <0xc25ae693 0xc359f2a4 0xa866c89d 0xb7b1994f 0xf9f9f690 0x518d54a7 0xda0b83e8 0x06606e12 0x6ad1cbf9 0x92438edd 0x81e039c0 0x5d7322cc 0x124cdc80 0xa0c3288a 0x9265c3ae 0x6ac47a4b 0x00000003 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000008 0x00000003 0x00000003 0x00000003 0x00000002 0x73657300 0x2f736572 0x00000000 0x2f64776d 0x00000003 0x6d634066 0x00000001 0x30303000 0x726f636b 0x67726600 0x00000008 0x00000003 0x00000004 0x00000001 0x30303000 0x726f636b 0x706d7567 0x00000003 0x00001000 0x00000003 0x00000002 0x6e616765 0x30000000 0x726f636b 0x706d7500 0x00000008>;
          rsa,exponent-BN = <0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000003 0x00010001 0xe95771c5 0x00000800 0x64657600 0x616c6961 0x0000002c 0x30303030 0x00000034 0x30303000 0x2f64776d 0x00000002 0x65303030 0x0000001b 0x3132362d 0x00000003 0x00020000 0x00000003 0x00000002 0x65303230 0x0000001b 0x3132362d 0x6e000000 0xfe020000 0x00000042 0x0000006d 0x722d6d61 0x65303030 0x0000001b 0x3132362d 0x00000003 0x00001000 0x00000002 0x6e74726f 0x30000000 0x726f636b 0x706d7563 0x0000003e 0x00000004 0x00000004 0x00000004 0x00000000 0x00000050 0x636c6f63 0x40666634 0x00000014 0x2c727631 0x00000008>;
          rsa,exponent = <0x00000000 0x00000368>;
          rsa,n0-inverse = <0xe95771c5>;
          rsa,num-bits = <0x00000800>;
          key-name-hint = "dev";
};
};

签名方案

上一节内容提到过，在secure boot中一般使用RSA签名方案。

要完成对镜像的签名，就必须使用私钥。而私钥一般是存在服务器上的，在本地PC上只存公钥。要想完成对镜像的签名，就必须把所有镜像上传到服务器重新打包。这种方案上传的文件太多，比较繁琐。下面我们介绍一种常用的签名方案。

在PC上，存放一把公钥和临时私钥，公钥是打包进dtb中的，安全启动时使用。临时私钥是为了生成签名数据。

在本地打包时，使用临时私钥对非安全镜像签名，将签名数据上传到服务器使用真正的私钥进行二次签名。将二次签名的数据和非安全镜像打包在一起，就得到了安全镜像。安全启动时，从dtb中拿出公钥对安全镜像进行校验即可。

这样既可以保证私钥的安全，又避免了上传所有镜像签名的繁琐。

签名镜像+签名配置

在secure boot中，除了对各个独立镜像签名外，还要对FIT Image中的配置项进行签名。

有些情况下，已经签名的镜像也有可能遭到破坏。例如，也可以使用相同的签名镜像创建一个FIT image，但是，其配置已经被改变，从而可以选择不同的镜像去加载（混合式匹配攻击）。也有可能拿旧版本的FIT Image去替换新的FIT image（回滚式攻击）。

下面举个例子。

/ {
 images {
  kernel@1 {
   data = <data for kernel1>
   signature@1 {
    algo = "sha1,rsa2048";
    # kernel image镜像的哈希值，由mkiamge工具自动生成
    value = <...kernel signature 1...>
   };
  };
  kernel@2 {
   data = <data for kernel2>
   signature@1 {
    algo = "sha1,rsa2048";
    value = <...kernel signature 2...>
   };
  };
  fdt@1 {
   data = <data for fdt1>;
   signature@1 {
    algo = "sha1,rsa2048";
    vaue = <...fdt signature 1...>
   };
  };
  fdt@2 {
   data = <data for fdt2>;
   signature@1 {
    algo = "sha1,rsa2048";
    vaue = <...fdt signature 2...>
   };
  };
 };
 configurations {
  default = "conf@1";
  conf@1 {
   kernel = "kernel@1";
   fdt = "fdt@1";
  };
  conf@1 {
   kernel = "kernel@2";
   fdt = "fdt@2";
  };
 };
};

两个kernel image 都已经被签名了，但是，攻击者可以很容易的将kernel1 和fdt2 作为configuration 3去加载。

 configurations {
  default = "conf@1";
  conf@1 {
   kernel = "kernel@1";
   fdt = "fdt@1";
  };
  conf@1 {
   kernel = "kernel@2";
   fdt = "fdt@2";
  };
  conf@3 {
   kernel = "kernel@1";
   fdt = "fdt@2";
  };
 };

攻击者可以拿到签名的镜像，并且镜像是正确的。这种组合式攻击会给设备带来很大风险。

因此，为了解决这个问题，除了给镜像签名外，我们可以把配置选项也签名，每个镜像都有自己的签名，在给配置选项签名时，把镜像的hash值也包含进去。具体例子如下：

/ {
 images {
  kernel@1 {
   data = <data for kernel1>
   hash@1 {
    algo = "sha1";
    value = <...kernel hash 1...>
   };
  };
  kernel@2 {
   data = <data for kernel2>
   hash@1 {
    algo = "sha1";
    value = <...kernel hash 2...>
   };
  };
  fdt@1 {
   data = <data for fdt1>;
   hash@1 {
    algo = "sha1";
    value = <...fdt hash 1...>
   };
  };
  fdt@2 {
   data = <data for fdt2>;
   hash@1 {
    algo = "sha1";
    value = <...fdt hash 2...>
   };
  };
 };
 configurations {
  default = "conf@1";
  conf@1 {
   kernel = "kernel@1";
   fdt = "fdt@1";
   signature@1 {
    algo = "sha1,rsa2048";
    # 对配置项签名，由mkimage工具自动生成
    value = <...conf 1 signature...>;
   };
  };
  conf@2 {
   kernel = "kernel@2";
   fdt = "fdt@2";
   signature@1 {
    algo = "sha1,rsa2048";
    value = <...conf 1 signature...>;
   };
  };
 };
};

如上所示，除了给所有镜像添加了hash值，还为每个配置添加了签名。mkimage将会对configurations/conf@1签名(/images/kernel@1, /images/kernel@1/hash@1,/images/fdt@1, /images/fdt@1/hash@1) 。签名会被写入 /configurations/conf@1/signature@1/value。

验签

FIT image 在加载时会验签。如果'required' 指定了验签的公钥，则会使用这把公钥校验该配置对应的所有镜像。

为了支持FIT格式，以下配置项必须被选上。

CONFIG_FIT_SIGNATURE ：使能FIT image的签名和验签

CONFIG_RSA ：使能RSA签名算法

默认情况下，使能FIT Image的签名和验签后，CONFIG_IMAGE_FORMAT_LEGACY会被禁用。即FIT uboot image的只能引导FIT kernel Image。如果需要引导legacy kernel image，需要手动添加CONFIG_IMAGE_FORMAT_LEGACY 定义。

测试

为了校验签名和验签是否正确，可以使用测试脚本test/vboot/vboot_test.sh。下面以sandbox为例子来说明bootm的启动和对镜像的验签。

$ make O=sandbox sandbox_config
$ make O=sandbox
$ O=sandbox ./test/vboot/vboot_test.sh
/home/hs/ids/u-boot/sandbox/tools/mkimage -D -I dts -O dtb -p 2000
Build keys
do sha1 test
Build FIT with signed images
Test Verified Boot Run: unsigned signatures:: OK
Sign images
Test Verified Boot Run: signed images: OK
Build FIT with signed configuration
Test Verified Boot Run: unsigned config: OK
Sign images
Test Verified Boot Run: signed config: OK
check signed config on the host
Signature check OK
OK
Test Verified Boot Run: signed config: OK
Test Verified Boot Run: signed config with bad hash: OK
do sha256 test
Build FIT with signed images
Test Verified Boot Run: unsigned signatures:: OK
Sign images
Test Verified Boot Run: signed images: OK
Build FIT with signed configuration
Test Verified Boot Run: unsigned config: OK
Sign images
Test Verified Boot Run: signed config: OK
check signed config on the host
Signature check OK
OK
Test Verified Boot Run: signed config: OK
Test Verified Boot Run: signed config with bad hash: OK

Test passed

完整校验流程

OTP校验loader

那么，这种镜像校验方式有个很重要的问题，公钥存在哪里才是安全的呢？

一般SOC中会有一个叫OTP或EFUSE的区域，这部分区域比较特殊，只可以写入一次，写入后就再也不可以修改了。把公钥存储在OTP中，就可以很好地保证其不能被修改。

OTP的存储空间很小，一般只有几KB，因此并不适合直接存放RSA公钥。一般都是将RSA公钥的hash val 存放在OTP中。像sha256的hash值仅为256 bits，而RSA 公钥本身一般存放在镜像中。

在使用公钥之前，只需要使用OTP中的公钥hash值验证镜像附带公钥的完整性，即可确定公钥是否合法。

RSA公钥需要一般使用芯片厂家的工具写入loader。安全启动时，bootrom首先从loader固件头中获取RSA公钥并校验合法性；然后再使用该公钥校验SPL的固件签名。

spl校验uboot

SPL把RSA公钥保存在u-boot-spl.dtb中，u-boot-spl.dtb会被打包进u-boot-spl.bin文件（最后打包进loader）；安全启动时SPL从自己的dtb文件中拿出RSA公钥对uboot.img进行安全校验。

uboot校验kernel

U-Boot把RSA公钥保存在u-boot.dtb中，u-boot.dtb会被打包进u-boot.bin文件（最后打包为uboot.img）；安全启动时U-Boot从自己的dtb文件中拿RSA公钥对boot.img进行校验。

总结

从bootrom到kernel为止的安全启动，统一使用一把RSA公钥完成安全校验,并且当前这级的RSA Key已经作为自身固件的一部分，由前一级loader完成了安全校验，从而保证了Key的安全。

2023-02-21T18:20:00.000+08:00

A Linux bridge is a kernel module that behaves like a network switch, forwarding packets between interfaces that are connected to it. It's usually used for forwarding packets on routers, on gateways, or between VMs and network namespaces on a host.

The Linux bridge has included basic support for the Spanning Tree Protocol (STP), multicast, and Netfilter since the 2.4 and 2.6 kernel series. Features that have been added in more recent releases include:

Configuration via Netlink
VLAN filter
VxLAN tunnel mapping
Internet Group Management Protocol version 3 (IGMPv3) and Multicast Listener Discovery version 2 (MLDv2)
Switchdev

In this article, you'll get an introduction to these features and some useful commands to enable and control them. You'll also briefly examine Open vSwitch as an alternative to Linux bridging.

Basic bridge commands

All the commands used in this article are part of the iproute2 module, which invokes Netlink messages to configure the bridge. There are two iproute2 commands for setting and configuring bridges: ip link and bridge.

ip link can add and remove bridges and set their options. bridge displays and manipulates bridges on final distribution boards (FDBs), main distribution boards (MDBs), and virtual local area networks (VLANs).

The listings that follow demonstrate some basic uses for the two commands. Both require administrator privileges, and therefore the listings are shown with the # root prompt instead of a regular user prompt.

Show help information about the bridge object:
```
# ip link help bridge

# bridge -h
```
Copy snippet
Create a bridge named br0:
```
# ip link add br0 type bridge
```
Copy snippet
Show bridge details:
```
# ip -d link show br0
```
Copy snippet
Show bridge details in a pretty JSON format (which is a good way to get bridge key-value pairs):
```
# ip -j -p -d link show br0
```
Copy snippet

Add interfaces to a bridge:

# ip link set veth0 master br0

# ip link set tap0 master br0

Copy snippet

Spanning Tree Protocol

The purpose of STP is to prevent a networking loop, which can lead to a traffic storm in the network. Figure 1 shows such a loop.

Figure 1: Without STP, a network can be configured in a loop.

With STP enabled, the bridges will send each other Bridge Protocol Data Units (BPDUs) so they can elect a root bridge and block an interface, making the network topology loop-free (Figure 2).

Figure 2: STP can choose a link and block it.

Linux bridging has supported STP since the 2.4 and 2.6 kernel series. To enable STP on a bridge, enter:

# ip link set br0 type bridge stp_state 1

Copy snippet

Note: The Linux bridge does not support the Rapid Spanning Tree Protocol (RSTP).

Now you can show the STP blocking state on the bridge:

# ip -j -p -d link show br0 | grep root_port

                "root_port": 1,

# ip -j -p -d link show br1 | grep root_port

                "root_port": 0,

# bridge link show

7: veth0@veth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2

8: veth1@veth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br1 state forwarding priority 32 cost 2

9: veth2@veth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state blocking priority 32 cost 2

10: veth3@veth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br1 state forwarding priority 32 cost 2

Copy snippet

The line labeled 9 in the output shows that the veth2 interface is in a blocking state, as illustrated in Figure 3.

Figure 3: The link from br0 to veth2 is blocked.

To change the STP hello time, enter:

# ip link set br0 type bridge hello_time 300

# ip -j -p -d link show br0 | grep \"hello_time\"

                "hello_time": 300,

Copy snippet

You can use the same basic approach to change other STP parameters, such as maximum age, forward delay, ageing time, and so on.

VLAN filter

The VLAN filter was introduced in Linux kernel 3.8. Previously, to separate VLAN traffic on the bridge, the administrator needed to create multiple bridge/VLAN interfaces. As illustrated in Figure 4, three bridges—br0, br2, and br3—would be needed to support three VLANs to make sure that VLAN traffic went to the corresponding VLANs.

Figure 4: Without the VLAN filter, three VLANs required three bridges and network configurations.

But with the VLAN filter, just one bridge device is enough to set all the VLAN configurations, as illustrated in Figure 5.

Figure 5: With the VLAN filter, a single bridge can serve multiple VLANs.

The following commands enable the VLAN filter and configure three VLANs:

# ip link set br0 type bridge vlan_filtering 1

# ip link set eth1 master br0

# ip link set eth1 up

# ip link set br0 up



# bridge vlan add dev veth1 vid 2

# bridge vlan add dev veth2 vid 2 pvid untagged

# bridge vlan add dev veth3 vid 3 pvid untagged master



# bridge vlan add dev eth1 vid 2-3



# bridge vlan show

port              vlan-id

eth1              1 PVID Egress Untagged

                  2

                  3

br0               1 PVID Egress Untagged

veth1             1 Egress Untagged

                  2

veth2             1 Egress Untagged

                  2 PVID Egress Untagged

veth3             1 Egress Untagged

                  3 PVID Egress Untagged

Copy snippet

Then the following command enables a VLAN filter on the br0 bridge:

ip link set br0 type bridge vlan_filtering 1

Copy snippet

This next command makes the veth1 bridge port transmit only VLAN 2 data:

bridge vlan add dev veth1 vid 2

Copy snippet

The following command, similar to the previous one, makes the veth2 bridge port transmit VLAN 2 data. The pvid parameter causes untagged frames to be assigned to this VLAN at ingress (veth2 to bridge), and the untagged parameter causes the packet to be untagged on egress (bridge to veth2):

bridge vlan add dev veth2 vid 2 pvid untagged

Copy snippet

The next command carries out the same operation as the previous one, this time on veth3. The master parameter indicates that the link setting is configured on the software bridge. However, because master is a default option, this command has the same effect as the previous one:

bridge vlan add dev veth3 vid 3 pvid untagged master

Copy snippet

The following command enables VLAN 2 and VLAN 3 traffic on eth1:

bridge vlan add dev eth1 vid 2-3

Copy snippet

To show the VLAN traffic state, enable VLAN statistics (added in kernel 4.7) as follows:

ip link set br0 type bridge vlan_stats_enabled 1

Copy snippet

The previous command enables just global VLAN statistics on the bridge, and is not fine grained enough to show each VLAN's state. To enable per-VLAN statistics when there are no port VLANs in the bridge, you also need to enable vlan_stats_per_port (added in kernel 4.20). You can run:

ip link set br0 type bridge vlan_stats_per_port 1

Copy snippet

Then you can show per-VLAN statistics like so:

# bridge -s vlan show

port              vlan-id

br0               1 PVID Egress Untagged

                    RX: 248 bytes 3 packets

                    TX: 333 bytes 1 packets

eth1              1 PVID Egress Untagged

                    RX: 333 bytes 1 packets

                    TX: 248 bytes 3 packets

                  2

                    RX: 0 bytes 0 packets

                    TX: 56 bytes 1 packets

                  3

                    RX: 0 bytes 0 packets

                    TX: 224 bytes 7 packets

veth1             1 Egress Untagged

                    RX: 0 bytes 0 packets

                    TX: 581 bytes 4 packets

                  2 PVID Egress Untagged

                    RX: 6356 bytes 77 packets

                    TX: 6412 bytes 78 packets

veth2             1 Egress Untagged

                    RX: 0 bytes 0 packets

                    TX: 581 bytes 4 packets

                  2 PVID Egress Untagged

                    RX: 6412 bytes 78 packets

                    TX: 6356 bytes 77 packets

veth3             1 Egress Untagged

                    RX: 0 bytes 0 packets

                    TX: 581 bytes 4 packets

                  3 PVID Egress Untagged

                    RX: 224 bytes 7 packets

                    TX: 0 bytes 0 packets

Copy snippet

VLAN tunnel mapping

VxLAN builds Layer 2 virtual networks on top of a Layer 3 underlay. A VxLAN tunnel endpoint (VTEP) originates and terminates VxLAN tunnels. VxLAN bridging is the function provided by VTEPs to terminate VxLAN tunnels and map the VxLAN network identifier (VNI) to the traditional end host's VLAN.

Previously, to achieve VLAN tunnel mapping, administrators needed to add local ports and VxLAN network devices (netdevs) into a VLAN filtering bridge. The local ports were configured as trunk ports carrying all VLANs. A VxLAN netdev for each VNI would then need to be added to the bridge. VLAN to VNI mapping was achieved by configuring a port VLAN identifier (pvid) for each VLAN as on the corresponding VxLAN netdev, as shown in Figure 6.

Figure 6. VxLAN used to require multiple netdevs.

Since 4.11, the kernel has provided a native way to support VxLAN bridging. The topology for this looks like Figure 7. The vxlan0 endpoint in this figure was added with lightweight tunnel (LWT) support to handle multiple VNIs.

Figure 7: Now Linux bridging can handle multiple VNIs with one VxLAN.

To create a tunnel, you must first add related VIDs to the interfaces:

bridge vlan add dev eth1 vid 100-101

bridge vlan add dev eth1 vid 200

bridge vlan add dev vxlan0 vid 100-101

bridge vlan add dev vxlan0 vid 200

Copy snippet

Now enable a VLAN tunnel mapping on a bridge port:

# ip link set dev vxlan0 type bridge_slave vlan_tunnel on

Copy snippet

Alternatively, you can enable the tunnel with this command:

# bridge link set dev vxlan0 vlan_tunnel on

Copy snippet

Then add VLAN tunnel mapping:

# bridge vlan add dev vxlan0 vid 2000 tunnel_info id 2000

# bridge vlan add dev vxlan0 vid 1000-1001 tunnel_info id 1000-1001



# bridge -j -p vlan tunnelshow

[ {

        "ifname": "vxlan0",

        "tunnels": [ {

                "vlan": 100,

                "vlanEnd": 101,

                "tunid": 100,

                "tunidEnd": 101

            },{

                "vlan": 200,

                "tunid": 200

            } ]

    } ]

Copy snippet

Multicast

Linux bridging has included support for IGMPv2 and MLDv1 support since kernel version 2.6. IGMPv3/MLDv2 support was added in kernel 5.10.

To use multicast, enable bridge multicast snooping, querier, and statistics as follows:

# ip link set br0 type bridge mcast_snooping 1

# ip link set br0 type bridge mcast_querier 1

# ip link set br0 type bridge mcast_stats_enabled 1

# tcpdump -i br0 -nn -l

02:47:03.417331 IP 0.0.0.0 > 224.0.0.1: igmp query v2

02:47:03.417340 IP6 fe80::3454:82ff:feb9:d7b4 > ff02::1: HBH ICMP6, multicast listener querymax resp delay: 10000 addr: ::, length 24

Copy snippet

By default, when snooping is enabled, the bridge uses IGMPv2/MLDv1. You can change the versions with these commands:

ip link set br0 type bridge mcast_igmp_version 3

ip link set br0 type bridge mcast_mld_version 2

Copy snippet

After a port joins a group, you can show the multicast database (mdb) like so:

# bridge mdb show

dev br0 port br0 grp ff02::fb temp

dev br0 port eth1 grp ff02::fb temp

dev br0 port eth2 grp ff02::fb temp

dev br0 port eth2 grp 224.1.1.1 temp

dev br0 port br0 grp ff02::6a temp

dev br0 port eth1 grp ff02::6a temp

dev br0 port eth2 grp ff02::6a temp

dev br0 port br0 grp ff02::1:ffe2:de9f temp

dev br0 port eth1 grp ff02::1:ffe2:de9f temp

dev br0 port eth2 grp ff02::1:ffe2:de9f temp

Copy snippet

Bridging also supports multicast snooping and querier on a single VLAN. Set them as follows:

bridge vlan set vid 10 dev eth1 mcast_snooping 1 mcast_querier 1

Copy snippet

You can show bridge xstats (multicast RX/TX information) with this command:

# ip link xstats type bridge

br0

                    IGMP queries:

                      RX: v1 0 v2 1 v3 0

                      TX: v1 0 v2 131880 v3 0

                    IGMP reports:

                      RX: v1 0 v2 1 v3 0

                      TX: v1 0 v2 496 v3 18956

                    IGMP leaves: RX: 0 TX: 0

                    IGMP parse errors: 0

                    MLD queries:

                      RX: v1 1 v2 0

                      TX: v1 51327 v2 0

                    MLD reports:

                      RX: v1 66 v2 6

                      TX: v1 3264 v2 213794

                    MLD leaves: RX: 0 TX: 0

                    MLD parse errors: 0

Copy snippet

There are other multicast parameters you can configure, including mcast_router, mcast_query_interval, and mcast_hash_max.

Bridge switchdev

Linux bridging is always used when virtual machines (VMs) connect to physical networks, by using the virtio tap driver. You can also attach a Single Root I/O Virtualization (SR-IOV) virtual function (VF) in a VM guest to get better performance (Figure 8).

Figure 8: VFs in virtual machines.

But the way Linux used to deal with SR-IOV embedded switches limited their expressiveness and flexibility. And the kernel model for controlling the SR-IOV eSwitch did not allow any forwarding unless it was based on MAC/VLAN.

To make VFs also support dynamic FDB (as in Figure 9) and maintain the benefits of the VLAN filter while still providing optimal performance, Linux bridging added switchdev support in kernel version 4.9. Switchdev allows the offloading of Layer 2 forwarding to a hardware switch such as Mellanox Spectrum devices, DSA-based switches, and MLX5 CX6 Dx cards.

Figure 9: Switchdev provides widespread support for offloading traffic to hardware.

In switchdev mode, the bridge is up and its related configuration is enabled, e.g., MLX5_BRIDGE for an MLX5 SRIOV eSwitch. Once in switchdev mode, you can connect the VF's representors to the bridge, and frames that are supposed to be transmitted by the bridge are transmitted by hardware only. Their routing will be done in the switch at the network interface controller (NIC).

Once a frame passes through the VF to its representor, the bridge learns that the source MAC of the VF is behind a particular port. The bridge adds an entry with the MAC address and port to its FDB. Immediately afterward, the bridge sends a message to the mlx5 driver, and the driver adds a relevant rule or line to two tables located in the eSwitch on the NIC. Later, frames with the same destination MAC address that come from the VF don't go through the kernel; instead, they go directly through the NIC to the appropriate port.

Switchdev support for embedded switches in NICs is simple, but for full-featured switches such as Mellanox Spectrum, the offloading capabilities are much richer, with support for link aggregation group (LAG) hashing (team, bonding), tunneling (VxLAN, etc.), routing, and TC offloading. Routing and TC offloading are out of scope for bridging, but LAGs can be attached to the bridge as well as to VxLAN tunnels, with full support for offloading.

Bridging with Netfilter

By default, the traffic forwarded by the bridge does not go through an iptables firewall. To let the iptables forward rules filter Layer 2 traffic, enter:

ip link set br0 type bridge nf_call_iptables 1

Copy snippet

The same procedure works for ip6tables and arptables.

Bridge ageing time

Ageing determines the number of seconds a MAC address is kept in the FDB after a packet has been received from that address. After this time has passed, entries are cleaned up. To change the timer, enter:

ip link set br0 type bridge ageing_time 20000

Copy snippet

Bridging versus Open vSwitch

Linux bridging is very useful and has become popular over the past few years. It supplies Layer 2 forwarding, and connects VMs and networks with VLAN/multicast support. Bridging on Linux is stable, reliable, and easy to set up and configure.

On the other hand, Linux bridging also has some limitations. It's missing some types of tunnel support, for instance. If you want to get easier network management, more tunnel support (GRE, VXLAN, etc.), Layer 3 forwarding, and integration with software-defined networking (SDN), you can try Open vSwitch (OVS).

To learn more about Linux network interfaces and other networking topics, check out these articles from Red Hat Developer:

SecureCRT & Notepad++ 的網路設備關鍵字顯示（Keyword Highlighting/Syntax highlighting）

2022-12-15T13:21:00.002+08:00

From:https://chingfengwang.com/2020/12/10/securecrt-and-notepad-keyword-highlighting-syntax-highlighting/

由於常常用SecureCRT終端機軟體及文字編輯器 NOTEPAD++ ,發現常常盯著眼睛有點花 ,之前有找到 Notepad++ 的,今天阿豐找到感覺不錯的 SCRT 跟 Notepad++ 的語法：）

1.SecureCRT 的 Text Highlighting
＃出處：feral packet 網站
https://feralpacket.org/?p=817

#下載ini：

feralpacket.ini 下載（unzip password：chingfengwang.com )下載

從作者的 feral packet 網站下載: http://download.feralpacket.org/feralpacket.ini

＃下載後把複製 ini 到：
#MAC:
/Users/username/Library/Application/Support/VanDyke/SecureCRT/Config/Keywords/.

Windows: 存放在 %APPDATA%,
C:\Users\{使用者名稱}\AppData\Roaming\VanDyke\Config\Keywords>

Linux：
複製 ini 檔案到: /home/username/.vandyke/SecureCRT/Config/Keywords/

＃設定方式：
SecureCRT Settings:
– Session Options -> Terminal -> Appearance
-> Current color scheme
-> White / Black
-> Highlight keywords
-> Name: feralpacket
-> Style: Color 打勾

– Keyword List Properties
-> Match case 打勾

– To set for the default session:
-> Global Options -> General -> Default Session
-> Edit Default Settings…

＃作者的截圖：

範例:出處 feral packet 網站

更多截圖可以到作者網站看喔:)

2.NOTEPAD++

給notepad++用的顯示不同網路設備 config 的語法（ Syntax Highlight ）下載：

https://github.com/click0/npp-udl

＃安裝：

解壓縮後,抓下來把要用的 xml 丟到：

C:\Users\{使用者名稱}\AppData\Roaming\Notepad++\userDefineLangs
1.然後再開啟notepad++ ,

2. 跟需要的config 檔案

3.至語言 > 選擇需要的設備語言 (如 Junos , iOS)

下面是作者範例的截圖:
(出處為作者github專案 https://github.com/click0/npp-udl )

Quagga config or ( Cisco IOS )

AlliedTelesis switch config

Mikrotik router config ( RouterOS )

Juniper router config ( JunOS )

#參考資料:
1.feral packet , Regular Expressions For SecureCRT Keyword Highlighting – Update , https://feralpacket.org/?p=817
2.npp-udl, Syntax Highlight Rules for Notepad++ Text Editor, https://github.com/click0/npp-udl
3.https://npp-user-manual.org/docs/user-defined-language-system/

Outlook-解除禁止存取可能不安全的附件

2022-08-03T15:50:00.007+08:00

當你 Outlook 中收到的郵件含有某些檔案格式的附件，會被 Outlook 判定為禁止存取(參考下圖)。要如何取消這個限制呢？

參考以下步驟：

1. 按一下 WinKey+R 鍵，輸入「regedit」，按一下 Enter 鍵。

2. 開啟以下路徑：(以 Outlook 365 為例)

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Security

3. 在 Security 中建立一個 Level1Remove 字串值。

4. 點選 Level1Remove 字串值，數值資料中輸入想要開放的檔案格式(本例為.asp)，若有多種檔案格式要開放，則在各個副檔名中間加上「;」(分號)，例如：「.exe;.asp」。

5. 你必須關閉登錄編輯程式，重新開啟outlook,設定才會生效。

註：如果想要回復這些檔案格式禁止開啟，則只要刪除 Level1Remove 字串值即可。

iOS 16 Beta downgrade 備份恢復問題

2022-07-04T12:20:00.004+08:00

Downgrade 回iOS15 要恢復備份時, iTunes 顯示版本不符所以不能恢復.

這時只需要修改 %userprofile%\Apple\MobileSync\Backup\xxxxxxx\Info.plist

把黃色部分改成15.0後存檔即可.

How do I scroll in tmux?

2022-06-16T23:18:00.000+08:00

echo "set -g mouse on" >> ~/.tmux.conf or Ctrl-b then [ then you can use your normal navigation keys to scroll around (eg. Up Arrow or PgDn). Press q to quit scroll mode.

log可打timestamp 並直接顯示在螢幕的 termnal : extraputty

2022-04-25T12:23:00.003+08:00

載點:https://sourceforge.net/projects/extraputty/

主機板廠牌與型號/Windows 10序號提取command

2022-04-25T12:12:00.000+08:00

主機板廠牌與型號
直接開啟「Windows系統 → 命令提示字元」
指令建議使用複製貼上：
wmic baseboard get product,Manufacturer,version,serialnumber

Windows 10序號

直接開啟「Windows系統 → 命令提示字元」

指令建議使用複製貼上：
wmic path softwarelicensingservice get OA3xOriginalProductKey

PHY暫存器

2022-02-18T10:52:00.005+08:00

PHY暫存器的地址空間為5位，從0到31最多可以定義32個暫存器（隨著晶片功能不斷增加，很多PHY晶片採用分頁技術來擴充套件地址空間以定義更多的暫存器），IEEE802.3定義了地址為0-15這16個暫存器的功能，地址16-31的暫存器留給晶片製造商自由定義，如下表所示。

（1）官方介紹請參考IEEE802.3標準的22.2.4 Management functions節。
（2）上圖的B和E表示了，在特定介面下，暫存器是基本的還是擴充套件的。例如：MII介面下只有0和1暫存器是基本的，其它的是擴充套件的。注意：所為擴充套件是指留給IEEE以後的擴充套件特性用，不是給PHY廠商的擴充套件，PHY廠商自定義的只能是16~31號暫存器
（3）在IEEE標準文件及某些PHY手冊中，某暫存器的位元(bit)用X.y表示，如0.15表示第0暫存器的第15位。

Control Register (Register 0)

暫存器0是PHY控制暫存器，通過Control Register可以對PHY的主要工作狀態進行設定。應該保證控制暫存器每個位的預設值，以便在沒有管理干預的情況下，上電或復位時PHY的初始狀態為正常操作狀態。Control Register的每一位完成的功能見下。

Reset：通過將位0.15設定為邏輯1來完成復位PHY。該操作應將狀態和控制暫存器設定為其預設狀態。因此，此操作可能會改變PHY的內部狀態以及與PHY關聯的物理鏈路的狀態。復位過程中Bit15保持為1，復位完成之後該位應該自動清零。在復位過程完成之前，PHY不需要接受對控制暫存器的寫入操作，並且在復位過程完成之前寫入0.15以外的控制暫存器位可能不起作用。復位過程應在0.15位設定的0.5 s內完成。

（1）一般要改變埠的工作模式（如速率、雙工、流控或協商資訊等）時，在設定完相應位置的暫存器之後，需要通過Reset位復位PHY來使配置生效。
（2）該位元位的預設值為 0。

Loopback：當位0.14被設定為邏輯1時，PHY應置於環回操作模式。當位0.14置位時，PHY接收電路應與網路介質隔離，並且MII或GMII處的TX_EN斷言不應導致網路介質上的資料傳輸。當位0.14置位時，PHY應接受來自MII或GMII傳送資料路徑的資料，並將其返回給MII或GMII接收資料路徑，以響應TX_EN的斷言。當位0.14置位時，從斷言TX_EN到斷言RX_DV的延遲應小於512 BT。當位0.14置位時，除非設定了位0.7，否則COL訊號應始終保持無效，在這種情況下，COL訊號的行為應如22.2.4.1.9所述。清0.14位為零允許正常操作。
Loopback是一個除錯以及故障診斷中常用的功能，Bit14置1之後，PHY和外部MDI的連線在邏輯上將被斷開，從MAC經過MII/GMII（也可能是其他的MAC/PHY介面）傳送過來的資料將不會被髮送到MDI上，而是在PHY內部（一般在PCS）迴環到本埠的MII/GMII接收通道上，通過Loopback功能可以檢查MII/GMII以及PHY介面部分是否工作正常，對於埠不通的情況可用於故障定位。

（1）需要注意的是，很多時候PHY設定Loopback後端口可能就Link down了，MAC無法向該埠發幀，這時就需要通過設定埠Force Link up才能使用Loopback功能。
（2）該位元位的預設值為 0。

Speed Selection：***Bit13和Bit6兩位聯合實現***對埠的速率控制功能。連結速度可以通過自動協商過程或手動速度選擇來選擇。通過將位0.12清零來禁用自動協商時，允許手動速度選擇。
當禁用自動協商並將位0.6清除為邏輯0時，將位0.13設定為邏輯1將PHY配置為100 Mb / s操作，並將位0.13清除為邏輯0將PHY配置為10 Mb / s操作。
當禁用自動協商並將位0.6設定為邏輯1時，將位0.13清零為邏輯0會選擇1000 Mb / s的操作。將位0.6和0.13設定為邏輯1的組合保留用於未來的標準化。
當使能自動協商時，可以讀取或寫入位0.6和0.13，但位0.6和位0.13的狀態對鏈路配置沒有影響，位0.6和位0.13不需要反映當它被讀取時連結。

如果PHY通過位元1.15：9和位元15.15：12報告它不能工作在所有速度時，則位元0.6和0.13的值應該與PHY可以操作的速度相對應。並且任何試圖將該位設定為無效的操作均將被忽略。

（1）對Speed Selection的修改設定，往往需要復位端口才能配置生效。因此在設定該位置的時候需要檢查自動協商的設定並通過Bit15復位埠。
（2）位0.6和0.13的預設值是根據位1.15：9和15.15：12所指示的PHY可以操作的***最高資料速率***的編碼組合。

Auto-Negotiation Enable：自動協商過程應通過將位0.12設定為邏輯1來啟用。如果位0.12設定為邏輯1，則位0.13、0.8和0.6不應對鏈路配置和除了自動協商協議規定之外的站操作產生影響。如果將位0.12清零為邏輯0，則無論鏈路配置和自動協商過程的先前狀態如何，位0.13、0.8和0.6都將確定鏈路配置。
如果PHY通過位1.3報告它缺乏執行自動協商的能力，則PHY應在位0.12返回零值。如果PHY通過位1.3報告它缺乏執行自動協商的能力，則位0.12應該始終寫為0，並且任何嘗試將1寫入位0.12都應該被忽略。

必須注意的是，對於1000BASE-T介面,自動協商必須開啟。

Power Down：通過將位0.11設定為邏輯1，可以將PHY置於低功耗狀態。清0.11位為零允許正常操作。 PHY在掉電狀態下的具體行為是特定實現的。處於掉電狀態時，PHY應響應管理事務。在轉換到掉電狀態期間和處於掉電狀態期間，PHY不應在MII或GMII上產生寄生訊號。
當位0.11或位0.10被設定為邏輯1時，PHY不需要滿足RX_CLK和TX_CLK訊號功能要求。在位0.11和0.10清零後，PHY應在0.5 s內滿足22.2.2中定義的RX_CLK和TX_CLK訊號功能要求。

（1）Power Down模式一般在軟體shut down埠的時候使用，需要注意的是埠從Power Down模式恢復，需要復位埠以保證埠可靠的連線。
（2）該位的預設值為 0。

Isolate：通過將位0.10設定為邏輯1，PHY可能被迫將其資料路徑與MII或GMII電隔離。清零位0.10允許正常操作。當PHY與MII或GMII隔離時，它不會響應TXD資料包和TX_EN，TX_ER、GTX_CLK的輸入。並且它的TX_CLK，RX_CLK，RX_DV，RX_ER，RXD資料包、COL和CRS輸出均應為高阻態。當PHY與MII或GMII隔離時，它將響應管理事務（MDC/MDIO介面的訊號）。

（1）IEEE802.3沒有對Isolate 時MDI介面的狀態進行規範，此時MDI端可能還在正常執行。Isolate在實際應用中並沒有用到。
（2）由於目前很多百兆的PHY晶片其MAC介面主流的都是SMII/S3MII，8個埠的介面是相互關聯的，一個埠設定Isolate可能會影響其他埠的正常使用，因此在使用中注意不要隨意更改bit10的狀態。

Restart Auto-Negotiation：如果PHY通過位1.3報告它缺乏執行自動協商的能力，或者如果自動協商被禁用，則PHY應在位0.9返回零值。如果PHY通過位1.3報告它缺乏執行自動協商的能力，或者如果禁用了自動協商，則應將位0.9始終寫為0，並且任何嘗試將1寫入位0.9應被忽略。
Bit9置1將重新啟動埠的自動協商程序，當然前提是Auto-Negotiation Enable是使能的。

一般在修改埠的自動協商能力資訊之後通過Bit9置1重新啟動自動協商來使埠按照新的配置建立link。

Duplex Mode：可以通過自動協商過程或手動雙面選擇來選擇雙工模式。通過將位0.12清零來禁用自動協商時，允許手動雙面選擇。
當禁用自動協商時，將位0.8設定為邏輯1將PHY配置為全雙工操作，並將位0.8清零以將邏輯0配置為用於半雙工操作的PHY。
當啟用自動協商時，可以讀取或寫入位0.8，但位0.8的狀態對鏈路配置沒有影響。

如果PHY通過位1.15：9和15.15：12報告它只能在一個雙工模式下工作，則位0.8的值應該與PHY可以工作的模式相對應，並且任何嘗試改變將該位0.8修改為無效指的操作應被忽略。

對Duplex Mode的修改配置也需要復位端口才能生效。

Collision Test：衝突訊號（COL）測試開關。在需要對COL訊號進行測試時，可以通過Bit7置1，這時PHY將輸出一個COL脈衝以供測試。實際測試操作中也可以將埠配置為半雙工狀態，通過發幀衝突來測試COL訊號，因此該配置實用價值不大。
Unidirectional enable：如果PHY通過位元1.7報告它不具備編碼和傳輸來自媒體獨立介面的資料的能力，而不管PHY是否確定已建立有效鏈路，則PHY應在位元0.5中返回零值，並且任何嘗試寫一個到位0.5應該被忽略。

Status register

暫存器1是PHY狀態暫存器，主要包含PHY的狀態資訊，大多數bit的值都是由晶片廠家確定的，每一個bit的功能在表3種已有詳細說明。

暫存器中各位的詳細說明如下：

100BASE-T4 ability：當讀為邏輯1時，位1.15指示PHY有能力使用100BASE-T4信令規範執行鏈路傳送和接收。當讀為邏輯0時，位1.15表示PHY缺乏使用100BASE-T4信令規範執行鏈路傳送和接收的能力。
100BASE-X full duplex ability：當讀為邏輯1時，位1.14指示PHY有能力使用100BASE-X信令規範執行全雙工鏈路傳輸和接收。當作為邏輯0讀取時，bit1.14表示PHY缺乏使用100BASE-X信令規範執行全雙工鏈路傳輸和接收的能力。
100BASE-X half duplex ability：當讀為邏輯1時，位1.13指示PHY有能力使用100BASE-X信令規範執行半雙工鏈路傳輸和接收。當讀為邏輯0時，位1.13指示PHY缺乏使用100BASE-X信令規範執行半雙工鏈路傳輸和接收的能力。
其他同類型的值意義基本與上面幾個相同：指示PHY所具有的工作模式能力，不再一一說明。
Unidirectional ability：當讀為邏輯1時，位1.7指示PHY具有編碼和傳輸來自媒體獨立介面的資料的能力，而不管PHY是否確定已建立有效鏈路。當讀為邏輯0時，位1.7指示PHY只有在PHY確定已建立有效鏈路時才能從媒體獨立介面傳輸資料。
MF preamble suppression ability：當讀為邏輯1時，位1.6指示PHY能夠接受管理幀，而不管它們是否在22.2.4.5.2中描述的前導碼模式之前。當讀為邏輯0時，位1.6指示PHY不能接受管理幀，除非它們之前是22.2.4.5.2中描述的前導碼模式。
Auto-Negotiation Complete：當讀為邏輯1時，位1.5指示自動協商過程已完成，並且由自動協商協議（條款28或條款37）實施的擴充套件暫存器的內容是有效的。當讀為邏輯0時，位1.5指示自動協商過程尚未完成，並且擴充套件暫存器的內容由自動協商協議的當前狀態定義，或者為手動配置寫入。如果自動協商通過清除位0.12禁用，則PHY應在位1.5返回零值。如果PHY缺乏執行自動協商的能力，它還應在位1.5返回零值。

在除錯以及異常故障處理時，可以通過該位暫存器的狀態判斷AN是否成功，從而進一步的檢查AN相關的設定是否正確，或者晶片的AN功能是否正常等。

Remote Fault：當讀為邏輯1時，位1.4表示檢測到遠端故障狀態。故障型別以及故障檢測的標準和方法是PHY特定的。遠端故障位必須使用鎖存功能來實現，以便發生遠端故障將導致遠端故障位置位，並保持置位狀態直至被清除。每當通過管理介面讀取暫存器1時，遠端故障位應清零，並且還應通過PHY復位清零。
遠端錯誤指示位。Bit4=1代表連線對端（Link Partner）出錯，至於出錯的具體型別以及錯誤檢測機制在規範中並沒有定義，由PHY的製造商自由發揮，一般的廠商都會在其他的暫存器（Register16-31由廠商自行定義）指示比較詳細的錯誤型別。在與埠相關的故障查證中，Remote Fault是一個重要的指示資訊，通過互聯雙方的Remote Fault資訊（可能要加上其他的具體錯誤指示），可以幫助定位故障原因。
Auto-Negotiation ability：當讀為邏輯1時，位1.3指示PHY有能力執行自動協商。當讀為邏輯0時，位1.3指示PHY缺乏執行自動協商的能力。
Link Status：當讀為邏輯1時，位1.2指示PHY已經確定已建立有效鏈路。當作為邏輯0讀取時，位1.2指示該連結無效。確定鏈路有效性的標準是PHY特定的。鏈路狀態位應該使用鎖存功能來實現，以便發生鏈路故障情況將導致鏈路狀態位清零並保持清零，直到通過管理介面讀取。此狀態指示旨在支援在30.5.1.1.4，aMediaAvailable中定義的管理屬性。
實際應用中一般都是通過Bit2來判斷埠的狀態。而且，一般的MAC晶片也是通過輪詢PHY的這個暫存器值來判斷埠的Link狀態的（這個過程可能有不同的名稱，比如BCM叫做Link Scan，而Marvell叫做PHY Polling。）如前所述，在AN Enable的情況下，Link Status的資訊只有在Auto-Negotiation Complete指示已經完成的情況下才是正確可靠的，否則有可能出錯。
Jabber Detect：當作為邏輯1讀取時，位1.1指示已經檢測到爆音條件。此狀態指示旨在支援30.5.1.1.6中定義的管理屬性，aJabber和30.5.1.3.1 nJabber中定義的MAU通知。檢測Jabber條件的標準是PHY特定的。 Jabber檢測位應該使用鎖存功能來實現，以便發生Jabber條件將導致Jabber檢測位置位，並保持置位狀態直至被清除。每次通過管理介面讀取暫存器1時，Jabber檢測位應清零，並且還應通過PHY復位清零。
IEEE802.3對Jabber的解釋是“A condition wherein a station transmits for a period of time longer than the maximum permissible packet length, usually due to a fault condition”。這一位指示的是Link Partner傳送的時間超過了規定的最大長度。值得注意的是，Jabber Detect只有在10BASE-T模式下才有意義，100和1000M模式是沒有定義Jabber這一功能的。

PHY Identifier Register

暫存器2和3存放PHY晶片的型號程式碼，暫存器2(PHY ID1)為高16位，而暫存器3(PHY ID2)為低16位。由晶片製造商自行定義，實際應用中軟體通過讀取這兩個暫存器的內容可以識別PHY的型號和版本。
PHY識別符號應由由IEEE分配給PHY製造商的組織唯一識別符號（OUI）的（只需要使用第3至第24位，共22位），加上6位製造商的型號以及4位製造商的修訂版編號組成。 PHY識別符號旨在提供足夠的資訊來支援30.1.2中所要求的oResourceTypeID物件。
OUI的第三位分配給位2.15，OUI的第四位分配給位2.14，依此類推。位2.0包含OUI的第十八位。位3.15包含OUI的第十九位，位3.10包含OUI的第二十四位。位3.9包含製造商型號的MSB。位3.4包含製造商型號的LSB。位3.3包含製造商版本號的MSB，位3.0包含製造商版本號的LSB。具體如下圖所示：

Auto-Negotiation Advertisement Register (Register 4) (R/W)

暫存器4是自動協商的能力通告暫存器，在AN Enable的前提下（見暫存器0），埠根據該暫存器的相關配置將自動協商資訊通過FLP在MDI上進行通告。當AN配置為Disable狀態的時候，暫存器4的配置將不起作用，埠的工作模式由控制暫存器中的配置決定。
該暫存器包含PHY的通告能力，它們將在自動協商期間傳送給其連結夥伴。基本頁的位定義在IEEE標準的28.2.1.2中定義。上電時，在自動協商開始之前，該暫存器應具有以下預設配置：

Selector Field （4.4：0）：被設定為適當的程式碼，如IEEE標準的附件28A中所規定。
Reserved（4.14）：被設定為邏輯0。
Technology Ability Field（4.11：5）：根據MII狀態暫存器（暫存器1）（1.15：11）中設定的值或等效值設定。另見28.2.1.2.3和附件28D。

Link codeword encoding（基本鏈路碼字）

在FLP Burst內傳輸的基本鏈路程式碼字（基本頁面）應該傳達如圖28-7所示的編碼。自動協商功能可以使用下一頁功能支援其他頁面。下一頁交換中使用的連結程式碼字的編碼在28.2.3.4中定義。在FLP Burst中，D0應該是第一個傳輸的位。

Next Page function

下一頁功能使用標準的自動協商仲裁機制來允許交換任意的資料。資料由可選的下一頁資訊攜帶，其遵循用於基本連結碼字的傳輸和確認過程。定義了四種類型的下一頁編碼：訊息頁面，未格式化頁面，擴充套件訊息頁面和擴充套件的未格式化頁面。
關於該部分，具體見IEEE標準的28.2.3.4 Next Page function。
在IEEE標準中，Auto-Negotiation Advertisement Register中的各部分全部是在獨立章節中進行介紹的。具體如下：

Selector Field：選擇器欄位（S [4：0]）是一個5位寬的欄位，編碼32個可能的訊息。鏈路碼字中的選擇器欄位S [4：0]應用於識別自動協商傳送的訊息的型別。下表列出了可能傳送的訊息的型別。隨著新訊息的發展，該表格將相應更新。

未指定的組合保留供將來使用。不會傳輸選擇器欄位的預留組合。***我們所接觸的乙太網PHY遵從IEEE802.3規範，Selector Field=0001，該區域不可隨意更改（很多PHY將此區域設計為只讀暫存器，以免被修改）***。
Technology Ability Field：技術能力欄位（A [6：0]）是一個7位寬的欄位，其中包含指示選擇器欄位值特定的支援技術的資訊。這些位被對映到各個技術，以便能夠針對單個選擇器欄位值並行通告能力。附錄28B.2和附件28D描述了IEEE 802.3選擇器的技術能力欄位編碼。連結程式碼字中可能會公佈多種技術。裝置應支援其宣傳的技術的資料服務能力。
Extended Next Page：擴充套件下一頁（XNP）被編碼在基本鏈路碼字的位D12中。擴充套件下一頁位指示本地裝置在設定為邏輯1時支援擴充套件下一頁的傳輸，並指示本地裝置在設定為邏輯0時不支援擴充套件下一頁。 Extended Next Page的使用與協商的資料速率，媒體或連結技術是正交的。擴充套件下一頁位按照28.2.3.4中的擴充套件下一頁功能規範使用。
Next Page：無論選擇器欄位值還是連結碼字編碼，下一頁（NP）都在D15位編碼。支援附加連結碼字編碼的傳輸和接收是可選的。如果不支援Next Page功能，NP位應始終設定為邏輯0。如果裝置實現下一頁功能並希望進行下一頁交換，則應將NP位設定為邏輯1。裝置可以實現下一頁功能，並通過將NP位設定為邏輯0來選擇不參與下一頁交換。下一頁功能在28.2.3.4中定義。
Remote Fault：遠端故障（RF）編碼在基本鏈路碼字的位D13中。預設值是邏輯零。遠端故障位為傳輸簡單的故障資訊提供了一種標準的傳輸機制。當自動協商通告暫存器（暫存器4）中的RF位設定為邏輯1時，傳送的基本鏈路碼字中的RF位被設定為邏輯1。當接收到的基本鏈路程式碼字中的RF位被設定為邏輯1時，如果存在MII管理功能，則MII狀態暫存器（暫存器1）中的遠端故障位將被設定為邏輯1。

Auto-Negotiation Link Partner ability register (Register 5) (RO)

暫存器5儲存的是本端PHY接收到的對端PHY所通告的埠能力，暫存器5的結構和暫存器4基本一致。

Auto-Negotiation Expansion Register (Register 6) (RO)

暫存器6儲存了PHY自動協商過程的異常資訊。從這個寄存其中我們可以獲取到Link Partner子否支援自動協商以及自動協商下一頁有沒有收到的資訊。

Auto-Negotiation Next Page transmit register (Register 7) (R/W)

自動協商下一頁傳送暫存器包含在支援下一頁功能時要傳送的下一頁連結碼字。（見表28-6）內容在28.2.3.4中定義。上電時，該暫存器應包含預設值2001H，該值表示訊息程式碼設定為Null訊息的訊息頁面。該值可以由裝置希望傳輸的任何有效的下一頁訊息程式碼替換。寫入該暫存器應將mr_next_page_loaded設定為true。

Auto-Negotiation Link Partner Received Next Page register (Register 8) (RO)

https://blog.csdn.net/sternlycore/article/details/89065789

GPON Type B保護

2020-11-17T11:28:00.002+08:00

from:https://blog.csdn.net/derek_yi/article/details/8743146

GPON TYPE B保護的組網圖如圖1所示，相應的保護範圍包括OLT的主用和備用PON端口，主用和備用光纖。

場景一：PON口工作過程中主用光纖斷，如圖2所示。

Standby PON口在進入Standby狀態後，啟動上行光信號檢測功能。
Active PON口檢測到LOS告警（主用光纖斷引起的LOS告警），立即關閉主用GPON端口光模塊發送功能。
Standby PON口檢測到主用PON口LOS告警，打開GPON端口光模塊發送功能並進行ONU測試操作。
如果Standby PON口光纖正常，並發現ONU，便上報端口LOS恢復告警。
Active PON口切換為Standby狀態，並啟動上行光檢測功能。Standby PON口被設置為Active狀態。至此倒換處理過程結束。

場景二：PON口相關聯的ONU全部離線，如圖3所示。

Standby PON口在進入Standby狀態後，啟動上行光信號檢測功能。
Active PON口檢測到LOS告警（所有ONU全部離線引起的LOS告警），立即關閉GPON端口光模塊發送功能。
Standby PON口檢測到主用PON口LOS告警，打開GPON端口光模塊發送功能並進行ONU測試操作。
由於PON口下沒有ONU在線，設備會一直進行主用端口與備用端口的循環檢測，直到有ONU上線。
當ONU上線的時候，PON端口沒有進行倒換。

MACsec on Linux

2020-11-10T11:42:00.000+08:00

from https://nextheader.net/2016/10/14/macsec-on-linux/

Starting with kernel 4.6, support for MACsec has been added in Linux so it won’t be needed to use a release candidate to test this feature.

There are two ways to implement MACsec:

manually configure secure channel(SC), security association(SA) and the keys(this is what we are going to see)
use dot1x with MACsec extensions that allows dynamic discovery of MACsec peers, SA and SC setup, key generation and distribution

This is the topology that is being used to demonstrate most of the implementation of MACsec on Linux and the purpose is to have connectivity between the two hosts using MACsec.

Between the two hosts there is a L2VPN that is provided by the QFX10K switches.

I won’t discuss how to set up the L2VPN as we already did this several times, one example being L2circuit for L2 protocol tunneling.

On top of this, we want to have additional security at Layer 2 between the two Linux hosts, hence MACsec is the suitable option here.

There are few prerequisites for running MACsec on Linux. I won’t mention here that you need a kernel that supports MACsec:

add the macsec module in kernel
install the latest version of iproute2

This is how you perform these two operations

git clone git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git
cd iproute2/
./configure
make
make install
modprobe macsec

So let’s move further with the configuration.

The required steps to configure MACsec are the following:

create a MACsec device on the physical link over the traffic will be received and sent
configure a secure association on the MACsec device
configure a receive channel(you will need to use the peer MAC address as parameter)
configure a receive association(you will need to use the peer MAC address as parameter)

First we need to know the MAC addresses of the two hosts between which MACsec will be configured. Each host needs to know from what MAC address will receive protected traffic.

This is UBUNTU-1:

root@UBUNTU-1:~# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 56:68:a6:6f:08:d1
          inet6 addr: fe80::5468:a6ff:fe6f:8d1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:114 errors:2 dropped:91 overruns:0 frame:2
          TX packets:158 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:30957 (30.9 KB)  TX bytes:26724 (26.7 KB)

root@UBUNTU-1:~#

And this is UBUNTU-2:

root@UBUNTU-2:~# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 56:68:a6:6f:08:d6
          inet6 addr: fe80::5468:a6ff:fe6f:8d6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:63 errors:2 dropped:36 overruns:0 frame:2
          TX packets:163 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:15079 (15.0 KB)  TX bytes:27392 (27.3 KB)

root@UBUNTU-2:~#

Let’s see the configuration for UBUNTU-1(the last two commands are also adding an IP address on the newly created interface and bring it up so we can test later on the IP reachability between the hosts):

ip link add link eth1 macsec0 type macsec

Creates the MACsec device on eth1 interface

ip macsec add macsec0 tx sa 0 pn 1 on key 01 12345678901234567890123456789012

Configure the transmit secure association, the packet number used as the start ID for the packets sent through this SA and the key.

ip macsec add macsec0 rx address 56:68:a5:c2:37:76 port 1
ip macsec add macsec0 rx address 56:68:a5:c2:37:76 port 1 sa 0 pn 1 on key 02 09876543210987654321098765432109

Configure the receive channel and receive association based on the peer MAC address, the port number, the first packet number expected and the key.

ip link set dev macsec0 up
ifconfig macsec0 10.10.12.1/24

These two bring up the interface and configure an IP address on macsec0 interface.

Remember that the transmit SA key has to match the peer’s receive SA key and the other way around.

And this is the configuration for UBUNTU-2:

ip link add link eth1 macsec0 type macsec
ip macsec add macsec0 tx sa 0 pn 1 on key 02 09876543210987654321098765432109
ip macsec add macsec0 rx address 56:68:a5:c2:4c:14 port 1
ip macsec add macsec0 rx address 56:68:a5:c2:4c:14 port 1 sa 0 pn 1 on key 01 12345678901234567890123456789012
ip link set dev macsec0 up
ifconfig macsec0 10.10.12.2/24

Once the configuration is applied on both sides, you can check the MACsec configuration:

root@UBUNTU-1:~# ip macsec show
8: macsec0: protect on validate strict sc off sa off encrypt off send_sci on end_station off scb off replay off
    cipher suite: GCM-AES-128, using ICV length 16
    TXSC: 5668a5c24c140001 on SA 0
        0: PN 12, state on, key 12345678901234567890123456789012
    RXSC: 5668a5c237760001, state on
        0: PN 12, state on, key 09876543210987654321098765432109
root@UBUNTU-1:~#

As you can see the traffic is authenticated and encrypted by default using AES-GCM-128.

From the above output, some packets protected by MACsec exited and entered this device(“PN 12” shows this, we started at 1).

Let’s send some packets between the two hosts:

root@UBUNTU-1:~# ping 10.10.12.2 -c 3
PING 10.10.12.2 (10.10.12.2) 56(84) bytes of data.
64 bytes from 10.10.12.2: icmp_seq=1 ttl=64 time=24.3 ms
64 bytes from 10.10.12.2: icmp_seq=2 ttl=64 time=20.8 ms
64 bytes from 10.10.12.2: icmp_seq=3 ttl=64 time=19.3 ms

--- 10.10.12.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 19.367/21.533/24.388/2.106 ms
root@UBUNTU-1:~# ip macsec show
8: macsec0: protect on validate strict sc off sa off encrypt off send_sci on end_station off scb off replay off
    cipher suite: GCM-AES-128, using ICV length 16
    TXSC: 5668a5c24c140001 on SA 0
        0: PN 15, state on, key 12345678901234567890123456789012
    RXSC: 5668a5c237760001, state on
        0: PN 15, state on, key 09876543210987654321098765432109
root@UBUNTU-1:~#

As you can see, the packet number increased.

You can also check detailed statistics about the MACsec traffic like this:

root@UBUNTU-1:~# ip -s macsec show
8: macsec0: protect on validate strict sc off sa off encrypt off send_sci on end_station off scb off replay off
    cipher suite: GCM-AES-128, using ICV length 16
    TXSC: 5668a5c24c140001 on SA 0
    stats: OutPktsUntagged InPktsUntagged OutPktsTooLong InPktsNoTag InPktsBadTag InPktsUnknownSCI InPktsNoSCI InPktsOverrun
                         0              0              0           9            0                0           0             0
    stats: OutOctetsProtected OutOctetsEncrypted OutPktsProtected OutPktsEncrypted
                           14                  0             1572                0
        0: PN 15, state on, key 12345678901234567890123456789012
           OutPktsProtected OutPktsEncrypted
                         14                0
    RXSC: 5668a5c237760001, state on
    stats: InOctetsValidated InOctetsDecrypted InPktsUnchecked InPktsDelayed InPktsOK InPktsInvalid InPktsLate InPktsNotValid InPktsNotUsingSA InPktsUnusedSA
                         668                 0               0             0        6             0          0              0                0              0
        0: PN 15, state on, key 09876543210987654321098765432109
           InPktsOK InPktsInvalid InPktsNotValid InPktsNotUsingSA InPktsUnusedSA
                  6             0              0                0              0
root@UBUNTU-1:~#

Two optional features that increase the security on MACsec traffic are encryption and replay protection.

Encryption – The original payload is encrypted and authenticated
Replay protection – The packet number of each packet that crossed the MACsec secured link is checked. If there is any packet that arrived out of sequence and the difference between the packet numbers is higher than the replay protection window size, the packet is dropped.

Let’s see how these are configured.

First the encryption:

ip link set macsec0 type macsec encrypt on

Remember that we were at PN 15. Let’s send another 3 packets using ping and then check the statistics:

root@UBUNTU-1:~# ip macsec show
8: macsec0: protect on validate strict sc off sa off encrypt on send_sci on end_station off scb off replay off
    cipher suite: GCM-AES-128, using ICV length 16
    TXSC: 5668a5c24c140001 on SA 0
        0: PN 19, state on, key 12345678901234567890123456789012
    RXSC: 5668a5c237760001, state on
        0: PN 19, state on, key 09876543210987654321098765432109
root@UBUNTU-1:~# ip -s macsec show
8: macsec0: protect on validate strict sc off sa off encrypt on send_sci on end_station off scb off replay off
    cipher suite: GCM-AES-128, using ICV length 16
    TXSC: 5668a5c24c140001 on SA 0
    stats: OutPktsUntagged InPktsUntagged OutPktsTooLong InPktsNoTag InPktsBadTag InPktsUnknownSCI InPktsNoSCI InPktsOverrun
                         0              0              0          23            0                0           0             0
    stats: OutOctetsProtected OutOctetsEncrypted OutPktsProtected OutPktsEncrypted
                           14                  4             1572              464
        0: PN 19, state on, key 12345678901234567890123456789012
           OutPktsProtected OutPktsEncrypted
                         14                4
    RXSC: 5668a5c237760001, state on
    stats: InOctetsValidated InOctetsDecrypted InPktsUnchecked InPktsDelayed InPktsOK InPktsInvalid InPktsLate InPktsNotValid InPktsNotUsingSA InPktsUnusedSA
                         668               464               0             0       10             0          0              0                0              0
        0: PN 19, state on, key 09876543210987654321098765432109
           InPktsOK InPktsInvalid InPktsNotValid InPktsNotUsingSA InPktsUnusedSA
                 10             0              0                0              0
root@UBUNTU-1:~#

As you can see, we are now at PN 19, which means that actually there were 4 packets that were sent.

Three of them were the ICMP packets and one of them was the ARP Request.

The 4 packets have a total size of 464B. Let’s decompose the ICMP Request packet:

IP – 20B

ICMP – 64B

ICV – 16B

SecTag – 16B

Ethernet – 14

So a total of 130B and this means that 3 ICMP Request packets are 390B, which leave us 74B for the ARP Request packet which is broken down like this:

ARP – 28B

ICV – 16B

SecTag – 16B

Ethernet – 14

Actually doing a tcpdump on UBUNTU-2 while an ICMP Request/Reply was received/sent, you can see that the size is 130B:

root@UBUNTU-2:~# tcpdump -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
07:51:20.389014 56:68:a5:c2:4c:14 (oui Unknown) > 56:68:a5:c2:37:76 (oui Unknown), ethertype Unknown (0x88e5), length 130:
07:51:20.389190 56:68:a5:c2:37:76 (oui Unknown) > 56:68:a5:c2:4c:14 (oui Unknown), ethertype Unknown (0x88e5), length 130:
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel
root@UBUNTU-2:~#

You can also see the MACsec ether-type, 0x88e5.

This is how you can enable the replay protection:

ip link set macsec0 type macsec replay on window 128

You can see that encryption and replay protection are enabled by checking the MACsec configuration:

root@UBUNTU-1:~# ip macsec show
8: macsec0: protect on validate strict sc off sa off encrypt on send_sci on end_station off scb off replay on window 128
    cipher suite: GCM-AES-128, using ICV length 16
    TXSC: 5668a5c24c140001 on SA 0
        0: PN 40, state on, key 12345678901234567890123456789012
    RXSC: 5668a5c237760001, state on
        0: PN 40, state on, key 09876543210987654321098765432109
root@UBUNTU-1:~#

And this would be the basic configuration that you need to enable MACsec to protect the Layer 2 traffic.

I also tried to enable MACsec on bond links(aggregated interfaces or port-channels how they are named in networking vendors terminology), but I wasn’t able to do it.

In case of bond interfaces, the macsec devices are enslaved instead of the physical links and the macsec devices are created on the physical links. However, I wasn’t allowed to enslave the macsec devices in the bond for some reason.

I hope you found this post useful.

References:

MACsec – Encryption for the wired LAN

SSH 命令的三種代理功能（-L/-R/-D）

2020-09-18T11:00:00.000+08:00

From:https://zhuanlan.zhihu.com/p/57630633

ssh 命令除了登陸外還有三種代理功能：

正向代理（-L）：相當於iptable 的port forwarding
反向代理（-R）：相當於frp 或者ngrok
socks5 代理（-D）：相當於ss/ssr

如要長期高效的服務，應使用對應的專用軟件。如沒法安裝軟件，比如當你處在限制環境下想要訪問下某個不可達到的目標，或者某個臨時需求，那麼ssh 就是你的兜底方案。

正向代理：

所謂“正向代理”就是在本地啟動端口，把本地端口數據轉發到遠端。

用法1：遠程端口映射到其他機器

HostB 上啟動一個PortB 端口，映射到HostC:PortC 上，在HostB 上運行：

HostB$ ssh -L 0.0.0.0:PortB:HostC:PortC user@HostC

這時訪問HostB:PortB 相當於訪問HostC:PortC（和iptable 的port-forwarding 類似）。

用法2：本地端口通過跳板映射到其他機器

HostA 上啟動一個PortA 端口，通過HostB 轉發到HostC:PortC上，在HostA 上運行：

HostA$ ssh -L 0.0.0.0:PortA:HostC:PortC  user@HostB

這時訪問HostA:PortA 相當於訪問HostC:PortC。

兩種用法的區別是，第一種用法本地到跳板機HostB 的數據是明文的，而第二種用法一般本地就是HostA，訪問本地的PortA，數據被ssh 加密傳輸給HostB 又轉發給HostC:PortC 。

反向代理：

所謂“反向代理”就是讓遠端啟動端口，把遠端端口數據轉發到本地。

HostA 將自己可以訪問的HostB:PortB 暴露給外網服務器HostC:PortC，在HostA 上運行：

HostA$ ssh -R HostC:PortC:HostB:PortB  user@HostC

那麼鏈接HostC:PortC 就相當於鏈接HostB:PortB。使用時需修改HostC 的/etc/ssh/sshd_config，添加：

GatewayPorts yes

相當於內網穿透，比如HostA 和HostB 是同一個內網下的兩台可以互相訪問的機器，HostC是外網跳板機，HostC不能訪問HostA，但是HostA 可以訪問HostC。

那麼通過在內網HostA上運行ssh -R告訴HostC，創建PortC端口監聽，把該端口所有數據轉發給我（HostA），我會再轉發給同一個內網下的HostB:PortB。

同內網下的HostA/HostB也可以是同一台機器，換句話說就是內網HostA把自己可以訪問的端口暴露給了外網HostC。

按照前文《韋易笑：內網穿透：在公網訪問你家的NAS》中，相當於再HostA上啟動了frpc，而再HostC上啟動了frps。

本地socks5 代理

在HostA 的本地1080 端口啟動一個socks5 服務，通過本地socks5 代理的數據會通過ssh 鏈接先發送給HostB，再從HostB 轉發送給遠程主機：

HostA$ ssh -D localhost:1080  HostB

那麼在HostA 上面，瀏覽器配置socks5 代理為127.0.0.1:1080，看網頁時就能把數據通過HostB 代理出去，類似ss/ssr 版本，只不過用ssh 來實現。

使用優化

為了更好用一點，ssh後面還可以加上：-CqTnN參數，比如：

$ ssh -CqTnN -L 0.0.0.0:PortA:HostC:PortC  user@HostB

其中-C為壓縮數據，-q安靜模式，-T禁止遠程分配終端，-n關閉標準輸入，-N不執行遠程命令。此外視需要還可以增加-f參數，把ssh放到後台運行。

這些ssh 代理沒有短線重連功能，鏈接斷了命令就退出了，所以需要些腳本監控重啟，或者使用autossh 之類的工具保持鏈接。

功能對比

正向代理（-L）的第一種用法可以用iptable 的port-forwarding 模擬，iptable 性能更好，但是需要root 權限，ssh -L 性能不好，但是正向代理花樣更多些。反向代理（-R）一般就作為沒有安裝frp/ngrok/shootback 時候的一種代替，但是數據傳輸的性能和穩定性當然frp 這些專用軟件更好。

socks5 代理（-D）其實是可以代替ss/ssr 的，區別和上麵類似。所以要長久使用，推薦安裝對應軟件，臨時用一下ssh 挺順手。

補充下iptable的 port-forwarding怎麼設置，十分管用的功能，兩個函數即可：

#! /bin/sh

# create forward rule by source interface
# http://serverfault.com/questions/532569/how-to-do-port-forwarding-redirecting-on-debian
PortForward1() {
    local IN_IF=$1
    local IN_PORT=$2
    local OUT_IP=$3
    local OUT_PORT=$4
    local IPTBL="/sbin/iptables"
    echo "1" > /proc/sys/net/ipv4/ip_forward
    $IPTBL -A PREROUTING -t nat -i $IN_IF -p tcp --dport $IN_PORT -j DNAT --to-destination ${OUT_IP}:${OUT_PORT}
    $IPTBL -A FORWARD -p tcp -d $OUT_IP --dport $OUT_PORT -j ACCEPT
    $IPTBL -A POSTROUTING -t nat -j MASQUERADE
}

# create forward rule by source ip
# http://blog.csdn.net/zzhongcy/article/details/42738285
ForwardPort2() {
    local IN_IP=$1
    local IN_PORT=$2
    local OUT_IP=$3
    local OUT_PORT=$4
    local IPTBL="/sbin/iptables"
    echo "1" > /proc/sys/net/ipv4/ip_forward
    $IPTBL -t nat -A PREROUTING --dst $IN_IP -p tcp --dport $IN_PORT -j DNAT --to-destination ${OUT_IP}:${OUT_PORT}
    $IPTBL -t nat -A POSTROUTING --dst $OUT_IP -p tcp --dport $OUT_PORT -j SNAT --to-source $IN_IP
}

第一個函數是按照網卡名稱設置轉發：

PortForward1 eth1 8765 202.115.8.2 8765

這時，本地eth1 網卡的8765 端口就會被轉發給202.115.8.2 的8765 端口。

第二個函數是按照本機的ip 地址，比如本機是192.168.1.2：

PortForward2 192.168.1.2 8765 202.115.8.2 8765

那麼任何訪問本機192.168.1.2 這個地址8765 端口，都會被轉發到202.115.8.2:8765

這個iptable的port forwarding是內核層運行的，性能極好，只不過每次重啟都需要重新設置下。

常見以太網接口介紹

2020-07-16T16:55:00.003+08:00

from:https://www.wpgdadatong.com/tw/blog/detail?BID=B0594

一. PHY包含的各個子層：

PCS：編碼和解碼

PMA：串行器和反序列化器

PMD：取決於物理介質

Firgure 1: OSI模型裡示意圖：

Firgure 2: 實際互連示意圖：

二. 以太網上常見的MAC 與PHY 之間的接口( 按照速度區分)

1億

MII：介質獨立接口（ IEEE 802.3 CL22 ）

一種數字接口，可在10/100 Mbit / s PHY與MAC子層之間提供4位寬的數據路徑。
TXC，TXD [3：0]，TXEN，TXER
RXC，RXD [3：0]，RXDV，RXER

RMII：簡化的媒體獨立接口

對比MII，是信號線數量減半
主要支持廠家有BRCM/AMD/TI等

Figure 3：RMII連接示意圖：

SMII：串行MII

串行化的MII
信號主要有： REFCLK, STXD, SRXD, SSYNC, TX_EN, RX_DV
主要支持廠家有Cisco

Figure 4：SMII連接示意圖：

S3MII：源同步SMII

REFCLK，SSMII_RXC，SSMII_RSYNC，RXD，SSMII_TXC，SSYNC，TXD
主要支持廠家Cisco

Figure 5：S3MII連接示意圖：

1000M

2.1>.1GE 並行接口

GMII：千兆位媒體獨立接口，IEEE 802.3 CL35

在1000 Mbit / s PHY和MAC子層之間提供8位寬數據路徑的數字接口。它還支持IEEE 802.3z規範中定義的4位寬的MII接口。
GTXCLK，TXD [7：0]，TXEN，TXER
RXC，RXD [7：0]，RXDV，RXER，COL CRS

Figure 6: GMII 連接示意圖：

RGMII：簡化的GMII，

-對比GMII，主要是數據線數量減半；

-主要支持廠家有BRCM/HP/MAVL

2.2>. 1GE 串行接口

SGMII：串行MII ，1.25G波特率，Cisco

一個數字接口，可在1000 Mbit / s PHY和MAC子層之間提供1.25 Gbps串行雙數據速率數據路徑。
SGIN +-/ SGOUT +-
8b / 10b編碼

Figure 7： SGMII 連接示意圖：

QSGMII：Quad SGMII ，5G波特率，Cisco

四路串行千兆媒體獨立接口：一種數字接口，可在四個1000 Mbit / s PHY端口和MAC子層之間提供5.0 Gbps串行數據路徑
QSGMII_RDp / n，QSGMII_TDp / n
8b / 10b編碼

USGMII：通用SGMII，1.25G / 5G / 10G波特率，思科

當前SGMII和QSGMII的擴展。USGMII提供了添加新功能的靈活性，同時保持了向後兼容性。
USGMII_RDp / n，USGMII_TDp / n
8b / 10b編碼
最多可以支持8個1GE 口
PCH: Packet Control Header. 這個是最大特點。

PCH提供諸如PTP時間戳之類的可選功能，並可以通過重複使用下文所述的擴展字段來添加功能。PHY通過PCH與端口MAC（ASIC）通信。PCH是8個字節，它代替了幀的前同步碼。

1000base-X： Serdes，8b / 10b編碼，IEEE 802.3 CL36 / 37

1000base-KX: 1G背板的應用, 8b/10b coding, IEEE 802.3 CL70

2.3>. 擴展—BRCM supports USXGMII:

USXGMII: Universal serial XGMII，它是基於一對serdes的一個端口；

-10.3125G波特率，64b / 66b編碼;

Figure 9:USXGMII工作在10G和5G時候的區別：

2.4>. 比較：

-USGMII與SGMII / QSGMII

USGMII可以最多支持8個1GE口，通過一對10G serdes，對於高密度的應用更合適；

USGMII可以過PCH（PacketControlHeader）傳遞MAC和PHY之間的control/status信息，這對PTP上timestamp的應用提供了便利；

USGMII與USXGMII

USGMII是出8個1GE口，

USXGMII是出一個口，此口可以是10M/100M/1000M/5G/10G等

XAUI ---- 10千兆位附件單元接口，IEEE 802.3 CL47 10GBASE-LX4（CL53），10GBASE-KX4（CL71），10GBASE-CX4（CL54）

125Gbps，8b / 10b編碼
XG_RX [3：0] _p / n，XG_TX [3：0] _p / n
4對差分線出1一個10G口；

DXAUI--雙重XAUI 4x6.25Gbps，8b / 10b編碼

XG_RX [3：0] _p / n，XG_TX [3：0] _p / n
4對差分線出一個20G口；

RAXUI ---減少XAUI 2x6.25Gbps，8b / 10b編碼

XG_RX [1：0] _p / n，XG_TX [1：0] _p / n
兩對差分線出一個10G口；

XFI： 10 Gigibit附件單元接口，INF-8077

The XFI 用來做10G速率下chip-to-chip 互聯，最初是被XFP multi-source agreement定義.
10.3125Gbps，64b / 66b編碼
一對差分線出10G口；

10GBASE-KR:背板側應用，IEEE 802.3，CL72

主要特點是CL73 AN，CL72 training，CL74 FEC；
速率10.3125G，64b/66b編碼；
一對差分線出一個10G口；

QoS中ToS和CoS的區別？802.1p、ip pri、dscp的區別？

2020-07-01T15:09:00.004+08:00

from:https://blog.51cto.com/imccie/1750821

談到qos首先需要了解qos調度的幾個重要過程,qos調度過程包括網絡入口數據流量的分類和標記、骨幹網設備上的擁塞避免和擁塞管理、網路出口的隊列調度這幾個重要過程.
1、cos和tos的區別:
通過acl對流量進行分類以後,緊接著就需要對報文進行標記,打標記可以在三層(ip)報文頭上做,也可以在二層報文頭上做.
tos（type of service）就是指在三層報文頭(即ip頭)作標記,cos（code of service）則是在二層報文頭作標記,tos與cos只是qos的一種標記機制。
2、802.1p、ip preference、tos、dscp的區別：
(1)、802.1p：
當需要在二層報文頭做標記的時候，由於單純二層報文沒有地方能打標記，二層打標記只能在trunk上完成，trunk要用到802.1q或isl協議，如果使用的是802.1q協議，標記會打在802.1q協議頭的tci字段上，打了標記（優先級）後的報文，就稱為802.1p報文了。
二層報文頭：

data

fcs

802.1q報文頭：

tpid
2byte

tci
2byte

data

fcs

tci字段結構：

tci
pri 3 bits	cfi 1 bit	vlan id 12 bits

tpid字段標識此報文是802.1q報文，tci字段有3bit是用來標記優先級的，如果標記了優先級就稱為802.1p報文了。
(2)、ip preference和tos：
ip報文結構如下：

version	ihl	type of service	packet length
identification			flag	frag offset
time to live		protocol	header checksum
source address
destination address
options					padding

ip報文頭的type of sevice字段長度為1個字節，其中高3 bit用來標記優先級，所以有0-7共8個ip preference級別。
type of service字段的中間4bit為tos子字段，最低1bit未用但必須置0。4bit的tos分別代表：最小時延、最大吞吐量、最小費用和最高可靠性。4bit中只能將其中1bit置1。如果所有4bit均為0，那麼就表示是普通服務。type of service字段結構如下：

type of service
x	x	x	delay	troughput	cost	rely	0
ip preference			tos				長置0

(3)、dscp：
為了更精細化的控制數據流分類，rfc2474定義了dscp（differential services code point），dscp擴展了type of service字段的高6 bit來表示報文優先級，因此，標記範圍從0-63。type of service字段結構如下：

type of service
x	x	x	x	x	x	0	0
ip preference						長置0

dscp定義了四個系列，default、cs系列、af系列、ef系列。
①、default :
就是默認的不做優先級，即ip preference字段都是0。

type of service
0	0	0	0	0	0	0	0
ip preference						長置0

②、cs系列:
rfc2474定義最高3比特為級別／類別選擇代碼（class selector codepoints，cs），其意義和ipv4報頭中ip優先級的定義是相同的，cs0 ～ cs7的級別相當於ip優先級0 ～ 7。但它並沒有定義第3到第5比特的具體含義以及使用規則。dscp使用6比特，可以定義64個優先級（0－63）。cs系列ip報文中type of service字段結構如下：

type of service
0	0	1	0	0	0	0	0
ip preference						長置0

.
.
.

type of service
1	1	1	0	0	0	0	0
ip preference						長置0

cs = 6網間控制（internetwork control），dscp = 48 (110000).路由協議優先級默認是cs6。
cs = 7網內控制（intranetwork control），dscp = 56 (111000)
③、af :
保證轉發（assured forwarding, af）由rfc2597對cs1～cs4進行進一步定義。它使用第3和第4比特做丟棄優先級標誌。01－低丟棄優先級；10－中丟棄優先級；11－高丟棄優先級。這樣，在同一類數據中，又根據被丟棄的可能性劃分出3個級別。af11～af13,af21～af23,af31～af33,af41～af43.下表列出了af服務等級及其對應的dscp值：

	cs1 00100	cs2 01000	cs3 01100	cs4 10000
low drop 01	af11 00101	af21 01001	af31 01101	af41 10001
medium drop 10	af12 00110	af22 01010	af32 01110	af42 10010
high drop 11	af13 00111	af23 01011	af33 01111	af43 10011

④、ef:
由rfc2598定義，dscp值為46 (101110)。ef服務適用於低丟包率，低延遲，低抖動及保證帶寬的業務，voip默認級別是ef。

SMI（MDC/MDIO）介紹 Clause 22/45

2020-06-02T10:16:00.000+08:00

From:http://blog.chinaaet.com/justlxy/p/5100064818

SMI：串行管理接口（Serial Management Interface），通常直接被稱為MDIO接口（Management Data Input/Output Interface）。MDIO最早在IEEE 802.3的第22卷定義，後來在第45卷又定義了增強版本的MDIO，其主要被應用於以太網的MAC和PHY層之間，用於MAC層器件通過讀寫寄存器來實現對PHY層器件的操作與管理。

MDIO主機（即產生MDC時鐘的設備）通常被稱為STA（Station Management Entity），而MDIO從機通常被稱為MMD（MDIO Management Device）。通常STA都是MAC層器件的一部分，而MMD則是PHY層器件的一部分。MDIO接口包括兩條線，MDIO和MDC，其中MDIO是雙向數據線，而MDC是由STA驅動的時鐘線。MDC時鐘的最高速率一般為2.5MHz，MDC也可以是非固定頻率，甚至可以是非週期的。MDIO接口只是會在MDC時鐘的上升沿進行採樣，而並不在意MDC時鐘的頻率（類似於I2C接口）。如下圖所示。

MDIO接口有兩個版本，通常被稱為卷22版本和卷45版本。卷22版本的MDIO接口最多支持連接32個MMD（PHY層設備），每個設備最多支持32個寄存器。卷45版本的MDIO接口最多支持連接32個MMD，32個設備類型，每個設備最多支持64K個寄存器。卷22版本的MDIO接口的數據幀格式如下：

具體每個bit描述如下：

卷45版本的MDIO接口的數據幀格式如下：

具體每個bit的描述如下：

如果是STA（MAC層設備）驅動MDIO，則MDIO相對於MDC上升沿，至少要有10ns的建立時間（Setup Time）和10ns的保持時間（Hold Time）。如下圖所示：

如果MDIO是由MMD（PHY層設備）驅動的，則MDIO相對於MDC的Tco（Clock to Output Delay）的範圍是0ns~300ns。如下圖所示：

實際上，MDC的頻率也並非一定是小於或等於2.5MHz，比如Marvell的88E1512最大支持12MHz的MDC：

IEEE 802.3建議同時對MDIO進行下拉（下拉電阻建議為2k歐姆+5%），和上拉（上拉電阻建議為1.5k歐姆+5%），使得在TA時，MDIO處於中間態。但是並非所有的PHY器件都有這樣的要求，比如Marvell的88E1512只要求對MDIO進行上拉即可，上拉電阻範圍為1.5k~10kΩ。

主要參考資料

1、IEEE 802.3 第22卷，第45卷

2、網友落塵紛擾的博客：https://blog.csdn.net/jasonchen_gbd/article/details/51628992

3、Lattice, RD1194, MDIO Master and Slave Controllers User Guide

4、Marvell，Alaska 88E1512 Datasheet

arp_ignore 和 arp_filter

2020-02-20T17:05:00.002+08:00

From:http://huntxu.github.io/2015-12-24-arp-filter-vs-arp-ignore.html

arp_ignore 和 arp_filter

24 Dec 2015

先說結論好了

arp_filter有個表哥叫做rp_filter，這裏的rp是Reserve Path的意思，其實就是用來檢查返回的包是否會從相對應的到來的包使用相同的網絡接口出去。它們的區別只是層次不同
arp_ignore 則是內核用來確定是否應該回覆從該端口收到的ARP請求的
這兩個判斷都在內核中的net/ipv4/arp.c中

故事是因爲有個同事在一個機器上用libvirt搭建了幾臺虛擬機之後使用橋接連接這幾臺機器，並且使用自動部署工具去部署這幾臺機器。結果發現其中有一臺機器的一個網卡沒有成功得到預期的地址。調查之後發現那臺機器在配置該地址之前使用了arping -D去檢查是否與其他機器已有的地址相互衝突了，剛巧該地址和宿主機之上的另外一個網卡地址相同，於是宿主機上橋接虛擬機網絡的網卡，便響應了那個ARP請求，導致配置失敗。

一開始我也很奇怪，爲什麼明明宿主機上橋接着虛擬機網絡的網卡並不擁有那個目標地址但卻會回覆，而更奇怪的是，虛擬機中使用arping不加-D參數，也收不到回覆。所以經過一番搜索與測試驗證，才大致搞明白了其中的原因。

首先，在內核文檔中有這樣一段對arp_filter參數的描述：

0 - (default) The kernel can respond to arp requests with addresses
from other interfaces. This may seem wrong but it usually makes
sense, because it increases the chance of successful communication.
IP addresses are owned by the complete host on Linux, not by
particular interfaces. Only for more complex setups like load-
balancing, does this behaviour cause problems.

內核認爲一個IP地址是屬於整個主機的，而非某個特定的端口，所以默認情況下，每個端口都會回覆目標是其他端口的IP地址的ARP請求。

查看了機器之後發現這一項爲默認值0，但是又一個疑問發生了，爲什麼使用arping不帶-D參數就無法收到返回呢？答案是rp_filter做了過濾，默認回應的包不從收到的端口出去，所以並不回覆。

那麼接下來又有一個問題，爲什麼帶了-D參數就收的到回覆呢？原因是，如果使用arping -D的話，發出的請求包的原地址是設置爲0.0.0.0的，這點可以參考RFC2131中的4.4.1一段。然後來看代碼：

    /* Special case: IPv4 duplicate address detection packet (RFC2131) */
    if (sip == 0) {
            if (arp->ar_op == htons(ARPOP_REQUEST) &&
                inet_addr_type_dev_table(net, dev, tip) == RTN_LOCAL &&
                !arp_ignore(in_dev, sip, tip))
                    arp_send_dst(ARPOP_REPLY, ETH_P_ARP, sip, dev, tip,
                                    sha, dev->dev_addr, sha, reply_dst);
            goto out;
    }

當請求包的地址爲0.0.0.0的時候，內核只照顧arp_ignore這個選項，而不去管arp_filter選項的內容，也不去管rp_filter的內容。

下面看兩個場景，加深一下對這幾個參數的印象：

主機上兩個接口，地址分別處於不同的子網之中
- 這種情況不會引起混亂
- 從哪個端口進來的ARP請求，一般來說請求的源地址也是那個子網之中的地址，因此回覆包也會從該端口出去，所以能通過rp_filter以及arp_filter的驗證
- 這種情況下的回覆只需要考慮arp_ignore的影響
主機上兩個接口，地址處於相同的子網之中
- 容易引起混亂的情況
- 兩個端口進來的ARP請求，基本上源地址是同一個子網，因此回覆的包只會從ifindex較小（猜測，未驗證）的端口發送出去，因此從其中一個端口進來的請求有可能無法通過rp_filter以及arp_filter的驗證
- 同樣需要考慮arp_ignore的影響，對於上面說的收到無法通過rp_filter以及arp_filter驗證的請求包的端口，除非請求的源地址爲0.0.0.0，否則便根本不會回覆，而另一端口收到的則正常，而且對兩個接口上所設置的地址，都能夠通過上述的驗證
- 要想讓兩個端口在同一子網中互不干擾，各自使用各自的地址並各自對請求包進行回覆，則需要使用策略路由，並且將arp_filter和rp_filter打開，arp_ignore正確設置

關於這些選項的具體設置值的意義，可以參考內核文檔，這裏就不複製粘貼進來加長篇幅了。總之，在能夠進行規劃的情況下，還是儘量避免容易引起混亂的情況爲好。

VXLAN vs VLAN

2019-03-25T15:49:00.001+08:00

from:https://zhuanlan.zhihu.com/p/36165475

VXLAN（Virtual eXtensible Local Area Network）或許是目前最熱門的網絡虛擬化技術。網絡虛擬化是指在一套物理網絡設備上虛擬出多個二層網絡。VXLAN由RFC7348定義，這是2014年定稿的一個協議，VXLAN協議將Ethernet幀封裝在UDP內，再加上8個字節的VXLAN header，用來標識不同的二層網絡。

同樣是網絡虛擬化技術的VLAN（Virtual Local Network）在1998年就提出了第一稿，並且得到廣泛的應用，VLAN直接在Ethernet幀的頭部加上4個字節的VLAN Tag，用來標識不同的二層網絡。VLAN已經在大部分的網絡設備和操作系統中得到了支持，它處理起來也比較簡單，在讀取Ethernet數據的時候，只需要根據EtherType相應的偏移4個字節就行。相比之下，VXLAN因為提出的較晚，在設備上的支持率不如VLAN，而且，VXLAN數據的封裝解封裝，要比VLAN複雜的多。看起來沒理由VXLAN搶占VLAN的地位，但是現實卻不是如此，那究竟是什麼原因導致的呢？

VXLAN協議

我們先來看看VXLAN協議，前面說過，VXLAN是將Ethernet Frame封裝在UDP包裡面，具體的協議格式如下。

除了常規的各層的header之外，VXLAN協議定義了8個字節的VXLAN Header。其中的24bit用來標識不同的二層網絡，這樣總共可以標識1600多萬個不同的二層網絡。一般的傳輸層端口號用來標識進程或者應用，但是在VXLAN協議裡面的，Ethernet Frame封裝在UDP裡面，UDP的source port被用來在ECMP或者LACP做負載均衡；destination port被用來標識VXLAN數據，IANA（Internet Assigned Numbers Authority）分配給VXLAN的端口號是4789。VXLAN數據是經過VTEP（VXLAN Tunnel EndPoint）封裝和解封裝的，相應的VXLAN數據的外層IP地址就是VTEP的IP地址。最外層的MAC地址用來實現VTEP之間的數據傳遞。

VXLAN與VLAN的最大區別在於，VLAN只是修改了原始的Ethernet Header，但是整個網絡數據包還是原來那個數據包，而VXLAN是將原始的Ethernet Frame隱藏在UDP數據裡面。經過VTEP封裝之後，在網絡線路上看起來只有VTEP之間的UDP數據傳遞，原始的網絡數據包被掩蓋了。

VXLAN並不是憑空出現，這種在UDP裡面封裝網絡數據的做法，在VXLAN之前就已經存在，例如OTV（Overlay Transport Virtualization）和LISP（Locator/ID Separation Protocol ）。

為什麼要VXLAN？

相比VLAN，VXLAN顯得複雜很多。再加上VLAN的先發優勢，已經得到了廣泛的支持。那為什麼還要VXLAN？

VLAN ID數量限制

首先是VLAN能支持的二層網絡數量有限。VLAN Tag總共4個字節，其中有12bit用來標識不同的二層網絡，這樣總共是4000多個。而VXLAN header有8個字節，有24bit用來標識不同的二層網絡，這樣總共是1600多萬個。這或許是知名度最高的一條原因。但這是最根本的原因嗎？VLAN自身也有一些相關的協議，其中QinQ（IEEE 802.1 ad）定義在Ethernet頭部加上2個VLAN Tag，這樣總共也可以由12+12=24bit的數據用來標識不同的二層網絡。如果僅僅是因為能支持的二層網絡數量有限，只需要在現有的VLAN設備上做一些改動，直接用QinQ就好了。所以，選用VXLAN一定還有其他原因。

TOR交換機MAC地址表限制

數據中心的虛擬化給網絡設備帶來的最直接影響就是：之前TOR（Top Of Rack）交換機的一個端口連接一個物理主機對應一個MAC地址，但現在交換機的一個端口雖然還是連接一個物理主機但是可能進而連接幾十個甚至上百個虛擬機和相應數量的MAC地址。傳統交換機是根據MAC地址表實現二層轉發。如下圖所示，交換機在收到一個數據幀之後，根據VLAN和目的MAC地址，查找到相應的交換機端口，再將數據幀從相應的端口發出。

這個MAC地址表是通過交換機的flood-learn學習並記錄在交換機的內存。交換機的內存比較寶貴，所以MAC地址表的大小通常是有限的。現在因為虛擬化，整個數據中心的MAC地址多了幾十倍，那相應的交換機裡面的MAC地址表也需要擴大幾十倍。如果交換機不支持這麼大的MAC地址表，那麼就會導致MAC地址表溢出。溢出之後，交換機不能將新的MAC地址學習到自己的MAC地址表。如果交換機收到這些MAC地址的數據幀，因為不能通過查表轉發，會flood到所有的端口。這不但增加了交換機的負擔，還增加了網絡中其他設備的負擔。為了避免這個問題，可以用一些更大容量的交換機，但是相應的成本也要上升，而且還不能從根本上解決這個問題。

如果使用VXLAN，虛擬機的Ethernet Frame被VTEP封裝在UDP裡面，一個VTEP可以被一個物理主機上的所有虛擬機共用。從交換機的角度，交換機看到的是VTEP之間在傳遞UDP數據。通常，一個物理主機對應一個VTEP，所以交換機的MAC地址表，只需要記錄與物理主機數量相當條目就可以了，虛擬化帶來的MAC地址表暴增的問題也不存在了。這是VXLAN能解決的，而現有的VLAN沒有辦法迴避的問題。

靈活的虛機部署和部署

採用VLAN網絡的虛擬環境，不存在overlay網絡。虛擬機的網絡數據，被打上VLAN Tag之後，直接在物理網絡上傳輸，與物理網絡上的VLAN是融合在一起的。這樣的好處是虛擬機能直接訪問到物理網絡的設備，但是壞處是，虛擬網絡現在不能打破物理網絡的限制。比如，如果要在VLAN 100部署虛擬機，那隻能在支持VLAN 100的物理設備上部署虛機。通常不同的VLAN網絡，會被分配不同的IP地址段，通過路由器或者其他的三層設備連接在一起。設想我有下面一個環境，紫色區域和綠色區域分別對應不同的VLAN網絡，紫色區域裡面每個服務器已經有10個虛機，綠色區域每個服務器只有2個虛機，紫色區域雖然服務器數量更多，但是總的負擔已經夠重了。現在因為業務的需求，我們還需要向紫色網絡裡面部署虛機，因為VLAN網絡無法打破物理二層網絡的限制，虛機還是只能部署在紫色區域，這明顯不合理。

另一方面，就算不部署新的虛擬機，只是對現有的部署做一個優化，將部分虛擬機從紫色區域遷移到綠色區域，因為無法打破物理二層網絡的限制，這也是不可行的。因為業務肯定不是平均分配的，那如果採用VLAN網絡，極有可能會導致數據中心的利用率分佈不均勻。

VLAN其實有自己的解決辦法，如果將所有的交換機Trunk連接起來，那在物理上沒有明確的區域區分。但是這樣就產生了一個大的二層，相應的BUM（Broadcast，Unknown Unicast，Multicast）和交換機MAC地址表的問題也會隨之產生。

如果使用VXLAN呢？因為VXLAN通過UDP傳輸Ethernet Frame，那相應的可以在一個L3網絡上，傳遞L2的數據。又或者用官方的說法，在一個L3網絡上構建了L2網絡。物理網絡的二層邊界還存在，但是現在虛機的網絡數據在三層網絡傳輸，可以跨越物理二層網絡的限制。

不管物理網絡的二層還是三層，虛擬機現在已經感知不到了。通過VXLAN的封裝，虛擬機現在走的是一套獨立於物理網絡（underlay network）的overlay network。這樣的話，在物理網絡上，就不必把所有的交換機Trunk連起來，還是可以保持一個個小的L2 Pod。但是同時，虛擬機的部署和遷移，又不用受物理網絡的限制，整個數據中心可以保持一個平均的利用率。這是另外一個VXLAN能解決，但是VLAN無法迴避的問題。

更好的利用多條網絡鏈路

VLAN協議使用STP（Spanning Tree Protocol）來管理多條線路，STP根據優先級和cost，只會選出一條線路來工作，這樣可以避免數據傳遞的環路。這種主備（active-passive）的模式，比只連接一條線路肯定是有優勢，但是對於用戶來說，相當於花了N倍的錢，卻只用到了1倍的服務。當網絡流量較大的時，也不能通過增加線路來提升性能。而VXLAN因為是通過UDP封裝，在三層網絡上傳輸。雖然傳遞的還是二層的Ethernet Frame，但是VXLAN可以利用一些基於三層的協議來實現多條線路共同工作（active-active），以實現負載均衡，例如ECMP，LACP。現在對於用戶來說，花了N倍的錢，也用到了N倍的服務。當網絡流量較大時，現在可以通過增加線路來減輕現有線路的負擔。這在提升數據中心網絡性能，尤其是東西向流量的性能時，尤其重要。這是VXLAN相比VLAN，能帶來的另一個好處。

最後

所以，儘管VXLAN要復雜一些，提出的晚一些，普及率也要低一些，但是隨著數據中心規模的發展和虛擬化的普及，VXLAN逐漸成為構建數據中心網絡的趨勢。

不過理智點看，VXLAN有這麼多優點，在可以預見的未來，還是不能完全替代VLAN。首先VXLAN是一種overlay網絡，不能獨立存在，必須依賴underlay網絡，而在構建underlay網絡時，還是需要藉助VLAN。其次，這裡介紹的VXLAN的優勢，都是在大規模環境下，如果你的數據中心的規模，不論虛機還是物理的，就百十台的樣子，那直接用VLAN也可以了，沒必要上VXLAN。

VXLAN最多是在構建數據中心時的一個選項，而不是唯一的選項。套用馬斯洛的“工具法則”：當你只有一個錘子時，任何東西看起來都像是個釘子。在設計數據中心網絡時，也應該避免用一種方法解決所有問題，VXLAN，VLAN，BGP，EVPN，OpenStack應該綜合考慮。

什麼是MPLS

2018-12-27T10:24:00.002+08:00

From:http://eservice.seed.net.tw/class/class0801c.html

多重通訊協定標籤交換傳輸(Multi-Protocol Label Switching)是由IETF 所發展出來的Network Standard。它是實現寬頻網際網路最熱門的技術；其目的是要提供一個更具彈性、擴充性及效率更高的IP層交換技術。
MPLS 是一種整合了標籤交換架構與網路層的路由機制的技術，最基本的概念是將進入MPLS Network 的封包(Packet)配置一個固定長度的標籤(Label)，在MPLS Network中Packet會根據標籤(Label) 做Forwarding , 由Label來決定Packet在網路上的路徑，不會再看 Layer 3的 IP Header(標頭)。

傳統IP Network 的運作方式

Packet在一般的IP Network傳遞時，路由器的運作是以所謂的"Store and Forward"的程序來做Packet路由的選擇及轉送，所以當路由器收到一個Packet時，會先儲存Packet 、分析路由、轉送Packet 到下一個適當的路由器，而當此路由器又收到下一個Packet 要傳送到相同的目的地時，它必須重覆執行相同的程序(儲存、分析、轉送)，這樣是很沒有效率的而且會耗用路由器大量的CPU處理能力及記憶體空間，此外傳統的路由器是以軟體的處理方式轉送IP 封包，而MPLS的技術則是引用與ATM交換技術類似的標籤交換(Label Switching)技術，簡化了路由器的轉送功能直接利用Switching Fabric以線上速度(Line Speed)來轉送封包(Packet)到達目的地。

MPLS Label 的Format及插入Packet的位置

Label是一個4Bytes、固定長度、locally-significant identifier類似在ATM網路中VPI(Virtual Path Identifier)/VCI(Virtual Circuit Identifier)或是Frame-Relay網路中的DLCI(Data Link Circuit Identifier)，Label是被插入於Packet的第二層資料鏈結層(data link layer)與第三層網路層(network layer)Header之間。

MPLS Network 的組成

MPLS 網路是由多個具有標籤交換能力的路由器LSR(Label Switch Router)互相連結所組成，根據在MPLS網路內扮演角色的不同LSR可以分為三種類型：
(1) Ingress LSR：負責將進入MPLS網路的IP Packet貼上標籤(Push Label)
(2) Core LSR：LSR則位於MPLS網路的核心，負責做標籤轉換(Label Swap)
(3) Egress LSR：當封包要離開MPLS網路到一般IP網路時，負責去除標籤( Pop Label)。

Label Assignment and Distribution的過程

LSR Routing Table的建立：在MPLS網路中所有的LSR利用routing protocol來交換路由資訊，建立自己的IP Routing Table，並根據Routing Table 建立自己的FIB(Forwarding Information Base)，此時的FIB中並沒有Label的資訊。
LSR Allocating Label過程：當LSR路由器開始啟動MPLS功能時,會根據由IGP(如RIP、OSPF)學來的路由表(Routing Table)內容，對於使用相同處理方式、相同path、到達相同目的地IP subnet的Routing entry 做彙整(aggregation)及分類後Assign Label。
LSR 初步建立自己的LIB及LFIB：將前面步驟Allocating 的local Label資訊儲存於LIB(Label Information Base)和LFIB(Label Forwarding Information Base)中，此時的LFIB中只有local Label 的資訊並沒有outgoing Label 的資訊。
LSR Label Distribution過程：LSR將他Local assign的Label資訊傳送(Distribution)給相鄰的LSR，不論這相鄰的LSR是local LSR的downstream或upstream 都會傳送，而Label Distribution 靠的是相鄰的LSR間要執行LDP(Label Distribution Protocol)的協定，來互相交換彼此的Label資訊。另外談到LDP 的特性，MPLS Device 會send/receive LDP，LDP 透過Discovery 去和Neighbor溝通對方是否有啟動MPLS及交換Label information，而LDP是用UDP protocol去discovery neighbor,並利用 TCP 去去交換彼此Label information。
LSR收到相鄰LSR送來的Lable資訊做資訊的彙整過程：最後每個LSR 根據接收到相鄰LSR送來的Label 資訊後，新增這些Label資訊於自己的LIB中，並根據routing table得到的最佳路徑，獲知到某網段的Next-hop LSR 所送來的Label資訊，插入到LFIB的outgoing Label資料結構中。

Packet在MPLS網路中傳送的過程

Ingress LSR(Router A)：IP Packet 進入MPLS網路的第一顆LSR路由器稱為Ingress LSR，當IP Packet 進入Ingress LSR 首先會查看Packet中的Destination IP address，並且在FIB中lookup 是否有符合的IP network ，如果有則進一步查看FIB中相對應的Label欄位其值為何？(例如：IP =X ，Label=25 )，當Packet從Ingress LSR 送出時，會在此Packet中打上Label=25的標示，再傳送出去。
Core LSR (Router B)：當帶有Label=25的Packet傳到Router B時，Router B會查看(lookup)他的LFIB的資料，看看是否有Inbound Label=25的entry，如果有則再查看此entry中Outgoing Label的欄位值為何？(例如 Outgoing Label=47)，所以Packet中的Label快速的被置換(Label=25 aLabel=47)並往下一個節點傳送出去。
Egress LSR(Router C)：當帶有Label=47的Packet傳到Router C時，Router C會查看(lookup)他的LFIB的資料，看看是否有Inbound Label=47的entry，如果有則再查看此entry中Outgoing Label的欄位值為何？(例如 Outgoing Label=Pop)，所以Packet中的Label被移除，此時已離開MPLS網路再進入到IP的網路中，因此重新查看Packet中的Destination IP address為何？並查看其FIB以決定Packet要傳送的下一個節點。

在MPLS網路中Egress LSR double lookup的問題

由於Egress LSR不但要查看LFIB中的資料以便移除Packet 中的Label，而且還要查看FIB中的資料以決定將Packet往IP網路的下一個節點傳送，這樣的作法會使Egress LSR 的負擔太重，而且對傳送有Label的封包也不是最有效的方式。

Penultimate Hop Popping

所以解決的方式就是在原來Egress LSR前一個節點就把Label移除，最後一顆Router 只要做IP lookup 就好了，此種運作方式稱為Penultimate Hop Popping。

結語

本篇文章從一開始介紹傳統路由器在IP 路由傳送封包的運作缺點及描述發展MPLS技術的優勢，並且說明整個MPLS 技術的運作原理，從MPLS Label的format介紹及Label在封包標頭位置的解說，到整個MPLS網路中各個不同角色LSR的運作方式，在其中更詳細的探討Label 如何被Assignment及相鄰LSR之間如何交換彼此的Label Information的過程，另外更舉例說明封包在MPLS網路中從Push(加上)Label，一直到離開MPLS網路前Pop(去除)Label的詳細過程，最後則探討為何封包在離開MPLS網路的前一個節點(Hop)就要先Pop(去除)Label的原因。

Tech黑手 - 工作雜記

How to repair and clone disk with ddrescue

Clone a partition to image file or other disk

PFC优先级流量控制

无损与有损的概念

How to use simple speedtest in RaspberryPi CLI

How to decompile dtb file (Device Tree)

HGU – Supported Service Scenarios

1.Bridge mode – only INTERNET:1-4/WIFI + MGMT

2.Bridge mode – INTERNET:1-4/WIFI, VoIP Interface + MGMT

3.Bridge mode – INTERNET:1-2/WIFI, IPTV:3-4, VoIP Interface + MGMT

4.Router mode – only INTERNET:1-4/WIFI + MGMT

5.Router mode – INTERNET:1-4/WIFI, VoIP Interface + MGMT

6.Router mode – INTERNET:1-2/WIFI, IPTV:3-4, VoIP + MGMT

SFU – Supported Service Scenarios

1.Access mode – only Internet

2.Access mode – only IPTV

3.Transparent mode – Internet, IPTV, VoIP

4.VLAN translation – rBSA

5.802.1q in 802.1q Begin/End of Tunnel

6.Transparent 802.1q in 802.1q

7.OSE/MdO

OMCI協議二層功能的模型選擇

secure boot（三）secure boot的签名和验签方案

简介

签名算法

创建RSA key和证书

绑定设备树

pubkey的存储

签名方案

签名镜像+签名配置

验签

测试

完整校验流程

OTP校验loader

spl校验uboot

uboot校验kernel

总结

Basic bridge commands

Spanning Tree Protocol

VLAN filter

VLAN tunnel mapping

Multicast

Bridge switchdev

Bridging with Netfilter

Bridge ageing time

Bridging versus Open vSwitch

SecureCRT & Notepad++ 的 網路設備 關鍵字顯示 （Keyword Highlighting/Syntax highlighting）

下面是作者範例的截圖:(出處為作者github專案 https://github.com/click0/npp-udl )

Outlook-解除禁止存取可能不安全的附件

iOS 16 Beta downgrade 備份恢復問題

How do I scroll in tmux?

log可打timestamp 並直接顯示在螢幕的 termnal : extraputty

主機板廠牌與型號/Windows 10序號 提取command

主機板廠牌與型號直接開啟「Windows系統 → 命令提示字元」指令建議使用複製貼上：wmic baseboard get product,Manufacturer,version,serialnumber

Windows 10序號

PHY暫存器

Control Register (Register 0)

Status register

PHY Identifier Register

Auto-Negotiation Advertisement Register (Register 4) (R/W)

Link codeword encoding（基本鏈路碼字）

Next Page function

Auto-Negotiation Link Partner ability register (Register 5) (RO)

Auto-Negotiation Expansion Register (Register 6) (RO)

Auto-Negotiation Next Page transmit register (Register 7) (R/W)

Auto-Negotiation Link Partner Received Next Page register (Register 8) (RO)

GPON Type B保護

MACsec on Linux

SSH 命令的三種代理功能（-L/-R/-D）

常見以太網接口介紹

QoS中ToS和CoS的區別？802.1p、ip pri、dscp的區別？

from:https://blog.51cto.com/imccie/1750821

SMI（MDC/MDIO）介紹 Clause 22/45

arp_ignore 和 arp_filter

arp_ignore 和 arp_filter

VXLAN vs VLAN

from:https://zhuanlan.zhihu.com/p/36165475

VXLAN協議

為什麼要VXLAN？

SecureCRT & Notepad++ 的網路設備關鍵字顯示（Keyword Highlighting/Syntax highlighting）

下面是作者範例的截圖:
(出處為作者github專案 https://github.com/click0/npp-udl )

主機板廠牌與型號/Windows 10序號提取command

主機板廠牌與型號
直接開啟「Windows系統 → 命令提示字元」
指令建議使用複製貼上：
wmic baseboard get product,Manufacturer,version,serialnumber