RFC2453 RIP

RFC2453 

3.8定时器

本章主要讲述由定时器产生的触发事件。

每30s,RIP进程会被唤醒，发送响应消息给所有的邻居路由，其中包含整个路由表。当在单一网络中存在很多路由器的时候，有一种倾向是等到彼此同步，比如同时更新的时候。如果在30s的时候发生同步更新，这样会导致整个网络负担重。不希望更新消息变成同步，因为这样会导致在广播网络中会存在不可避免的冲突。因此实现者需要注意以下两个事项：

3.9输入流程

该章节将描述从RIP端口接收到数据报文的处理。处理的流程取决于特定区域的值。

3.9.1 请求消息

请求消息是用来要求路由表中某个端口或所有端口的响应。一般说来，请求消息以广播的方式发送（RIP-2是多播）,同时消息来自那些路由器中刚刚UP，为了尽快填充路由表的端口。然而，在某些情况下，路由表中只有一个路由是需要的。在这种情况下，请求消息应该从UDP的端口直接发送到改路由器，而不是从RIP端口发出。如果这样的请求消息接收到，路由器应该直接响应请求者的地址和接口。

请求消息是一条一条的处理。如果没有任何条目，也不会有任何回应。只有一种特殊的情况，如果请求消息中只有一个条目，且其地址为全0，metric为无效，这个请求是请求整个路由表。在这种情况下，调用输出流程，输出整个路由表项到请求的地址或接口。除了这种特殊的情况，请求处理流程非常简单。一条条的检查请求的RTES，对于每个条目，如果有路由，将路由的metric填入到RTE的metric中。如果不存在到指定地址的显示路由，metric置为无效。一旦所有的条目都填入完成，从请求处理变为响应处理，然后发送数据岛响应器。

记住，在整个路由表请求中metric的处理有点特殊。如果请求的是整个路由表项，常规的输出流程处理，包括水平分割。如果请求的是指定条目，需要在整个路由表中进行查找，返回的信息是没有水平分割流程的处理。产生这样差别的原因是，请求是出于不同的目的。当路由器第一次UP的时候，项所有连接的网络发送组播报文，请求完整的路由表。这是假定这些完整的路由表可以用来更新请求者的路由表，因此，水平分割是必须要做的。然而对于请求特定网络是仅来自诊断软件，而不是用于路由，在这种情况下，请求者只是想知道当前网络的连接状态，而不是隐藏或修改某些信息。

3.9.2 响应报文处理

响应报文可以来自以下不同原因的一种：

响应特殊的查询；

常规更新(不请自来的响应)；

路由变化触发的更新；

不管响应报文是由那种情况触发的，其处理的流程是一样的。

因为处理响应报文可能会更新路由表，因为需要仔细检查响应报文的有效性。如果报文不是来自RIP端口，响应报文忽略不处理。报文的IPv4源地址必须检查其是否来自有效的邻居；报文必须来自直连的网络。同时也需要检查报文是否来自于本地路由地址。在广播域中的接口可能会收到拷贝自己的广播/多播报文。如果路由器讲自己的输出又当做输入，那么这种会引起混淆的数据报文就必须忽略掉。

一旦整个报文检查有效，那么开始一个个的处理响应报文。再次开始有效性检查。不正确的度量和其他格式错误通常表示不正确行为的邻居，需要引起管理员的认识。例如：如果度量比无穷还大，忽略此条目，但是记录该事件。基本有效性检查包含以下内容：

1.地址有效性检查：单播地址、非全0地址或127；

2.度量有效性检查：在1-16之间，

如果任何检查失败，忽略该条目处理下一个，记录错误是很好的想法。

一旦条目经过检查是有效的，通过增加消息达到网络所需要的成本来更新度量。如果度量值比无穷大，那么使用无穷，其计算公式为：

metric = MIM(metric+cost,无穷)

现在开始检查对于目的地址，是否存在指定的路由。如果不存在指定的路由，那么将该路由添加到路由表中，除非该度量是不可达。添加路由到路由表包含以下内容：

1.将目的地址填入到RET的目的地址中；

2.将计算所得的新metric填入；

3.设置下一跳地址为数据报文中携带路由的地址；

4.初始化路由的超时时间，如果该路由的回收定时器正在运行，关闭这个定时器。

5.设置路由的改变标志位；

6.信号的输出过程触发了更新。

