According to an analysis published on the ipSpace.net blog, the SR Linux BGP RIB automatically includes all system routes rather than keeping them separate until redistribution. While the author could not determine whether SR Linux uses the BGP Routing Information Base (BGP RIB) directly as its system routing table (RIB), testing on ipSpace.net showed that OSPF and host prefixes appear in the BGP table without any redistribution statements.
Traditional NOS vs. FRRouting Route Processing
As explained by ipSpace.net, traditional network operating systems handle the BGP RIB, the system RIB, and the forwarding table (FIB) through a six-step sequence:
- Store routes received from BGP neighbors inside the BGP RIB.
- Recreate routes redistributed into BGP from other protocols within the BGP RIB.
- Select the best routes in the BGP RIB using BGP rules.
- Advertise the best routes from the BGP RIB to BGP neighbors.
- Compare the best BGP RIB routes against routes from other routing protocols based on administrative distance to enter the IP routing table (system RIB).
- Copy routes from the system RIB into the FIB once their next hops are fully evaluated, which might involve multiple recursive lookups.
FRRouting modifies this workflow by using the system RIB as a repository for all routes, changing the final steps of the process:
- Copy the best routes from the BGP RIB into the system RIB.
- Select the best routes from the system RIB using the routing table manager (zebra) based on administrative distance.
- Copy the best RIB routes into the FIB following next-hop resolution.
Testing SR Linux in a netlab Topology
While updating SR Linux netlab configuration templates, the ipSpace.net author observed how SR Linux handles routing tables using a test network with an SR Linux router (SRL) connected to two adjacent routers: R1 running OSPF and X2 running EBGP.
┌────────┐ ┌─────────┐ ┌────────┐
│ R1 │ │ SRL │ │ X2 │
│10.0.0.1├────┤10.0.0.42├────┤10.0.0.2│
└────────┘ └─────────┘ └────────┘
◄─────────────► ◄────────────►
OSPF EBGPThe author built the lab using the following netlab topology file, which uses unnumbered IPv4 links on line 3 to keep the routing table clean and disables loopback advertising on line 11 so X2 should receive no BGP routes from SRL:
defaults.device: frr
provider: clab
addressing.p2p.ipv4: True
nodes:
srl:
module: [ ospf, bgp ]
bgp.as: 65000
device: srlinux
id: 42
bgp.advertise_loopback: false
r1:
module: [ ospf ]
x2:
module: [ bgp ]
bgp.as: 65001
links: [ srl-r1, srl-x2 ]Checking the IPv4 unicast route table on the SR Linux router shows the three expected prefixes across ospfv2, bgp, and host route types:
A:srl# show route-table ipv4-unicast summary | as text
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
IPv4 unicast route table of network instance default
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
+--------------------+------+-----------+---------------------+---------+---------+--------+-----------+------------+------------+------------+---------------+
| Prefix | ID | Route | Route Owner | Active | Origin | Metric | Pref | Next-hop | Next-hop | Backup | Backup Next- |
| | | Type | | | Network | | | (Type) | Interface | Next-hop | hop Interface |
| | | | | | Instanc | | | | | (Type) | |
| | | | | | e | | | | | | |
+====================+======+===========+=====================+=========+=========+========+===========+============+============+============+===============+
| 10.0.0.1/32 | 0 | ospfv2 | ospf_mgr | True | default | 16 | 10 | 169.254.0. | ethernet- | | |
| | | | | | | | | 1 (direct) | 1/1.0 | | |
| 10.0.0.2/32 | 0 | bgp | bgp_mgr | True | default | 0 | 170 | fe80::a8c1 | ethernet- | | |
| | | | | | | | | :abff:fe4e | 1/2.0 | | |
| | | | | | | | | :f30b | | | |
| | | | | | | | | (direct) | | | |
| 10.0.0.42/32 | 4 | host | net_inst_mgr | True | default | 0 | 0 | None | None | | |
| | | | | | | | | (extract) | | | |
+--------------------+------+-----------+---------------------+---------+---------+--------+-----------+------------+------------+------------+---------------+
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
IPv4 routes total : 3
IPv4 prefixes with active routes : 3
IPv4 prefixes with active ECMP routes: 0However, inspecting the BGP route table on SR Linux reveals that all three prefixes also appear in the BGP RIB:
A:srl# show protocols bgp routes ipv4 summary
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Show report for the BGP route table of network-instance "default"
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Status codes: u=used, *=valid, >=best, x=stale
Origin codes: i=IGP, e=EGP, ?=incomplete
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
+------+------------------+--------------------------+------+------+---------------------------------------------------+
| Stat | Network | Next Hop | MED | LocP | Path Val |
| us | | | | ref | |
+======+==================+==========================+======+======+===================================================+
| u*> | 10.0.0.1/32 | 169.254.0.1 | 16 | | i |
| u*> | 10.0.0.2/32 | fe80::a8c1:abff:fecf:209 | - | | [65001] i |
| | | a%ethernet-1/2.0 | | | |
| u*> | 10.0.0.42/32 | 0.0.0.0 | - | | i |
+------+------------------+--------------------------+------+------+---------------------------------------------------+
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
3 received BGP routes: 3 used, 3 valid, 0 stale
3 available destinations: 0 with ECMP multipathsTo verify why this happened, the author examined the SR Linux BGP configuration generated by netlab after removing all export-policy statements. The configuration contains neither a network statement nor route redistribution:
A:srl# info protocols bgp
protocols {
bgp {
admin-state enable
autonomous-system 65000
router-id 10.0.0.42
dynamic-neighbors {
interface ethernet-1/2.0 {
peer-group intf-ethernet-1/2
allowed-peer-as [
65001..65001
]
}
}
ebgp-default-policy {
import-reject-all false
export-reject-all false
}
afi-safi ipv4-unicast {
admin-state enable
}
group intf-ethernet-1/2 {
admin-state enable
afi-safi ipv4-unicast {
admin-state enable
ipv4-unicast {
advertise-ipv6-next-hops true
receive-ipv6-next-hops true
}
}
afi-safi ipv6-unicast {
admin-state disable
}
send-community {
standard true
large true
}
timers {
connect-retry 10 !!! Reduce default 120s to 10s
minimum-advertisement-interval 1
}
}
}
}Inspecting OSPF Routes and Default Export Policies
Looking closely at the OSPF prefix 10.0.0.1/32 inside the BGP RIB shows how SR Linux treats the imported entry:
A:srl# show protocols bgp routes ipv4 prefix 10.0.0.1/32
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.0.0.1/32" network-instance "default"
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Network: 10.0.0.1/32
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 0.0.0.0
Route Preference: MED is 16, No LocalPref
BGP next-hop : 169.254.0.1
Path : i
Communities : None
Path 1 was advertised to:
[ ]According to ipSpace.net, three details stand out in this output: the route source is the local router (neighbor 0.0.0.0, meaning it was redistributed into BGP), the MED is set to the OSPF cost of 16, and the route was not advertised to any neighbor, which is why X2 receives no BGP routes from SRL.
SR Linux achieves this by applying a default BGP export-policy that matches only routes learned via BGP. Because of this, routes imported into the BGP RIB from other sources are not advertised to BGP neighbors by default.
Prefix Origination and Route Redistribution Policies
As the ipSpace.net author notes, this architecture makes BGP prefix origination and route redistribution work differently than on other platforms. Instead of using a network statement, administrators must match prefixes in the outbound export-policy, and instead of configuring route redistribution, they must match the protocol in the outbound export-policy.
To originate a local prefix into BGP (the equivalent of a network statement), ipSpace.net provides the following routing policy:
A:srl# info routing-policy
routing-policy {
prefix-set default_bgp_advertise {
prefix 10.0.0.42/32 mask-length-range exact {
}
}
policy default_bgp_export {
default-action {
policy-result reject
}
statement prefixes {
match {
prefix-set default_bgp_advertise
}
action {
policy-result accept
}
}
statement bgp {
match {
protocol bgp
}
action {
policy-result accept
}
}
}To redistribute connected subnets and OSPF routes into BGP, the policy must also explicitly match BGP routes, otherwise BGP neighbors will not receive them:
A:srl# info routing-policy
policy default_bgp_export {
default-action {
policy-result reject
}
statement bgp {
match {
protocol bgp
}
action {
policy-result accept
}
}
statement export_local {
match {
protocol local
}
action {
policy-result accept
}
}
statement export_ospfv2 {
match {
protocol ospfv2
}
action {
policy-result accept
}
}
statement export_ospfv3 {
match {
protocol ospfv3
}
action {
policy-result accept
}
}
}Unintended Route Leaks and SR Linux 24.7.1
While the author notes that the SR Linux approach gets the job done, he points out that it could violate the Principle of Least Astonishment. For example, an administrator wanting to set the MED to 42 on BGP routes advertised from SRL to X2 might write a simple routing policy:
A:srl# info routing-policy policy set-med
routing-policy {
policy set-med {
statement med-is-42 {
action {
policy-result accept
bgp {
med {
set 42
}
}
}
}
}
}Applying this policy to the BGP neighbor produces the following BGP table on X2:
$ netlab connect x2 --show ip bgp
Connecting to container clab-X-x2, executing vtysh -c "show ip bgp"
BGP table version is 3, local router ID is 10.0.0.2, vrf id 0
Default local pref 100, local AS 65001
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.0.0.1/32 eth1 42 0 65000 i
*> 10.0.0.2/32 0.0.0.0(x2) 0 32768 i
*> 10.0.0.42/32 eth1 42 0 65000 iBecause the custom export policy accepted all routes in the BGP RIB without filtering by protocol, it set the MED to 42 on every route in the BGP RIB - including OSPF and local host routes - and advertised all of them to the EBGP neighbor X2.
In a simple setup, adding match protocol bgp to the routing policy fixes the issue. However, combining prefix origination, route redistribution, and per-neighbor policies previously required complex policy combinations until SR Linux release 24.7.1 introduced a chain of BGP export policies, which the author plans to cover after shipping netlab release 1.9.1.
This article was written by AI from reporting by blog.ipspace.net.
