Ethernet keepalive 信息

偶然抓包看到wireshark定义协议名称为LOOP

Ethertype为0x9000，见下图：

测试了一下，主要起作用的是接口配置keepalive；可以手动修改间隔时间0～32767；

在no keepalive 之后，接口不检测端口的UP/DOWN，协议始终保持UP；

在keepalive时间改短之后，接口可以更迅速做出变化，从而影响上层协议（这条只是推理，模拟器有问题）。

WIKIpedia的解释如下：

Ethernet Configuration Testing Protocol is a diagnostic protocol included in the Xerox Ethernet II specification.^[1] Functionality of the protocol is similar to that offered by ping but it operates at the data link layer as opposed to the network layer. Ethernet Configuration Testing Protocol was implemented on DEC hosts and Cisco routers.

CISCO的文档对几种Keepalive的解释如下：

Common Keepalive Mechanisms

Keepalive messages are sent by one network device via a physical or virtual circuit to inform another network device that the circuit between them still functions. The keepalive interval is the period of time between each keepalive message that is sent by a network device. The keepalive retries is the number of times that the device continues to send keepalive packets without response before the interface is brought down.

Ethernet Keepalives

On broadcast media like an Ethernet, keepalives are slightly different. Since there are many possible neighbors on the Ethernet, the keepalive is not designed to determine if the path to any one particular neighbor on the wire is available. It is only designed to check that the local system has read and write access to the Ethernet wire itself. The router produces an Ethernet packet with itself as the source and destination MAC-address and a special Ethernet type code of 0x9000. The Ethernet hardware sends this packet onto the Ethernet wire and then immediately receives this packet back again. This checks the sending and receiving hardware on the Ethernet adapter and the basic integrity of the wire.

HDLC Keepalives

Another well known keepalive mechanism is serial keepalives for HDLC. Serial keepalives are sent back and forth between two routers and the keepalives are acknowledged. With the use of sequence numbers, each router keeps track of the keepalive packets sent and acknowledged. In this way, the remote routers look at each others keepalives and track if the keepalives they send are received.

As an illustration of how serial keepalives work, Router 1 and Router 2 are directly connected via Serial0/0 and Serial2/0 respectively. In the Router 1output, Serial 0/0 is shut down purposely. This causes Router 2 to miss three keepalives in order to illustrate how this failure causes Router 2 to shut down Serial2/0 when keepalives are missed.

This is sample output from the debug serial interface command for an HDLC connection when keepalives are enabled. When the difference in the values in the myseq and mineseen fields exceeds 3 on Router 2, the line goes down and the interface is reset.

Router 1

17:21:09.685: Serial0/0: HDLC myseq 0, mineseen 0*, yourseen 1, line up 17:21:19.725: Serial0/0: HDLC myseq 1, mineseen 1*, yourseen 2, line up 17:21:29.753: Serial0/0: HDLC myseq 2, mineseen 2*, yourseen 3, line up 17:21:39.773: Serial0/0: HDLC myseq 3, mineseen 3*, yourseen 4, line up 17:21:49.805: Serial0/0: HDLC myseq 4, mineseen 4*, yourseen 5, line up 17:21:59.837: Serial0/0: HDLC myseq 5, mineseen 5*, yourseen 6, line up 17:22:09.865: Serial0/0: HDLC myseq 6, mineseen 6*, yourseen 7, line up 17:22:19.905: Serial0/0: HDLC myseq 7, mineseen 7*, yourseen 8, line up 17:22:29.945: Serial0/0: HDLC myseq 8, mineseen 8*, yourseen 9, line up Router1 (config-if)#shut 17:22:39.965: Serial0/0: HDLC myseq 9, mineseen 9*, yourseen 10, line up 17:22:42.225: %LINK-5-CHANGED: Interface Serial0/0, changed state to administratively down 17:22:43.245: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to down

Router 2

