Routes and next hops

Captured 2026-08-03 from one CE of this deployment.

Argo keeps forwarding state separate from the Linux kernel. When ip and these commands disagree, these commands are what moves traffic.

rt

The vRouter route table, per VRF.

{"command":["rt","--dump","2"]}

Flags: L=Label Valid, P=Proxy ARP, T=Trap ARP, F=Flood ARP, H=Proxy ARP for host interface, V=Preferred VRF
Labels/Misc: S=SiteId N=NetworkId
vRouter inet4 routing table 0/2/unicast
Destination           PPL        Flags        Label         Nexthop  Labels/Misc
                                 Number of routes: 4

0.0.0.0/0               0                       -              0
169.254.254.102/32     32            L        263             13
172.16.12.126/32       32            L          0             46     (S,N):2298:0
172.16.84.126/32       32            L          0             46     (S,N):2298:0

The VRF id is not the one BGP reports

show-ip-bgp-summary prints vrf-id 3. That is FRR’s numbering and it is a different namespace from the vRouter table id. Passing it here fails in a way that reads as a broken node:

vRouter(Response):  [No such file or directory (2)]

The same answer comes back for --dump 0. On this topology VRF 2 is the populated inet4 table, with VRF 1 holding two routes. If you do not know the id, probe upward from 1 rather than trusting the BGP output.

nh

The next-hop table. Every route points at a next-hop id, and this resolves them.

{"command":["nh","--list"]}

Id:0          Type:Drop           Fmly: AF_INET  Rid:0  Vrf:0
              Flags:Valid, Tunnel: None

Id:1          Type:Drop           Fmly: AF_INET  Rid:0  Vrf:0
              Flags:Valid, Tunnel: None

Id:2          Type:Receive        Fmly: AF_INET  Rid:0  Vrf:1
              Flags:Valid, Policy, Tunnel: Udp,
              Oif:0

Id:3          Type:Receive        Fmly: AF_INET  Rid:0  Vrf:2
              Flags:Valid, Policy, Tunnel: Udp,
              Oif:0

Id:4          Type:Receive        Fmly: AF_INET  Rid:0  Vrf:3
              Flags:Valid, Policy, Tunnel: Udp,
              Oif:0

Id:5          Type:Receive        Fmly: AF_INET  Rid:0  Vrf:4
              Flags:Valid, Policy, Tunnel: Udp,
              Oif:0

Id:6          Type:Vrf_Translate  Fmly: AF_INET  Rid:0  Vrf:1
              Flags:Valid, Policy, Tunnel: None

Id:7          Type:Vrf_Translate  Fmly: AF_INET  Rid:0  Vrf:2
              Flags:Valid, Policy, Tunnel: None

Id:8          Type:Vrf_Translate  Fmly: AF_INET  Rid:0  Vrf:3
              Flags:Valid, Policy, Tunnel: None

Id:9          Type:Vrf_Translate  Fmly: AF_INET  Rid:0  Vrf:4
              Flags:Valid, Policy, Tunnel: None

Id:10         Type:Vrf_Translate  Fmly: AF_INET  Rid:0  Vrf:5
              Flags:Valid, Policy, Tunnel: None

Id:11         Type:Vrf_Translate  Fmly: AF_INET  Rid:0  Vrf:6
              Flags:Valid, Policy, Tunnel: None

Id:12         Type:Encap          Fmly: AF_INET  Rid:0  Vrf:1
              Flags:Valid, Policy, Tunnel: None
              Oif:2  Len:14
              Encap Data: 02 01 02 03 04 05 00 00 5e 00 01 00 08 00

Id:13         Type:Encap          Fmly: AF_INET  Rid:0  Vrf:2
              Flags:Valid, Policy, Tunnel: None
              Oif:4  Len:14
              Encap Data: 02 01 02 03 04 06 00 00 5e 00 01 00 08 00

Id:14         Type:Encap          Fmly: AF_INET  Rid:0  Vrf:3
              Flags:Valid, Policy, Tunnel: None
              Oif:6  Len:14
              Encap Data: 00 00 5e 00 02 00 00 00 5e 00 01 00 08 00

Id:15         Type:Encap          Fmly: AF_INET  Rid:0  Vrf:6
              Flags:Valid, Policy, Tunnel: None
              Oif:10  Len:14
              Encap Data: 02 01 02 03 04 09 00 00 5e 00 01 00 08 00


... [capture trimmed: first 60 of 3820 lines]

Each entry carries a Type and the VRF it belongs to. Eight types occur on these nodes, in these proportions — identical across all three CEs when counted:

Tunnel 558   Encap 27   NAT 22   Vrf 16   Receive 14   Composite 4   Drop 2   Resolve 2

A route resolving to a Drop next hop is a blackhole, and that combination is worth checking whenever a prefix is present in rt yet traffic still disappears.

The capture above is trimmed, so it does not contain every type

