On Tue, 2021-06-22 at 12:21 +0300, Lyubomir Yotov wrote: > Hi Clemens, > What version of BSDRP are you using?
One of the latest, an uname -a gives me: FreeBSD amarklor.atnoc.net 14.0-CURRENT FreeBSD 14.0-CURRENT BSDRP- AMD64 amd64 > I would suggest that you check your configuration for some errors in > peers definitions in the first place. A help from a colleague of > yours would help a lot (I have had some stupid typos like using /29 > instead of /30 and the sort, also metrics here and there in route- > maps could be good place to look for errors) These are fine, I'm doing BGP on ISP Level for >20 years; I' seeing the same Problem on other prefixes too. For that matter, I just got a 'looping' -Complaint right now - I spare the BGP Info as a first. Im seeing the following information in the BSD kernel-routing table (for the IP I've got the compaint for): [root@amarklor]/etc# route -n get 149.13.75.104 route to: 149.13.75.104 destination: 149.12.0.0 mask: 255.254.0.0 gateway: 149.6.174.241 fib: 0 interface: cxl0 flags: <UP,GATEWAY,DONE,PROTO1> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 Which clearly indicates a next-Hop at 149.6.174.241 - the router of our upstream. But If I 'traceroute' the IP: [root@amarklor]/etc# traceroute -n 149.13.75.104 traceroute to 149.13.75.104 (149.13.75.104), 64 hops max, 40 byte packets 1 193.239.188.36 0.256 ms 0.333 ms 0.368 ms 2 193.239.188.38 0.270 ms 0.096 ms 0.118 ms The BSD-Kernel sends the Packets towards 193.239.188.36. Which is completely wrong. And not what the Kernel FIB klaims what will happen to the packets. I spare you with the BGP-related entries right now; I checked thema, The BGP-Paths seems correct, and all the routers in question produce correct paths (If I look at the BGP routes, everythin is correct, If I look at the kernel-routing-tables, as well the RIBs on the Ciscos: They reflect the BGP Information in a consitent manner) But for what Its worth: The BSD-kernel seems to forward the Packet towards another router. If I 'grep' all routes (from a netstat -rn) for the range in quesion one gets the following: 149.12.0.0/20 149.6.174.241 UG1 cxl0 149.12.0.0/15 149.6.174.241 UG1 cxl0 149.12.17.0/24 149.6.174.241 UG1 cxl0 149.12.70.0/24 149.6.174.241 UG1 cxl0 149.12.128.0/24 149.6.174.241 UG1 cxl0 149.12.128.0/22 149.6.174.241 UG1 cxl0 149.12.129.0/24 149.6.174.241 UG1 cxl0 149.12.130.0/24 149.6.174.241 UG1 cxl0 149.12.131.0/24 149.6.174.241 UG1 cxl0 149.12.183.0/24 149.6.174.241 UG1 cxl0 149.12.184.0/22 149.6.174.241 UG1 cxl0 149.12.200.0/24 149.6.174.241 UG1 cxl0 149.12.201.0/24 149.6.174.241 UG1 cxl0 149.12.224.0/24 149.6.174.241 UG1 cxl0 149.12.227.0/24 149.6.174.241 UG1 cxl0 149.12.241.0/24 193.239.188.34 UG1 igb0 149.12.242.0/23 193.239.188.34 UG1 igb0 149.12.244.0/24 149.6.174.241 UG1 cxl0 149.13.0.0/24 149.6.174.241 UG1 cxl0 149.13.2.0/24 149.6.174.241 UG1 cxl0 149.13.3.0/24 149.6.174.241 UG1 cxl0 149.13.16.0/24 149.6.174.241 UG1 cxl0 149.13.18.0/23 149.6.174.241 UG1 cxl0 149.13.24.0/23 149.6.174.241 UG1 cxl0 149.13.24.0/22 149.6.174.241 UG1 cxl0 149.13.25.0/24 149.6.174.241 UG1 cxl0 149.13.26.0/23 149.6.174.241 UG1 cxl0 149.13.32.0/24 193.239.188.34 UG1 igb0 149.13.65.0/24 149.6.174.241 UG1 cxl0 149.13.69.0/24 149.6.174.241 UG1 cxl0 149.13.70.0/24 149.6.174.241 UG1 cxl0 149.13.72.0/24 149.6.174.241 UG1 cxl0 149.13.78.0/23 193.239.188.34 UG1 igb0 149.13.80.0/23 193.239.188.34 UG1 igb0 149.13.82.0/24 149.6.174.241 UG1 cxl0 149.13.83.0/24 193.239.188.34 UG1 igb0 149.13.90.0/24 149.6.174.241 UG1 cxl0 149.13.94.0/24 149.6.174.241 UG1 cxl0 149.13.113.0/24 149.6.174.241 UG1 cxl0 149.13.115.0/24 149.6.174.241 UG1 cxl0 149.13.145.0/24 149.6.174.241 UG1 cxl0 149.13.146.0/24 149.6.174.241 UG1 cxl0 149.13.147.0/24 149.6.174.241 UG1 cxl0 149.13.148.0/22 149.6.174.241 UG1 cxl0 149.13.152.0/22 149.6.174.241 UG1 cxl0 149.13.156.0/22 149.6.174.241 UG1 cxl0 149.13.176.0/24 149.6.174.241 UG1 cxl0 There ar in fact some more-spefics within 149.12.0.0/15, but none for 149.13.75.104. So 149.13.75.104 is handled by 149.12.0.0/15 (compare route -n get 149.13.75.104) - but despite the *korrekt* information in the FIB, the Packets get forwardet via 193.239.188.36 (even though this Border is not referenced even once in the FIB for 149.12.0.0/15, and more specific prefixes within this network. > Another thing you could try is to reconfigure the peers one by one > but not copy and paste. Take some time to make the configurations > again. > Most probably it is a matter of configuration. > The Configuration seems pretty solid, to me; Which part could I've missed leding to packet-forwarding not matching the kernels fib? I do have *some* ipfw rules, but no redirects in there (filtering of RFC1918 (rules numered 3000), denying AS35339 SRC-Address Packets in via Upstream-Interfaces (rules 2000), such stuff. Bog-Standard basic network security rules, Required by some BCPs. And Im Blocking TR69-Syns towards our dialin-ranges (rules 04001 und 04002). Ah yes, and I'v enabled ipfw_netflow. Redirects are disabled: net.inet.ip.redirect: 0 complete ipfw show output as follows: 00100 666753 70419169 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 8 4768 deny ip from 127.0.0.0/8 to any 00400 0 0 deny ip from any to ::1 00500 0 0 deny ip from ::1 to any 00600 0 0 allow ipv6-icmp from :: to ff02::/16 00700 1264589 84841128 allow ipv6-icmp from fe80::/10 to fe80::/10 00800 704954 52076976 allow ipv6-icmp from fe80::/10 to ff02::/16 00900 16562562 2242736622 allow ipv6-icmp from any to any icmp6types 1 01000 1937949 1330602388 allow ipv6-icmp from any to any icmp6types 2,135,136 01000 70475719 73830970321 allow ip from me to any 01001 91537 13532464 allow ip from 95.129.200.0/21 to me 01002 3829904 334555883 allow ip from 193.239.188.0/23 to me 02000 1481 142567 deny ip from 95.129.200.0/21 to any in via cxl0 02001 257 22873 deny ip from 193.239.188.0/23 to any in via cxl0 02002 552 49209 deny ip from 185.65.232.0/22 to any in via cxl0 02003 0 0 deny ip6 from 2a02:b18::/32 to any in via cxl0 03001 552891 51238709 reject ip from any to 10.0.0.0/8 03002 4753 431799 reject ip from any to 172.16.0.0/12 03003 5018090 381259117 reject ip from any to 192.168.0.0/16 04001 833432 33475188 unreach port tcp from any to 95.129.200.0/21 7547 in via cxl0 setup 04002 33411 1409920 unreach port tcp from any to 185.65.232.0/22 7547 in via cxl0 setup 10000 73384539658 34867129902846 ngtee 9995 ip from any to any 65000 73552389878 34940200731572 allow ip from any to any I'm a decades user of *BSDs, I've never seen such a forwarding behaviour in my life. Is there something 'new' in 13 / or 14 Releases, I'm not aware of? some kind of caching, or new route-lookup-mechanic (going haywire, here, obviously)? If yes: Can that be disabled? > Regards, > > Lyubo > > cu Clemens. PS: I've a Hard time playing with this spefic Box, as she handles multiple GBits/s of Upstream, but I have another one, which I can setup for testing. I did intend to relayce the other upstream too (currently Cisco), but I'm currently refraining from that, until I know whats going on here. PPS: I can provide more-or-less complete configurations, If required; I do not have really sensitive information in those.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Bsdrp-users mailing list Bsdrp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bsdrp-users
