Bridge Interfaces

Bridges connect multiple interfaces together bidirectionally, linking the networks on bridge members together into a single bridge domain. The net effect is similar to the members being connected to the same layer 2 or switch.

This is commonly used to connect interfaces across different types of links, such as Ethernet to VXLAN. Another common use is to enable filtering between two segments of the same network. It could also be used to allow individual ports on TNSR to act in a manner similar to a switch, but unless filtering is required between the ports, this use case is not generally desirable.


Bridges connect together multiple layer 2 networks into a single larger network, thus it is easy to unintentionally create a layer 2 loop if two bridge members are already connected to the same layer 2. For example, the same switch and VLAN.

There are two components to a bridge: The bridge itself, and the interfaces which are members of the bridge.

Bridge Configuration

Creating a Bridge

A bridge is created by the interface bridge domain <bdi> command, available in config mode. This command enters config-bridge mode where the following options are available:

arp entry ip <ip-addr> mac <mac-addr>:

Configures a static ARP entry on the bridge. Entries present will be used directly, rather than having TNSR perform an ARP request flooded on all bridge ports to locate the target. Additionally, when a bridge is not set to learn MACs, these entries must be created manually to allow devices to communicate across the bridge.

arp term:

Boolean value that when present enables ARP termination on this bridge. When enabled, TNSR will terminate and respond to ARP requests on the bridge. Disabled by default.

description <text>:

A brief description of the bridge for reference purposes.


Boolean value that when present enables Layer 2 flooding. When TNSR cannot locate the interface where a request should be directed on the bridge, it is flooded to all ports.


Boolean value that when present enables Layer 2 unicast forwarding. Allows unicast traffic to be forwarded across the bridge.


When present, enables Layer 2 learning on the bridge.

mac-age <minutes>:

When set, enables MAC aging on the bridge using the specified aging time.


When present, enables Layer 2 unknown unicast flooding.


At least one of flood, forward, learn, or uu-flood must be enabled when creating a bridge for it to be valid.

Bridge Interface Settings

To add an interface to a bridge as a member, the following settings are available from within config-interface mode:

bridge domain <domain-id> [bvi] [shg <n>]
domain id:

Bridge Domain ID, corresponding to the ID given when creating the bridge interface previously.


Boolean value that when present indicates that this is a Bridged Virtual Interface (BVI). A bridge connects multiple interfaces together but it does not connect them to TNSR. A BVI interface, typically a loopback, allows TNSR to participate in the bridge for routing and other purposes.

An L3 packet routed to the BVI will have L2 encapsulation added and then is handed off to the bridge domain. Once on the bridge domain, the packet may be flooded to all bridge member ports or sent directly if the destination is known or static. A packet arriving from the bridge domain to a BVI will be routed as usual.


A bridge domain may only contain one BVI member.

shg <n>:

A Split Horizon Group (SHG) identifier. Can be used with any interface that carries Layer 2 data (e.g. Hardware interfaces, L2 GRE tunnels, etc.), but is primarily used with VXLAN interfaces.

When a non-zero SHG is configured on a member of a bridge domain, TNSR will not forward packets arriving on that interface to any other members of the bridge domain configured with the same SHG identifier. This can be useful to prevent packets from looping back across member interfaces which are meshed between peers.

A value of 0 disables the SHG check.

Using ACLs with Bridges

There are two main scenarios to consider when crafting ACLs (Access Lists) for use with bridges and their member interfaces:

Packets forwarded within a bridge domain

The first scenario is filtering packets forwarded within a single bridge domain. For example, packets which arrive on one bridge domain member interface and are sent on another bridge domain member interface.

In this case, apply the access list to one or more individual member interfaces of the bridge domain. Applying an access list to the BVI loopback interface will not have any effect on these packets as the packet does not enter or exit the bridge or the BVI interface.

Packets routed between a bridge and an L3 hardware interface

The second scenario is filtering packets routed between a bridge domain and an L3 hardware interface which is not a member of the bridge.

In this case, packets are entering or exiting the bridge, thus access lists can be applied to the bridge domain BVI loopback interface and/or the L3 hardware interface.

Bridge Example

This example will setup a bridge between GigabitEthernet3/0/0 and GigabitEthernet0/14/1, joining them into one network. Further, a loopback interface is used to allow TNSR to act as a gateway for clients on these bridged interfaces.

First, create the bridge with the desired set of options:

tnsr(config)# interface bridge domain 10
tnsr(config-bridge)# flood
tnsr(config-bridge)# uu-flood
tnsr(config-bridge)# forward
tnsr(config-bridge)# learn
tnsr(config-bridge)# exit

Next, add both interfaces to the bridge:

tnsr(config)# int GigabitEthernet3/0/0
tnsr(config-interface)# bridge domain 10
tnsr(config-interface)# enable
tnsr(config-interface)# exit
tnsr(config)# int GigabitEthernet0/14/1
tnsr(config-interface)# bridge domain 10
tnsr(config-interface)# enable
tnsr(config-interface)# exit
tnsr(config)# interface loopback bridgeloop
tnsr(config-loopback)# instance 1
tnsr(config-loopback)# exit
tnsr(config)# interface loop1
tnsr(config-interface)# ip address
tnsr(config-interface)# bridge domain 10 bvi
tnsr(config-interface)# enable
tnsr(config-interface)# exit

Bridge Status

To view the status of bridges, use the show interface bridge domain [<id>] command:

tnsr(config)# show interface bridge domain 10
Bridge Domain Id: 10
    flood: true
    uu-flood: true
    forward: true
    learn: true
    arp-term: false
    mac-age: 0
    BVI IF: loop1
    Domain Interface Members
        IF: GigabitEthernet0/14/1    SHG: 0
        IF: GigabitEthernet3/0/0    SHG: 0
        IF: local0    SHG: 0
        IF: loop1    SHG: 0
    ARP Table Entries

If the id value is omitted, TNSR will print the status of all bridges.