@jimp said in DNS queryes source interface:

The name resolution at the OS level uses systemd-resolve which as far as I can see in its docs (not the TNSR docs, but the docs for the OS) does not support specifying a source address.

Using unbound to control this behavior isn't a workaround, it's the most flexible and potentially only way to configure the behavior you want.

Ok, now is perfectly clear, thank you again for your help! :)

@jimp Thanks!

@derelict When you said what are you running it on, I thought you were asking for the hardware :)

Anyway, I have turned down the config to just 1 worker. 4 were working fine since last reboot, but since a single core should also service the purpose, I'll put that to 1 worker to see if that works fine.

Thanks for the help.

@derelict Thanks, I was not aware this would imply a certain direction from the router. I appreciate the help.

I solved the issue which wasn't present on my previous design (pfsense only). It was indeed the mikrotik switch and how it handled vlans in this context a bit differently. I was able to routing going after fiddling with bridge vlans on that device.

Sadly, my throughput did not increase as I expected from placing TNSR in as a router for the network, tried some tuning with the dpdk and it just did not get where I was hoping it to go.

I'll revisit tnsr when I get my GNS3/CML lab up and running.

Turns out the service will not work without adding any filters in there. Once I add /interface as a filter, Prometheus service stands up fine showing metrics/data expected.

Thanks

TNSR is unlike traditional firewalls and routers (including pfSense). The way TNSR works it is in a tight CPU loop looking for items to process. It's completely normal and expected for it to be using 100% of its configured CPU cores. Monitoring by CPU usage isn't going to be helpful as it has zero bearing on how busy the system is.

You can get better stats from Prometheus and look at some of the rate values there, such as vector rate per worker, input rate, and vector rate.

Pretty sure this is all well covered by previous threads as well, so search around on those terms and you should find more info.

@marsalans

https://forum.netgate.com/topic/152607/tnsr-cpu-utilization-on-sg-5100

Hi @Derelict and @johnpoz and thank you,

I created a VM in proxmox and use it to install tnsr. Installed proxmox in the VM didn't read all the tnsr requirements. After all the installation I did not did much just went around support and leave it to work on the weekend and that was when i found that when I started my server couldn't access the proxmox WebGUI.
I can access to proxmox ip via ssh but I think that tnsr "took control", the reason is when i login to the server it comes root as user but not the machine name so i get foot@tnsr not root@alexserver.
So when do qm status i get:

root@TNSR:~# qm status
ipcc_send_rec[1] failed: Connection refused
ipcc_send_rec[2] failed: Connection refused
ipcc_send_rec[3] failed: Connection refused
Unable to load access control list: Connection refused
root@TNSR:~#

or pvecm updatecerts

root@TNSR:~# pvecm updatecerts
ipcc_send_rec[1] failed: Connection refused
ipcc_send_rec[2] failed: Connection refused
ipcc_send_rec[3] failed: Connection refused
Unable to load access control list: Connection refused
root@TNSR:~#

This is a server I have to learn and test ideas and so on, so as a tnsr user i am completely new and with some experience in proxmox.
I don't know what i did and I have a post in proxmox to see how i can have the WebGUI back if it helps in some way.
Is there something I can do to fix it?

Cheers,
Alex

note: i run packet sniffer, capture packets of BGP session

i see then keepalive messages and at one point tnsr with IP 10.62.40.245 sends TCP FIN and closes connection without any obvious reason

@sheebz said in TNSR on Proxmox:

@jimp ahh it needs 3 virtual nics? my server has a dual 10g nic, but i do have a node with 2 more 1gig nics. will that work? or does it have to be 3+ nics on the main machine?

It's possible to run with two (e.g. internal and external) in the dataplane only but TNSR works best when you have a management interface. The host management itself doesn't use the dataplane network, it's separate. That doesn't need to be real, it could be internal to Proxmox on a bridge to somewhere else you have a management client. There are ways to nudge things to use the dataplane from within the host for tasks like OS updates, so it's not a complete non-starter, it's just not an ideal setup.

@derelict yes i see ipfix dont giving all data sending only nat data

we cant use fastnetmon right now

if possible please add sflow exported on next version

@derelict

Well there is this page suggesting it could be supported.
https://doc.dpdk.org/guides/nics/axgbe.html
Dunno if the Epyc Embedded 3000 are the same as Ryzen Embedded regarding the NIC. Cannot find much about that.

As I own a system with a v1500b inside maybe I will just try and install TNSR and see what happens.

@indianatux OK thanks for trying that.

@jimp Thanks, I have since found that out.

Heads up for anyone else trying to get this working on CentOS, the information you are looking for to get this working is to specify the NetworkNamespace="dataplane" in your rsyslog.conf configuration. This would have been a useful tip as it goes off the typical, basic, default config in rsyslog and specific for the TNSR config.

