FRR BGP协议分析8 -- BGP 层3隧道 (2)

关注

原创最新推荐文章于 2026-09-28 11:22:34 发布 1.3k 阅读 AI 写同款· GEO 优化 ›

Kubernetes BGP集成实战：构建生产级Anycast服务网络 BGP（边界网关协议）是互联网自治系统间路由交换的基础协议，其核心原理在于通过AS路径、本地优先级和多出口判别（MED）等属性实现跨域最优路径选择；技术价值在于赋予Kubernetes集群网络主权，摆脱云厂商负载均衡器的路由黑盒与协议限制；典型应用场景包括多云/混合云服务统一入口、边缘计算低延迟接入、金融级高可用网关及全球Anycast服务IP部署；本文聚焦2018年成熟稳定的FRRouting + MetalLB组合方案，详解BGP邻居建立、Service IP动态宣告、Anycast地址规划与四层连通性阅读详情

本文，我们分析UPDATE消息的处理过程

层3VPN 的UPDATE消息和前面的路由更新报文的接受处理是一样的，从解析属性的地方开始区别，报文如下图：

2019/12/26 09:32:44 BGP: : 20.20.20.20 rcvd UPDATE w/ attr: , origin ?, metric 100, extcommunity RT:12.1.1.2:2, path 200

2019/12/26 09:32:44 BGP: : 20.20.20.20 rcvd UPDATE wlen 0 attrlen 69 alen 0

2019/12/26 09:32:44 BGP: : 20.20.20.20 rcvd RD 12.1.1.2:2 1.1.1.1/32 label 154 IPv4 vpn

2019/12/26 09:32:44 BGP: : vpn_leak_to_vrf_update: start (path_vpn=0x5589ff3debf0)

2019/12/26 09:32:44 BGP: : vpn_leak_to_vrf_update_onevrf: skipping: import not set

2019/12/26 09:32:44 BGP: : vpn_leak_to_vrf_update_onevrf: updating 1.1.1.1/32 to vrf VRF 1

2019/12/26 09:32:44 BGP: : vpn_leak_to_vrf_update_onevrf: pfx 1.1.1.1/32: num_labels 1

2019/12/26 09:32:44 BGP: : leak_update: entry: leak-to=VRF 1, p=1.1.1.1/32, type=9, sub_type=0

2019/12/26 09:32:44 BGP: : leak_update: nexthop is valid (in vrf VRF default)

2019/12/26 09:32:44 BGP: : leak_update: ->VRF 1: 1.1.1.1/32: Added new route

2019/12/26 09:32:44 BGP: : group_announce_route_walkcb: afi=IPv4, safi=vpn, p=1.1.1.1/32

2019/12/26 09:32:44 BGP: : subgroup_process_announce_selected: p=1.1.1.1/32, selected=0x5589ff3debf0

2019/12/26 09:32:44 BGP: : bgp_zebra_announce: p=1.1.1.1/32, bgp_is_valid_label: 2

2019/12/26 09:32:44 BGP: : Tx route add VRF 7 1.1.1.1/32 metric 100 tag 0 count 1

2019/12/26 09:32:44 BGP: : nhop [1]: 20.20.20.20 if 0 VRF 0 label 154

2019/12/26 09:32:44 BGP: : bgp_zebra_announce: 1.1.1.1/32: announcing to zebra (recursion set)

2019/12/26 09:32:44 BGP: : u11:s11 send UPDATE w/ attr: , origin ?, extcommunity RT:12.1.1.2:2, path 200

2019/12/26 09:32:44 BGP: : u11:s11 send MP_REACH for afi/safi 1/128

2019/12/26 09:32:44 BGP: : u11:s11 send UPDATE RD 12.1.1.2:2 1.1.1.1/32 label 154 IPv4 vpn

2019/12/26 09:32:44 BGP: : u11:s11 send UPDATE len 89 numpfx 1

2019/12/26 09:32:44 BGP: : u11:s11 20.20.20.20 send UPDATE w/ nexthop 10.10.10.10 and RD

属性解析

在属性解析函数 bgp_attr_parse里面，我们分析和层3隧道相关的属性解析。

解析MP_REACH_NLRI

首先解析报文的afi和safi的值为1和128，然后转化为FRR 内部自己定义的afi和safi的值。

解析下一跳

获取下一跳的长度为12，然后获取RD(8字节)，但没有存储，只是跳过，在获取IP地址4字节，存放在attr下一跳nexthop里面。

最后存放在bgp_nlri的NLRI_MP_UPDATE里面，nlri保存的是MP_REACH_NLRI信息。

