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

Bridge not talking to Bridgeloop Interface

TNSR
3
3
1.3k
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.
  • F
    fargox
    last edited by fargox Mar 24, 2022, 2:26 PM Mar 24, 2022, 2:22 PM

    Hi,

    i've using TNSR in a lab with Bonding, VLAN Subinterface, BGP etc. Everything is working like expected sofar.

    Now i am trying to Bridge two Interfaces BondEthernet0.262 and GigabitEthernet6/13/0.262 with a bridgeloop Interface loop262 as bvi together.

    So far the VM behind GigabitEthernet6/13/0.262 is talking to hosts behind BondEthernet0.262 without any problems. I can ping, see arp packages an so on. But i cannot ping the loop262 bridge virtual interface on the tnsr router. I see the packet counter of loop262 rising when pinging but i don't see any arp for the router on the hosts and vm itself. The drops counter is also rising. But i have no idea how to see what is being dropped and why.

    I see the correct host mac address by using "sh neighbor" on TNSR.

    By digging deeper i don't see any packages with tcpdump on the vpp11 interface on the tnsr. When pinging from the tnsr i see packages on tcpdump but no answers.

    It seems to me that there is no connection between the both bridge interfaces and the tnsr local bridgeloop.

    tnsr(config)# interface bridge domain 262
    tnsr(config-bridge)# flood
    tnsr(config-bridge)# uu-flood
    tnsr(config-bridge)# forward
    tnsr(config-bridge)# learn
    tnsr(config-bridge)# exit
    
    tnsr(config)# int GigabitEthernet6/13/0.262
    tnsr(config-interface)# bridge domain 262
    tnsr(config-interface)# enable
    tnsr(config-interface)# exit
    tnsr(config)# int BondEthernet0.262
    tnsr(config-interface)# bridge domain 262
    tnsr(config-interface)# enable
    tnsr(config-interface)# exit
    tnsr(config)# interface loopback bridgeloop
    tnsr(config-loopback)# instance 262
    tnsr(config-loopback)# exit
    tnsr(config)# interface loop262
    tnsr(config-interface)# ip address 192.168.1.1/24
    tnsr(config-interface)# bridge domain 262 bvi
    tnsr(config-interface)# enable
    tnsr(config-interface)# exit
    

    The host 192.168.1.100 can ping 192.168.1.52 and vice versa. The first one is behind GigE6/13/0.262 the second one behind Bond0.262. So basically they are seeing each other. But neither can ping the 192.168.1.1 of the router itself.

    The tnsr is seeing the mac addresses so at least some physics must be happen here, but L3 seems to be missing.

    loop262   D             192.168.1.100 92:9c:dd:1a:2a:e9        0
    loop262   D              192.168.1.52 74:d4:35:8a:85:c9        0
    

    Any ideas?

    Best regards,

    fargox

    D 1 Reply Last reply Apr 11, 2022, 3:53 PM Reply Quote 0
    • D
      Derelict LAYER 8 Netgate @fargox
      last edited by Apr 11, 2022, 3:53 PM

      @fargox Sorry for the delay.

      In my testing of this I had no trouble using two physical interfaces as bridge members but as soon as I started trying VLAN subifs and Bonds I saw inconsistent behavior. I never saw exactly what you are describing but siminlar things like the ability to ARP in one direction but not the other, etc.

      I have opened an internal bug report on the matter.

      Thank you for posting.

      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
      • M
        Mia_white Banned
        last edited by Apr 21, 2022, 5:05 PM

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