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.
Creating a Bridge¶
A bridge is created by the
interface bridge domain <bdi> command, available
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
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
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 identifier, used with VXLAN interfaces. This number must be non-zero and the same number must be used on each VXLAN tunnel added to a bridge domain. This prevents packets from looping back across VXLAN interfaces which are meshed between peers.
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.
This example will setup a bridge between
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
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 10.25.254.1/24 tnsr(config-interface)# bridge domain 10 bvi tnsr(config-interface)# enable tnsr(config-interface)# exit
To view the status of bridges, use the
show interface bridge domain [<id>]
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
id value is omitted, TNSR will print the status of all bridges.