TNSR Feature Request and Bug Reporting

[khegel]

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

[matlear]

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 :)

[Florian 0]

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

[jdoodle]

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

[mleighton]

@jdoodle Thank you for your feedback! I sent you a message to ask a couple of questions.

[Ulrik]

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>

[rmccall2k16]

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.

[patrickv]

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.

[tylorswift]

This post is deleted!

[fractal_boy]

@patrickv this feature introduced in 23.11.

[fractal_boy]

@matlear DHCP relay is coming in 24.10.

[dutchman]

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.