解析EXT_COMMUNITIES

NLRI处理

bgp_nlri_parse 函数里面由于前面解析的safi是SAFI_MPLS_VPN，所以NLRI的处理会是bgp_nlri_parse_vpn函数，主要处理过程如下，可以结合上面的报文一起看代码处理过程：

bgp_update 前面分析的时候，大概过程已经分析过了，下面会分析下，前面忽略的L3VPN相关的处理过程。

has_valid_label处理会变成1，因为前面传入了解析出来的label值

在构建struct bgp_path_info的时候，如果label有值，还需要构建struct bgp_path_info_extra，然后把label值存放在info_extra里面

把路由信息导入到VRF的BGP里面

vpn_leak_to_vrf_update 函数处理有点长，主体处理的是把vpn peer收到的路由信息，导入到VRF的BGP里面

发送端ospf vrf的路由导入BGP处理：

Zebra:

ubuntu# 2019/12/26 13:05:00 ZEBRA: : netlink_parse_info: netlink-listen (NS 0) type RTM_NEWNEIGH(28), len=76, seq=0, pid=0

2019/12/26 13:05:00 ZEBRA: : Neighbor Entry received is not on a VLAN or a BRIDGE, ignoring

2019/12/26 13:05:00 ZEBRA: : netlink_parse_info: netlink-listen (NS 0) type RTM_NEWNEIGH(28), len=76, seq=0, pid=0

2019/12/26 13:05:00 ZEBRA: : Neighbor Entry received is not on a VLAN or a BRIDGE, ignoring

2019/12/26 13:05:08 ZEBRA: : zebra message[ZEBRA_ROUTE_ADD:7:45] comes from socket [42]

2019/12/26 13:05:08 ZEBRA: : Read 1 packets from client: ospf

2019/12/26 13:05:08 ZEBRA: : rib_add_multipath: 7:1.1.1.1/32: Inserting route rn 0x56275b8132b0, re 0x56275b812140 (ospf) existing (nil)

2019/12/26 13:05:08 ZEBRA: : rib_add_multipath: dumping RE entry 0x56275b812140 for 1.1.1.1/32 vrf 7

2019/12/26 13:05:08 ZEBRA: : 1.1.1.1/32: uptime == 118014, type == 6, instance == 0, table == 1

2019/12/26 13:05:08 ZEBRA: : 1.1.1.1/32: metric == 100, mtu == 0, distance == 110, flags == 0, status == 0

2019/12/26 13:05:08 ZEBRA: : 1.1.1.1/32: nexthop_num == 1, nexthop_active_num == 0

2019/12/26 13:05:08 ZEBRA: : 1.1.1.1/32: NH 12.1.1.1[5] vrf 1(7) with flags

2019/12/26 13:05:08 ZEBRA: : 1.1.1.1/32: dump complete

2019/12/26 13:05:08 ZEBRA: : rib_link: 7:1.1.1.1/32: rn 0x56275b8132b0 adding dest

2019/12/26 13:05:08 ZEBRA: : rib_meta_queue_add: 7:1.1.1.1/32: queued rn 0x56275b8132b0 into sub-queue 2

2019/12/26 13:05:08 ZEBRA: : 7:1.1.1.1/32: Processing rn 0x56275b8132b0

2019/12/26 13:05:08 ZEBRA: : 7:1.1.1.1/32: Examine re 0x56275b812140 (ospf) status 2 flags 0 dist 110 metric 100

2019/12/26 13:05:08 ZEBRA: : 7:1.1.1.1/32: After processing: old_selected 0x0 new_selected 0x56275b812140 old_fib 0x0 new_fib 0x56275b812140

2019/12/26 13:05:08 ZEBRA: : 7:1.1.1.1/32: Adding route rn 0x56275b8132b0, re 0x56275b812140 (ospf)

2019/12/26 13:05:08 ZEBRA: : netlink_route_multipath(): RTM_NEWROUTE 1.1.1.1/32 vrf 7(1)

2019/12/26 13:05:08 ZEBRA: : netlink_route_multipath() (single-path): nexthop via 12.1.1.1 if 5(7)

2019/12/26 13:05:08 ZEBRA: : netlink_talk: netlink-dp (NS 0) type RTM_NEWROUTE(24), len=60 seq=115 flags 0x501

2019/12/26 13:05:08 ZEBRA: : 7:1.1.1.1/32: rn 0x56275b8132b0 dequeued from sub-queue 2

2019/12/26 13:05:08 ZEBRA: : update_from_ctx: 7:1.1.1.1/32: SELECTED

