TNSR Feature Request and Bug Reporting
-
If you have a suggestion for making TNSR better, we want to hear about it and this is the place to submit them. Here are some tips for writing a beautiful feature request.
Is it unique?
Use the search feature in TNSR documentation to double check that your idea isn’t already supported in TNSR. You may have already scanned the docs, but it is possible that you missed it and the search feature is pretty good at finding hidden gems.
Check to see if someone hasn’t already submitted a similar request in the TNSR forum. If an existing request exists, give it an upvote. Add additional details or use-cases that are missing from the original post or replies. This type of engagement and details help us with planning and prioritization.
Explain your use case
We love solving problems. So tell us a story to make the problem interesting by providing context about how the feature (or enhancement) will be used. We are likely already familiar with the feature, but we may not have thought about all the reasons a particular feature is important, so please add as much detail as possible to help with this.
Describe the problem and propose a solution
Most feature requests only describe solutions -- that is, a specific product improvement.
Make your feature request better by describing the problem you are facing, and only then proposing the feature request as one solution to that problem. You might find that the product team (or another RStudio user) proposes a different solution you hadn't thought of.
Is it a bug?
Maintaining a high standard of quality and stability in our software is always a priority, so if you think you have found a bug, please send us the details required to reproduce the bug including what you were trying to do, the expected outcome, and the observed result (screen captures, config and log files are our mutual friend).
-
This post is deleted! -
@dennis_s In future releases I would like to see IPv6 prefix delegation and router advertisement. This would be helpful in a service provider implementation.
-
A minor but useful feature would be the ability to configure a host interface gateway address. Currently, I can use the shell and modify network-scripts and that works just fine. I just don't want to create a problem that is an issue in upgrades or when making other cli configuration.
-
In addition to the PSK, it would be great to have "username/password" authentication too for the IPsec IKEv2.Some context, a feature that allows to setup a connection with a commercial VPN service provider (e.g. ProtonVPN).
-
QOS? At a minimum, egress priority queuing based on DSCP would be good.
-
I would ask you to consider incorporating RPKI support with FRR since it is available. As TNSR would be used in the edge, it would be a requirement to support this.
-
1-) syn-proxy protection
2-) match a prefix on fullroute
example:
show route dynamic bgp vrf default ipv4 neighbors x.x.x.x received-routes | match 1.1.1 -
When configuring outgoing-interface for unbound it is required to enter an IP address rather than an interface name. My WAN interface is assigned by DHCP so the IP may change. Could this configuration option be changed to allow entering an interface name as well?
fw0 tnsr(config-unbound)# outgoing-interface WAN CLI syntax error: "outgoing-interface WAN": Invalid IPv4 address -
Hi,
Would like to see DHCP Relay (unless I missed it in the documentation).
Would also like to be able to add "description" to static DHCP leases which are configured.Keep up the good work !
Thanks :)
-
@matlear +1 for DHCP Relay. I want to be able to setup a single DHCP server for all my subnets.
While I could (afaik) setup a relay agent for every subnet with Windows RAS, that would be wasted resources, especially when we are talking 10+ subnets. -
My wishlist - for router visibility via SNMP + syslog
- SNMP FRR integration for BGP stats / states
- SNMP interface ifAlias sourced from interface descriptions
- SNMP disk usage - so I can setup alerting rules at >90% usage in case logging is misconfigured and uses up all the disk space
- Easier Syslog configuration - it looks like I have to edit rsyslog.conf to enable syslogging.
On Cisco it's just "logging host 10.99.99.99", so it's quite a bit more work on TNSR.
The critical messages are BGP peer changes and interface up/down notifications
-
@jdoodle Thank you for your feedback! I sent you a message to ask a couple of questions.
-
A couple of suggestions for future release
-
CLI: Add support for showing the full current "active" configuration node name as part of the config mode prompt. example tnsr tnsr(config-ospf-if GigabitEthernet0/3/4)#
-
CLI: Add support for showing settings of the current active configuration node. Currently running show in a subbranch of the configuration tree returns unknown command rather than showing setting in that branch of the tree.
-
Add support for interface names rather than only ip addresses in settings where ip address might be assigned by dhcp. like tnsr(config-wireguard)# source-address <ip-addr> or tnsr(config-unbound)# [no] outgoing-interface <ip-address>
-
-
I'd like multicast implemented (i.e. PIM). I'd like to be able to create a rendezvous point and enable pim sparse mode to process multicast traffic amongst multiple sub interfaces. PIM BSR would be even better.
I'm also waiting for a dhcp relay functionality that allows me to forward dhcp requests to a specific dhcp server instead of relying on a L3 switch for this functionality.
-
I request to implement a | (pipe) in the CLI so it's possible to show only specific information.
For example, if you do "show nat sessions" it should be nice to have the option "show nat sessions | match 10.0.0.1" to show only the entries matching 10.0.0.1.
match could also be grep or include. -
This post is deleted! -
@patrickv this feature introduced in 23.11.
-
@matlear DHCP relay is coming in 24.10.
-
Giving us the ability to manually set interface speeds and/or duplex settings would be helpful.
Explain your use case
Say you have a TNSR router and you want to hook it up to an ISP handoff for MPLS or a mux/demux or whatever, their equipment hands off a 10Gbps link to your 10Gbps link, but they may only be providing you 2Gbps bandwidth. This can muddy the waters with OSPF if you don't statically set the link cost. Setting the reference bandwidth to 10Gb and statically setting the speed of the link to 2Gbps would then auto set the OSPF cost of the interface.
Another use case would be if you're connecting a 10Gb interface to a 1Gb interface, or some legacy equipment. I do not know the ins and outs of how TNSR negotiates speed/duplex settings, but it can't be good if TNSR decides that a link is 10Gb when it's effectively receiving 1Gbps on the other end.
Also if you're in a lab environment, like emulated Eve-NG or GNS3, not being able to set the speeds manually results in inconsistencies in how fast the link actually is so you can't get a good idea of what real-world links/routing tables are going to look like.
Describe the problem and propose a solution
I've had all of the above problems. Being able to say "speed 1000" or "speed 10000" would have been able to resolve most of my issues without having to buy more transceivers or rearrange what ports are able to dynamically negotiate speeds. (This is prevalent on the older models of TNSR hardware, where the board's NICS could not negotiate, but the add-on card could negotiate speeds).
Is it a bug?
No, just not a feature.
