Cisco Catalyst 8000V Edge Software Installation And Configuration Guide

PDF

Cisco Catalyst 8000V Edge Software Installation And Configuration Guide

Information about bridge domain interface

Updated: April 24, 2026

Want to summarize with AI?

Log in

Introduces bridge domain interface architecture, detailing restrictions, Ethernet virtual circuits, encapsulation, MAC address assignment, IP protocol support, forwarding mechanisms between Layer 2 and Layer 3, link states, interface statistics, and providing step-by-step configuration and verification instructions including virtual IP interface overview.

A bridge domain interface is a logical interface that

  • allows bidirectional flow of traffic between a Layer 2 bridged network and a Layer 3 routed network,

  • is identified by the same index as its associated bridge domain,

  • represents a Layer 2 broadcast domain through each bridge domain, and

  • can be associated only once per bridge domain, allowing just one bridge domain interface per domain.

Bridge domain interfaces support these features:

  • IPv4 Multicast

  • QoS marking and policing. Shaping and queuing are not supported

  • IPv4 VRF

  • IPv6 unicast forwarding

  • Dynamic routing such as BGP, OSPF, EIGRP, RIP, IS-IS, and STATIC

  • Hot Standby Router Protocol (HSRP)

  • Virtual Router Redundancy Protocol (VRRP) from IOS XE 3.8.0 onwards.

  • IP termination

  • Layer 3 VPN termination

  • Address Resolution Protocol (ARP), G-ARP, and P-ARP handling

  • MAC address assignment

Restrictions for bridge domain interfaces

These are restrictions for bridge domain interfaces

  • Only 4096 bridge domain interfaces are supported per system.

  • For a bridge domain interface, the maximum transmission unit (MTU) size can be configured between 1500 and 9216 bytes.

Unsupported Features

Bridge domain interfaces do not support these features:

  • PPP over Ethernet (PPPoE)

  • Bidirectional Forwarding Detection (BFD) protocol

  • QoS

  • Network-Based Application Recognition (NBAR) or Advanced Video Coding (AVC)

Ethernet virtual circuit overview

An Ethernet Virtual Circuit (EVC) is an end-to-end representation of a single instance of a Layer 2 service that

  • is offered by a provider and defines the service parameters,

  • consists of one or more Layer 2 interfaces called service instances within the Cisco EVC Framework,

  • instantiates a service instance on a specific router port, and

  • associates each service instance with a bridge domain based on configuration.

An incoming frame can be classified as a service instance based on these criteria:

  • Single 802.1Q VLAN tag, priority-tagged, or 802.1ad VLAN tag

  • Both QinQ (inner and outer) VLAN tags, or both 802.1ad S-VLAN and C-VLAN tags

  • Outer 802.1p CoS bits, inner 802.1p CoS bits, or both

  • Payload Ethernet type (IPv4, IPv6, PPPoE-all, PPPoE-discovery, and PPPoE-session)

Service instance also supports alternative mapping criteria:

  • Untagged—Maps to all frames lacking an 802.1Q or 802.1ad header

  • Default—Maps to all frames

Bridge domain interface encapsulation

Security Group classification includes both Source and Destination Group, which is specified by source SGT and DGT. SGT Based PBR feature provides the PBR route-map match clause for SGT/DGT based packet classification. SGT Based PBR feature supports configuration of an unlimited number of tags. Configure the tags according to the memory available on the platform.

An EVC provides the ability to employ different encapsulations on each Ethernet flow point (EFP) present in a bridge domain. A BDI egress point may not be aware of the encapsulation of an egress packet. The packet may have exited from one or more EFPs with different encapsulations.

Encapsulation in a bridge domain is a configuration method that dictates how traffic is tagged and untagged within the domain, depending on the encapsulation settings of its Ethernet Flow Points (EFPs).

  • If all EFPs have different encapsulations, the Bridge Domain Interface (BDI) must be untagged (using the no 802.1Q tag), and you must configure traffic encapsulation (popped or pushed) and rewriting at each EFP.

  • If all EFPs have the same encapsulation, configure the encapsulations directly on the BDI using the encapsulation command.

  • Enabling encapsulation at the BDI when EFPs have the same encapsulation ensures effective pushing or popping of tags. This eliminates the need to configure the rewrite command at the EFPs.

Assign a MAC address

Important information about assigning a MAC Address includes:

  • All bridge domain interfaces on Cisco Catalyst 8500 Series Edge Platforms share one MAC address. The first interface within a bridge domain receives a MAC address, and each additional bridge domain interface in the same domain uses that address.

  • You can configure a static MAC address on a bridge domain interface using the mac-address command.

Support for IP protocols

