3、IB网络访问控制列表（ACL）：ACL基础概念、基于L2/L3的ACL配置、ACL在IB网络中的最佳实践
各位好，咱们今天聊聊IB网络里的ACL。说实话，很多做传统以太网的朋友刚接触IB时，总觉得ACL这玩意儿没啥好讲的。但我在几个数据中心项目里吃过亏之后，才真正意识到——IB的ACL，跟以太网完全是两码事。
你想想看，IB网络里跑的是RDMA流量，延迟要求是微秒级的。如果ACL配置不当，轻则性能腰斩，重则整个集群通信瘫痪。嗯，咱们今天就把这块掰开揉碎了讲清楚。
3.1 ACL基础概念：IB世界的门禁系统
ACL，全称是Access Control List。说白了，就是给IB网络装个门禁。谁可以进，谁不可以进，全凭这张表说了算。
但IB的ACL跟以太网有个本质区别。以太网ACL通常是在交换机端口上做过滤，而IB的ACL是在分区管理器（SM）层面生效的。这意味着什么？意味着ACL规则是在整个子网管理层面统一管控的，而不是分散在每个端口上。
核心要点：IB的ACL本质上是一种基于路径的访问控制。它不是在数据包经过时才检查，而是在路径建立阶段就决定了——这个通信能不能建立。
我记得第一次配置IB ACL时，犯了个低级错误。我以为跟以太网一样，在端口上配个deny就完事了。结果发现IB的ACL规则是全局生效的，配错了整个集群的节点都互相ping不通。嗯，那次教训挺深刻的。
IB ACL主要基于以下几个维度做过滤：
- LID（Local Identifier）：本地标识符，相当于IB网络里的MAC地址
- GID（Global Identifier）：全局标识符，相当于IPv6地址
- P_Key（Partition Key）：分区键，IB网络隔离的核心机制
- Q_Key（Queue Key）：队列键，用于控制对特定队列对的访问
3.2 基于L2的ACL配置：LID级别的精细管控
L2 ACL，说白了就是基于LID的过滤。LID是IB网络二层的基础地址，每个端口都有一个唯一的LID。
配置L2 ACL时，我建议你遵循一个原则：先白名单，再黑名单。什么意思？先允许必要的通信，再拒绝不需要的。这样不容易误伤。
来看一个实际配置示例：
# 创建一个ACL规则组
ibacl_create -g my_l2_acl
# 添加规则：允许特定LID的通信
ibacl_add -g my_l2_acl -s 0x0002 -d 0x0005 -a allow
# 添加规则：拒绝某个LID访问
ibacl_add -g my_l2_acl -s 0x0003 -d 0x0005 -a deny
# 将ACL应用到端口
ibacl_apply -p 0x12 -g my_l2_acl小技巧：我个人习惯在配置L2 ACL时，先用ibacl_show命令查看当前LID分配情况。这样可以避免配错LID。我曾经因为手误把LID写成了0x0000，结果导致整个端口无法通信，排查了半天才发现是LID写错了。
L2 ACL的匹配规则是按顺序执行的。规则列表从上到下依次匹配，一旦匹配就停止。所以规则的顺序很重要。我一般把最严格的规则放在前面，宽松的放在后面。
3.3 基于L3的ACL配置：GID级别的跨子网管控
L3 ACL，就是基于GID的过滤。GID是IB网络三层的地址，类似于IPv6地址。当你的IB网络跨越多个子网时，L3 ACL就派上用场了。
配置L3 ACL时，有一个坑我必须要提醒你——GID的格式问题。GID由64位的GUID和64位的子网前缀组成，写错了格式ACL根本不会生效。
来看一个L3 ACL的配置示例：
# 创建L3 ACL规则组
ibacl_create -g my_l3_acl -t l3
# 添加规则：允许特定GID的通信
ibacl_add -g my_l3_acl -s fe80::2:c903:4:5 -d fe80::2:c903:4:10 -a allow
# 添加规则：拒绝某个子网的所有通信
ibacl_add -g my_l3_acl -s fe80::2:c903:4:0/112 -d any -a deny
# 应用L3 ACL
ibacl_apply -p 0x12 -g my_l3_acl警告：L3 ACL的匹配会消耗更多的SM计算资源。如果你的网络规模很大（超过1000个节点），我建议你优先使用L2 ACL。我曾经在一个2000节点的集群上用了L3 ACL，结果SM的CPU直接飙到90%，路径建立时间从毫秒级变成了秒级。
为什么会这样？因为L3 ACL需要解析GID，而GID的匹配涉及更复杂的计算。L2 ACL只匹配16位的LID，速度自然快得多。
3.4 ACL在IB网络中的最佳实践
这部分是我最想跟你分享的。踩过的坑多了，自然就总结出经验了。
3.4.1 最小权限原则
这是安全领域的老生常谈，但在IB网络中尤其重要。只允许必要的通信，其他的全部拒绝。我见过太多人图省事，直接配个permit any，结果安全事件发生时追悔莫及。
3.4.2 性能优先原则
ACL规则越多，SM的负担越重。我建议你：
- 规则数量控制在100条以内
- 优先使用L2 ACL，少用L3 ACL
- 避免使用通配符（any）规则
3.4.3 分层隔离策略
结合P_Key和ACL做分层隔离。P_Key做粗粒度的分区隔离，ACL做细粒度的端口级控制。这样既保证了性能，又实现了安全。
| 隔离层级 | 粒度 | 性能影响 | 推荐场景 |
|---|---|---|---|
| P_Key | 粗粒度（分区级） | 低 | 租户隔离、业务隔离 |
| L2 ACL | 中粒度（端口级） | 中 | 特定节点间的访问控制 |
| L3 ACL | 细粒度（子网级） | 高 | 跨子网的精细管控 |
避坑指南：我曾经在一个金融客户的项目中，为了追求极致安全，配了300多条ACL规则。结果业务上线后，存储节点的IOPS直接掉了30%。后来我花了整整两天时间，把规则精简到50条，性能才恢复正常。所以，ACL不是越多越好，够用就行。
3.4.4 定期审计与清理
ACL规则会随着业务变化而积累。我建议每季度做一次ACL审计，清理掉不再使用的规则。可以用ibacl_show -s命令查看每条规则的命中次数，那些长期命中次数为0的规则，基本可以删掉了。
3.4.5 变更管理
修改ACL前，一定要先在测试环境验证。我见过有人直接在现网改了ACL，结果导致整个存储集群断连，业务中断了2小时。嗯，那次事故的责任人就是我。从那以后，我养成了一个习惯——任何ACL变更，先在测试环境跑一遍，确认无误后再上生产。
好了，关于IB网络ACL的内容就讲到这里。记住一句话：ACL是IB网络安全的第一道防线，但绝不是最后一道。合理使用，才能既安全又高效。
公众号:蓝海资料掘金营，微信deep3321