<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi Grant,</div><div><br></div><div>Thanks for the reply.</div><div><br></div><div>I have recently tested ip rule on my company's server.</div><div>Our network structure is like this.</div><div> <br></div><div> GRE<br></div><div>Server(IN) >>>>> Server(SG)>>> upstream.</div><div><br></div><div>The ip rule on Server(IN)</div><div><br></div><div>0: from all lookup local<br>32760: from all iif gre_sg lookup 147<br>32762: from <a href="http://156.236.18.0/24" target="_blank">156.236.18.0/24</a> lookup 147<br>32763: from <a href="http://185.81.217.0/24" target="_blank">185.81.217.0/24</a> lookup 147<br>32764: from <a href="http://46.23.100.0/22" target="_blank">46.23.100.0/22</a> lookup 147<br>32765: from <a href="http://46.23.110.0/24" target="_blank">46.23.110.0/24</a> lookup 147<br>32766: from all lookup main<br>32767: from all lookup default<br><br></div><div><br></div><div>20230227:~# ip route get 8.8.8.8<br>8.8.8.8 via 139.84.140.1 dev enp1s0f0 src 139.84.140.60 uid 0 <br> cache <br></div><div><br></div><div>root@20230227:~# ip route show table 147 | grep <a href="http://8.8.8.0/24" target="_blank">8.8.8.0/24</a><br><a href="http://8.8.8.0/24" target="_blank">8.8.8.0/24</a> via 10.0.5.1 dev gre_sg proto bird metric 32 <br></div><div><br></div><div>When I did ping -B 46.23.100.0 8.8.8.8 on the server (IN), I'm not sure how to bind the source address by using ping.</div><div><br></div><div>20230227:~# ping -B 46.23.100.0 8.8.8.8<br>PING 8.8.8.8 (8.8.8.8) from 46.23.100.0 : 56(124) bytes of data.<br><br></div><div>20230227:~# tcpdump -i any host 46.23.100.0 -n<br>tcpdump: data link type LINUX_SLL2<br>tcpdump: verbose output suppressed, use -v[v]... for full protocol decode<br>listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes<br>10:57:09.328396 lo In IP 46.23.100.0 > <a href="http://46.23.100.0" target="_blank">46.23.100.0</a>: ICMP echo request, id 47075, seq 1, length 64<br>10:57:10.360390 lo In IP 46.23.100.0 > <a href="http://46.23.100.0" target="_blank">46.23.100.0</a>: ICMP echo request, id 47075, seq 2, length 64<br>10:57:11.384382 lo In IP 46.23.100.0 > <a href="http://46.23.100.0" target="_blank">46.23.100.0</a>: ICMP echo request, id 47075, seq 3, length 64<br>10:57:12.408391 lo In IP 46.23.100.0 > <a href="http://46.23.100.0" target="_blank">46.23.100.0</a>: ICMP echo request, id 47075, seq 4, length 64<br>10:57:13.432389 lo In IP 46.23.100.0 > <a href="http://46.23.100.0" target="_blank">46.23.100.0</a>: ICMP echo request, id 47075, seq 5, length 64<br>10:57:14.456384 lo In IP 46.23.100.0 > <a href="http://46.23.100.0" target="_blank">46.23.100.0</a>: ICMP echo request, id 47075, seq 6, length 64<br>10:57:15.480390 lo In IP 46.23.100.0 > <a href="http://46.23.100.0" target="_blank">46.23.100.0</a>: ICMP echo request, id 47075, seq 7, length 64<br>10:57:16.504398 lo In IP 46.23.100.0 > <a href="http://46.23.100.0" target="_blank">46.23.100.0</a>: ICMP echo request, id 47075, seq 8, length 64<br></div><div><br></div><div>Then I tried MTR<br></div><div><br></div><div>20230227:~# mtr -a 46.23.100.0 8.8.8.8<br></div><div><br></div><div>The output from tcpdump shows that it's still using the default table, not table 147.<br></div><div><br></div><div>ip007-20230227:~# tcpdump -i any host 46.23.100.0 -n<br>tcpdump: data link type LINUX_SLL2<br>tcpdump: verbose output suppressed, use -v[v]... for full protocol decode<br>listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes<br>10:59:28.525837 enp1s0f0 Out IP 46.23.100.0 > <a href="http://8.8.8.8" target="_blank">8.8.8.8</a>: ICMP echo request, id 50435, seq 33038, length 44<br>10:59:28.597606 enp1s0f0 Out IP 46.23.100.0 > <a href="http://8.8.8.8" target="_blank">8.8.8.8</a>: ICMP echo request, id 50435, seq 33039, length 44<br>10:59:28.669374 enp1s0f0 Out IP 46.23.100.0 > <a href="http://8.8.8.8" target="_blank">8.8.8.8</a>: ICMP echo request, id 50435, seq 33040, length 44<br>10:59:28.741155 enp1s0f0 Out IP 46.23.100.0 > <a href="http://8.8.8.8" target="_blank">8.8.8.8</a>: ICMP echo request, id 50435, seq 33041, length 44<br>10:59:28.812956 enp1s0f0 Out IP 46.23.100.0 > <a href="http://8.8.8.8" target="_blank">8.8.8.8</a>: ICMP echo request, id 50435, seq 33042, length 44<br>10:59:28.884728 enp1s0f0 Out IP 46.23.100.0 > <a href="http://8.8.8.8" target="_blank">8.8.8.8</a>: ICMP echo request, id 50435, seq 33043, length 44<br>10:59:28.956542 enp1s0f0 Out IP 46.23.100.0 > <a href="http://8.8.8.8" target="_blank">8.8.8.8</a>: ICMP echo request, id 50435, seq 33044, length 44<br>10:59:29.028369 enp1s0f0 Out IP 46.23.100.0 > <a href="http://8.8.8.8" target="_blank">8.8.8.8</a>: ICMP echo request, id 50435, seq 33045, length 44<br>10:59:29.100148 enp1s0f0 Out IP 46.23.100.0 > <a href="http://8.8.8.8" target="_blank">8.8.8.8</a>: ICMP echo request, id 50435, seq 33046, length 44<br></div><div><br></div><div>However, when I use netcat. It follows the ip rule.<br></div><div><br></div><div>-20230227:~# nc -s 46.23.100.0 -u 8.8.8.8 53<br>hello<br></div><div><br></div><div><div><br></div>tcpdump output on Server(IN)</div><div><br></div><div>20230227:~# tcpdump -i any host 46.23.100.0 -n<br>tcpdump: data link type LINUX_SLL2<br>tcpdump: verbose output suppressed, use -v[v]... for full protocol decode<br>listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes<br>10:59:28.525837 enp1s0f0 Out IP 46.23.100.0 > <a href="http://8.8.8.8" target="_blank">8.8.8.8</a>: ICMP echo request, id 50435, seq 33038, length 44<br>10:59:28.597606 enp1s0f0 Out IP 46.23.100.0 > <a href="http://8.8.8.8" target="_blank">8.8.8.8</a>: ICMP echo request, id 50435, seq 33039, length 44<br>10:59:28.669374 enp1s0f0 Out IP 46.23.100.0 > <a href="http://8.8.8.8" target="_blank">8.8.8.8</a>: ICMP echo request, id 50435, seq 33040, length 44<br>10:59:28.741155 enp1s0f0 Out IP 46.23.100.0 > <a href="http://8.8.8.8" target="_blank">8.8.8.8</a>: ICMP echo request, id 50435, seq 33041, length 44<br>10:59:28.812956 enp1s0f0 Out IP 46.23.100.0 > <a href="http://8.8.8.8" target="_blank">8.8.8.8</a>: ICMP echo request, id 50435, seq 33042, length 44<br>10:59:28.884728 enp1s0f0 Out IP 46.23.100.0 > <a href="http://8.8.8.8" target="_blank">8.8.8.8</a>: ICMP echo request, id 50435, seq 33043, length 44<br>10:59:28.956542 enp1s0f0 Out IP 46.23.100.0 > <a href="http://8.8.8.8" target="_blank">8.8.8.8</a>: ICMP echo request, id 50435, seq 33044, length 44<br>10:59:29.028369 enp1s0f0 Out IP 46.23.100.0 > <a href="http://8.8.8.8" target="_blank">8.8.8.8</a>: ICMP echo request, id 50435, seq 33045, length 44<br>10:59:29.100148 enp1s0f0 Out IP 46.23.100.0 > <a href="http://8.8.8.8" target="_blank">8.8.8.8</a>: ICMP echo request, id 50435, seq 33046, length 44<br><br></div><div><br></div><div>tcpdump output on Server(SG)<br></div><div><br></div><div>-2252644:~# tcpdump -i any host 46.23.100.0 -n<br>tcpdump: data link type LINUX_SLL2<br>tcpdump: verbose output suppressed, use -v[v]... for full protocol decode<br>listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes<br>11:01:25.167122 vultr_IN In IP 46.23.100.0.14417 > 8.8.8.8.53: domain [length 6 < 12] (invalid)<br>11:01:25.167142 eth0 Out IP 46.23.100.0.14417 > 8.8.8.8.53: domain [length 6 < 12] (invalid)<br><br></div><div>The income packages disappear, I don't think it's related to this question. Perhaps DNS should not reply to my "hello" package or I misconfigure the BGP session, which causes the income packages to go to another server.<br></div><div><br></div><div>So maybe some software like mtr does not follow the IP rule? Even though the source address is selected.</div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Linux Advanced Routing & Traffic Control (LARTC) mailing list </blockquote><div><br></div><div>I have subscribed to the mailing list on here, could you CC <a href="mailto:brandon@huize.asia">brandon@huize.asia</a> for the thread?</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">List: lartc; ( subscribe / unsubscribe )<br>Info:<br> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>This is the mailing list for Linux Advanced Routing and Traffic Control discussion.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Archives:<br> <a href="http://www.spinics.net/lists/lartc/">http://www.spinics.net/lists/lartc/</a></blockquote><br> <br>Best,</div><div><br></div><div><div dir="ltr"><div dir="ltr"><div style="color:rgb(0,0,0);font-family:"lucida Grande",Verdana;font-size:14px"><b style="font-size:12px;color:rgb(24,43,75);font-family:Helvetica,sans-serif">Brandon Zhi</b></div><div style="color:rgb(0,0,0);font-family:"lucida Grande",Verdana;font-size:14px"><font face="Helvetica, sans-serif" color="#5f5f5f"><span style="font-size:10.6667px">HUIZE LTD</span></font></div><div style="color:rgb(0,0,0);font-family:"lucida Grande",Verdana;font-size:14px"><p class="MsoNormal" style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small"><span style="font-size:8pt;font-family:Helvetica,sans-serif;color:black" lang="EN-HK"><a href="https://huize.asia/" style="outline:none;color:rgb(40,108,69)" target="_blank"><span style="color:rgb(4,74,145)">www.huize.asia</span> </a>| <a href="https://www.ixp.su/" style="outline:none;color:rgb(40,108,69)" target="_blank"><span style="color:rgb(4,74,145)">www.ixp.su</span></a> | Twitter</span></p><p class="MsoNormal" style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small"><br></p><p class="MsoNormal" style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small">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.</p></div></div></div></div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 19 Mar 2023 at 17:07, Grant Taylor via Bird-users <<a href="mailto:bird-users@network.cz" target="_blank">bird-users@network.cz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3/19/23 4:06 AM, Brandon Zhi wrote:<br>
> Hi guys,<br>
<br>
Hi,<br>
<br>
> I'm doing a "split routing table" on my router, and I'm importing routes <br>
> into specific kernel routing tables via bird.<br>
> So I'm doing some strange routing by using ip rule.<br>
<br>
I've got systems doing similar.<br>
<br>
> [root@archlinux ~]# ip -4 rule<br>
> 0: from all lookup local<br>
> 32751: from 134.195.121.118 lookup 101<br>
...<br>
> 32766: from all lookup main<br>
> 32767: from all lookup default<br>
> <br>
> As you could see, IPv4 from <a href="http://134.195.121.118/32" rel="noreferrer" target="_blank">134.195.121.118/32</a> <br>
> will using table 101<br>
<br>
ACK<br>
<br>
> When I am mtr to 8.8.8.8, it still uses the main route table NOT table <br>
> 101 which does not follow the ip rule.<br>
<br>
Have you tried using something other than `mtr`?<br>
<br>
What happens if you simply try to use `ping` or `telnet` or `netcat`?<br>
<br>
> [root@archlinux ~]# mtr -a 134.195.121.118 8.8.8.8<br>
> <br>
> [root@archlinux ~]# tcpdump -i any host 134.195.121.118<br>
> tcpdump: data link type LINUX_SLL2<br>
> tcpdump: verbose output suppressed, use -v[v]... for full protocol decode<br>
> listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot <br>
> length 262144 bytes<br>
<br>
Please tweak your tcpdump command line and re-run your test.<br>
<br>
Please:<br>
- match the source (134.195.121.118) and destination (8.8.8.8)<br>
- disable name resolution (-n)<br>
<br>
> As you could see, the package still using the default route table not <br>
> table 101.<br>
<br>
Unfortunately I'm not far enough through my cup of coffee to use the <br>
information at hand to deduce anything.<br>
<br>
What happens when you run the following command:<br>
<br>
ip route get from 134.195.121.118 8.8.8.8<br>
<br>
> This happens on Debian at the same time, and I think it's a problem <br>
> about Linux, not just ArchLinux. I also tested passing ip -6 rule add <br>
> from some ipv6 address table 101. It can work normally, that is to say, <br>
> there is a matching problem with ipv4 in ip rule, but this phenomenon <br>
> does not exist in ipv6.<br>
<br>
I feel like this isn't a BIRD specific issue.<br>
<br>
I've had problems in the past with ip rules relying on the source <br>
address. I think /some/, but not all, of it has to do with when and / <br>
or how the program in question picks the source address. Though I do <br>
see that you specified the source (BIND) address for `mtr` via it's `-a` <br>
option. I've also seen some systems that PBR using source address <br>
doesn't work reliably and I never took the time to figure out why.<br>
<br>
I think I'd re-send a copy of the message that I'm replying to off to <br>
the Linux Advanced Routing & Traffic Control (LARTC) mailing list if I <br>
were you as I think that's probably a better place than here. But I <br>
wouldn't hold my breath as that list has been very hit or miss for a <br>
while now.<br>
<br>
<br>
<br>
-- <br>
Grant. . . .<br>
unix || die<br>
</blockquote></div>