Hi Michael, On Thu, 2025-06-26 at 12:56 -0400, Michael Richardson wrote: > > Ferenc Fejes <ferenc.fejes=40ericsson....@dmarc.ietf.org> wrote: > > We have an open-source tool tablesnoop [0], which might be of interest > > for fellow hackers. It can trace IPv4 and IPv6 routing table lookups in > > real-time on Linux. Also, it can trace policy lookups (ip rule) > > too. The tool written in C and it has a user and kernelspace part (eBPF > > C). > > So this tells me how the FIB and, later, other tables are responding to > current uses? > > Or does this let me provide source/dest (and other tuples) in order to learn > how they would be processed?
Its the first: show the rules/FIB lookups when actual traffic processed by the network stack. Other tables not supported at the moment, but they could implemented similarly. If routing is the only concern, "ip route get" command provide similar info, like how they would processed. But this does not include NAT or other mangling I'm afraid... I'm extended the README on github with an output on the SRv6 ROSE topology [0]. While the next cSID operation not visualized by the tool yet, in the destination addresses it's clearly visible that the IPv6 DST address actually shifted hop by hop: dst: fcff:20e:70e:40e:50e:8d6:: dst: fcff:70e:40e:50e:8d6:: dst: fcff:40e:50e:8d6:: dst: fcff:50e:8d6:: dst: fcff:8d6:: > > I've often thought that the sockets API needs a "just kidding" flag, which > would send a trial packet through the entire stack, and then report how the > packet got mangled on the way. But not actually send the packet! > Then report that to the application. > > (Of course, it can't report on mangling by devices elsewhere, so it won't let > you learn what the policy-aware NAPT did to you. You still need TURN or the > various in-band OEM proposals, like Ron Bonica has been working on) That would be fun :-) Something like that would be possible using SO_MARK socket option and retis [1] tool's PCAP output, and dropping the marked packet at the POSTROUTING chain, or with a tc classifier right before the queuing. I'm not tested this however, and even if works not exactly what you proposed, but pretty close. > > > It would be great if it could trace other table lookups as well, e.g.: > > lookups in the lwtunnel infrastructure (SRv6, MPLS, VXLAN), ARP table > > lookups, bridge FDB lookups. There are also netfilter lookups, > > configured with nftables (or legacy iptables). Currently, none of these > > are supported, but some of them could be implemented with minimal > > effort. > > > I will be attending on the IETF 123 Hackathon Madrid and I plan to work > > on this tool there, the main focus will be tracing SRv6 encaps and End > > behaviors. If anyone is interested, I'm happy to show the tool and > > discuss about potential extensions and hack together. > > Feedback to applications, to the effect, that their desire for DSCP XYZ will > not be respected, or that the outbound firewall does not permit something > would be useful. The current APIs for UDP packets and ICMP replies are hard > to use. > > I recognize that's probably not the goal of tablesnoop (i read the readme..), > but this is my 6man-focused content :-) Thanks for the comment. While it is not our main priority, I mentioned nftables support in the readme as something could be implemented in the future. With that, execution of netfilter hooks would be logged. Even better, they could be dechipered to their userspace rule see this proof of concept from Toke [2]. > > > -- > Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide Best, Ferenc Fejes [0] https://github.com/netgroup/rose-srv6-tutorial/tree/master/nets/8routers-named-netns [1] https://retis.readthedocs.io/en/stable/ [2] https://blog.tohojo.dk/2023/04/netfilter-packet-drop-attribution-using-bpf.html _______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
