@Derelict
done.
this time got an email.
thanks

@MatthaeusHarris

All existing MIBs are net-snmp core. There is no defined MIB for Netgate or VPP specific OIDs.

Were you looking to do something specific that the core MIBs do not provide?

That makes a lot of sense. A system, or person for that matter, waiting to be told to work will never be as responsive as one that is at the ready to pounce.

Thank you Dennis your reply is very helpful.

I do look forward to seeing the new trial model for TNSR I'm very excited about that!

Hi Shem,

Thanks for bringing this to our attention. As we have been discussing over email, we have reproduced the issue and working on it.

Emre

Fine thanks, nice to hear back. Also autoselect is the default when setting up an interface so that should have been the case for you, too. So if you configured it manually no wonder it failed the auto-negotiating and thus reported no L2 carrier :)

But good for you that it worked out and you found it! Just let it on auto-negotiating the next time ;)

@IsaacFL thanks! We'll certainly consider a simple NAT64 implementation in TNSR.

Right now, the primary request has been from carriers who need to transit IPv4 traffic across their IPv6 backbone networks. I'm always open to hearing about other uses though. Thanks for the feedback!

@talwell Any host needs a default route if it is to reach anything not localy resolvable by arp. It is also called the default gateway.
In many linux systems the default gateway is defined as a default (static) route and it IS required in most situations.

The discussion here is about tensor (tnsr). Even though my knowledge on tensor is close to none, it seems that it has its own routing table and is not using the routing table of its centos7 host os. So it is like having two machines in one, and obviously static routing is required for the two systems to route traffic.
I believe this is by design.