bird-1.6.8: Withdrawals during an enhanced route-refresh process
Garri Djavadyan
g.djavadyan at gmail.com
Fri Oct 14 01:28:27 CEST 2022
Hello everyone,
I noticed that the legacy Bird version behaves strangely while it is in
an enhanced route-refreshing process, but I am not sure whether it is a
known/expected behaviour for version 1.6.8. Namely, right after a 1.6.8
peers sends a BoRR message, it also sends withdrawals for the prefixes
it received from that same peer. For example, below is the output from
two Bird peers (1.6.8 and 2.0.10):
# birdc show route
BIRD 1.6.8 ready.
10.2.0.0/24 dev lo [direct1 21:09:14] * (240)
10.3.0.0/24 via 172.17.0.3 on eth0 [bird2 21:09:14] * (100)
[AS65003i]
# birdc reload out bird2
BIRD 1.6.8 ready.
bird2: reloading
Below is the debug output from the bird-2.0.10 peer:
2022-10-13 21:10:17.561 <TRACE> bird1: Got KEEPALIVE
2022-10-13 21:10:17.602 <TRACE> bird1: Got BEGIN-OF-RR
2022-10-13 21:10:17.602 <TRACE> bird1: Got UPDATE <=== this is a WD
2022-10-13 21:10:17.602 <TRACE> bird1: Got UPDATE
2022-10-13 21:10:17.602 <TRACE> bird1.ipv4 > ignored 10.2.0.0/24
unicast
2022-10-13 21:10:17.602 <TRACE> bird1: Got END-OF-RR
Below is the packets content for that RR process:
Frame 1: 89 bytes on wire (712 bits), 89 bytes captured (712 bits)
Internet Protocol Version 4, Src: 172.17.0.2, Dst: 172.17.0.3
Border Gateway Protocol - ROUTE-REFRESH Message
Marker: ffffffffffffffffffffffffffffffff
Length: 23
Type: ROUTE-REFRESH Message (5)
Address family identifier (AFI): IPv4 (1)
Subtype: Demarcation of the beginning of a route refresh (1)
Subsequent address family identifier (SAFI): Unicast (1)
Frame 3: 93 bytes on wire (744 bits), 93 bytes captured (744 bits)
Internet Protocol Version 4, Src: 172.17.0.2, Dst: 172.17.0.3
Border Gateway Protocol - UPDATE Message
Marker: ffffffffffffffffffffffffffffffff
Length: 27
Type: UPDATE Message (2)
Withdrawn Routes Length: 4
Withdrawn Routes
10.3.0.0/24
Total Path Attribute Length: 0
Frame 5: 113 bytes on wire (904 bits), 113 bytes captured (904 bits)
Internet Protocol Version 4, Src: 172.17.0.2, Dst: 172.17.0.3
Border Gateway Protocol - UPDATE Message
Marker: ffffffffffffffffffffffffffffffff
Length: 47
Type: UPDATE Message (2)
Withdrawn Routes Length: 0
Total Path Attribute Length: 20
Path attributes
Network Layer Reachability Information (NLRI)
10.2.0.0/24
Frame 7: 89 bytes on wire (712 bits), 89 bytes captured (712 bits)
Internet Protocol Version 4, Src: 172.17.0.2, Dst: 172.17.0.3
Border Gateway Protocol - ROUTE-REFRESH Message
Marker: ffffffffffffffffffffffffffffffff
Length: 23
Type: ROUTE-REFRESH Message (5)
Address family identifier (AFI): IPv4 (1)
Subtype: Demarcation of the ending of a route refresh (2)
Subsequent address family identifier (SAFI): Unicast (1)
Interestingly, bird-2.0.10 does not do that. For example:
# birdc show route
BIRD 2.0.10 ready.
Table master4:
10.3.0.0/24 unicast [direct1 21:05:38.768] * (240)
dev lo
10.2.0.0/24 unicast [bird1 21:09:15.455] * (100) [AS65002i]
via 172.17.0.2 on eth0
# birdc reload out bird1
BIRD 2.0.10 ready.
bird1: reloading
There is only one BGP update in the debug output of bird-1.6.8:
2022-10-13 22:05:30 <TRACE> bird2: Got BEGIN-OF-RR
2022-10-13 22:05:30 <TRACE> bird2: Got UPDATE
2022-10-13 22:05:30 <TRACE> bird2 > ignored 10.3.0.0/24 via 172.17.0.3
on eth0
2022-10-13 22:05:30 <TRACE> bird2: Got END-OF-RR
No withdrawals in the packet capture:
Frame 1: 89 bytes on wire (712 bits), 89 bytes captured (712 bits)
Internet Protocol Version 4, Src: 172.17.0.3, Dst: 172.17.0.2
Border Gateway Protocol - ROUTE-REFRESH Message
Marker: ffffffffffffffffffffffffffffffff
Length: 23
Type: ROUTE-REFRESH Message (5)
Address family identifier (AFI): IPv4 (1)
Subtype: Demarcation of the beginning of a route refresh (1)
Subsequent address family identifier (SAFI): Unicast (1)
Frame 3: 113 bytes on wire (904 bits), 113 bytes captured (904 bits)
Internet Protocol Version 4, Src: 172.17.0.3, Dst: 172.17.0.2
Border Gateway Protocol - UPDATE Message
Marker: ffffffffffffffffffffffffffffffff
Length: 47
Type: UPDATE Message (2)
Withdrawn Routes Length: 0
Total Path Attribute Length: 20
Path attributes
Network Layer Reachability Information (NLRI)
10.3.0.0/24
Frame 5: 89 bytes on wire (712 bits), 89 bytes captured (712 bits)
Internet Protocol Version 4, Src: 172.17.0.3, Dst: 172.17.0.2
Border Gateway Protocol - ROUTE-REFRESH Message
Marker: ffffffffffffffffffffffffffffffff
Length: 23
Type: ROUTE-REFRESH Message (5)
Address family identifier (AFI): IPv4 (1)
Subtype: Demarcation of the ending of a route refresh (2)
Subsequent address family identifier (SAFI): Unicast (1)
Below is the Bird configuration for both daemons:
bird-1.6.8:
# grep '^[^#]' /etc/bird/bird.conf
log "/var/log/bird.log" all;
debug protocols all;
router id 172.17.0.2;
protocol kernel {
scan time 60;
import none;
export all; # Actually insert routes into the kernel routing
table
}
protocol device {
scan time 60;
}
protocol direct {
interface "lo";
}
protocol bgp bird2 {
local as 65002;
neighbor 172.17.0.3 as 65003;
import all;
export all;
}
bird-2.0.10:
# grep '^[^#]' /etc/bird/bird.conf
log "/var/log/bird.log" all;
router id 172.17.0.3;
debug protocols all;
protocol device {
}
protocol direct {
ipv4; # Connect to default IPv4 table
interface "lo";
}
protocol kernel {
ipv4 { # Connect protocol to IPv4 table by
channel
export all; # Export to protocol. default is export
none
};
}
protocol bgp bird1 {
local as 65003;
neighbor 172.17.0.2 as 65002;
ipv4 {
import all;
export all;
};
}
So, I am just curious if it is a bug or some architectural limitation
of Bird-1.6. If I understand correctly, there are two problems here:
- bird-1.6 sends a withdrawal for a prefix it never advertised before
- there is no need to explicitly send withdrawals during an enhanced RR
process as RR receivers must implicitly remove stale prefixes
associated with the RR sender right after EoRR message per RFC 7313.
Thank you.
Garri Djavadyan
More information about the Bird-users
mailing list