如果一个路由，将该路由的下一跳地址与从数据报中携带路由的地址进行比较，如果相同，重新初始化超时定时器。然后再比较metric，如果路由一样，但是新的metric与旧的metric不一样，或新的metric比旧的要小，执行以下操作：

1.采用来自数据报中的路由（如果必要的话，填入新的metric，调整下一跳地址。

2.设置路由变化标志位，信号输出流程触发更新；

3.如果新的metric是无穷，开始删除流程，否则重新初始化超时定时器。

如果新的metric是无穷，路由开始执行删除流程，该路由不再用于数据报文。注意，只有当metric第一次设置为无穷大的时候，才开始执行删除流程。如果metric已经设置为无穷，那么不需要开启新的删除流程。

如果新的metric和旧的一样，那这是最简单的，什么都不需要做,但是有关启发式的操作需要使用。通常，新的路由与已经存在的路由完全相同，并且新的路由取代已经存在的路由，那样的操作是毫无意义的，这会导致路由的震荡，触发难以忍受的更新。然而，如果现有路由出现超时的迹象，其最好的方式立即切换到相同的其他路由上，而不是等待超时的发生。因此当新的metric与已有路由的一样时，检查已经存在路由的超时定时器，如果超时定时器少于一半，那就切换到新的路由。这种启发式操作是可选的，但是强烈建议这样操作。

任何经过以上测试失败的条目都被忽略掉，因为它不是优于当前路由条目的。

3.10 输出处理流程

该章节主要描述如何创建返回消息的流程，包含所有或者部分的路由表项。该流程可能会按照以下的方式触发出路。

在输入处理流程中，当一个请求接收到后(响应是单播到请求者）

在常规路由更新流程（每30s广播/组播)

在触发更新（当路由变化）

当响应报文发送到所有邻居，响应报文直接发送到所有端到端连接的最远处，在支持广播的所有连接网络中进行广播。因此，一个响应报文需要为所有直连的网络准备，并发送到合适的地址。在大多数情况下，响应报文会到达所有的邻居路由器。然而，在有些情况下，这样可能不好。这包含了不支持广播的网络，或者不可用的路由器。在这种情况下，必须指定实际连接的路由器，然后发送报文到每个显示的路由。这是留给是现在去决定应该选择何种机制，列表如何指定。

3.10.1 触发更新

触发更新需要特殊处理有两个原因：第一，经验显示，触发更新可能会导致有限资源的网络过多负荷。因此，协议规定要求实现者限制触发更新的频率。在一个触发更新发出后，定时器必须设置在1到5s内的任意数。如果在定时周期到期前，触发更新有其他变化，也要等到定时器到期后才触发新的更新，定时器也重新设置。如果常规更新即将发出，那么触发更新需要抑制。

第二，触发更新不需要包含所有的路由表项。原则上，只有那些发生变化的路由才需要包含上。因此，部分路由触发更新产生的消息，至少需要设置上路由改变标签。这样在是实现者的描述中，会包含其他额外的路由。因此发送整个路由更新时强烈禁止的。当触发更新在处理的时候，消息必须为所有直连的网络产生。触发更新和常规更新一样，都会进行水平分割的处理。如果在给定的网络中，经过水平分割的处理后，变化的路由和没有变化的路由将区分开来，没有变化的路由将不需要发送。如果在该网络中没有路由发送，那么更新流程取消。一旦所有的更新触发已经产生，那么路由改变的标志需要清除。

如果当输出流程正在处理，而输入流程也是允许的，那么需要合适的锁机制。当触发更新消息产生的时候，作为输入处理结果的路由改变标签不能改变。

触发更新和其他更新消息的仅有区别在于：可能遗漏的路由没有改变。剩余的机制将在下一章节描述。

3.10.2 产生响应消息

本章主要描述直连网络的回应消息如何产生。

RIP的版本号，要么是1，要么是2。版本号的决定是由实现者指定的。如果是回应请求，那么回应的版本就要和请求的版本一致。设置命令响应，设置标志为0，开始填入RTES。响应消息最大只能包含25个RTEs,如果更多，需要重新建一个新的。没有明确限制数据报的数量。

为了填入RTEs,路由表中的每个路由都需要检查。如果一个触发更新已经产生，只有路由标签改变的才需要包含进去。如果在水平分割检查之后，路由条目不能包含进去，需要忽略掉。如果路由条目包含进去，那么目的地址和metric都要填入到RTEs中。即使路由的metrics是无效的，也要包含到响应数据报中。