ea74c66d-e6b1-43ac-adec-f892d5d69899-image.png

@jwt said in Does TNSR support PPPOE client and UPNP service ?:

Of note: we have recently developed a new pppoe stack for FreeBSD (and thus pfsense) which avoids using netgraph. It is netgraph which is causing the poor performance, and the single-threading. I’d expect that code to make its way to a pfsense release in the next six months.

I also expect to be able to leverage that code (which we control the copyright to) to be able to implement a VPP based pppoe client for Netgate products.

This is extraordinary good news and somewhat buried in this thread. Happy to run tests on one of my routers when you need feedback. 👑

thanks all for your input. GNS3 and EVE-NG images are on our radar. We are working on this.

this was their answer:

"If you get 3 Full Views, please check this guide: https://docs.netgate.com/tnsr/en/latest/dynamicrouting/bgp/tuning.html"

well... yes thank you.

After reading a comment in this thread - https://www.reddit.com/r/Netgate/comments/1bzsv4m/the_sfp_10gbaset_80m_copper_rj45_transceiver_for/ - I found the problem.

I was testing to a 1gig port on a Cisco switch. Temporarily moved it to a 10G port on a server and the interface is up and working.

did you try something like this?

R1 tnsr(config)# sh run route route table ipv4-VRF:0 id 0 route 0.0.0.0/0 next-hop 0 via 10.100.1.2 e1 next-hop 1 via 10.100.0.2 e2 exit exit R1 tnsr(config)# sh route Route Table ipv4-VRF:0 AF: ipv4 ID: 0 ----------------------------------------- 0.0.0.0/0 via 10.100.0.2 e2 weight 1 preference 0 via 10.100.1.2 e1 weight 1 preference 0

@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.