It is the first 60 lines of 3,849. Tunnel, the most common type by a wide margin, does not appear in those 60 at all — so do not read the capture as the full type inventory, and do not conclude a type is absent from a node because it is absent from a trimmed capture. The counts above came from the untrimmed response.

vif

The virtual interface table: what the data plane binds to, and per-interface counters.

{"command":["vif","--list"]}

Vrouter Interface Table

Flags: P=Policy, X=Cross Connect, S=Service Chain, Mr=Receive Mirror
       Mt=Transmit Mirror, Tc=Transmit Checksum Offload, L3=Layer 3, L2=Layer 2
       D=DHCP, Vp=Vhost Physical, Pr=Promiscuous, Vnt=Native Vlan Tagged
       Mnp=No MAC Proxy, Dpdk=DPDK PMD Interface, Rfl=Receive Filtering Offload, Mon=Interface is Monitored
       Nf=Dont Fragment, Vof=VLAN insert/strip offload, Mq=MultiQ, L=MAC Learning Enabled
       Proxy=MAC Requests Proxied Always, Fr=Force Recv, Mn=Mirror without Vlan Tag, TTL=TTL not modified
       Mn=Mirror without Vlan Tag, Tun=Tunnel, NoArp=No ARP interface, RawIp=RAW IP interface(No L2 header)
       Npers=Non-Persistent, NoRPF=No RPF Checks, SynC=Syn Cookies, Gro=GRO Enabled
       NoIpfix=IPFIX disabled

evif0/1     Virtual: eth0 (Speed 10000, Duplex 1) Parent:vif0/-1
            Type:Physical HWaddr:60:45:bd:eb:3f:f2  Driver: net_failsafe
            CrossConnectIdx: 2 PartnerIdx: 14
            Vrf:0 Mcast Vrf:0 VN:0x0 Flags:L3L2Vp Ref:7
            MTU: 1500 EncMSS: 0 NH: 0
            RX device packets:386252  bytes:355098338 errors:0
            RX port   packets:386252 errors:0
            RX queue  packets:385977 errors:0
            RX queue errors to lcore 0 0 0 0 0 0 0 0 0 0 0 0 0 0
            RX packets:386252  bytes:355098338 errors:0
            TX packets:274826  bytes:132476854 errors:0
            Drops:0
            TX queue  packets:27 errors:0
            TX port   packets:274826 errors:0
            TX device packets:274826  bytes:132476854 errors:0

evif0/2     Virtual: vhost0 Parent:vif0/-1
            Type:Host HWaddr:60:45:bd:eb:3f:f2  Driver: vr_dpdk_tap
            CrossConnectIdx: 1 PartnerIdx: 15
            Vrf:0 Mcast Vrf:0 VN:0x0 Flags:L3L2 Ref:6
            MTU: 1500 EncMSS: 0 NH: 0
            RX device packets:263582  bytes:122772389 errors:0
            RX queue  packets:263582 errors:0
            RX queue errors to lcore 0 0 0 0 0 0 0 0 0 0 0 0 0 0
            RX packets:263582  bytes:120136569 errors:0
            TX packets:374276  bytes:343331787 errors:0
            Drops:0
            TX queue  packets:370829 errors:3447
            TX device packets:370820  bytes:341968151 errors:9

vif0/2      Ethernet: vethfrr0 Parent:vif0/-1
            Type:Virtual HWaddr:0:0:5e:0:1:0  Driver: net_af_packet
            Vrf:1 Mcast Vrf:1 VN:0x0 Flags:PL3Proxy Ref:10
            MTU: 1500 EncMSS: 130 NH: 12
            RX port   packets:4919 errors:0
            RX queue  packets:4917 errors:0
            RX queue errors to lcore 0 0 0 0 0 0 0 0 0 0 0 0 0 0
            RX packets:907  bytes:153742 errors:0
            TX packets:6  bytes:444 errors:0
            Drops:905
            TX queue  packets:346 errors:0
            TX port   packets:3987 errors:0
            Ingress ACL: 65 67
            Egress ACL: 65 67
            Service ACL: 65 67

vif0/4      Ethernet: vethbfd0 Parent:vif0/-1
            Type:Virtual HWaddr:0:0:5e:0:1:0  Driver: net_af_packet

... [capture trimmed: first 60 of 378 lines]

The flags legend at the top is worth reading once — Vp marks the vhost physical interface, Dpdk a DPDK-managed one. Use this to confirm the data plane has claimed the interface you expect, and to see RX and TX counters that Linux does not show because the traffic never reaches the kernel.

mpls

execcli mpls --help

The Argo MPLS table. Reachable only from the box — mpls is not on the debug API, so unlike rt, nh and vif above it needs SSH or the serial console, through execcli.

No captured output here. On this deployment the CE forwards IPv4 with BGP and ECMP and does not use MPLS labels, so a capture would show an empty table and teach nothing. Its existence and its --help argument form are verified from the appliance’s own completion menu; its populated output is not reproduced.