路由器内的三条信息流：路由信息、过境数据与本地报文

路由器既学习路由，也转发数据，但这不表示两件事都在处理同一种内容。Juniper的《Router Data Flow Overview》分别列路由信息流、数据报文流与本地报文流。顺着原文的对象阅读，可以看清路由表里的信息怎样与实际通过接口的报文相联系，以及为什么还有一类报文以路由器自身为一端。

路由信息来自路由协议从相邻路由器学到的路线，保存在路由表中。原文将active route解释为从表内各路线中选出的、用于到达一个目的地的路线；协议从路由表通告的也是活动路线。这一段的中心是路线的学习、存储与通告，而不是一份用户数据已经从某个端口离开。

Routing Engine运行控制平面软件，处理路由协议与路由表之间，以及路由表与转发表之间的信息流。文档还说它运行Junos OS，并保存主路由表和主转发表。表的形成与保存由此有了所在环节，不能将路由引擎只写成一个抽象的“管理部件”，忽略它与后续转发依据的联系。

过境的数据报文则从一个来源经路由器向目的地转发。设备从接口收到报文后，查转发表寻找通向目的地的路线，再经相应接口发出。原文把Packet Forwarding Engine称作转发平面的中央处理部件，由它处理报文进出物理接口的流动。这里关注的是已经到达设备、需要继续前行的数据，与前段学习路线的信息有所区别。

本地报文的界定不依赖报文大小，而依赖其一端是谁：它们目的地为路由器，或由路由器发出。原页举路由协议、IP服务与管理协议的数据作为通常例子。路由引擎收到这类报文，会交给相应进程、内核，或转发引擎。因此，“本地”并不是说它没有经过物理接口，而是在说明报文与路由器自身的关系。

最后一节把两类主要流程重新相连：路由信息的处理决定哪些路线进入转发表，转发表又参与决定数据报文应经哪个物理接口继续转发。前者形成依据，后者使用依据，这就是文档所说不同流程之间的相互依赖。将它们分开介绍，仍应保留这项联系，不能把控制与转发写成互不相干的两个系统。

本篇只采用三流定义与相互关系的连续文字，首次发布日期未知。没有观看示意图、运行设备或采用过滤器、带宽控制与配置说明，也不判断吞吐或网络安全。其用途是让路由器资料中的路线、表、报文和处理部件各自具有清楚的对象。