Linux Advanced Routing & Traffic Control (LARTC) mailing list
List: lartc; ( subscribe / unsubscribe )
Info:
This is the mailing list for Linux Advanced Routing and Traffic Control discussion.
Archives:
http://www.spinics.net/lists/lartc/
www.huize.asia | www.ixp.su | Twitter
This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.
On 3/19/23 4:06 AM, Brandon Zhi wrote:
> Hi guys,
Hi,
> I'm doing a "split routing table" on my router, and I'm importing routes
> into specific kernel routing tables via bird.
> So I'm doing some strange routing by using ip rule.
I've got systems doing similar.
> [root@archlinux ~]# ip -4 rule
> 0: from all lookup local
> 32751: from 134.195.121.118 lookup 101
...
> 32766: from all lookup main
> 32767: from all lookup default
>
> As you could see, IPv4 from 134.195.121.118/32
> will using table 101
ACK
> When I am mtr to 8.8.8.8, it still uses the main route table NOT table
> 101 which does not follow the ip rule.
Have you tried using something other than `mtr`?
What happens if you simply try to use `ping` or `telnet` or `netcat`?
> [root@archlinux ~]# mtr -a 134.195.121.118 8.8.8.8
>
> [root@archlinux ~]# tcpdump -i any host 134.195.121.118
> tcpdump: data link type LINUX_SLL2
> tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
> listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot
> length 262144 bytes
Please tweak your tcpdump command line and re-run your test.
Please:
- match the source (134.195.121.118) and destination (8.8.8.8)
- disable name resolution (-n)
> As you could see, the package still using the default route table not
> table 101.
Unfortunately I'm not far enough through my cup of coffee to use the
information at hand to deduce anything.
What happens when you run the following command:
ip route get from 134.195.121.118 8.8.8.8
> This happens on Debian at the same time, and I think it's a problem
> about Linux, not just ArchLinux. I also tested passing ip -6 rule add
> from some ipv6 address table 101. It can work normally, that is to say,
> there is a matching problem with ipv4 in ip rule, but this phenomenon
> does not exist in ipv6.
I feel like this isn't a BIRD specific issue.
I've had problems in the past with ip rules relying on the source
address. I think /some/, but not all, of it has to do with when and /
or how the program in question picks the source address. Though I do
see that you specified the source (BIND) address for `mtr` via it's `-a`
option. I've also seen some systems that PBR using source address
doesn't work reliably and I never took the time to figure out why.
I think I'd re-send a copy of the message that I'm replying to off to
the Linux Advanced Routing & Traffic Control (LARTC) mailing list if I
were you as I think that's probably a better place than here. But I
wouldn't hold my breath as that list has been very hit or miss for a
while now.
--
Grant. . . .
unix || die