2020年11月17日 星期二

GPON Type B保護

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端口沒有進行倒換。

2020年11月10日 星期二

MACsec on Linux

 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.

 

linux_macsec_single

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:

2020年9月18日 星期五

SSH 命令的三種代理功能(-L/-R/-D)

 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年7月16日 星期四

常見以太網接口介紹

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

一. 
PHY包含的各個子層

PCS:編碼和解碼
PMA:串行器和反序列化器
PMD:取決於物理介質
Firgure 1: OSI模型裡示意圖:
Firgure 2: 實際互連示意圖:


二. 以太網上常見的MAC 與PHY 之間的接口( 按照速度區分)
  1. 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連接示意圖:

  1. 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等
  1. 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口;

GPON Type B保護

from:https://blog.csdn.net/derek_yi/article/details/8743146  GPON TYPE B保護的組網圖如 圖1 所示,相應的保護範圍包括OLT的主用和備用PON端口,主用和備用光纖。 場景一:PON口工作過程中主用光纖斷,如 ...