不同版本的linux系统的arp缓存数量不同，数量默认存放在/proc/sys/net/ipv4/neigh/default/gc_thresh3配置文件中，修改后，重启系统生效。
arp缓存数量不足，会导致很多问题，参见：深信服防火墙AF上arp表数量限制导致网络问题的处理说明。
关于更多的arp缓存说明，可以参考：https://vincent.bernat.ch/en/blog/2011-ipv4-route-cache-linux，https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk43772
现有一台深信服防火墙AF，内网口上启用多个vlan接口，每个vlan接口为该各自网段的网关，测试时总用户数大概在2000左右，正式上线后总用户数在7000左右。
测试时，使用一切正常，CPU利用率低于10%，内存利用率低于30%，网络也都正常。
但是用户陆续开机上线后，发现部分用户网络不通，到网关（防火墙上vlan接口）都不通。
在深信服AF上查看arp，发现总数是4095，与研发确认，发现深信服AF上arp表总数就是4096个，也就是在这种场景下，总用户也只能达到4000多点。
与研发商量后，预计要做定制包实现，但是用户强烈要求当天解决，后来多名研发确认只需要修改AF后台的某个参数即可实现对限制的放开，且修改该参数不影响业务。
对主备两台参数分别修改为20000后，已正常使用。
截止目前最新的AF版本8.0.26，都存在这个问题。当然在大规模的网络中，一般也很少会将内网用户的网关都启用在防火墙上，更多是将网关放在核心交换机上。对于这种少见的特殊的部署场景才将这个问题暴露了出来。
另外深信服AF的arp老化时间是15秒，且无法修改。并且AF上的vlan数量也有限制，限制为256个vlan，dhcp地址池也有限制，限制为1万个。不过对于vlan数量以及dhcp地址池的限制可以通过定制来解决。
具体修改方法，参见：修改linux系统的arp缓存数量的方法。
现有四台深信服防火墙AF，名称分别为A、B、C、D，A和B做成HA，C和D做成HA，都是路由模式，网口1都是带外管理口，并且都加入到了监视网口，双机热备配置的虚拟ID组都是默认的100，A、B两台带外管理口地址是192.168.1.1/24，C、D两台带外管理口地址是192.168.1.2/24。
做好配置后，发现192.168.1.1/24和192.168.1.2/24无法同时管理，当可以打开192.168.1.1控制台时，192.168.1.2则打不开，并且两个IP也无法同时ping通，当192.168.1.1可以ping通时，192.168.1.2则ping不通，当192.168.1.2可以ping通时，则192.168.1.1ping不通，在同网段设备上查看arp，发现192.168.1.1和192.168.1.2的MAC地址是一样的。
经确认，深信服防火墙AF做双机时，网卡的虚拟MAC是根据虚拟ID组和网口编号计算得出的，所以这个环境中，虚拟ID组都是100，网卡编号都是eth1口，它们的虚拟MAC就是一样的。
这种情况的处理办法非常简单，一是修改其中一个的虚拟ID组即可，还有一种办法是将A、B或者C、D的带外管理口不要加到网口监视中，并且每台带外管理口配置成-HA的不同的地址即可。
针对这个问题，建议厂家可以将虚拟MAC的计算方式复杂一点，比较加个随机数或者加个网关编号、硬盘ID等等，使得每个虚拟MAC都不相同。
有的环境下，尤其一个项目中，防火墙设备数量较多的情况下，建议修改默认的虚拟ID组，并且不同的HA设备采用的心跳口都设置成不同的网段，比如A、B用5.5.5.0/24段，C、D用6.6.6.0/24段，来避免一些问题。
本文主要是讲nmap的扫描和基于msf的扫描发现内网存活主机，每一个点都尽量详细介绍。
UDP简介：UDP（User Datagram Protocol）是一种无连接的协议，在第四层-传输层，处于IP协议的 上一层。UDP有不提供数据包分组、组装和不能对数据包进行排序的缺点，也就是说，当报 文发送之后，是无法得知其是否安全完整到达的。
UDP显著特性：1.UDP 缺乏可靠性。UDP 本身不提供确认，超时重传等机制。UDP 数据报可能在网络中被 复制，被重新排序，也不保证每个数据报只到达一次。2.UDP 数据报是有长度的。每个 UDP 数据报都有长度，如果一个数据报正确地到达目的 地，那么该数据报的长度将随数据一起传递给接收方。而 TCP 是一个字节流协议，没有任 何（协议上的）记录边界。3.UDP 是无连接的。UDP 客户和服务器之前不必存在长期的关系。大多数的UDP实现中都 选择忽略源站抑制差错，在网络拥塞时，目的端无法接收到大量的UDP数据报 4.UDP 支持多播和广播
nmap扫描
nmao -sU -T5 -sV —max-retries 1 192.168.1.100 -p 500 （不推荐，理由慢）
-sU 基于UDP的扫描
-T5 nmap的扫描速度 -T（0-5）越大越快
-sV 探测开启的端口来获取服务、版本信息
—max-retries 扫描探测的上限次数设定
-p 只扫描指定端口
msf扫描
use auxiliary/scanner/discovery/udp_prob
use auxiliary/scanner/discovery/udp_sweepuse 引用
show options 显示可设置的参数
auxiliary （辅助）/ scanner（扫描）/discovery（发现）/udp_probe（探测）/udp_sweep(彻底搜索)
ARP简介：ARP,通过解析网路层地址来找寻数据链路层地址的一个在网络协议包中极其重要的网络传输 协议。根据IP地址获取物理地址的一个TCP/IP协议。主机发送信息时将包含目标IP地址的 ARP请求广播到网络上的所有主机，并接收返回消息，以此确定目标的物理地址
nmap扫描 nmap -sn -RP 192.168.1.1/24
-sn 不扫描端口，只扫描主机
-PR ARP ping扫描
-sP Ping扫描 sn
-P0 无Ping扫描
-PS TCP SYN Ping扫描
-PA TCP ACK Ping扫描
-PU UDP ping扫描
-PE/PM/PP ICMP Ping Types扫描
msf扫描 use auxiliary/scanner/discovery/arp_sweep
nmap扫描
netbios简介：IBM公司开发，主要用于数十台计算机的小型局域网。该协议是一种在局域网上的程序可以 使用的应用程序编程接口（API），为程序提供了请求低级服务的同一的命令集，作用是为 了给局域网提供网络以及其他特殊功能。系统可以利用WINS服务、广播及Lmhost文件等多种模式将NetBIOS名-——特指基于 NETBIOS协议获得计算机名称——解析为相应IP地址，实现信息通讯，所以在局域网内部使 用NetBIOS协议可以方便地实现消息通信及资源的共享
nmap -sU —script nbstat.nse -p137 172.16.0.127 -T4
—script 指定脚本
nbstat.nse netbios扫描脚本
137端口默认开发netbios
msf use auxiliary/scanner/netbios/nbname
SNMP简介：SNMP是一种简单网络管理协议，它属于TCP/IP五层协议中的应用层协议，用于网络管理的 协议。SNMP主要用于网络设备的管理。SNMP协议主要由两大部分构成：SNMP管理站和 SNMP代理。SNMP管理站是一个中心节点，负责收集维护各个SNMP元素的信息，并对这 些信息进行处理，最后反馈给网络管理员；而SNMP代理是运行在各个被管理的网络节点之 上，负责统计该节点的各项信息，并且负责与SNMP管理站交互，接收并执行管理站的命 令，上传各种本地的网络信息。
nmap扫描
nmap -sU —script snmp-brute ip -T4
msf扫描
use auxiliary/scanner/snmp/snmp_enum
默认161端口
ICMP简介：它是TCP/IP协议族的一个子协议，用于在IP主机、路由器之间传递控制消息。控制消息是指 网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输 用户数据，但是对于用户数据的传递起着重要的作用。
nmap扫描
nmap -sP -PI 192.168.1.1/24 -T4
nmap ‐sn ‐PE ‐T4 192.168.1.0/24
-PI 进行ping扫描
-PE与P0功能一样 无ping扫描
SMB(全称是Server Message Block)是一个协议名，它能被用于Web连接和客户端与服务器之间的信息沟通。SMB最初是IBM的贝瑞·费根鲍姆（Barry Feigenbaum）研制的，其目的是将DOS操作系统中的本地文件接口“中断13”改造为网络文件系统。
nmap扫描
默认端口445
-sS ：半开放扫描（非3次握手的tcp扫描）
（使用频率最高的扫描选项：SYN扫描,又称为半开放扫描，它不打开一个完全的TCP连接，执行得很快，效率高（一个完整的tcp连接需要3次握手，而-sS选项不需要3次握手）Tcp SYN Scan (sS) 它被称为半开放扫描优点：Nmap发送SYN包到远程主机，但是它不会产生任何会话，目标主机几乎不会把连接记入系统日志。（防止对方判断为扫描攻击），扫描速度快，效率高，在工作中使用频率最高缺点：它需要root/administrator权限执行）
msf扫描
目前内网中有台电脑出现了一个很奇怪的现象，该电脑IP为192.168.1.1/25，网关为192.168.1.126，使用某业务软件客户端有时出现卡顿的现象，甚至有连接不上服务端10.X.X.X的情况，但是一般浏览网页又是正常的，更换了交换机端口、网线，更新了网卡驱动，问题依旧。
排查的时候发现，当出现业务软件卡顿的时候，ping网关也不丢包，但是TTL值会从255变为64，TTL如果发生改变，一般是网关有地址冲突，或者arp欺骗等相关情况。
ping网关时当TTL值是255时，使用arp -a可以查看192.168.1.124和192.168.1.126的MAC都是11-22-33-44-55-66，由于启用了VRRP，所以会出现这种情况，并且当TTL变为64时，使用arp -a可以看到假冒的网关的MAC11-22-33-44-55-AA，根据该MAC地址可以查询到网卡厂家，刚好内网中只存在一台该品牌的设备，基本可以定位出假冒网关的设备了，是一台XX品牌的终端设备，并不是一台电脑。
该终端上的菜单里查看到的MAC是11-22-33-44-55-BB，发现并非刚才arp -a看到的MAC地址 11-22-33-44-55-AA，并且其配置的IP是192.168.1.20/25，但是该设备配置的网关是错误的，其配置的网关是192.168.2.254，配置的这个网关和IP都不在同一网段，但是该终端竟然也可以配置上。
拿笔记本直连该终端，笔记本配置192.168.1.X/25，ping通终端192.168.1.20后，查看arp，发现该终端的MAC的确是 11-22-33-44-55-AA ，该终端显示屏上的MAC竟然是错误的。
将终端的网关修改为正确的192.168.1.126后，电脑192.168.1.1上软件客户端使用正常，并且ping网关192.168.1.126的TTL值一直是255，问题解决。
局域网中一台电脑突然无法上网，通过arp -a查看到网关的MAC并不是真实的，判断内网存在arp攻击，此种情况下，只需将网关绑定真实的MAC即可防御。
有时我们使用arp -s并不能实现绑定，这里需要其他的方法来做。
通过netsh i i show in查看本机网卡情况，记住外网网卡的Idx，一般为11，如果Idx为11，然后通过命令netsh -c “i i” add meogjnprs 11 “IP地址” “MAC地址”来绑定网关的MAC，即可恢复上网。
问题描述
1.RH2288-1、RH2288-2安装的是SUSE11操作系统。
2.服务器采的是双网卡绑定，bond0在VLAN100、bond1在VLAN200。
3.VLAN100的网关为172.16.0.1、VLAN200的网关为192.168.0.1。
RH2288-1的默认网关为192.168.0.1，RH2288-2的默认网关为172.16.0.1。
4.RH2288-2 ping RH2288-1的bond1网卡 192.168.0.187不通。
告警信息
FY-NMS:~ # ping -c 1 192.168.0.187
PING 192.168.0.187 (192.168.0.187) 56(84) bytes of data.
— 192.168.0.187 ping statistics —
1 packets transmitted, 0 received, 100% packet loss, time 0ms
处理过程
1.在RH2288-1、RH2288-2 ping 各自默认网关是否正常。
结果正常，无丢包。
2.检查RH2288-1、RH2288-1默认网关配置正确。
RH2288-1配置正确，检查结果如下：
FY-HIS:/etc # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 bond1
RH2288-2配置正确，检查结果如下：
FY-NMS ~ # route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 172.16.0.1 0.0.0.0 UG 0 0 0 bond0
3.在RH2288-1抓取网络数据包，是否能收到RH2288-2请求的ping请求。
FY-HIS:~ # tcpdump -ni bond1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond1, link-type EN10MB (Ethernet), capture size 96 bytes
09:45:38.900680 IP 172.16.0.188 > 192.168.0.188: ICMP echo request, id 24523, seq 54, length 64
09:45:39.908686 IP 172.16.0.188 > 192.168.0.188: ICMP echo request, id 24523, seq 55, length 64
09:45:40.916731 IP 172.16.0.188 > 192.168.0.188: ICMP echo request, id 24523, seq 56, length 64
09:45:41.924674 IP 172.16.0.188 > 192.168.0.188: ICMP echo request, id 24523, seq 57, length 64
4.根据抓包显示，从RH2288-2 ping RH2288-1 192.168.0.188不通，是因为在RH2288-1上只能抓到RH2288-2的request报文，但没有抓到RH2288-1 的reply的报文。
原因
问题产生的根因应该是SUSE 系统路由表策略，优先级低的路由，它不回复对端的arp请求。
解决方案
1．sysctl -a |grep rp_fi，查看返回值是否都为0。
2．将不为0的值改为0。
如net.ipv4.conf.all.rp_filter = 1，则修改sysctl -w net.ipv4.conf.all.rp_filter=0
3．将该修改值写入配置文件：
vi /etc/sysctl.conf
在该文件中将需要修改为0的值进行更改，需要注意格式与文件中其他配置一致。
建议与总结
在处理服务器侧网络不通时，建议多使用抓包的方法，通过分析网络报文快速定位问题。