RFC2544

Throughput:
    a. Specific rate
    b. Specific frame size
    c. Binary Search ( Fail = Reduce the rate)
    d. Result = Maximum rate ( frames/second or bits/second)

Latency:
    a. Maximum rate (Result of throughput testing)
    b. Specific corresponded frame size
    c. Option:
        c-1 Store and Forward (LIFO)
        c-2 Bit Forwarding (FIFO)
        c-3 Cut Through (LILO)
    d. Result =>time interval
       
Frame Loss Rate:
    a. Specific maximum rate (100% Utilization)
    b. Specific frame size
    c. Binary Search (Fail = Reduce the maximum rate (10% interval))
    d. Result: Frame loss rate (%)

Back-to-Back:
    a. Minimum inter-frame gap
    b. Send a specific number of frames
    c. Binary Search (Reduce the length of burst)
    d. Result: Frame count

設定 Wireshark 解析無法被預設設定解析出來的封包

有時候我們改變 RFC 定義預設的 port number，Wireshark 就無法解析用預設的設定解析出封包。這時候我們可以在該封包上點滑鼠右鍵，選 Decode as，指定我們想要的 Protocol 解析方式，就可以看到原來 Protocol 應該顯示的欄位。

http://www.wireshark.org/docs/wsug_html_chunked/ChCustProtocolDissectionSection.html#ChAdvDecodeAsFig

SNMPv3 engine-id discovery

節錄自 RFC3414

4. Discovery
   The User-based Security Model requires that a discovery process
   obtains sufficient information about other SNMP engines in order to
   communicate with them.  Discovery requires an non-authoritative SNMP
   engine to learn the authoritative SNMP engine’s snmpEngineID value
   before communication may proceed.  This may be accomplished by
   generating a Request message with a securityLevel of noAuthNoPriv, a
   msgUserName of zero-length, a msgAuthoritativeEngineID value of zero
   length, and the varBindList left empty.  The response to this message
   will be a Report message containing the snmpEngineID of the
   authoritative SNMP engine as the value of the
   msgAuthoritativeEngineID field within the msgSecurityParameters field.  It contains a Report PDU with the usmStatsUnknownEngineIDs
   counter in the varBindList.
   If authenticated communication is required, then the discovery
   process should also establish time synchronization with the
   authoritative SNMP engine.  This may be accomplished by sending an
   authenticated Request message with the value of
   msgAuthoritativeEngineID set to the newly learned snmpEngineID and
   with the values of msgAuthoritativeEngineBoots and
   msgAuthoritativeEngineTime set to zero.  For an authenticated Request
   message, a valid userName must be used in the msgUserName field.  The
   response to this authenticated message will be a Report message
   containing the up to date values of the authoritative SNMP engine’s
   snmpEngineBoots and snmpEngineTime as the value of the
   msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime fields
   respectively.  It also contains the usmStatsNotInTimeWindows counter
   in the varBindList of the Report PDU.  The time synchronization then
   happens automatically as part of the procedures in section 3.2 step
   7b.  See also section 2.3.

Stateful DHCPv6、Stateless DHCPv6、and Stateless Autoconfiguration

Router Advertisement Option 當中的 M 欄位與 O 欄位。

1. M 欄位 (Managed Address Configuration)：
這個 bit 如果是 1，代表要請電腦另外透過 DHCPv6 要 IPv6 Prefix

2. O 欄位 (Other Configuration )：
這個 bit 如果是 1，代表請電腦另外透過 要 DNS 等等資訊。

我們常聽到的 stateful DHCPv6 與 stateless DHCPv6，就是由 M 欄位與 O 欄位組合不同而來的。

1. M=1, O=0 or 1：所有資訊(包括 Prefix、DNS等等資訊)都請電腦使用 DHCPv6 取得。(Stateful DHCPv6)
2. M=0, O=1：使用 RA 裡面的 Prefix，但是 DNS 等等資訊請電腦使用 DHCPv6 取得。(Stateless DHCPv6)
3. M=0, O=0：電腦將只得到 Prefix，無法取得 DNS 等資訊。(Stateless autoconfiguration)

所謂的 stateful 就是必須要由 server 去動態維護、保留其對應狀態的資訊。
而 stateless 則是不須動態維護的資訊，如 DNS 等資訊，因為這些不會動態改變，都是固定的資訊。
所以當 prefix 由 DHCPv6 來提供的時候，因為 DHCPv6 server 會有對應表(binding table)，所以這種就叫 stateful DHCPv6。
而 prefix 是由 router 提供，因為 router 不會留存這個 binding table，所以這種方式就叫做 stateless autoconfiguration or stateless DHCPv6。

IPv6 Neighbor Discovery (ND) Summary

1. ND 是藉由 ICMPv6 在 hosts 和 routers 間傳送資料

2. 共分為 5 種 type 的 ICMPv6 message：
a. Router Solicitation / Router Advertisement
b. Neighbor Solicitation / Neighbor Advertisement
c. Redirect message

