Retrieve nexthop address from ctx route info using LUA script on FRR

[Aminiok]

Hi everyone,
I’m working with FRR in Lua and trying to retrieve the nexthop address from the ctx.routeinfo structure. I’ve tried accessing it using constructs like ctx.rinfo.nhe.ng, but these seem to be empty or nil.
Has anyone successfully retrieved the nexthop address from ctx.routeinfo? What’s the correct way to access this information? Any examples or insights would be greatly appreciated.

[Aminiok]

@dlqs, @qlyoung, @ton31337 I would really appreciate your insights or any guidance you could provide.

[ton31337]

You should use ctx.rinfo.zd_ng.nexthop.

[ton31337]

How are you trying to get it? Using this function on_rib_process_dplane_results()?

[Aminiok]

In the middle. The complet logs:

2024/08/29 12:39:41 ZEBRA: [QH1H1-KPQ84] Route 192.168.202.0/24(0) (add) queued for processing into sub-queue Early Route Processing
2024/08/29 12:39:41 ZEBRA: [RCED7-DFGA1] process_subq_early_route_add: (0:?):192.168.202.0/24: Inserting route rn 0x13be630, re 0x12c92c0 (bgp/IPv4/unicast) existing 0x0, same_count 0
2024/08/29 12:39:41 ZEBRA: [Q4T2G-E2SQF] process_subq_early_route_add: dumping RE entry 0x12c92c0 for 192.168.202.0/24 vrf default(0)
2024/08/29 12:39:41 ZEBRA: [M5M58-9PD2R] 192.168.202.0/24: uptime == 768213, type == 10, instance == 0, table == 254
2024/08/29 12:39:41 ZEBRA: [RVZMM-N7DME] 192.168.202.0/24: metric == 0, mtu == 0, distance == 20, flags == Recursion status == None
2024/08/29 12:39:41 ZEBRA: [KC40Q-0DH3A] 192.168.202.0/24: tag == 0, nexthop_num == 1, nexthop_active_num == 0
2024/08/29 12:39:41 ZEBRA: [ZSB1Z-XM2V3] 192.168.202.0/24: NH 10.10.10.19[0] vrf default(0) wgt 1, with flags
2024/08/29 12:39:41 ZEBRA: [SCETK-GQ9E4] 192.168.202.0/24: dump complete
2024/08/29 12:39:41 ZEBRA: [GCGMT-SQR82] rib_link: (0:?):192.168.202.0/24: rn 0x13be630 adding dest
2024/08/29 12:39:41 ZEBRA: [JF0K0-DVHWH] rib_meta_queue_add: (0:254):192.168.202.0/24: queued rn 0x13be630 into sub-queue BGP Routes
2024/08/29 12:39:41 ZEBRA: [NZNZ4-7P54Y] default(0:254):192.168.202.0/24: Processing rn 0x13be630
2024/08/29 12:39:41 ZEBRA: [ZJVZ4-XEGPF] default(0:254):192.168.202.0/24: Examine re 0x12c92c0 (bgp) status: Changed flags: Recursion dist 20 metric 0
2024/08/29 12:39:41 ZEBRA: [JPJF4-TGCY5] default(0:254):192.168.202.0/24: After processing: old_selected 0x0 new_selected 0x12c92c0 old_fib 0x0 new_fib 0x12c92c0
2024/08/29 12:39:41 ZEBRA: [ZFRN1-EZNJZ] default(0:254):192.168.202.0/24: Adding route rn 0x13be630, re 0x12c92c0 (bgp)
2024/08/29 12:39:41 ZEBRA: [HH6N2-PDCJS] default(0:254):192.168.202.0/24 rn 0x13be630 dequeued from sub-queue BGP Routes

=============== log.trace(ctx) ===============
2024/08/29 12:39:41 ZEBRA: [GCZ7N-MM9D9] {
  zd_provider: 1
  zd_vrf_id: 0
  rinfo: {
    zd_mtu: 0
    zd_tag: 0
    zd_distance: 20
    zd_metric: 0
    zd_dest: {
      network: "192.168.202.0/24"
      length: 24
      family: 2
    }
    zd_type: 10
    zd_old_instance: 0
    old_backup_ng: {
    }
    zd_old_distance: 0
    zd_safi: 1
    backup_ng: {
    }
    zd_nexthop_mtu: 0
    zd_ng: {
      1: {
        backup_idx: 0
        srte_color: 0
        vrf_id: 0
        weight: 1
        backup_num: 0
        type: 3
        nh_encap_type: 0
        ifindex: 2
        nh_label_type: 0
        flags: 3
      }
    }
    zd_old_metric: 0
    zd_nhg_id: 13
    zd_afi: 1
    zd_instance: 0
    nhe: {
      afi: 0
      nh_grp: {
        weight: 0
        id: 0
      }
      type: 0
      id: 13
      nh_grp_count: 0
      vrf_id: 0
      ng: {
      }
      old_id: 0
    }
    zd_old_tag: 0
    zd_old_ng: {
    }
    zd_old_type: 10
  }
  zd_status: 1
  zd_op: 1
  zd_table_id: 254
  zd_ifindex: 0
  zd_ifname: ""
}
 ==================================

2024/08/29 12:39:41 ZEBRA: [GHWHS-ZKQM5] update_from_ctx: default(0:254):192.168.202.0/24: SELECTED, re 0x12c92c0
2024/08/29 12:39:41 ZEBRA: [TS3SH-1276M] default(0:254):192.168.202.0/24 update_from_ctx(): no fib nhg
2024/08/29 12:39:41 ZEBRA: [HKQXC-4STSK] default(0:254):192.168.202.0/24 update_from_ctx(): rib nhg matched, changed 'false'
2024/08/29 12:39:41 ZEBRA: [Z1MP1-RFGJA] (0:254):192.168.202.0/24(0): Redist update re 0x12c92c0 (bgp), old 0x0 (None)

[ton31337]

I have almost identical output: https://gist.github.com/ton31337/bb006f67dd69fafac0292a8b5bea679a, don't understand what could cause that in your case.

[Aminiok]

Weird! Could you share your configuration, show ip route and show ip bgp?

[ton31337]

ton# show ip route 100.100.100.100/32
Routing entry for 100.100.100.100/32
  Known via "bgp", distance 20, metric 0, best
  Last update 00:00:09 ago
    172.16.13.1 (recursive), weight 1
  *   192.168.10.1, via wlp82s0, weight 1

ton# 

ton# show ip bgp 100.100.100.100/32
BGP routing table entry for 100.100.100.100/32, version 17
Paths: (1 available, best #1, table default)
  Advertised to non peer-group peers:
  127.0.0.1
  65002
    172.16.13.1 (metric 600) from 127.0.0.1 (10.10.10.10)
      Origin IGP, valid, external, best (First path received)
      Last update: Tue Sep  3 09:38:52 2024
ton# 

[Aminiok]

I have almost the same output. The only difference is at Origin IGP, metric 0,

FRR-test# show  ip route 192.168.202.0/24
Routing entry for 192.168.202.0/24
  Known via "bgp", distance 20, metric 0, best
  Last update 4d12h55m ago
  * 10.10.10.19, via eth0, weight 1

FRR-test# show  ip bgp 192.168.202.0/24
BGP routing table entry for 192.168.202.0/24, version 38
Paths: (1 available, best #1, table default)
  Advertised to non peer-group peers:
  10.10.10.19
  65555
    10.48.37.19 (metric 100) from 10.10.10.19 (10.10.10.19)
      Origin IGP, metric 0, valid, external, best (First path received)
      Last update: Thu Aug 29 18:07:39 2024