Each time I point out unnumbered BGP classes in a webinar, somebody inevitably asks “and the way precisely does that work?” I at all times replied “gee, that’s a weblog publish I ought to write certainly one of nowadays,” and though some readers would possibly discover it lengthy overdue, right here it’s 😉
We’ll work with a easy two-router lab with two parallel unnumbered hyperlinks between them. Each gadgets will probably be working Cumulus VX 4.4.0 (FRR 8.4.0 container generates virtually equivalent printouts).
EBGP classes in unnumbered BGP lab
Simply in case you need to replicate the outcomes, right here’s the netlab topology I used:
Unnumbered BGP take a look at lab topology
---
module: [ bgp ]
defaults.system: cumulus
supplier: clab
nodes:
r1:
bgp.as: 65001
r2:
bgp.as: 65002
hyperlinks:
- r1:
r2:
unnumbered: True
- r1:
r2:
unnumbered: True
netlab configures loopback IPv4 tackle on unnumbered Linux interfaces. Whereas that doesn’t change the outcomes, I eliminated it to show that Linux fortunately sends and receives IPv4 packets over an interface that doesn’t have an IPv4 tackle:
Interface addressing on R1
r1(bash)#ip addr present dev swp1
1985: [email protected]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
hyperlink/ether aa:c1:ab:14:a7:c9 brd ff:ff:ff:ff:ff:ff link-netnsid 1
inet6 fe80::a8c1:abff:fe14:a7c9/64 scope hyperlink
valid_lft eternally preferred_lft eternally
r1(bash)#ip addr present dev swp2
1987: [email protected]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
hyperlink/ether aa:c1:ab:ea:a0:advert brd ff:ff:ff:ff:ff:ff link-netnsid 1
inet6 fe80::a8c1:abff:feea:a0ad/64 scope hyperlink
valid_lft eternally preferred_lft eternally
We all know that unnumbered BGP classes use IPv6 link-local addresses, and that FRR advertises IPv4 prefixes with IPv6 subsequent hops utilizing encoding laid out in RFC 5549 (now RFC 8950).
A fast take a look at the BGP neighbors on R1 confirms that:
- The IP tackle of the BGP neighbor is a link-local IPv6 tackle;
- The BGP session has been established between IPv6 link-local addresses;
- The routers have negotiated prolonged subsequent hop capabilities for IPv4 tackle household
- The native subsequent hop used on outgoing updates would be the native link-local IPv6 tackle
First BGP neighbor on R1
r1# sh ip bgp nei
BGP neighbor on swp1: fe80::a8c1:abff:fe14:ea9e, distant AS 65002, native AS 65001, exterior hyperlink
Description: r2
Hostname: r2
BGP model 4, distant router ID 10.0.0.2, native router ID 10.0.0.1
BGP state = Established, up for 00:13:10
Final learn 00:00:01, Final write 00:00:01
Maintain time is 9, keepalive interval is 3 seconds
Neighbor capabilities:
4 Byte AS: marketed and obtained
AddPath:
IPv4 Unicast: RX marketed IPv4 Unicast and obtained
Prolonged nexthop: marketed and obtained
Deal with households by peer:
IPv4 Unicast
...
Native host: fe80::a8c1:abff:fe14:a7c9, Native port: 60794
International host: fe80::a8c1:abff:fe14:ea9e, International port: 179
Nexthop: 10.0.0.1
Nexthop world: fe80::a8c1:abff:fe14:a7c9
Nexthop native: fe80::a8c1:abff:fe14:a7c9
BGP desk (displayed by FRR) confirms FRR makes use of IPv6 subsequent hops for IPv4 prefixes:
BGP desk entry for R2 loopback on R1
r1# present ip bgp 10.0.0.2
BGP routing desk entry for 10.0.0.2/32
Paths: (2 accessible, finest #2, desk default)
Marketed to non peer-group friends:
r2(swp1) r2(swp2)
65002
fe80::a8c1:abff:feaf:4333 from r2(swp2) (10.0.0.2)
(fe80::a8c1:abff:feaf:4333) (used)
Origin IGP, metric 0, legitimate, exterior, multipath
Final replace: Fri Nov 11 14:17:52 2022
65002
fe80::a8c1:abff:fe14:ea9e from r2(swp1) (10.0.0.2)
(fe80::a8c1:abff:fe14:ea9e) (used)
Origin IGP, metric 0, legitimate, exterior, multipath, bestpath-from-AS 65002, finest (Neighbor IP)
Final replace: Fri Nov 11 14:17:52 2022
Apparently, the IPv4 routing desk in Linux kernel nonetheless makes use of the IPv6 subsequent hops:
IPv4 routing desk on R1
r1(bash)#ip route
10.0.0.2 nhid 23 proto bgp metric 20
nexthop by way of inet6 fe80::a8c1:abff:fe14:ea9e dev swp1 weight 1
nexthop by way of inet6 fe80::a8c1:abff:feaf:4333 dev swp2 weight 1
Nonetheless, understand that the position of subsequent hops in any forwarding desk is to level to ARP/ND entries that comprise the next-hop MAC tackle – the factor the router has to insert into the vacation spot MAC tackle of the forwarded packets.
Listed below are the ND entries for the BGP subsequent hops:
IPv4 routing desk on R1
r1(bash)#ip neigh
169.254.0.1 dev swp1 lladdr aa:c1:ab:14:ea:9e PERMANENT proto zebra
169.254.0.1 dev swp2 lladdr aa:c1:ab:af:43:33 PERMANENT proto zebra
fe80::a8c1:abff:feaf:4333 dev swp2 lladdr aa:c1:ab:af:43:33 router REACHABLE
fe80::a8c1:abff:fe14:ea9e dev swp1 lladdr aa:c1:ab:14:ea:9e router REACHABLE
By now it must be evident how Linux kernel makes the packet forwarding selections:
- IPv4 packet will be obtained on any interfaces, even when that interface doesn’t have an IPv4 tackle
- Forwarding desk lookup leads to a subsequent hop that would belong to a distinct tackle household
- A lookup into the neighbor desk produces the MAC tackle of the following hop
- The subsequent hop MAC tackle is used because the vacation spot MAC tackle when constructing the outgoing MAC header.
The above clarification works nicely for software-based forwarding, however what occurs on a Cumulus Linux change the place the packet forwarding is finished in {hardware}, and the {hardware} forwarding tables are derived from Linux kernel tables? I’d be stunned if all forwarding {hardware} can be as versatile because the Linux kernel, which might be the place the faux static ARP entries for 169.254.0.1 come into play:
- If the forwarding {hardware} requires an IPv4 subsequent hop for an IPv4 prefix, the {hardware} forwarding desk is programmed with link-scope subsequent hop IPv4 tackle 169.254.0.1
- At any time when required, a next-hop entry is created mapping IPv4 tackle 169.254.0.1 and the outgoing interface into the MAC tackle of the downstream router (derived from that router’s IPv6 neighbor entry).