example config for my rsyslog.conf that work for me in CentOS 8:-
action(type="omfwd"
queue.filename="tnsr_syslog"
queue.maxdiskspace="1g"
queue.saveonshutdown="on"
queue.type="LinkedList"
action.resumeRetryCount="-1"
Target="example.com" Port="514" Protocol="udp" NetworkNamespace="dataplane")

@dans I might be about to have a similar setup as yours. How did it end?
Thanks from a fellow "Dan"

@jimp Thank you sir

@viragomann My question about TNSR Home+Lab setup.

Thanks jimp. Maybe just a newbie issue. Anyway, I've got an initial build up now. Throughput is about twice as fast as testing I've done with FreeBSD packet filters but still tops out at about 3-4Gbps. I'm hoping I can improve this with tuning.

Looking forward to the next release. Debian distro's are my preferred Linux flavour 👍

@derelict
is worked thanx

@derelict Thought i would give this another shot on the latest code v21.01-588~tnsr_v21.07_1~g31b3e823e, but to no avail, but i did find somting interesting using the show hardware-interface command in vppctl it is seeing the non working interface VirtualFunctionEthernet6/0/0 MTU at 9206 and the admin up flag is not present and this error [rte_eth_dev_start[port:1, errno:-22]: Unknown error -22]. any Ideas how to look/debug further into this or do yo know what this error is?

I have also included working interface VirtualFunctionEthernet5/0/0 for comparison

vpp# sh hardware-interfaces
Name Idx Link Hardware
VirtualFunctionEthernet5/0/0 1 up VirtualFunctionEthernet5/0/0
Link speed: 10 Gbps
RX Queues:
queue thread mode
0 main (0) polling
Ethernet address 02:09:c0:99:4a:be
Intel 82599 VF
carrier up full duplex mtu 1500
flags: admin-up pmd maybe-multiseg subif tx-offload intel-phdr-cksum rx-ip4-cksum
rx: queues 1 (max 2), desc 1024 (min 32 max 4096 align 8)
tx: queues 1 (max 2), desc 1024 (min 32 max 4096 align 8)
pci: device 8086:10ed subsystem 8086:000c address 0000:05:00.00 numa 0
max rx packet len: 9728
promiscuous: unicast off all-multicast on
vlan offload: strip off filter off qinq off
rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum vlan-filter
jumbo-frame scatter keep-crc rss-hash
rx offload active: ipv4-cksum jumbo-frame scatter
tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum
tcp-tso multi-segs
tx offload active: udp-cksum tcp-cksum multi-segs
rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex ipv6-tcp
ipv6-udp ipv6-ex ipv6
rss active: ipv4-tcp ipv6-tcp-ex ipv6-tcp ipv6-udp ipv6-ex
tx burst function: ixgbe_xmit_pkts
rx burst function: ixgbe_recv_scattered_pkts_vec

tx frames ok 86 tx bytes ok 7258 rx frames ok 1325 rx bytes ok 191694 extended stats: rx_good_packets 1325 tx_good_packets 86 rx_good_bytes 191694 tx_good_bytes 7258 rx_multicast_packets 1550

VirtualFunctionEthernet6/0/0 2 up VirtualFunctionEthernet6/0/0
Link speed: 10 Gbps
RX Queues:
queue thread mode
0 main (0) polling
Ethernet address 02:09:c0:c1:84:fc
Intel 82599 VF
carrier up full duplex mtu 9206
flags: pmd maybe-multiseg subif tx-offload intel-phdr-cksum rx-ip4-cksum
rx: queues 1 (max 2), desc 1024 (min 32 max 4096 align 8)
tx: queues 1 (max 2), desc 1024 (min 32 max 4096 align 8)
pci: device 8086:10ed subsystem 8086:000c address 0000:06:00.00 numa 0
max rx packet len: 9728
promiscuous: unicast off all-multicast off
vlan offload: strip off filter on qinq off
rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum vlan-filter
jumbo-frame scatter keep-crc rss-hash
rx offload active: ipv4-cksum jumbo-frame scatter
tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum
tcp-tso multi-segs
tx offload active: udp-cksum tcp-cksum multi-segs
rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex ipv6-tcp
ipv6-udp ipv6-ex ipv6
rss active: ipv4-tcp ipv6-tcp-ex ipv6-tcp ipv6-udp ipv6-ex
tx burst function: ixgbe_xmit_pkts
rx burst function: ixgbe_recv_pkts

rx frames ok 4294966922 rx bytes ok 68719442425 Errors: rte_eth_dev_start[port:1, errno:-22: Unknown error -22

Thanks.

@gabacho4 Thanks!

@jbelthoff said in CLI syntax error: "int WAN": Unknown command:

Active Interface ens19

Okay nevermind, I see I have to remove the "Active" interfaces...

@insanesplash I get yeah, my reply is pure guess work on my part as well ;) Since I have no insight to who or how many etc. are actually using TNSR in large scale environments or even small ones.. It could be 1000's it could be 1..

I was more just commenting/guessing to why you don't see many posts about it here on the forums. I have not done any personal testing/playing with it as of yet myself - because well I don't have the lab to do it justice for one ;)