@olivertbuffet For outbound ("in2out") traffic, translation is done first and then output ACLs are evaluated. For inbound ("out2in"), it's the opposite. Input ACLs are evaluated and then translation. This matches the documentation here: https://docs.netgate.com/tnsr/en/latest/acl/acl-nat.html#acl-and-nat-interaction Where in the documentation did you see it is the same in both directions so it can be evaluated and corrected if necessary?

Another cool use case for TNSR is to use them as Spine switches running BGP as underlay and vxlan for overlay in your data center. I built a lab in GNS3 using Arista for leaf switches and it worked well. This solution will work fine in small data centers running 100G uplinks with about 3 pairs of leaf switches since the number of ports will be limited on TNSR.

I solved the problem, the NIC was down no-carrier. Once I had the interface up I was able to configure everything as I wanted. A positive note to Netgate support who gave me assistance in resolving the problem.

@fractal_boy I can confirm that specifying an interface does indeed work.

@meatprofit there is an interesting section starting from here explaining ACL https://datatracker.ietf.org/doc/html/rfc8341#section-3 As an example, if an action is defined as /interfaces/interface/reset-interface, the group must be authorized to (1) read /interfaces and /interfaces/interface and (2) execute on /interfaces/interface/reset-interface. [image: 1702463566494-7251b782-96b8-4416-98ff-cbc4da408612-image.png] glad you have solved anyway

@Qwireca FYI, TNSR 23.11 release will have a bunch of IPFIX bug fixes.

@paulwollner66 The documentation explained it rather well. https://docs.netgate.com/tnsr/en/latest/advanced/dataplane-cpu.html

@scourtney2000 said in TNSR Route Leak BGP learned routes between VRFs: but I'm not sure how to engage Netgate in Azure. https://go.netgate.com/ Include a screenshot of your Azure appliance window that shows your TAC subscription of Pro or Enterprise.

I have created a patch that achieves incrementing and decrementing the local-preference. It is the first time I have worked with yang, but I think I have checked all the boxes. Hopefully this is useful for others. local-preference.patch

@Derelict said in Route visibility: show route dynamic bgp ipv4 network 1.1.1.1 Thank you. That was exactly what I was looking for :)

I want to back up a little bit and ask what your specific goal is currently. I would like to get a better handle on your intended use case, as exploring new features and use cases for TNSR is something I am quite interested in. As I understand it currently, your goal was to create a container on to run iperf3 from? Is your reasoning for the container because you didn't see a way of running the iperf3 binary in a way that was accessible from the dataplane networks? Or was your goal to provide isolation to the iperf3 service AND have it be accessible from the dataplane networks? Are you using iperf3 in these posts as just an example of a generic application to run in a container or link to the dataplane, with the intention of running other applications after you found a solution to an example application? I would say all of the above. My self built test box that has enough cores to support multiple services. So I was looking to put those cores and memory to some use, such that I don't need another system. TNSR AIO if you want. Ideally those services running should support some sort of resource contention. The linux kernel provides that via cgroups with a multitude of implementation. Docker being just one of them. Of course we should isolate/reserve/dedicate some cores for TNSR and DPDK only. iperf was indeed an example. This would eventually imply that our monitoring system performs and records regular tests. I work for a Swiss university so we already use that to measure different parts of our network. Nothing out of ordinary here. Anyway the generic application sounds more likely to what I would like to achieve. I was thinking to expose a webserver for an not so trustworthy containerized App through the TNSR dataplane. If this gets compromised it should not be possible to influence the TNSR router. I saw on the VPP wiki they have nginx examples I would try that next. I am not sure(I forgot to check) if that iperf port is exposed on all TNSR interfaces. I would probably need to apply some ACLs. Btw. do the TNSR ACLs protect/work against packet fragmentation attacks? Are the TNSR ACLs the VPP ones? The TNSR Docu is not clear about that... I hope it explains a bit more my use case.

@insmod does it work for you? I tried it, however it is not exporting the data into cloud.

Thanks for the reply, we don't have any support or access from Adva as it's supplied by the carrier. This circuit is also being terminated at the end of next month (the entire reason I've been using it to test, as we've already moved traffic away from it). I've done further tests, I put a Mikrotik between the TNSR box and the Adva and I can verify via a pcap that the traffic is being transmitted out of TNSR, I can verify it's also leaving the Mikrotik to the Adva - and in Wireshark it looks in no way obviously different to the none dropped pings. Where it gets odd is the Mikrotik now gets packet loss to the other side of the Adva. It didn't used to, so I am thinking the issue is very much on the adva/carrier side and not the tnsr side. Just it only manifested itself when we started to test tnsr. So we jumped to the conclusion that it was an issue in tnsr. I think in this situation I'm going to have to ask the carrier to investigate.

@jimp Looking forward to the early realization of 10 Gigabit home network is being popularized

@meatprofit So I had it on 12 before for no particular reason other than there is too many cpu cores on the system, but I reduced it to 6 to get rid of the memory/crash problem in 23.06-3.

@paolobyte average 5 min speed will added soon under "show interface"

@jimp Sorry for being so slow. Forgetting to check in to a new forum :) I think in iptables --syn actually only hit packets with SYN and ACK,RST and FIN bits cleared. Do I understand correctly if the rule, Iptable -A <chain> -j Deny -s <network> -p tcp --syn Translates to , action drop ip-version ipv4 source destination <network> protocol tcp tcp flags value 2 mask 18 Reason being "tcp flags value 2 mask 18" will only hit if SYN flag is set. It can't match the whole mask, that is to say ACK must not be set. Illegal combinations like SYN+RST will be ignored as it's not part of the mask. Other flag combinations will not be a hit as a SYN flag is not set. I guess I have a hard time getting that it's not like this. Value nominates what flag need to be set to start a match against the mask. The mask must be fulfilled to trigger the rule. This gives that "tcp flags value 2 mask 18" would only start check if SYN is set, and the rule would only trigger if the packet have SYN+ACK.

@michmoor we use elastic with filebeat module for netflow collection