2019/12/26 13:05:08 ZEBRA: : 7:1.1.1.1/32 update_from_ctx(): no fib nhg

2019/12/26 13:05:08 ZEBRA: : 7:1.1.1.1/32 update_from_ctx(): rib nhg matched, changed 'true'

2019/12/26 13:05:08 ZEBRA: : 7:1.1.1.1/32: Redist update re 0x56275b812140 (ospf), old 0x0 (None)

2019/12/26 13:05:08 ZEBRA: : zsend_redistribute_route: ZEBRA_REDISTRIBUTE_ROUTE_ADD to client bgp: type ospf, vrf_id 7, p 1.1.1.1/32

2019/12/26 13:05:08 ZEBRA: : Not Notifying Owner: 6 about prefix 1.1.1.1/32(1) 2 vrf: 7

Bgp:

ubuntu# 2019/12/26 13:05:08 BGP: : vpn_leak_from_vrf_update: from vrf VRF 1

2019/12/26 13:05:08 BGP: : vpn_leak_from_vrf_update: post merge static_attr.ecommunity{12.1.1.2:2}

2019/12/26 13:05:08 BGP: : vpn_leak_from_vrf_update: new_attr->ecommunity{12.1.1.2:2}

2019/12/26 13:05:08 BGP: : leak_update: entry: leak-to=VRF default, p=1.1.1.1/32, type=6, sub_type=3

2019/12/26 13:05:08 BGP: : leak_update: nexthop is valid (in vrf VRF 1)

2019/12/26 13:05:08 BGP: : leak_update: ->VRF default: 1.1.1.1/32: Added new route

2019/12/26 13:05:08 BGP: : vpn_leak_to_vrf_update: start (path_vpn=0x557deca2fe90)

2019/12/26 13:05:08 BGP: : vpn_leak_to_vrf_update_onevrf: skipping: import not set

2019/12/26 13:05:08 BGP: : Rx route ADD VRF 7 ospf[0] 1.1.1.1/32 nexthop 12.1.1.1 (type 3 if 5) metric 100 tag 0

2019/12/26 13:05:08 BGP: : group_announce_route_walkcb: afi=IPv4, safi=vpn, p=1.1.1.1/32

2019/12/26 13:05:08 BGP: : subgroup_process_announce_selected: p=1.1.1.1/32, selected=0x557deca2fe90

2019/12/26 13:05:08 BGP: : u4:s4 send UPDATE w/ attr: nexthop 0.0.0.0, metric 100, extcommunity RT:12.1.1.2:2, originator 2.2.2.2, path

2019/12/26 13:05:08 BGP: : u4:s4 send MP_REACH for afi/safi 1/128

2019/12/26 13:05:08 BGP: : u4:s4 send UPDATE RD 12.1.1.2:2 1.1.1.1/32 label 154 IPv4 vpn

2019/12/26 13:05:08 BGP: : u4:s4 send UPDATE len 92 numpfx 1

2019/12/26 13:05:08 BGP: : u4:s4 10.10.10.10 send UPDATE w/ nexthop 20.20.20.20 and RD

2019/12/26 13:05:08 BGP: : 10.10.10.10 rcvd UPDATE w/ attr: , origin ?, extcommunity RT:12.1.1.2:2, path 100 200

2019/12/26 13:05:08 BGP: : 10.10.10.10 rcvd UPDATE wlen 0 attrlen 66 alen 0

2019/12/26 13:05:08 BGP: : 10.10.10.10 rcvd UPDATE about RD 12.1.1.2:2 1.1.1.1/32 label 154 IPv4 vpn -- DENIED due to: as-path contains our own AS;

Bgp端的函数subgroup_update_packet构造的update报文发送

发送的时候如果报文里面nexthop属性为0的话，bpacket_reformat_for_peer 这个函数会改nexthop的IP地址

收录于

FRR

【重识云原生】第四章云网络4.3.7.4节——BGP协议高级特性为保证 IBGP 对等体之间的连通性，需要在 IBGP 对等体之间建立全连接关系。假设在一个 AS 内部有 n 台设备，那么建立的 IBGP 连接数就为 n(n-1)/2。当设备数目很多时，设备配置将十分复杂，而且配置后网络资源和 CPU 资源的消耗都很大。在 IBGP 对等体间使用路由反射器可以解决以上问题。如图，在一个 AS 内部关于路由反射器有以下几种角色：路由反射器示意图同一集群内的客户机只需要与该集群的 RR 直接交换阅读详情