- 产品与解决方案
- 行业解决方案
- 服务
- 支持
- 合作伙伴
- 新华三人才研学中心
- 关于我们
目 录
在目前的Portal实际组网应用中，如果接入设备与Portal服务器的通信中断，会造成新用户无法上线，已经在线的Portal用户无法正常下线，设备和Portal服务器信息不一致带来的计费问题。
这些现象会给网络的使用者带来很大的不便。因此需要在Portal服务器无法正常工作的情况下，能够提供一种方式，让用户仍然可以正常使用网络，并通过日志和Trap的方式报告故障，也就是本文所述的Portal逃生方案。
Portal逃生方案实现以下两大功能：
l 周期性探测Portal服务器
通过可配置的探测方法（在下面提到有两种探测方式）周期性探测Portal服务器，若Portal服务器N次（N可配）不可达则变成Down状态（逃生状态），取消网络的认证限制，允许Portal用户不需经过认证即可访问网络资源，并发送状态改变的Trap信息和日志。当探测到服务器可达时，恢复服务器状态为Up状态（认证状态），并重新开启网络认证限制，不允许未认证的用户访问网络，并发送状态恢复的日志和Trap。
l 设备和Portal服务器同步用户信息
Portal服务器定时将自己的在线用户信息周期性地通过用户信息同步报文发送给接入设备。如果同步报文中包含了设备上不存在的的用户信息，则接入设备会将这些用户信息返回给Portal服务器，由Portal服务器将其强制下线。如果某用户连续N个周期（N可配）都未在从Portal服务器发送过来的同步报文中出现，则接入设备会将该用户强制下线。
l 当Portal服务器不可达或者Portal服务不能正常工作时，设备可以临时放开对用户访问网络的认证限制，不中断或停止用户的正常网络访问，当Portal服务器恢复后，设备再恢复为正常认证状态，减少了服务器故障给用户业务带来的影响。
l 用户信息同步功能提供了一种同步机制，使得Portal服务器和设备上的用户信息保持周期性同步，避免了因为服务器断开而造成用户长时间无法下线的问题。
接入设备探测Portal服务器状态的具体实现方式有以下两种：
l 探测HTTP连接：接入设备定期向Portal服务器的HTTP服务端口发起TCP连接。若连接成功建立则表示此服务器的HTTP服务已开启，就认为一次探测成功且服务器可达（状态为Up）；若连接失败则认为一次探测失败。
l 探测Portal心跳报文：支持Portal逃生心跳功能的Portal服务器（目前仅iMC支持）会定期向接入设备发送Portal心跳报文，设备通过检测此报文来判断服务器的可达状态：若设备在指定的周期内收到Portal心跳报文或者其它认证报文，且验证其正确，则认为此次探测成功且服务器可达（状态为Up），否则认为此次探测失败。
在实际应用中，支持只采用其中一种探测方式或同时采用两种探测方式。如果同时采用了两种探测方式，则只要其中任何一种探测方式结果表明服务器不可达，即认为服务器不可达。而在服务器不可达状态下，只有采用两种探测方式的探测都成功后才能认为服务器恢复为可达状态。
通过命令行可以配置每次探测之间的时间间隔，此间隔称为探测周期。一次探测失败并不一定认为服务器不可达，而需要查看连续探测失败的次数是否达到配置的最大探测失败次数，若达到此值则认为服务器不可达，否则只是累加，当某此探测成功后，此值会自动清零。
若探测结果标明某Portal服务器可达状态发生了变化，则接入设备可触发执行相应的操作来应对这种变化带来的影响，具体包括以下三种：
l 发送Trap：Portal服务器可达或者不可达的状态改变时，向网管服务器发送Trap信息。Trap信息中记录了Portal服务器名以及该服务器的当前状态。
l 发送日志：Portal服务器可达或者不可达的状态改变时，发送日志信息。日志信息中记录了Portal服务器名以及该服务器状态改变前后的状态。
l 打开网络限制（Portal逃生）：Portal服务器不可达时，暂时取消端口进行的Portal认证，允许所有Portal用户访问网络资源。之后，若设备收到Portal服务器的心跳报文，或者收到其它认证报文（上线报文、下线报文等），则恢复该端口的Portal认证功能。
在实际应用中，支持同时配置的多种操作并发执行。
假设接入设备上同时开启了两种方式的服务器探测功能，且Portal服务器上启用了针对该接入设备的Portal逃生心跳功能，具体的探测过程如下图所示。
图 1 Portal服务器探测过程示意图
互为备份的两台接入设备均开启Portal服务器探测功能，只要有一端探测成功（探测到服务器状态可达），就将此消息通知对端，对端收到消息后也认为此次探测成功。
Portal服务器定期将自己的在线用户信息通过用户信息同步报文发送给设备。该用户信息同步报文中包含了Portal服务器上记录的当前在线用户的IPv4地址，一个报文最多可以包含630个用户的IP地址。
接入设备周期性地对同步报文进行检测，检测到该用户信息同步报文后，将自己本地保存的用户信息与其内容进行对比，具体处理过程如下：
l 如果发现同步报文中有设备上不存在的用户信息，则认为这些用户在服务器上多余，并通过响应报文将这些用户信息发送给Portal服务器。
l 如果同步报文中的用户信息在设备上都存在，则设备不对该同步报文进行响应，只是将这些用户标记为已同步，对于不在同步报文中的用户不置同步标记，并认为一次同步失败。
通过命令行可以配置设备检测用户信息同步报文的时间间隔，此间隔称为检测间隔。用户的一次同步失败并不一定代表该用户在设备上多余，而需要查看连续同步失败的次数是否达到配置的最大检测失败次数，若达到此值则认为该用户多余，否则只是累加，当某次同步成功后，此值会自动清零。
设备上多余的用户信息在用户的同步失败次数达到最大值后删除，Portal服务器上多余的用户信息在每次同步报文交互后被服务器删除。通过这种机制，设备与服务器的用户信息保持了一致。
假设接入设备上配置了Portal用户信息同步功能，且Portal服务器上启用了针对该接入设备的Portal用户心跳功能，具体的同步过程如下图所示。
图 2 Portal用户信息同步过程示意图
l 只有对于支持Portal逃生心跳功能（目前仅iMC的Portal服务器支持）的Portal服务器，探测Portal心跳报文类型的探测方法才有效。为了配合此类型的探测，还需要在Portal服务器上选择支持逃生心跳功能，且服务器上配置的逃生心跳间隔要小于等于设备上配置的服务器探测间隔。类似，Portal用户信息同步功能也需要Portal服务器的配合：需要在Portal服务器上选择支持用户心跳功能，且服务器上配置的用户心跳间隔要小于等于设备上配置的用户同步报文检测间隔。
l 对于本地Portal服务器或不支持Portal逃生心跳功能的Portal服务器，只能采用探测HTTP连接的探测方式进行探测。
l 在Portal双机热备运行过程中，对于普通用户，若在连续指定的最大次数内未被同步，设备会将其强制下线，但对于处于双机协同状态的用户，设备不会将其强制下线。
H3C实现的Portal逃生方案与业界其它方案相比，不仅实现了接入设备可根据服务器的状态变化来开启或关闭Portal认证的功能，还可以允许Portal服务器功能恢复正常后，之前已经在线的用户不必重新认证就能直接上线。
图 3 Portal逃生典型组网图
用户通过Device上的Portal认证接入网络，并采用RADIUS服务器作为认证/计费服务器。
具体要求如下：
l 用户在通过Portal认证前，只能访问Portal服务器；在通过Portal认证后，可以使用此IP地址访问非受限的互联网资源。
l 接入设备能够探测到Portal服务器是否可达，并输出可达状态变化的Trap信息，在服务器不可达时（例如，网络连接中断、网络设备故障或服务器无法正常提供服务等情况），取消Portal认证，使得用户仍然可以正常访问网络。
l 接入设备能够与服务器定期进行用户信息的同步。
售前咨询
售后咨询
人工在线咨询
