本实验的逻辑拓扑如图：
关于该实验配置丢失后的排错：
因为笔者经常带笔记本干活，eNSP在未保存拓扑及设备配置后，笔记本断电后常会导致配置丢失，以下为笔者的自用笔记，用于重新配置。
1.开启CentOS（Zabbix Server）的zebra与ospfd服务。
2.所有设备需要配置SNMP。
3.三层交换机通过Vlanif201与Zabbix Server通信，心跳线为Trunk口，放行所有Vlan，与Zabbix Servers的端口default Vlan为201，且端口视图stp disable。
4.两台三层设备都与Zabbix Server，该表现形式（如拓扑图）为逻辑表现，实际上为三层设备各自与Cloud（Zabbix Server）相连，最后将两个Cloud叠合在一起。
——————————
接上文，该拓扑中SW1至SW8、出口路由器R1与R4已录入至Zabbix主机群组中。
其中设备的各个地址规则如下：
核心交换机地址为Vlanif 201，该接口用于与Zabbix Server通信，地址为192.168.201.x；
其余交换机地址为Vlanif 1000，即管理Vlan，用于被远程管理；
出口路由器R1地址为其连接核心交换机SW1的接口地址Gigabitethernet0/0/0；
分支站点路由器R4地址为连接出口路由器R1的接口地址Gigabitethernet0/0/0。
在R4的Gigabitethernet0/0/0上抓包：
时间显示格式采用为年、年积日、时间。
在抓包中主要有OSPF Hello包、SNMP包及ICMP包。
只查看ICMP包：
可以发现每隔一分钟，192.168.201.128（Zabbix Server）便会向 14.1.1.2（分支站点路由器R4）发送三个Ping包，用于检查如下三个状态/监控项：
ICMP loss、ICMP ping、 ICMP response time。
ICMP loss：
表达式：
{Template Module ICMP Ping:icmppingloss.min(5m)}>{$ICMP_LOSS_WARN} and {Template Module ICMP Ping:icmppingloss.min(5m)}<100
如果五分钟内的最小丢包率大于20%，则该触发器被触发。
（在“检测——最新数据”中，我们可以看到该值的单位为%）
ICMP ping：
表达式：
{Template Module ICMP Ping:icmpping.max(#3)}=0
如果当最后一次Ping的三个包全部丢失，则ICMP Ping的触发器会被触发，告知该设备不在线。
（Last three attempts returned timeout. Please check device connectivity.）
在正常情况下（最新数据）中，该值为Up（1）。
ICMP response time：
表达式：
{Template Module ICMP Ping:icmppingsec.avg(5m)}>{$ICMP_RESPONSE_TIME_WARN}
如果在五分钟内Ping的平均响应时间超过0.15s（即150ms），则该触发器被触发。
只查看SNMP包：
无非是192.168.201.128（Zabbix Server）与14.1.1.2（R4）之间的SNMP get-request包以及get-response包（当然也有getBulkRequest包）。
笔者推测这些SNMP的OID获取保证了该设备47个监控项的数据采集（其实应该是42个，因为Snmp Agent类型数量只有42个）。
监控项按应用集分类，General项6个，四个接口每个接口9个（依靠自动发现），Status项5个。
我们可以在Source为14.1.1.2（R4，被监控的设备），Destination为192.168.201.128（Zabbix Server）的SNMP get-response包中看到许多OID值，这些OID负责采集当前的监控项信息。在这里笔者不逐一查看OID。