Bridge domain interfaces allow the Cisco 8500 Series Catalyst Edge Platform to function as a Layer 3 endpoint on a Layer 2 bridge domain for these IP-related protocols:

  • ARP

  • DHCP

  • HTTP

  • ICMP

  • NTP

  • RARP

  • SNMP

  • TCP

  • Telnet

  • TFTP

  • UDP

IP forward support

Bridge domain interface supports these IP forwarding features:

  • IPv4 input and output access control lists (ACL)

  • IPv4 input and output QoS policies. The operations supported for the input and output service policies on a bridge domain interface are:

    • Classification

    • Marking

    • Policing

  • IPv4 L3 VRFs

Packet forwarding

A bridge domain interface provides bridging and forwarding services between the Layer 2 and Layer 3 network infrastructure.

Layer 2 to Layer 3

During a packet flow from a Layer 2 network to a Layer 3 network, the packet or a copy of the packet is forwarded to the bridge domain interface in these cases.

  • If the destination MAC address matches the bridge domain interface MAC address, the packet is forwarded to the bridge domain interface.

  • If the destination MAC address is a multicast address, a copy of the packet is forwarded to the bridge domain interface.

Note

MAC address learning cannot not be performed on the bridge domain interface.

Layer 3 to Layer 2

When a packet arrives at a Layer 3 physical interface of a router, a route lookup action is performed. If the route lookup points to a bridge domain interface, the bridge domain interface adds layer 2 encapsulation and forwards the frame to the correct bridge domain.

During a Layer 2 lookup on a bridge domain to which the bridge domain interface belongs, the bridge domain forwards the packets to the correct service instance based on the destination MAC address.

Bridge domain interface acts as a routable IOS interface on Layer 3 and as a port on a bridge domain. Both bridge domain interfaces and bridge domains operate with individual administrative states.

Shutting down a bridge domain interface stops the Layer 3 data service, but does not override or impact the state of the associated bridge domain.

Shutting down a bridge domain has several impacts on its associated components

  • It stops Layer 2 forwarding across all associated members, including service instances and bridge domain interfaces.

  • The operational state of a bridge domain is influenced by its associated service instances.

  • A bridge domain interface can only become operational if at least one of its associated service instances is active.

Because a bridge domain interface is an internal interface, the operational state of bridge domain interface does not affect the bridge domain operational state.

Bridge domain interface-initial state

The initial administrative state of a BDI depends on how the BDI is created. When you create a BDI at boot time in the startup configuration, the default administrative state for the BDI is up. It will remain in this state unless the startup configuration includes the shutdown command.

This behavior is consistent with all the other interfaces. When you create a BDI dynamically at command prompt, the default administrative state is down.

A BDI maintains a link state that comprises of three states: administratively down, operationally down, and up. The link state of a BDI is derived from two independent inputs: the BDI administrative state set by the corresponding users and the fault indication state from the lower levels of the interface states. It defines a BDI link state based on the state of the two inputs.

Fault Indication State BDI Admin State Resulting BDI Link State
No faults asserted Shutdown Admin-down
No faults asserted No Shutdown Up
At least one fault Shutdown Admin-down
At least one fault No Shutdown Operationally Down

Bridge domain interface statistics

For virtual interfaces, such as the bridge domain interface, protocol counters are periodically queried from the QFP.

When packets flow from a Layer 2 bridge domain network to a Layer 3 routing network through the bridge domain interface, the packets are treated as bridge domain interface input packets and bytes.

When packets arrive at a Layer 3 interface and are forwarded through the bridge domain interface to a Layer 2 bridge domain, the packets are treated as output packets and bytes, and the counters are updated accordingly.

A BDI maintains a standard set of Layer 3 packet counters, as is the case with all Cisco IOS interfaces.

The convention of the counters is relative to the Layer 3 cloud. For example, input refers to the traffic entry to the Layer 3 cloud from the Layer 2 BD, while output refers to the traffic exit from the Layer 3 cloud to the Layer 2 BD.

Use the show interfaces accounting command to display the statistics for the BDI status. Use the show interface <if-name> command to display the overall count of the packets and bytes that are transmitted and received.

Create or delete a bridge domain interface

When you define an interface or subinterface for a Cisco IOS router, you name it and specify how it is assigned an IP address. You can create a bridge domain interface before adding a bridge domain to the system. The new bridge domain interface is activated after the associated bridge domain is configured.

When you create the bridge domain interface and the bridge domain, the system maintains the required associations for mapping the bridge domain-bridge domain interface pair.

The system maintains the mapping between bridge domains and bridge domain interfaces. The bridge domain interface uses the index of the associated bridge domain to show the association.

Note
When a bridge domain interface is created, a bridge domain is automatically created.

Bridge domain virtual IP interface