*Sep 24 17:21:04.929: Serial2/0: HDLC myseq 0, mineseen 0, yourseen 0, line up *Sep 24 17:21:14.941: Serial2/0: HDLC myseq 1, mineseen 1*, yourseen 1, line up *Sep 24 17:21:24.961: Serial2/0: HDLC myseq 2, mineseen 2*, yourseen 2, line up *Sep 24 17:21:34.981: Serial2/0: HDLC myseq 3, mineseen 3*, yourseen 3, line up *Sep 24 17:21:45.001: Serial2/0: HDLC myseq 4, mineseen 4*, yourseen 4, line up *Sep 24 17:21:55.021: Serial2/0: HDLC myseq 5, mineseen 5*, yourseen 5, line up *Sep 24 17:22:05.041: Serial2/0: HDLC myseq 6, mineseen 6*, yourseen 6, line up *Sep 24 17:22:15.061: Serial2/0: HDLC myseq 7, mineseen 7*, yourseen 7, line up *Sep 24 17:22:25.081: Serial2/0: HDLC myseq 8, mineseen 8*, yourseen 8, line up *Sep 24 17:22:35.101: Serial2/0: HDLC myseq 9, mineseen 9*, yourseen 9, line up *Sep 24 17:22:45.113: Serial2/0: HDLC myseq 10, mineseen 10*, yourseen 10, line up *Sep 24 17:22:55.133: Serial2/0: HDLC myseq 11, mineseen 10, yourseen 10, line up *Sep 24 17:23:05.153: HD(0): Reset from 0x203758 *Sep 24 17:23:05.153: HD(0): Asserting DTR *Sep 24 17:23:05.153: HD(0): Asserting DTR and RTS *Sep 24 17:23:05.153: Serial2/0: HDLC myseq 12, mineseen 10, yourseen 10, line up *Sep 24 17:23:15.173: HD(0): Reset from 0x203758 *Sep 24 17:23:15.173: HD(0): Asserting DTR *Sep 24 17:23:15.173: HD(0): Asserting DTR and RTS *Sep 24 17:23:15.173: Serial2/0: HDLC myseq 13, mineseen 10, yourseen 10, line down 17:23:16.201: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/0, changed state to down Router2# 17:23:25.193: Serial2/0: HDLC myseq 14, mineseen 10, yourseen 10, line down

GRE Tunnel Keepalives

The GRE tunnel keepalive mechanism is slightly different than for Ethernet or serial interfaces. It gives the ability for one side to originate and receive keepalive packets to and from a remote router even if the remote router does not support GRE keepalives. Since GRE is a packet tunneling mechanism for tunneling IP inside IP, a GRE IP tunnel packet can be built inside another GRE IP tunnel packet. For GRE keepalives, the sender pre-builds the keepalive response packet inside the original keepalive request packet so that the remote end only needs to do standard GRE decapsulation of the outer GRE IP header and then forward the inner IP GRE packet. This mechanism causes the keepalive response to forward out the physical interface rather than the tunnel interface. This means that the GRE keepalive response packet is not affected by any output features on the tunnel interface, such as 'tunnel protection ...', QoS, and so forth. ).

Note: If an inbound ACL on the GRE tunnel interface is configured, then the GRE tunnel keepalive packet that the opposite device sends must be permitted. If not, the opposite device's GRE tunnel will be down. (access-list <number> permit gre host <tunnel-source> host <tunnel-destination>)

Another attribute of GRE tunnel keepalives is that the keepalive timers on each side are independent and do not have to match. The problem with the configuration of keepalives only on one side of the tunnel is that only the router that has keepalives configured marks its tunnel interface as down if the keepalive timer expires. The GRE tunnel interface on the other side, where keepalives are not configured, remains up even if the other side of the tunnel is down. The tunnel can become a black-hole for packets directed into the tunnel from the side that did not have keepalives configured. In a large hub-and-spoke GRE tunnel network, it might be appropriate to only configure GRE keepalives on the spoke side and not on the hub side. This is because it is often more important for the spoke to discover that the hub is unreachable and therefore switch to a backup path (Dial Backup for example).