3. 可達到下列功能
a. Neighbor Discovery (ND)
b. Router Discovery (RD)
c. Address Autoconfiguration
d. Address Resolution
e. Neighbor Unreachability Detection (NUD)
f. Duplicate Address Detection (DAD)
g. Redirection

在 IE 瀏覽器上輸入 IPv6 Link Local Address 為 URL 時的注意事項

因為當使用 IPv6 Link local Address 來連線時必須要指定連線使用的 NIC (Network Interface Card )。

假設我要透過第一張 NIC 連線到 "fe80::02E0:0CFF:FE11:2233"，
我必須要以 "fe80::02E0:0CFF:FE11:2233%1" 來表示。

但是 IE 在處理 URL 時遇到 % 會出現編碼問題，所以我必須在 % 後加上 25，
也就是 "http://[fe80::02E0:0CFF:FE11:2233%251]" 來表示。

Reference:
IPv6 URIs in IE7
ASCII Table and Description

ARP Operation (Local network v.s. Remote network)

http://www.tildefrugal.net/tech/arp.php

在這篇文章中，可以了解在送出封包之前，會根據下列的過程決定 ARP 封包要往哪邊送：

1.   先拿 Destination IP Address 跟 Subnet Mask 比對
a. 同網段
b. 不同網段

2. 同網段
a. 先在本身的 ARP Table 中找尋是否有  Destination IP Address 對應的 MAC Address 記錄
b. 有，直接送出資料封包
c. 沒有，發出廣播 ARP 封包徵詢 Destination IP Address 的 MAC Address

3. 不同網段
a. 將 ARP 封包夾帶 Destination IP Address，和 Default Gateway 的 MAC Address 送往 Default Gateway
b. 接下來沿路的節點會不斷透過 Destination IP Address 與 Subnet Mask 的比對，決定要將 ARP 封包送往本身連接的網段還是下一個 Router
c. 送往 Router 本身連接的網段，發出廣播 ARP 封包徵詢 Destination IP Address 的 MAC Address
d. 送往下一個 Router，將 ARP 封包夾帶 Destination IP Address，和 下一個 Router 的 MAC Address 送往下一個 Router
e. 重複 b ~ d


PS.
1. 可是我看不出來最終取得 Destination IP Address 對應的 MAC Address 後的後續動作是什麼？
2. 再補一份參考資料 TCP/IP Address Resolution Protocol (ARP)

網路數學

上禮拜四去汐止的廣聯上課，有些觀念又重新理了一下。

1. 在網路傳輸的環境下，資料量應該用 bit 來表示


2. 在網路傳輸中 Giga、Mega、Kilo 間換算用 1000 而不是 1024

PS. 所以 1Mb => 1000Kb => 1000000b


3. 不同頻寬下 Packet/Sec 的計算方式

100Mbps: Packets/sec=(100*1000*1000)/(Preamble+IFG+Packet Size)

PS. 調整 Utilization 變動的是總封包量 Packets/sec 來反推其他變數

原來不是每個 Chip 都支援 VLAN ID 0 ~ 4093

搞了我半天的問題，

完全沒思考到這個方向 Orz。

Priority tag

昨天看 test plan 發現要測 priority tag 的 traffic forwarding，

花點時間查一一下這是什麼東西



page 25 of the IEEE Std 802.1Q-2005

##

3.23 Priority-tagged frame: A tagged frame whose tag header carries priority information but carries no VLAN identification information.

##



另外在網路上爬到的



http://www.devicescape.com/docs/wip/package_guide/pkg_ieee80211.php#wp157858



##

802.1q Priority Tag Setup



Out of the box Linux 2.4 and 2.6 support 802.1q tags for vlan-id. They do not support 802.1q priority tags - i.e. tags where that vlan-id is set to 0, and the tag is used just to add priority information to the frame. Devicescape adds 802.1q priority tag support through the ebtables strip1q extension. Ebtables is a mechanism which allows packets to be inspected and processed during various stages of forwarding through a Linux Bridge. All packets received on a linux bridge pass through the 'broute chain' before any other processing. To use the strip1q module you add it to the broute chain or nat chain on a Linux bridge that will be forwarding 802.1q priority tagged frames. This command does this:



$ ebtables -t broute -A BROUTING -p 802_1Q --vlan-id 0 -j strip1q



Note



You must use the provided version of the ebtables user space command. This version has been extended to support the strip1q target.



This command registers the Devicescape strip1q module to be called for all frames received on the bridge which have an Ethernet protocol of 802_1Q (as all 802.1q tagged frames do), and where the vlan-id is equal to 0. When the strip1q module receives one of these frames it removes the 802.1q tag from the frame, while recording the priority from the tag in the skb->priority field. The now untagged frame is forwarded by the bridge appropriately. The value in the skb->priority field can be used later on when the frame reaches the 802.11 qdisc to select which wireless hardware queue to use to transmit the frame.



By default the strip1q modules maps 802.1q priority values (0-7) to skb->priority values of 256->263.

##



但是我還不知道這東西在真實環境中會被用在啥地方 =.=