The Virtual IP Interface (VIF) feature helps to associate multiple BDI interfaces with a BD instance. The BD-VIF interface inherits all the existing L3 features of IOS logical IP interface.

The Virtual IP Interface (VIF) feature has these limitations:

  • BD-VIF interface does not support IP multicast.

  • The number of BD-VIF interfaces with automatically generated MAC addresses varies depending on the platform.

  • BD-VIF Interface does not support MPLS.

  • The maximum number of BD-VIF interfaces per bridge-domain and the total number of BD-VIF interface for per system vary based on the type of platforms.

Note

You must configure every BD-VIF interface with a unique MAC address and it should belong to a different VRF.

The maximum number of BD-VIF supported on Cisco Catalyst 8500 Series Edge Platforms are:

  • C8500-12X4QC supports a maximum of 100 BD-VIF interfaces for a bridge domain.

  • C8500-12X supports a maximum of 16 BD-VIFs for a bridge domain.

Note

From Cisco IOS XE 17.7 release, BD-VIF supports Flexible Netflow (FNF).

How to configure a bridge domain interface

To configure a bridge domain interface, perform the these steps:

Procedure

  1. enable

    Example:

     Router> enable

    Enables privileged EXEC mode. Enter your password if prompted.

  2. configure terminal

    Example:

    Router# configure terminal

    Enters global configuration mode.

  3. interface BDI {interfacenumber}

    Example:

    Router(config-if)# interface BDI3

    Specifies a bridge domain interface on a Cisco 8500 Series Catalyst Edge Platform.

  4. encapsulation encapsulationdot1q<first-tag>[second-dot1q<second-tag>]

    Example:

    Router(config-if)# encapsulation dot1Q 1 second-dot1q 2

    Defines the encapsulation type.

    The example shows how to define dot1q as the encapsulation type.

  5. Do one of these steps:

    Example:

    ipaddress ip-addressmask

    Example:

    ipv6address {X:X:X:X::X link-local |X:X:X:X::X/prefix[ anycast | eui-64 ]| autoconfig [ default ]}

    Example:

    Router(config-if)# ip address 2.2.2.1 255.255.255.0

    Example:

    Router(config-if)# ipv6 address AB01:CD1:123:C::/64 eui-64

    Specifies either the IPv4 or IPv6 address for the bridge domain interface.

  6. match security-group destination tag sgt-number

    Example:

    Router(config-route-map)# match security-group destination tag 150

    Configures the value for security-group destination security tag.

  7. mac address {mac-address}

    Example:

    Router(config-if)# mac-address 1.1.3

    Specifies the MAC address for the bridge domain interface.

  8. no shut

    Example:

    Router(config-if)# no shut

    Enables the bridge domain interface on the Cisco 8500 Series Catalyst Edge Platform.

  9. shut

    Example:

    Router(config-if)# shut

    Disables the bridge domain interface on the Cisco 8500 Series Catalyst Edge Platform.

Bridge domain interface is configured.

Display and verify bridge domain interface configuration

To display and verify bridge domain interface configuration, follow these steps.

Procedure

  1. enable

    Example:

    Router> enable

    Enables privileged EXEC mode. Enter your password if prompted.

  2. show interfaces bdi

    Example:

    Router#showinterfacesBDI3

    Displays the configuration summary of the corresponding BDI.

  3. show platform software interface fp active name

    Example:

    Router# showplatformsoftwareinterfacefpactivenameBDI4

    Displays the bridge domain interface configuration in a Forwarding Processor.

  4. show platform hardware qfp active interface if-name

    Example:

    Router# showplatformhardwareqfpactiveinterfaceif-nameBDI4

    Displays the bridge domain interface configuration in a data path.

  5. debug platform hardware qfp feature

    Example:

    Router# debugplatformhardwareqfpactivefeaturel2bdclientall

    The selected CPP L2BD Client debugging is on.

  6. platform trace runtime process forwarding-manager module

    Example:

    Router(config)#platformtraceruntimeslotF0bay0processforwarding-managermoduleinterfaceslevelinfo

    Enables the Forwarding Manager Route Processor and Embedded Service Processor trace messages for the Forwarding Manager process.

  7. platform trace boottimeprocess forwarding-manager module interfaces

    Example:

    Router(config)#platformtraceboottimeslotR0bay1processforwarding-managerforwarding-managerlevelmax

    Enables the Forwarding Manager Route Processor and Embedded Service Processor trace messages for the Route Processor Forwarding Manager process during bootup.

Bridge domain interface configuration is verified.

What to do next

For additional information on the commands and the options available with each command, see the Cisco IOS Configuration Fundamentals Command Reference Guide located at:

{start hypertext}http://www.cisco.com/en/US/docs/ios/fundamentals/command/reference/cf_book.html{end hypertext}