Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    TNSR initial config issues

    Scheduled Pinned Locked Moved TNSR
    7 Posts 2 Posters 1.7k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • H
      Homelabberdude
      last edited by

      Just started out with TNSR recently. Running this on ESXi with VMNET3 interfaces.

      Currently I have configured 3 interfaces, x.x.0.1/24 x.x.1.1/24 and x.x.2.1/24.
      Devices I have on these subnets are able to ping the gateways and TNSR is able to ping the devices.
      devices on x.x.0.0/24 subnet are not able to ping devices on x.x.1.0/24 or x.x.2.0/24. TNSR ping from x.x.0.1/24 interface can not reach x.x.2.1/24 interface address.

      I'm scratching my head a little bit here, from the routing table I would assume inter-subnet routing to be available.
      No ACLs/VRFs in play (other than default).
      Am I missing something simple here, maybe in the dataplane intitialization? Do I need to manually enable a loopback or something?

      DerelictD 1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate @Homelabberdude
        last edited by

        @homelabberdude Something in the network config? Default gateways? vSwitch? You have to work to prevent that kind of connectivity with tnsr. It all works by default.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        H 1 Reply Last reply Reply Quote 1
        • H
          Homelabberdude @Derelict
          last edited by

          @derelict I rebuilt the entire install twice last night. Looks like it might be an ARP issue for one of the networks. The odd part is the 2.0/24 network works flawlessly. I have no special configurations on here, I just ran through bringing up interfaces on the dataplane and assigned 2 static addresses + dhcp for the uplink on interface 5/0/0.

          I noticed in the documentation that a show interface command appears to output a local0 interfaces, this does not appear in my route table or interface list.

          I really don't understand how this ping isn't working if no ACLs are present (unless there is a hidden default acl?)

          56eaa251-ecd3-4c57-9737-6f1b895ddef8-image.png

          DerelictD 3 Replies Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate @Homelabberdude
            last edited by

            @homelabberdude There is no default ACL. If you don't put ACLs on an interface there is nothing.

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • DerelictD
              Derelict LAYER 8 Netgate @Homelabberdude
              last edited by Derelict

              @homelabberdude You're trying to ping the tnsr interface from itself using another interface address? Try using source 192.168.2.1 instead of interface

              Chattanooga, Tennessee, USA
              A comprehensive network diagram is worth 10,000 words and 15 conference calls.
              DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
              Do Not Chat For Help! NO_WAN_EGRESS(TM)

              1 Reply Last reply Reply Quote 0
              • DerelictD
                Derelict LAYER 8 Netgate @Homelabberdude
                last edited by Derelict

                @homelabberdude That command passes the interface name to ping using the -I flag which causes the packet to go out that interface (vpp8 in your case), not just be sourced from that address. 192.168.0.1 is not reachable out that interface.

                -I interface
                           interface is either an address, or an interface name. If interface is an address, it sets source address to specified
                           interface address. If interface in an interface name, it sets source interface to specified interface. NOTE: For
                           IPv6, when doing ping to a link-local scope address, link specification (by the '%'-notation in destination, or by
                           this option) can be used but it is no longer required.
                

                Chattanooga, Tennessee, USA
                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                Do Not Chat For Help! NO_WAN_EGRESS(TM)

                H 1 Reply Last reply Reply Quote 0
                • H
                  Homelabberdude @Derelict
                  last edited by

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

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.