ADMAN方案交换机转控分离场景IPTV业务,IPOE上线已经成功,但IPTV业务转发有问题
无
ADMAN方案主要以H3C NFV Orchestrator业务编排器配合H3C CloudOS云管理平台,控制H3C CAS虚拟化平台创建vBRAS虚拟宽带远程接入服务器资源池,同时配合硬件交换机与vBRAS资源池建立VXLAN隧道用于转发用户接入业务控制报文,来完成运营商城域网接入层功能。
在ADMAN方案IPTV转控分离场景组网下,控制平面(CP)与转发平面(DP)分离,控制平面和数据平面可分别选择合适的网元分别承载,以标准接口交互。控制平面要求能处理复杂逻辑和维护状态机,需要强计算、大内存、高扩展能力,一般采用X86来承载,ADMAN方案中一般使用vBRAS来承载CP(如无特殊说明,下文中vBRAS即指代CP);转发平面功能简单但性能压力大,需要高性能、低延时、低抖动能力,适合采用网络处理器(NP)或可编程ASIC来承载,ADMAN方案中目前使用交换机或路由器来承当DP(如无特殊说明,下文均以POP交换机做为DP)。
ADAMN方案IPTV业务交换机转控分离场景组网中,用户通常为IPoE接入方式,IPTV终端通过发送DHCP报文触发IPOE认证上线。POP交换机将接入OLT上送的IPTV用户控制报文封装为VXLAN报文上送给vBRAS设备,vBRAS设备解封装VXLAN报文后与AAA服务器交互,并将回应报文通过VXLAN隧道送回POP交换机,POP交换机解封装后返回给OLT,而IPTV业务报文从OLT发送至POP接入交换机后,在POP接入交换机上上行查找路由表转发,下行查找流表转发。
IPTV业务问题现象表现为用户上线成功,但IPTV无法正常播放。排查此类问题时,需要首先排查vBRAS上是否存在IPoE表项:如果不存在表项,则需要排查IPTV用户无法上线的原因;如果存在表项,则需排查OpenFlow流表是否下发正确,路由是否学习正确等。具体排查思路如下:
1.
2.
3.
4. 步骤4:排查CDN到CR是否存在故障
5. 步骤5:确认在CR上是否存在用户网段路由。如果不存在相应的用户网段路由,则进入步骤6继续排查。如果已经学习到相应路由,请排查CR到POP交换机这一段的转发问题。
6. 步骤6:确认在POP交换机上是否存在用户网段路由。如果不存在相应的用户网段路由,请排查相应配置。如果已经下发相应路由,请排查CR到POP交换机这一段的路由学习问题。
7. 步骤7:检查OpenFlow流表是否在POP交换机下发。转控分离IPTV业务的下行流量是查找OpenFlow流表进行转发的,如果在POP交换机上无法直接Ping通IPTV终端,则证明OpenFlow流表存在问题。如果流表存在问题,请进入步骤10继续排查,如果流表没有问题,请进入步骤8继续排查。
8. 步骤8:排查POP交换机上VSI相关配置是否正确。如果相关配置正确,请进入步骤9继续排查,如果相关配置有问题,请登录vBRASSO进行相应修改。
9. 步骤9:排查l2vpn mac-address和ARP相关表项是否学习正确。如果表项学习正确,请进入步骤12继续排查。如果表项学习错误,可以尝试让IPTV终端重新上线。
10. 步骤10:检查OpenFlow配置是否下发正确。如果OpenFlow配置下发正确,请进入步骤11继续排查。如果OpenFlow配置下发错误,请在vBRASSO上检查对应的POP交换机状态是否正确、交换机类型是否选择正确。
11. 步骤11:确认交换机ACL硬件资源是否超规格。如果超规格需要设法释放一些资料或扩容。
12. 步骤12:沿用户接入报文转发路径排查流量经过的其他设备(服务器网卡或者网络设备),确认流量丢弃的位置,并排查中间链路丢包原因。流量统计和抓包配置方法可参考相关交换机或vBRAS配置指导,如果确认报文未丢弃,可拨打H3C热线电话400-810-0504寻求帮助。
检查vBRAS上是否存在对应用户的IPoE会话。如果不存在,则请参考《ADMAN方案IPTV转控分离用户上线失败问题排查云图》排查IPTV用户无法上线的原因;如果存在会话,则转入步骤2继续排查业务转发状态。
登录NFV Orchestrator WEB界面后,在NFV编排/vBRASSO页面,选择对应的虚拟机资源池,通过名称或管理IP查找到对应的vBRAS后,即可点击操作一栏最右侧的控制台按钮,进入vBRAS的命令行界面。本例中,vBRAS名称为“IPTV”,管理IP为“99.1.4.200”。如果操作员可以直接访问vBRAS的管理IP,也可以SSH直接登录vBRAS命令行。
登录vBRAS命令行界面之后,可使用“display ip subscriber session”命令查看是否存在对应用户的IPoE会话。当已知用户的IP地址时,可使用“display ip subscriber session ip X.X.X.X”(X.X.X.X字段为用户IP地址)命令查找具体的用户会话;当已知用户的MAC地址时,可使用“display ip subscriber session mac X-X-X”(X-X-X字段为用户MAC地址)查找具体的用户会话。如下举例所示,由标红加粗字段可知,IP地址为“180.0.0.1”及MAC地址为“84d9-3191-5484”的用户已上线,且状态正常为“Online”。
除去Online状态外,其他均为上线未成功状态;如果根本不存在对应用户会话,同样不正常,均需要参考《ADMAN方案IPTV转控分离用户上线失败问题排查云图》进一步排查。这里对IPoE用户会话状态进行简要列举:
Init:初始化
Offline:正在下线中
Auth:认证中
AuthFail:认证失败
AuthPass:认证通过
ssignedIP:用户已具备地址
Online:用户在线
SSH登录POP交换机,使用Ping命令 “ping –a 源VTEP IP 目的VTEP IP”命令检查POP交换机上的网关IP是否能与IPTV终端互通。如下所示,由标红加粗字段可以知源IP地址为“180.1.1.254”,目的IP地址为“180.1.1.1”,由“0.0% packet loss”可知源目 IP之间无丢包,通信正常,POP交换机与IPTV终端之间源目IP可达;否则,如果“packet loss”字段前数字不为“0.0%”,则说明POP交换机与IPTV终端之间通信异常,需要转入步骤7进一步排查。如果“packet loss”字段前数字为“0.0%”,则说明POP交换机与IPTV终端之间通信正常,需要转入步骤3进一步排查。
注意这里的源IP为IPTV终端网关IP,只能在POP交换机上发起该Ping操作,vBRAS上的该Ping操作正常情况下亦无法Ping通IPTV终端。如果配置了VPN,还需要带上“-vpn-instance vpn-name”参数发起Ping操作。
<104-POP-1>ping -a 180.1.1.254 180.1.1.1 Ping 180.1.1.1 (180.1.1.1) from 180.1.1.254: 56 data bytes, press CTRL_C to break 56 bytes from 180.1.1.1: icmp_seq=0 ttl=255 time=2.708 ms 56 bytes from 180.1.1.1: icmp_seq=1 ttl=255 time=2.122 ms 56 bytes from 180.1.1.1: icmp_seq=2 ttl=255 time=1.949 ms 56 bytes from 180.1.1.1: icmp_seq=3 ttl=255 time=2.479 ms 56 bytes from 180.1.1.1: icmp_seq=4 ttl=255 time=1.913 ms
--- Ping statistics for 180.1.1.1 --- 5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss round-trip min/avg/max/std-dev = 1.913/2.234/2.708/0.310 ms <104-POP-1> |
登录POP交换机,使用Ping命令 “ping –a 源VTEP IP 目的VTEP IP”命令检查POP交换机上的用户业务网段网关地址是否能与公网互通。如下所示,由标红加粗字段可以知源IP地址为“180.1.1.254”,目的IP地址为“10.1.1.1”,由“0.0% packet loss”可知源目 IP之间无丢包,通信正常,POP交换机与CR之间源目IP可达,需要进入步骤4进一步排查;否则,如果“packet loss”字段前数字不为“0.0%”,则说明设备之间通信异常,需要转入步骤5进一步排查。
<104-POP-1>ping -a 180.1.1.254 10.1.1.1 Ping 180.1.1.1 (10.1.1.1) from 180.1.1.254: 56 data bytes, press CTRL_C to break 56 bytes from 10.1.1.1: icmp_seq=0 ttl=255 time=2.708 ms 56 bytes from 10.1.1.1: icmp_seq=1 ttl=255 time=2.122 ms 56 bytes from 10.1.1.1: icmp_seq=2 ttl=255 time=1.949 ms 56 bytes from 10.1.1.1: icmp_seq=3 ttl=255 time=2.479 ms 56 bytes from 10.1.1.1: icmp_seq=4 ttl=255 time=1.913 ms
--- Ping statistics for 10.1.1.1 --- 5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss round-trip min/avg/max/std-dev = 1.913/2.234/2.708/0.310 ms <104-POP-1>
|
经过上面三步的测试,我们可以判断CR到IPTV这一段的网络是通畅,如果IPTV业务仍旧存在问题,接下来需要判断运营商侧的CDN机房本身是否存在故障以及CND机房到CR这一段网络是否存在故障,同时需要了解现场IPTV直播业务是否有特殊之处,比如是否需要大包放通、防火墙放通等,并做针对性测试。本文中不再赘述CDN到CR一段的排查方法。
如果CR无法Ping通IPTV终端或POP交换机无法Ping通CR,而POP交换机可以Ping通IPTV终端,则需要登录CR上排查CR是否学习到了用户网段的路由,一般是由POP交换机通过IBGP邻居将该用户网段路由发送给CR交换机,所以如果CR无法学习到用户网段路由,首先需要排查IBGP邻居是否正常,以及路由是否通过IBGP传递到CR了。如果邻居正常而POP交换机上没有用户网段路由,则需要参考步骤6排查POP交换机是否生成、引入了用户网段路由并发布给了CR。如果CR上已经学习到了用户网段路由,但仍旧无法Ping通IPTV终端,则需要排查CR到POP交换机的转发是否存在问题,因该转发过程不涉及VXLAN,这里不再赘述。
POP交换机上的用户网段路由一般由vBRAS(CP)通过OpenFlow通道下发给POP交换机(DP),所以我们需要首先需要判断现场vBRAS(CP)上的DHCP地址池类型,如果是普通地址池、或地址池组内加入的是普通地址池,则需要在地址池内配置命令“subnet alloc-mode dp-address ”,否则vBRAS(CP)不会主动向POP交换机(DP)下发用户网段路由,此时需要手工在POP交换机上配置用户网段的静态黑洞路由,并在BGP的IPV4地址簇中引入该静态路由。如果是动态地址池(配置了“dhcp server ip-pool pool-name subnet-alloc”命令),则vBRAS(CP)不用绑定DP也会自动下发用户网段路由。
如下举例中,vBRAS(CP)上配置了普通地址池,但其在地址池内使用标红命令“binding dp-address 11.0.0.10”绑定了DP 11.0.0.10,故而该CP会向该DP下发用户网段路由。
[IPTV-CP01]dis cu | begin ip-pool dhcp server ip-pool iptv_pool_1 binding dp-address 11.0.0.10 gateway-list 10.0.0.254 export-route network 10.0.0.0 mask 255.255.255.0 export-route address range 10.0.0.1 10.0.0.253 # |
在POP交换机(DP)上,我们可以使用命令“display openflow instance 1 flow-table”来查看POP交换机上是否下发了对应的用户网段流表,如下:
[104-POP-1]display openflow instance 1 flow-table Instance 1 flow table information:
Table 0 information: Table type: MAC-IP, flow entry count: 2, total flow entry count: 2
Flow entry 1 information: COOKIE: 0xc080000000000005, priority: 70, hard time: 0, idle time: 0, flags: flow_send_rem|check_overlap, byte count: --, packet count: -- Controller ID: 1 Match information: Ethernet type: 0x0800 IPv4 destination address: 10.0.0.0, mask: 255.255.255.0 Instruction information: Write actions: Output interface: NULL0 |
该流表的目的地址为用户网段,出接口为NULL0。同时,该流表会在IP路由表中生成一条静态路由,我们可以使用命令“display ip routing-table protocol static”来确认查看,注意“display current-configuration”命令无法查看到该静态路由。
[104-POP-1]display ip routing-table protocol static
Summary count : 2
Static Routing table status : <Active> Summary count : 2
Destination/Mask Proto Pre Cost NextHop Interface 10.0.0.0/24 Static 254 0 0.0.0.0 NULL0 99.1.4.0/24 Static 60 0 99.1.1.254 MGE1/0/0/2
Static Routing table status : <Inactive> Summary count : 0 [104-POP-1] |
如果vBRAS(CP)上的地址池为普通地址池且未指定DP,则上述OpenFlow流表不会下发至POP交换机(DP),此时可以选择在CP上绑定DP,或直接在POP交换机上手工配置用户网段静态路由,如下:
[104-POP-1]ip route-static 10.0.0.0 24 NULL0 preference 254 |
如果POP交换机(DP)上未查看到该用户网段流表,则首先需要排查是否有用户终端上线,只有该网段的第一个终端上线成功后,该用户网段流表才会从CP下发至DP,然后需要排查CP与DP的OpenFlow实例是否正常,如下标红字段,在POP交换机上使用命令“display openflow instance 1 controller”来判断OpenFlow连接是否正常,当“Connect state”为“Established”状态时是正常状态,其他状态均不正常。同时需要关注字段“Local IP address”和“Controller IP address”,其应该分别为VXLAN tunnel的源目的IP地址。
[104-POP-1]display openflow instance 1 controller Instance 1 controller information: Reconnect interval: 60 (s) Echo interval : 5 (s)
Controller ID : 1 Controller IP address : 129.2.2.3 Controller port : 6633 Local IP address : 11.0.0.10 Controller role : Equal Connect type : TCP Connect state : Established Packets sent : 221 Packets received : 271 SSL policy : -- VRF name : --
[104-POP-1]dis cu int tunnel 100 # interface Tunnel100 mode vxlan source 11.0.0.10 destination 129.2.2.3 # return [104-POP-1] |
如果上述流表未下发,需要排查用户终端是否上线,OpenFlow连接是否正常等,请参考上述步骤排查。
如果该状态不正常或不存在openflow instance 1,请先确认防火墙是否放行相应端口,再进入步骤10继续排查。
转控分离IPTV业务的下行流量是查找OpenFlow流表进行转发的,如果在POP交换机上无法直接Ping通IPTV终端,则证明OpenFlow流表存在问题。首先,我们需要确认用户终端已在vBRAS(CP)上拿到地址并成功上线。然后,我们可以在POP交换机上使用命令“display openflow instance 1 controller”来判断OpenFlow连接是否正常,当“Connect state”为“Established”状态时是正常状态,其他状态均不正常。同时需要关注字段“Local IP address”和“Controller IP address”,其应该分别为VXLAN tunnel的源目的IP地址。
[104-POP-1]display openflow instance 1 controller Instance 1 controller information: Reconnect interval: 60 (s) Echo interval : 5 (s)
Controller ID : 1 Controller IP address : 129.2.2.3 Controller port : 6633 Local IP address : 11.0.0.10 Controller role : Equal Connect type : TCP Connect state : Established Packets sent : 221 Packets received : 271 SSL policy : -- VRF name : --
[104-POP-1]dis cu int tunnel 100 # interface Tunnel100 mode vxlan source 11.0.0.10 destination 129.2.2.3 # return [104-POP-1] |
如果OpenFlow连接不正常或不存在openflow instance 1,请进入步骤10继续排查。
确认OpenFlow连接正常后,我们需要在POP交换机(DP)上,使用命令“display openflow instance 1 flow-table”来查看POP交换机上是否下发了对应的用户终端流表,如下:
[104-POP-1]display openflow instance 1 flow-table Instance 1 flow table information:
Table 0 information: Table type: MAC-IP, flow entry count: 2, total flow entry count: 2
Flow entry 1 information: COOKIE: 0xc080000000000005, priority: 70, hard time: 0, idle time: 0, flags: flow_send_rem|check_overlap, byte count: --, packet count: -- Controller ID: 1 Match information: Ethernet type: 0x0800 IPv4 destination address: 10.0.0.0, mask: 255.255.255.0 Instruction information: Write actions: Output interface: NULL0
Flow entry 2 information: COOKIE: 0x8080000000000006, priority: 0, hard time: 0, idle time: 0, flags: flow_send_rem|check_overlap, byte count: --, packet count: -- Controller ID: 1 Match information: Ethernet type: 0x0800 IPv4 destination address: 10.0.0.1, mask: 255.255.255.255 Tunnel ID: 2000, mask: 0xffffffffffffffff Experimenter: Application: IpoE V4, Session ID: 0x0 Address ID: 146068374377604 Instruction information: Apply actions: Push VLAN tag: 0x8100 Set field: VLAN ID: 2000 Set field: Ethernet destination MAC address: 84d9-3191-5484 Output interface: XGE1/0/0/2
[104-POP-1] |
在openflow teble 0中我们找到了entry 2,其匹配域为VXLAN 2000中的IP 10.0.0.1(在匹配域中Tunnel ID即意为VXLAN ID),同时entry 2的指令集中包含动作“Set field:VLAN ID :2000”,意为将报文打上VLAN 标签2000,此处如果是QINQ报文进入的POP交换机,则用户终端流表中会带上双层VLAN标签;同时指令集还包含动作“ Set field: Ethernet destination MAC address: 84d9-3191-5484 Output interface: XGE1/0/0/2”,意为将报文的目的MAC地址修改为终端MAC“84d9-3191-5484”,然后将报文从出接口XGE1/0/0/2发出去。
如果上述流表未下发,需要排查用户终端是否上线,OpenFlow连接是否正常,防火墙是否放行相应端口等,请参考上述步骤排查。
如果上述流表已经下发,仍旧无法在POP交换机上Ping通IPTV终端,请进入步骤8继续排查。
根据第7步的排查,我们已经找到了IPTV用户终端对应的OpenFlow流表,并从该流表信息中得知,示例中的终端IP为10.0.0.1,MAC地址为84d9-3191-5484,其应该携带VLAN2000的标签从POP交换机的XGE1/0/0/2口上来,进入VXLAN 2000。故而首先我们需要根据现场情况确认IPTV终端在OLT上携带什么VLAN标签上到POP交换机,以及POP交换机上对应的配置是否下发正确。
此处我们可以通过抓包和流统等手段确认IPTV终端携带了什么VLAN标签从OLT发送至POP交换机,这里不再赘述。
关于POP交换机上的配置,首先我们从上述步骤中得知了IPTV终端10.0.0.1应该从POP交换机的XGE1/0/0/2口上来,故而可以通过命令“display current-configuration interface te1/0/0/2”来确认配置,如下:
[104-POP-1]display current-configuration interface te1/0/0/2 # interface Ten-GigabitEthernet1/0/0/2 port link-mode bridge description to-104-POOLGW-2 port link-type trunk port trunk permit vlan 1 2000 # service-instance 2000 encapsulation s-vid 2000 xconnect vsi VBRASSO_POP-DC1_2000 access-mode ethernet # return [104-POP-1] |
我们可以得知该POP交换机的te1/0/0/2口上放行了vlan 2000,同时绑定了服务实例2000,该服务实例匹配外层vlan标签(s-vid)2000,并将此类报文送入vsi实例“vsi VBRASSO_POP-DC1_2000”。我们可以通过命令“display current-configuration configuration vsi”来确认该vsi绑定了哪个VXLAN,如下图标红处,可以得知该实例绑定了VXLAN 2000,完全符合第七步的OpenFlow用户终端流表信息:
[104-POP-1]display current-configuration configuration vsi # vsi VBRASSO_POP-DC1_2000 gateway vsi-interface 1 vxlan 2000 tunnel 100 relay-agent ipoe # return [104-POP-1] |
如果确认配置均正确,IPTV业务仍旧不通,则需要进入第九步排查表项是否学习正确。
如果VSI相关配置错误,请登录vBRASSO Web页面的【NFV编排/vBRASSO】路径,按照下图标注的步骤,依次进入【服务实例/服务实例名/资源绑定/修改】,找到对应的AC链路,并确认该链路的配置是否正确,如果不正确需要在vBRASSO上修改为正确配置。
如果POP交换机下行口不存在上述配置,请确认POP交换机的AC资源是否已经超规格。
在上述步骤中,POP交换机的Ten-GigabitEthernet1/0/0/2口下存在服务实例2000,其匹配的外层VLAN(s-vid)为2000,进入到VSI实例“VBRASSO_POP-DC1_2000”里,同时接口下配置了“port trunk permit vlan 2000”。此时如果IPTV终端发送DHCP报文上到OLT,OLT理应打上VLAN 2000的标签,送到POP交换机的Ten-GigabitEthernet1/0/0/2口,匹配service-instance 2000的s-vid 2000,进入到VSI实例“VBRASSO_POP-DC1_2000”。如果以上配置均正确,且报文已携带正确的VLAN标签进入到POP交换机对应接口,则在POP交换机上输入命令“display l2vpn mac-address vsi VBRASSO_POP-DP1_2000”,能够看到终端的MAC地址,如下图红框处。
[104-POP-1]dis l2vpn mac-address MAC Address State VSI Name Link ID/Name Aging 74ea-c830-6601 Dynamic VBRASSO_POP-DC1_2000 Tunnel100 Aging 84d9-3191-5484 Dynamic VBRASSO_POP-DC1_2000 XGE1/0/0/2 Aging --- 2 mac address(es) found ---
[104-POP-1]dis arp Type: S-Static D-Dynamic O-Openflow R-Rule M-Multiport I-Invalid IP address MAC address VLAN/VSI Interface/Link ID Aging Type 10.0.0.1 84d9-3191-5484 0 0 -- O [104-POP-1]
|
如果不能看到该终端的l2vpn mac-address,请首先排查POP交换机业务口下的配置是否正确。配置正确的情况下,仍旧看不到l2vpn mac-address,则需要在该业务口配置流量统计或流镜像功能,确认OLT是否将DHCP报文上到POP交换机对应接口,以及DHCP报文携带的VLAN标签是否正确。
通过抓包或流量统计方法检查终端DHCP报文是否可以正常到达POP交换机。如果终端DHCP报文无法到达POP交换机,请排查POP下层网络;如果终端DHCP报文携带的VLAN标签不正确,请确认OLT配置;如果终端DHCP报文可以到达POP交换机,且能看到l2vpn mac-address,终端IPTV用户仍旧无法在POP交换机上Ping通,请使用命令查看POP交换机“display arp”查看ARP表项是否生成,该ARP表项为用户终端的IP+MAC地址,其Type为“O类型”,意为根据OpenFlow流表生成,即根据第七步的OpenFlow用户终端流表生成。如果该ARP表项生成有问题,可以尝试将该IPTV终端下线并触发重新认证上线,从而触发OpenFlow流表重新下发。
[104-POP-1]dis arp Type: S-Static D-Dynamic O-Openflow R-Rule M-Multiport I-Invalid IP address MAC address VLAN/VSI Interface/Link ID Aging Type 10.0.0.1 84d9-3191-5484 0 0 -- O [104-POP-1]
|
流镜像或利用MQC进行流量统计的配置方法可参考POP交换机对应型号版本的相关配置指导。
在POP交换机上使用命令“display current-configuration | begin "openflow instance"来确认openflow实例的配置是否已经下发,如下:
[104-POP-1]display current-configuration | begin "openflow instance" openflow instance 1 default table-miss permit undo tcp-connection backup flow-table mac-ip 0 classification global data-plane enable controller 1 address ip 129.2.2.3 local address ip 10.0.0.10 active instance # [104-POP-1] |
其中最重要的配置为标红的两行,第一行指明了控制器IP和本地IP,这两个IP为OpenFlow连接的IP,必须能够互通,同时这两个IP为VXLAN Tunnel的源目IP。
第二行“active instance”为激活该OpenFlow实例,正常情况下由vBRASSO自动下发。
如果上述配置未下发或有缺失,请在确认网络连通性后,登录vBRASSO Web页面的【NFV编排/vBRASSO】路径,按照下图标注顺序依次点击【资源目录/物理设备/交换机/详情】查看对应POP交换机的运行状态和交换机类型。
如果运行状态不未AVAILABLE,请检查管理IP的连通性及Netconf账号密码的正确性。如果交换机类型不是“VXLAN DP转发节点”,请修改为该类型。
检查交换机ACL硬件资源是否超规格,ACL资源超规格可能导致OpenFlow流表软件表项下发成功但未下发至硬件,从而业务转发不通。请在POP交换机上使用命令“display qos-acl resource”确认:
[104-POP-1]display qos-acl resource Interfaces: XGE1/0/0/1 to XGE1/0/0/48 (chassis 1 slot 0) --------------------------------------------------------------------- Type Total Reserved Configured Remaining Usage --------------------------------------------------------------------- VFP ACL 37632 0 0 37632 0% IFP ACL 46080 8194 10 37876 17% IFP Meter 30720 79 0 30641 0% IFP Counter 8175 87 0 8088 1% EFP ACL 16768 0 0 16768 0% EFP Counter 4094 0 0 4094 0%
[104-POP-1] |
如上图标红处,IFP ACL的Usage为17%,则证明ACL资源还剩余83%,资源充足。如果该IFP ACL资源已达到或接近100%,请扩容交换机,或排除哪些项目占用了过多的ACL资源并释放解决。
沿转发路径排查流量经过的其他设备(服务器网卡或者网络设备),确认流量丢弃的位置,并排查中间链路丢包原因。流量统计和抓包配置方法可参考交换机或vBRAS相关配置指导,如果确认报文未丢弃,可拨打H3C热线电话400-810-0504寻求帮助。如果通过流量统计、抓包、流镜像等方式确认报文丢在某一设备上,则需要在该设备上具体分析,可拨打H3C热线电话400-810-0504寻求帮助。
该案例暂时没有网友评论
✖
案例意见反馈
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作